[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Safety of pre-shared keys? (Re: Reliable delete notifies)



I'm not convinced of this at all.

There are many ways to verify that the correct key has been transferred - an
attacker would have to defeat them all.  Confidentiality is muh more
fragile.

Chris

> The authenticity requirement is always equally or more 
> difficult to satisfy
> than the confidentiality requirement so the point is moot.
> 
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
> 
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Chris Trobridge
> > Sent: Tuesday, October 24, 2000 12:33 PM
> > To: ipsec
> > Subject: RE: Safety of pre-shared keys? (Re: Reliable 
> delete notifies)
> >
> >
> > Isn't the biggest difference that whilst you need to ensure
> > that the peer
> > receives the correct self-signed public key out-of-band 
> (authenticity
> > requirement), if a secret key is used then there is an additional
> > confidentiality requirement.
> >
> > A self-signed certicate also includes an implicit integrity
> > check which is
> > also important.
> >
> > This all means that handling of self-signed certificates is 
> much less
> > onerous than pre-shared secert keys.
> >
> > Chris
> >
> > > Note that the vulnerabilities of pre-shared key that you refer to
> > > only apply to the case of a WEAK KEY (such as a
> > password-derived key).
> > > It says nothing about the security of the pre-shared mode (main
> > > or agressive) when using a strong key.
> > > In such a case there is no security problem!
> > > (There is always a security problem if you do not choose your keys
> > > correctly or you do not know how to manage them securely).
> > >
> > > In any case preshared mode (main or aggressive) was NOT
> > designed to be
> > > used with passwords. A password-based protocol needs a
> > > specialized design
> > > (either a new mode for IKE or the proposals of ipsra).
> > >
> > > Hugo
> >
>