On Mon, Apr 29, 2002 at 11:58:46AM +1200, Peter Gutmann wrote: > Adam Back <[EMAIL PROTECTED]> writes: > >| [RFC3211 mode] > > > > are you sure it's not vulnerable to splicing attacks (swapping > > ciphertext blocks around to get a partial plaintext change which > > recovers after a block or two)? CBC mode has this property, and > > this mode seems more like CBC in CBC than a CBC-MACed CBC-encrypted > > message -- there can't be a MAC property as such because there is no > > where to store one, so the best you could hope for is earch byte of > > plaintext depends on each byte of ciphertext, and this is the > > property I'm questioning based on the usual CBC splicing attacks. > > It is a CBC MAC. A CBC MAC encrypts n blocks and then takes the > final output as the MAC. Now look at where the IV for the second > pass comes from. It's a nice trick, because it works without any > data expansion.
I can see that, but the security of CBC MAC relies on the secrecy of the ciphertexts leading up to the last block. In the case of the mode you describe in RFC3211, the ciphertexts are not revealed directly but they are protected under a mode which has the same splicing attack. The splicing attack on "CBC MAC with leading ciphertext" works through CBC encryption, here's how that works: Consider plaintext P1,P2,P4,P5, first pass ciphertext A1,...,A5 and second pass ciphertext B1,...,B5: If we swap the first and second blocks of ciphertext (B1,B2) like this: B1'=B2, B2'=B1, B3'=B3, B4'=B4, B5'=B5 and then try decrypting as usual with the two pass mode, first decrypt B5 using B4 as IV to get A5: IV = A5 = D(B5)+B4 = A5 so the IV is the same. Then decrypt B1' to B4' to get A1' to A4': A1'=B1+A2+A5,A2'=A5+A1+B1',A3'=B2+A3+B2',A4'=A4 So the CBC mode has recovered by A4, then decyrpt A1',...,A5' using IV of 0 as usual to get P1',...P5': P1'=D(B1+A2+A5),P2'=D(A2')+A1',P3'=D(A3')+A2',P4'=A3+A3',P5'=P5 and you can see we have effected a partial and targetted garbling of the plaintext. I would have thought this would be considered a 'break' of a non-malleable cipher mode as discussed for disk encryption where each bit of plaintext depends on each bit of ciphertext as would be the case with a secure cipher matching Mercy's design goals (a block cipher used in ECB mode with a different key per block). With a disk mode, unlike with RFC3211 pasword based encryption for CMS there is no place to store the structure inside the plaintext which may to some extent defend against this attack. Adam -- http://www.cypherspace.org/adam/
