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
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 quot
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 m
Adam Back <[EMAIL PROTECTED]> wrote:
> But the salt doesn't increase the MAC length. It just frustrates
> attempts to collect message+MAC pairs to find a collision.
[...]
> There is still probability 1/2^m of finding a collision given two
> random messages, whether the salt has size 0 or 64.
No,
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