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

["Stephane Beaulieu" <stephane@cisco.com>]

> 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).
>
> Does anyone have any examples of security failures that resulted from
people
> using some previously untested combination of algorithms? Also, what type
of
> bug was it? (If it's just a buffer overflow, then I think that's just
> symptomatic of bad coding overall.)

I personally don't buy the complexity argument (but then again... it appears
I never do :).  I think the desire to reduce the permutations stems more
from a testing (box (and not module) testing that is).  However, I think as
long as we focus on testing the MUSTS (AES, 3DES, SHA, MD5), then the
testing matrix becomes much smaller.  Even more so, if you remove AH.

Regardless of how SOI negotiates the algorithms, they'll still be
implemented the same modularity they have today (at least hopefully).  After
all, a good implementor knows that in order to build a complex system you're
better off to design small abstract modules that are easy to test
individually rather than the large
AH-MD5_ESP-3DES-SHA1_IPCOMP-LZS_TRANSPORT_MODE.c module.

Whether we should negotiate them as modules, or suites is a different issue,
but modularity is always easier to build on....



>
> 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: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent
> > Sent: Monday, March 25, 2002 11:08 AM
> > To: andrew.krywaniuk@alcatel.com
> > Cc: ipsec@lists.tislabs.com
> > Subject: RE: pre-shared key v RSA encryption or RSA signature
> > authentication modes
> >
> >
> > At 12:00 PM -0500 3/24/02, Andrew Krywaniuk wrote:
> > >Ask a politically incorrect question like that on a list
> > like this and you
> > >are bound to get a lot of FUD-type replies. Of course PK
> > crypto has the
> > >advantage of scalability, but that's not the question you
> > asked. Some people
> > >replied already, but here's a more presise response.
> > >
> > >The fact is, you can get any arbitrary strength you want
> > with either asymm
> > >or symm algorithms by increasing the keylength. If you want
> > a basis for
> > >comparing their strengths, you could compare the speed of
> > the algorithms for
> > >equivalent crypto strength (which is not as silly as it
> > seems, since you are
> > >always trading off crypto strength for speed). In that case,
> > you could say
> > >that pre-shared secrets are stronger than public keys. (I
> > don't know of any
> > >fundamental difference between the strength of PK encryption and PK
> > >signatures for authentication. )
> > >
> > >Also, pre-shared secrets have an additional advantage for
> > authentication,
> > >which is that you cannot mount a pure offline attack against
> > them. In order
> > >to get some data for a brute force attack, you must first
> > impersonate the
> > >responder in an active attack against the initiator. With
> > public keys, you
> > >can conduct a purely offline attack. Of course, the strength of the
> > >authentication will still be limited by the amount of
> > entropy in the secret.
> > >
> > >Andrew
> >
> > I'm glad you mentioned what I consider to be a significant downside
> > of pre-shared secrets, although we come to very different
> > conclusions.  It is not too hard to imagine an attack in which the
> > initiator connects to the wrong address, e.g., via some form of DNS
> > attack, and the fake responder collects the initiator's secret, then
> > drops the connection. This seems like such a serious concern that it
> > argues very strongly against pre-shared secrets vs. public keys. Note
> > that using public keys. e.g., in self-signed certs, does not suffer
> > from this problem.
> >
> > Steve
> >
>