Re: Combining signing and encrypting

Hiroshi Maruyama, <>, writes:
> Regarding combining signature and encryption, David Solo writes:
> >An alternative suggestion, made originally by Jim Schaad, is to define a
> "don't
> >decrypt" transform.  Coupled with a rule that says, in general "decrypt
> then
> >verify", this would allow the signer to indicate an exception.  An
> implication
> >of this is that signing applications need to be encryption aware.
> I like Jim Schaad's idea.  This is an elegant way to handle
> signature/encryption
> interdependency.  One may object to put this information in <Transform>
> because it is not actually a transformation.  Instead,
> I would like to propose to use the <SignatureProperty>
> element to convey this information as in the following example:

It is conceivable that an XML document might have portions signed
(by the author, perhaps), then portions encrypted, then other portions
(or the whole document) signed by someone else (say, to protect from
modifications during transport).  The result would be that a particular
piece of encrypted content should be checked before encryption for one
signature, and after encryption for another.

Your suggestion to tag the signature rather than the encryption info
would solve this.

However I am still concerned about leaving the signature in the clear
if the signed data is encrypted.  It allows plaintext guessing attacks.
It is necessary to guess the entire plaintext so that may or may not be
a concern in a particular application.  Still it is a worrisome leak,
and it would be avoided if the rule were adopted that signatures over
data to be encrypted were also encrypted.  This rule would also fix the
ambiguity about which to do first: anytime a signature is visible, it
is checkable.

Hal Finney
PGP Security

Received on Tuesday, 28 November 2000 08:23:09 UTC