At 01:43 PM 5/6/2003 -0400, Russ Housley wrote:
Presently, if you want integrity, then a signature is required, which
defeats the attack that is described. I would be interested in looking
into the use of CCM, EAX, CWC, or any other authenticated encryption mode
AFTER the update to RFC 2633 is published. I would not like to delay
publication of the update while this is investigated.
makes sense.
As far as the attack, let's call that a typo where I meant to say:
There may be reason to use authenticated-encryption even when
signing-then-encrypting. An attacker could tamper with the CBC-encrypted
ciphertext. Since ASN.1 parsing of the decrypted plaintext needs to occur
before signature verification, if the attacker could distinguish different
parsing failures, or distinguish a parsing failure from a
signature-verification failure (by observing timings or error messages from
a server, for example) he could possibly learn something about the plaintext.
Example: The attacker copies some ciphertext block C[x] over C[y]. The
attacker then adjusts C[y-1] so that P[y] will decrypt properly, if his
guess about P[x] and P[y] is correct. As a result of these changes, P[y-1]
and P[y+1] will decrypt randomly.
However if he chooses y so that P[y-1] and P[y+1] are allowed to be random
data (within the SignedInfo, they might be the content, signature, or
SubjectKeyIdentifier blocks), but P[y] has an ASN.1 structure that has to
be parsed correctly, then he can possibly verify guesses about P[x] xor
P[y] by differentiating between parsing and signature verification failures
(or whatever type of failure is caused by damaging P[y-1] and P[y+1]).
Is this possible? I don't know, depends on all sorts of things (cipher
blocksize, the size of the various SignedInfo OIDs, hash values, and signed
attributes, how the recipient handles errors, etc.).. Maybe it's not worth
worrying about, but authenticated-encryption would eliminate any concern.
Trevor