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, though a Google search found it in http://www.cs.ucdavis.edu/~rogaway/ocb/xcbc.pdf which appears to be the complete version of the same presentation. In any case, I don't see any mention of extension forgery attacks in either the portion you quoted nor elsewhere in the paper. There isn't reason to mention it since 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 and the use of K2 and K3 that would only be true when x and y are the same length or both have lengths that are multiples of the cipher block size. > Given that RMAC's salt should be _optional_ [...] > so they can match the defense to that which makes sense > in the context they are deploying it. I agree with your conclusion, but I don't see how anything Rogaway says about XCBC has anything to do with it. In the case of RMAC, if the parameter sets were chosen to make the work factors comparable on the two attacks, I think it is making the mistake of comparing apples and oranges: In the exhaustive key search attack, the attackers captures one message and the work factor is multiplied times the time it takes to try a key on their own computers. In the extension forgery attack the work factor is multiplied by the time between captured messages. The latter is somewhat under the control of the person who is using RMAC. There is no reason to require that they have similar work factors if the scale is much different. It was just my supposition that equality of the work factors was the motivation behind selecting those parameter sets. I would like to see another reason or a pointer to an explanation by the author if there is one. -- sidney --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
