The problem with this one-size fits all approach is that for most applications given the key size of AES, the extension forgery is impractical. It would be more flexible to specify RMAC as having an optional salt, with the size determined by the implementer as appropriate for their scenario.
So mostly no salt as the number of messages required under the same key to stand a non-negligible chance of finding a collision would be greater than that possibly exchanged in the life-time of the MAC key. For longer lived key scenarios, the size of the salt would be chosen to address the problem. See for example Rogaway's arguments about limited value of defending against extension forgery attacks in XCBC: "No Added Resistance to Key-Search Attacks. While other CBC MAC variants use additional keys to improve resistance to key-search attacks, what is presented here does not. One can perform an exhaustive key-search on the MAC presented just as efficiently as on the underlying AES primitive. But this concern, quite appropriate for DES, would seem to be moot for AES." http://csrc.nist.gov/encryption/modes/workshop2/presentations/xcbc.pdf Given that RMAC's salt should be _optional_ on all MAC output sizes (contrary to the parameter sets given in the RMAC draft), and the choice of salt size should be up to the developer -- for example sizes ranging from 0 to 128 bits in increments of 8 bits, so they can match the defense to that which makes sense in the context they are deploying it. Adam On Tue, Oct 22, 2002 at 04:07:53PM -0700, Sidney Markowitz wrote: > > The choice of parameter sets is a bit odd. > > I think that they are chosen to make the work factors for General > Forgery and Extension Forgery attacks about the same in any one > parameter set. It would not make sense to have a parameter set which > was a lot weaker to one of the attacks than to the other. Look at > Table 2 to see that is so. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]