OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Crypto Archives: Re: Testvectors

Re: Testvectors

Marcus Watts (mdwumich.edu)
Fri, 03 Sep 1999 17:54:47 -0400

> Message-ID: <37D0351C.FEF34FEt-online.de>
> Date: Fri, 03 Sep 1999 22:52:44 +0200
> X-Mailer: Mozilla 4.08 [de]C-DT (Win98; I)
> MIME-Version: 1.0
> To: Bill Sommerfeld <sommerfeldorchard.arlington.ma.us>
> CC: iangsystemics.com, coderpunkstoad.com
> Subject: Re: Testvectors
> References: <199909032024.UAA22524orchard.arlington.ma.us>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Sender: 320032439720-0001t-online.de
> From: mok-kong.shent-online.de (Mok-Kong Shen)
> Sender: owner-coderpunkstoad.com
> Precedence: bulk
>
> Bill Sommerfeld schrieb:
> >
>
> > My ~15 years of experience as a programmer and software engineer has
> > taught me that there's no such thing as a programming task which is
> > too simple to screw up.
>
> Do you think that simply piping the output of one unit into another
> can go wrong, assuming an amount of experience equivalent to that
> of yours? (If yes, no program can be trusted at all.) The flow diagram
> of the original version of 3DES is nothing but that piping, if I don't
> err.
>
> M. K. Shen
>

Ok, here are some of the ways you could screw this up:

[1] byte ordering of the input.
[2] byte ordering of the key.
[3] which key is used in what order.
[4] passing the bits wrong between stage 1 and 2.
[5] passing the bits wrong between stage 2 and 3.
[6] some versions of 3des don't do the IP/FP transformations
        between the stages, because they're redundant.
        So, botching the ip/fp interstage optimization.
[7] byte ordering of the output.
[8] getting confused because your machine is little-endian (or
        big endian), and you're thinking in big-endian (or
        little endian) byte ordering.
[9] some versions of 3des uses 2 keys, some versions use 3 keys.
        So, using the wrong number of keys.
[10] if using 64-bit registers to hold intermediate results,
        word ordering of the input, key, or output.
[11] other program glitches, such as incorrectly declared or
        sized intermediate storage, swapping input & output,
        "off by 1" errors, typos, and so forth.
[12] array of arrays confusion. some des implementations use arrays to
        pass parameters around; and an array of arrays can introduce
        new orders of type complexity and additional opportunities
        to pass the wrong value, such as the wrong key schedule,
        intermediate key, or data result. This gets particularly
        complicated with formal parameters.

So, there are a lot of ways to botch things in going from the nice
little arrows printed in the book, to a real live implementation that
interoperates with anyone else's implementation.

If you're using CBC, things get even more complicated. I believe
there's inner mode 3des, and outer mode 3des, and one is much better
than the other, but I forget which is which. If I expect my 3des cbc
implementation to interoperate with someone else's, getting confused on
inner vs. outer is an obvious way for things to break. Since there's
lot of data flowing all over the place for this one, there are lots of
othe additional opportunities for things to go wrong.

There is also DEAL, which is yet another variation of 3des, which is
supposedly better, but introduces the complexity of using 6 different
des keys to to encrypt 128 bites at a time. On the bright side of
things, it's easy to get test vectors for DEAL.

Test vectors make this all much more straight forward. Sure, with
sufficiently good documentation, and proper attention, you *ought* to
get the same results every time. But if you get interrupted for any
reason, or are fuzzy for any reason, all bets are off. Ie, any phone
call, or, a hangover, a looming cold, a sudden irresistable urge to eat
food or sleep (because you haven't done one in the past 4 hours, or the
other in the past 12 hours), and you have the potential for a bug. In
the real world, even if you work nights, plan all work into 4 hour
chunks in advance, and make it a practice to snarl at everyone who
calls up for any reason whatsoever, perfection is still mighty hard to
come by. So, you program defensively -- and because of the nature of
cryptography (if anything goes wrong, you get instant gibberish), you
can't be too careful. One of the most important differences between a
bad programmer and a good programmer is the good programmer makes more
mistakes--he's just better at catching them.

If all goes well, you run through the test vectors, everything works,
you pat yourself on the back and go on to the next thing. If something
goes wrong, you start wishing you had more intermediate vectors, you
find an implementation that you know does work, and you start stepping
through both and examining intermediate results to find out what went
wrong. If you're lucky, it will be something obvious, and not
something annoying like a compiler glitch (for some reason, compiler
bugs are particularly fond of mangling encryption code.)

                                        -Marcus Watts
                                        UM ITD PD&D Umich Systems Group

This archive was generated by hypermail 2.0b3 on Fri Sep 03 1999 - 19:28:55 CDT