Subject: [Hipsec] Null IPsec

From: [email-masked] (Gonzalo Camarillo)
Date: Wed Mar 9 18:21:01 2005

Folks,

during today's meeting, the chairs got an action point to talk to the 
security ADs about the possibility of having a MUST implement IPsec with 
null encryption and/or null integrity protection.

I talked to Russ, and his gut reaction was that null encryption with 
integrity may be fine, but he would need to see the use case people have 
in mind before accepting null encryption and null integrity.

Gonzalo

---

From: [email-masked] (Robert Moskowitz)
Date: Thu Mar 10 10:47:01 2005

Most of the work on hash truncation came from Hugo's work back in '95.  So=
=20
I went to the source.

I am asking him about the pre-image attack (find (x,y) where H9x) =3D H(y)).

But I am not sure the security risk of the pre-image attack.  The only case=
=20
I can see is Malice got hired to create a HI for a public server.  But=20
Malice creates a HI with a collision and walks off with the collision and=20
sets up his own version of this server.

Date: Thu, 10 Mar 2005 01:26:16 +0200 (IST)
From: Hugo Krawczyk <[email-masked]>
To: Robert Moskowitz <[email-masked]>
Subject: Re: Truncating Hashes in this new world weakened hashes
In-Reply-To: <6.2.1.2.2.20050309141335.038a1b40@localhost>
Message-ID:=20
<[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=3DUS-ASCII

I am not familiar with HIP. If the application uses the one-way
(or second pre-image) property of SHA-1
(namely, given a pair (x,H(x)) find y such that H(x)=3DH(y)),
then SHA-1 is still secure for all we know even if you truncate the output
moderately (say to 96 or more bits). In particular this is the case if in
the application the attacker does not have control of the public key
(but rather needs to find another public key that hashes to the same
value).

Assuming that indeed the issue in your application is one-wayness and not
collisions then I do not see a reason to move immediately to SHA-256.
It would be better to see how well the available techniques can be
stretched to work against the one-wayness of SHA-1. Indeed, breaking
one-wayness is a much harder
problem with more safety margins since the basic brute force attack takes
2^160 rather than 2^80 (even if you truncate to 128 bits the brute
force attack takes 2^128) and therefore a new attack will have to be
about 2^50 times faster to be of any practical value.

Hugo

On Wed, 9 Mar 2005, Robert Moskowitz wrote:

 > Hugo,
 >
 > I greatly need some supporting information on the strengths of truncated
 > hashes.
 >
 > This question is coming for the work in HIP
 >
 > www.ietf.org/internet-drafts/draft-ietf-hip-arch-02.txt
 > www.ietf.org/internet-drafts/draft-ietf-hip-base-02.txt
 >
 > The Host Identity is a Public Key, (RSA or DSA)
 >
 > But you don't want to use a variable length field in the ways needed in
 > HIP, thus we truncate a hash of the public key at 126 bits.Currently
 > SHA-1 is used for the hashing.And there is concern about the long term
 > use of SHA-1 here.
 >
 > But since this is a truncation of a hash, some wonder if going to SHA-256
 > will actually be more secure.
 >
 > It seems to me that the attacks are to create hash collisions, not
 > truncated hash collisions.Thus it is not a  matter of the length of the
 > truncation (within reason) as it is the collisions with the hash itself.
 >
 > Can you point me to any information on this?
 >
 > Robert Moskowitz

"Perfection is achieved not when there is nothing more to
add, but rather, when there is nothing left to take away"

Antoine de Saint-Exup=E9ry (1900-1944)