Subject: RE: digested-data

From: Trevor Perrin <[email-masked]>
Date: Thu, 1 Aug 2002 02:57:19 -0700

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: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 28, 2002 8:55 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: digested-data, surreptitious forwarding, D-H

Trevor Perrin <[email-masked]> 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.