comparing RMAC to AES+CBC-MAC or XCBC (Re: Why is RMAC resistant to birthday attacks?)

[Adam Back]

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 majordomo at wasabisystems.com