Re: AES-GMAC as a hash

2009-09-04 Thread Hal Finney
Darren J Moffat darren.mof...@sun.com asks:
 Ignoring performance for now what is the consensus on the suitabilty of 
 using AES-GMAC not as MAC but as a hash ?

 Would it be safe ?

 The key input to AES-GMAC would be something well known to the data 
 and/or software.

No, I don't think this would work. In general, giving a MAC a fixed key
cannot be expected to produce a good hash. With AES-GMAC in particular,
it is unusual in that it has a third input (besides key and data to MAC),
an IV, which makes your well-known-key strategy problematic. And even as a
MAC, it is very important that a given key/IV pair never be reused. Fixing
a value for the key and perhaps IV would defeat this provision.

But even ignoring all that, GMAC amounts to a linear combination of
the text blocks - they are the coefficients of a polynomial. The reason
you can get away with it in GMAC is because the polynomial variable is
secret, it is based on the key. So you don't know how things are being
combined. But with a known key and IV, there would be no security at all.
It would be linear like a CRC.

Hal Finney

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: AES-GMAC as a hash

2009-09-04 Thread Darren J Moffat

Hal Finney wrote:

Darren J Moffat darren.mof...@sun.com asks:
Ignoring performance for now what is the consensus on the suitabilty of 
using AES-GMAC not as MAC but as a hash ?


Would it be safe ?

The key input to AES-GMAC would be something well known to the data 
and/or software.


No, I don't think this would work. In general, giving a MAC a fixed key
cannot be expected to produce a good hash. With AES-GMAC in particular,
it is unusual in that it has a third input (besides key and data to MAC),
an IV, which makes your well-known-key strategy problematic. And even as a
MAC, it is very important that a given key/IV pair never be reused. Fixing
a value for the key and perhaps IV would defeat this provision.

But even ignoring all that, GMAC amounts to a linear combination of
the text blocks - they are the coefficients of a polynomial. The reason
you can get away with it in GMAC is because the polynomial variable is
secret, it is based on the key. So you don't know how things are being
combined. But with a known key and IV, there would be no security at all.
It would be linear like a CRC.


Thanks, that is pretty much what I suspected would be the answer but you 
have more detail than I could muster in my head at a first pass on this.


Thanks.

--
Darren J Moffat

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: AES-GMAC as a hash

2009-09-04 Thread Matt Ball
On Thu, Aug 27, 2009 at 8:45 AM, Darren J Moffat wrote:

 Ignoring performance for now what is the consensus on the suitabilty of using 
 AES-GMAC not as MAC but as a hash ?

 Would it be safe ?

 The key input to AES-GMAC would be something well known to the data and/or 
 software.

 The only reason I'm asking is assuming it can be made to perform on some 
 classes of machine better than or close to SHA256 if it would be worth 
 considering as an available alternate now until SHA-3 is choosen.

In the 2005 Security in Storage Workshop (see
http://ieeeia.org/sisw/2005/), David McGrew proposed using GMAC to
protect large dynamic data sets, such a random access memory (RAM)
(see http://ieeeia.org/sisw/2005/PreProceedings/10.pdf).  The general
idea is to use the linear characteristics of GMAC to dynamically
update the MAC when updating a memory address.  If your use-case is
similar to this approach, then it would be possible to securely use
GMAC.

However, there are many caveats when using GMAC, so it's vitally
important to understand all the constraints.

Cheers,

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com