Re: 1,342,532,544 combinations of algorithms

[Paul Koning <pkoning@equallogic.com>]

Excerpt of message (sent 25 March 2002) by Andrew Krywaniuk:
> At the IETF and on this list, I have heard security experts complain about
> how many possible combinations of algorithms there are. This has never
> seemed like a big concern to me because most people would not implement
> every permutation of algorithms in a separate file (I say most people
> because I know at least one person who did, but they have been duly
> chastised).

I guess this is surprising to some, but there are legitimate reasons
for implementing each permutation separately. 

If you are doing a very highly optimized software implementation, one
thing you'd want to do is make only a single pass over the buffer.
The other thing you may want to do is to avoid function call overhead.

If you combine these two goals, you end up with code that looks like
this:
	for (;;)
	{
		// fetch some more bytes
		// feed them to the encryption transform
		// feed them to the authentication transform
	}
and you have one of these for each encrypt/auth transform pair that
you support.  For sensible implementations, that number isn't very
large (null/DES/3DES times MD5/SHA1).  If you started adding lots of
other transforms, this would definitely get ugly.

And yes, I realize that the function call overhead may be trivial
compared to the overhead of DES, so arguably this coding style is
taking things too far...

       paul