Encryption done the Perfectly Wrong Way(tm)

[prev] [thread] [next] [lurker] [Date index for 2006/08/19]

From: Peter Pentchev
Subject: Encryption done the Perfectly Wrong Way(tm)
Date: 21:20 on 19 Aug 2006
--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