If it's just HMAC with K = h(m) then it's currently (or just recently) been discussed on cfrg: http://www.irtf.org/cfrg/, starting here: http://www1.ietf.org/mail-archive/web/cfrg/current/msg00708.html.
-- Michael On Mon, 21 Mar 2005 11:56:44 +0000, Ben Laurie <[EMAIL PROTECTED]> wrote: > It was suggested at the SAAG meeting at the Minneapolis IETF that a way > to deal with weakness in hash functions was to create a new hash > function from the old like so: > > H'(x)=Random || H(Random || x) > > However, this allows an attacker to play with Random (the advice I've > seen is that if one is going to use an IV with a hash function, then one > should transfer the IV with integrity checks to deny attackers this > freedom). > > Another objection is that this construction changes the API at the > sender end, which could lead to a great deal of complexity when the use > of the hash API is deeply embedded. > > A third is that the length of the hash is changed, which could break > existing protocols. > > Musing on these points, I wondered about the construction: > > H'(x)=H(H(x) || H(H(x) || x)) > > which doesn't allow an attacker any choice, doesn't change APIs and > doesn't change the length of the hash. Does this have any merit? Note > that this is essentially an HMAC where the key is H(x). I omitted the > padding because it seems to me that this actually makes HMAC weaker > against the current attacks. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]