[prev] [thread] [next] [lurker] [Date index for 2006/08/19]
--9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [okay, apologies in advance - or, come to think of it, I'm here, so no apologies are needed; anyway, this will not be a real software hate, more like a software design hate; still, I think it counts as mind-software hate, so there] Dear Wossname[0], For about four months now, you've been subjecting me and the company I work for to a kind of Chinese water torture - first, telling us that the next version of your system[1] will require some sort of user authentication[2], and then dropping tiny pieces of information, all different, all ever so slightly incompatible with each other, at the maddening rate of about once every lunar month. So we will need to supply a plain-text username and an encrypted password for each query to your product[2]. Now. Let me tell you some things about the way I understand cryptography[3]. 1. Picking an encryption algorithm should not take three weeks. 2. When an algorithm is finally chosen, telling us "use 3DES" would suffice; sending us a three-page listing of Visual Basic code *without* actually mentioning the algorithm's name - except in two lines of code instantiating a CryptoAPI object - is... a bit verbose. 3. Picking an encryption key and an IV should be left to the customers who will actually use the product, *not* referred back to the software vendor. 4. Picking an encryption key and an IV should not take three weeks. 5. Telling us that the encryption key and the IV will not be needed, since you're changing the algorithm, two weeks before our deadline, is a bit... unexpected[4]. 6. Sending us a two-page document (the first page describing the full data path and exchange procedures, the second page describing the actual encryption algorithm) might have been a Good Thing(tm), were it not for the minor mishap of misspelling "algorithm" as "logarithm" in all three places it's mentioned. 7.... Okay. I am at a bit of a loss here. A loss for words. Although a full day - and a half - has passed since we received said two-page document, I still have not completely come to terms with my inner self as to how I *ought* to feel about it, and how I *do* feel about it. Suffice it to say that, after working on this project for an year and a half now, I honestly, sincerely thought that no communication from The Other Side could actually surprise me any more. This document managed to surprise, nay, confuzzle, nay, completely befuddle me for all of two minutes; then I started laughing hysterically, and sometimes I still do. So... let's try this again. 7.... Nope. More hysterical laughter. Just one last time... 7. All the communication with your software so far has involved specifying a character set. Thus, you understand character sets - or, well, or at least you are barely aware of their existence. Also, you understand character set conversion - or, well, or at least you are barely aware of its existence, too. So... if you want the password - only the password, not the username - to be represented in EBCDIC[5], you might have put more than one single passing mention in said document. But hold on, that's not really the hysterical laughter-inducing part. 8. A Caesar substitution does not count as industrial-strength encryption in my book. Yes. Ohhhhhh yes. Ahem. Yep. I know it's hard for you to believe what I just said, but... Taking the numeric code (in EBCDIC, as previously mentioned) of a letter, subtracting it from a constant number, then subtracting the result from *another* constant number, is indeed equivalent to adding a third constant number to the original numeric code of the letter. So when you say we have to do this for each particular letter of the password, you are effectively describing a Caesar substitution. Okay, so it's in EBCDIC; okay, so the offset puts the result well outside of the normal alphanumeric range in EBCDIC; okay, so the result will not look like letters or numbers at all. WHAT THE HELL DOES IT MATTER?! It's still a Caesar subtitution. It's still security through obscurity. It's still not suited AT ALL for this particular software system! And... yes. I'll still do it. I'll write the code, I'll integrate it into our part of the system, and I'll deliver it on time. I'll do this with one, and only one, purpose in mind. To get our part of the system deployed at our customer's site on time, so then you can first wallow, then drown in the slew of bug reports that will first come to us, then be analyzed, and finally duly reflected to land on your desk. I think I need a drink now. Over and out[6], Peter[7] [0] I'm not actually sure I even *want* to know your name. Bearing in mind the existence of certain books and rituals, the world might even be a much safer place for you if were I were to never, ever, ever learn it. For the present, it is enough for me that you think you write software and that you have managed to drag enough people down into this delusion. [1] A big, steamin' piece of s... s... software, that a client of ours has at the core of their services, and that I and a couple of cow-orkers have to write an interface module for. Come to think of it, I may have mentioned it before in this place - and when I may have mentioned it, I may have concluded my mentioning with a hope never to hear about it again. Unfortunately, things didn't quite turn out that way. [2] "Each message will contain a plain-text username and an encrypted password. Well, okay, not at once - there will be a transition period when some messages will work the old way, without the username and password. Yep, only some messages - there are some important ones that will require authentication at once. Yes, this is one of them. No, not this one. No, not this one either. No, we cannot give you the full list yet. Oh, well, some messages will not require authentication even after the full deployment. No, not this one. No, not this one either. Yes, of *course* that one will work without authentication. No, we cannot give you *that* full list either. What? Of *course* we know which messages will require authentication and which ones won't - we just can't tell you yet. Yep, that's our version and we're stickin' to it." [3] Not all that well, of course. I think most people here will wholeheartedly agree that teaching does not necessarily imply understanding, especially so in Academentia, so my being on a team teaching a university-level network and software security course would be completely irrelevant. [4] Well, okay, it *should have been* unexpected. In this case... to be honest, I wasn't a bit surprised. The surprise came later - read on. [5] Aye, mates, you heard that right! Yep. I've been aware of EBCDIC for the past fifteen to seventeen years. I've been aware of it pretty much in the same way I've been aware of the Enigma and Bombe encryption gadgets - in a fun piece of trivia sort of way - I've known what it was, I've known where and when it was used first, I've known where and when it was widespread, I've had at my disposal conversion tools that I could use any time I had a couple of minutes with nothing to do and, just for the fun of it, I could convert a piece of text from ASCII to EBCDIC and back, just to see what comes out... But I've never - never - NEVER even imagined that I could ever actually *come across* it in any kind of Real Life(tm) and Real Job(tm). Oh, the sweet delusions of youth. [6] Normally I conclude my e-mail communication with a "G'luck", but in this particular case... [7] The careful reader might note that I've taken the time to edit my work e-mail address out of this e-mail's signature, just to state even more clearly that this is a purely personal opinion and in no way affiliated with any legal or physical entity except for the dozen or so selves dancing around inside my mind. --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE53Kc7Ri2jRYZRVMRAmETAJ4jgFqaImJPXq4q++rwN3yvCS8u1wCgif+X UmxHtsAOGP7kyV8pxlp6JyY= =N131 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--
Generated at 23:01 on 22 Aug 2006 by mariachi 0.52