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

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> 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.

Yes, that is a legitimate reason for combining the encrypt + auth operations
into a single file. But obviously, you would want to have a very limited
number of these, and any other permutation of algorithms would hit the
fall-though case. (In the case I mentioned before, the programmer decided to
implement *EVERY* permutation of algorithms/modes as a separate file.)

But I think the motivation of the 1,342,532,544 combinations of algorithms
complaint is that many of these combinations will never be tested. If you
implement 4 specific combinations of algorithms as optimized cases then
presumably you will test these permutations very thoroughly. But how many of
the other 1,342,532,540 combinations do you have to test in order to be
confident that the generic case is working correctly?

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: Paul Koning [mailto:pkoning@equallogic.com]
> Sent: Monday, March 25, 2002 5:47 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: 1,342,532,544 combinations of algorithms
>
>
> 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
>