Adam Back [EMAIL PROTECTED] wrote:
See for example Rogaway's arguments about limited value of
defending against extension forgery attacks in XCBC:
[... quote snipped ...]
http://csrc.nist.gov/encryption/modes/workshop2/presentations/xcbc.pdf
This doesn't contain the paragraph that you quoted,
On Thu, Oct 24, 2002 at 02:08:11AM -0700, Sidney Markowitz wrote:
[...] XCBC should be inherently resistant to extension forgery
attacks. The attack requires that the MAC have the property that
MAC(x) == MAC(y) implies that MAC(x||z) == MAC(y||z). In the case of
XCBC, because of the padding
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
But the salt doesn't increase the MAC length. It just frustrates
attempts to collect message+MAC pairs to find a collision. Think of
it like a salt on unix passwords. You can still brute force one
particular target in the same time, but the salt reduces your scope
for pre-computation.
There is
