W3C home > Mailing lists > Public > xml-encryption@w3.org > March 2001

Re: Signing encrypted data

From: Joseph Ashwood <jashwood@arcot.com>
Date: Mon, 26 Mar 2001 18:24:44 -0800
Message-ID: <019501c0b665$19590370$2a0210ac@livermore>
To: "Yongge Wang" <ywang@certicom.com>
Cc: "Xml Encrypt \(E-mail\)" <xml-encryption@w3.org>
----- Original Message -----
From: "Yongge Wang" <ywang@certicom.com>
Cc: "Xml Encrypt (E-mail)" <xml-encryption@w3.org>

> > Well the security reason is that if the signature doesn't include enough
> > randomness then the signature can be guessed. Which leads to potential
> > compromises.
> First I think this is a XML-DSIG problem.

I believe it is a problem with the line between them. BUt if I were to place
it in one generically I would agree, however the DSIG spec is effectively
done, so the place to make changes to the line would be here.

> Secondly,
> DSA and ECDSA all require to have a random seed "r"
> for each signature.

Yes but with both cases the original hash can be found with vastly
diminished work. So the effect is that of publishing the hash (with some
extra workload), which is exactly where the problem started.

> And the security issues are discussed
> in the DSA or ECDSA standard. It is not a problem for
> XML-Encryption.

Actually there is surprisingly little discussion about the entropy content
issues in either the DSS or SHS papers (DSA and SHA-1). They generally
simply assume that the problems of hash algorithms and signatures is known,
the proof of usability supplied by the papers is of little use because they
provide proof of difficulty of changing the hash value.

> Also generally the signatures are on
> plaintext.

I think much of this discussion is on what needs to be considered plaintext.
If the data will be enrypted either the signature needs to be a part of that
plaintext, or the signature needs to be performed on the ciphertext.

> So this is really no reason to exclude
> the case that one can sign on a plaintext. Most
> contract are signed on plaintext (of course, need to
> hash it first).

However you will still have to have the decryption key to verify that
signature, which means there is no reason at all to leave the signature in
the open, and significant risk associated with it. Based on this I see very
significant reasons to specifically exclude the simultaneous operation of
encryption and signing.

We need to enforce that they are serialized. If the encryption happens
before the signing there is not problem. If the encryption happens after the
signing there needs to be a some method in place that will disallow guessing
attacks. Since the prime target for this seems to be credit cards which have
significantly less than 64-bits of entropy the reasonable decision would be
to simply not do it (to do it securely you have to blend the encryption and
signature, which would put it outside the scope of the encryption and dsig
groups). All that will happen by exposing signatures on data that is later
encrypted is the exposure of another potential method of attack.
Received on Monday, 26 March 2001 21:25:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:00 UTC