Hi Peter,
I still don't understand why you can't do two layers in a single pass. I'd
assume that at a certain point the inner layer is finished with the previous
X bytes, so it could pass control to the outer layer who could chew on them,
and when it's consumed that chunk, pass control back to the inner layer,
etc.. But I don't really know anything about ASN.1, so never mind..
Anyways, I was thinking S/MIME clients might reject a message that decrypts
with garbled, non-ASCII characters. Outlook Express at least doesn't.
Given CBC chaining it was easy to modify the ciphertext block previous to a
known plaintext block to change the known plaintext block to anything
desired, at the cost of garbling the modified block. Presumably I could cut
and paste chunks of ciphertext around as well, and with a stereotyped
plaintext and some experimentation I'm sure all sorts of devilment could be
done with that...
Maybe this is "working as designed", but I think most users of S/MIME would
be surprised. Has this been discussed before? Is there a group consensus
I'm unaware of? If not, is it worth trying to remedy this now?
modified plaintext line, as displayed by OE:
AAAAAAAAAAAAAAAAAAAAAAA8á8$2@ HELLOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Trevor
-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Sunday, July 28, 2002 8:55 PM
To: Tperrin(_at_)sigaba(_dot_)com; ietf-smime(_at_)imc(_dot_)org;
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
Subject: RE: digested-data, surreptitious forwarding, D-H
Trevor Perrin <Tperrin(_at_)sigaba(_dot_)com> writes:
Interesting, I'd assumed that you could do multiple layers (like a
digestedData and envelopedData, or signedData and envelopedData) in a
single
pass, by hashing and then encrypting each content block, then moving to the
next one, etc.. You're saying that this isn't possible,
It isn't, because of ASN.1 encoding restrictions. Changing a single byte of
inner content can change several bytes of outer content due to
variable-length
length-of-length encoding, and there are some data lengths which can never
be
achieved, eg. when you move from a short-encoded data length to a
long-encoded
one and adding a single byte to the data also increases the length-of-length
value. When you combine this with data blocking requirements and
requirements
for PKCS #5 padding, it becomes unworkably complex to implement and test
unless
you buffer an entire message, in which case you're just doing a standard
two-
pass encoding.
but the scheme below can be done in one pass?
Sure, since the encoding is one-step. With DigestedData you're
encapsulating
the entire data block just to add a 20-byte hash at the end. All this does
it add the hash at the end of the EncryptedData.
Peter.