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

Re: Signing and Encryption

From: Yongge Wang <ywang@certicom.com>
Date: Tue, 23 Jan 2001 10:11:23 -0500
To: xml-encryption@w3.org
Message-ID: <852569DD.0052F4A3.00@smtpmail.certicom.com>
Joseph Ashwood wrote:
> ambiguous understanding of the requirements of the program, it has been
> shown that encrypting before signing is bad (ref. PKCS #1 v1.0 was broken
> when it was shown that you could alter the data that was signed by changing
> the RSA key for the encryption, and the signature remained valid), by
> forcing the encryption/decryption of data to invalidate the signature we

I am not sure which attack on RSA you are talking about. If you are talking
about Daniel Bleichenbacher's crypto 98 paper:
     Chosen Ciphertext Attacks against Protocols Based on RSA Encryption
Standard PKCS #1"
     in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1--12, 1998
Then that is quite a different story. Indeed, up to my knowledge, this is the
only attack on PKCS#1.
That has nothing to do with the order of encryption and signature.
I am sure, you guys may have interest in reading H.Krawczyk's recent paper:
  Vulnerabilities of Authenticate-then-Encrypt Secure Channels (not published
There he showed the only way to achieve secure channels is to
encrypt first, then MAC (message authentication code). Though signature
is different from MAC, but we should keep in mind that digital signature
is an extension of MAC.


> enforce this issue, the statement about the encrypted data is "This
> encrypted data has been certified as untampered" if the key is also
> certified then the statement is stronger, however if the key is signed then
> the order of operations is unambiguous, the encryption happened before the
> signing. I believe the (semi-)ambiguous cases should not be addressed,
> perhaps specifically left unaddressed, because the statement that is made is
> by nature ambiguous.
Received on Tuesday, 23 January 2001 10:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:01 UTC