On Fri, 4 Mar 2016 14:45:13 +0100 (CET) m...@sap.com (Martin Rex) wrote: > What should have adopted for TLSv1.2 already, however, is the less > forgiving PKCS#1 v1.5 signature check, that re-creates the encoding > and then compares the recreated inner encoding with the RSA-decrypted > encoding only. Get rid of the de-padding and get rid of the ASN.1 > decoding of the contents.
The Problem with this is that you're relying on the implementor to get it right. Sure, you're giving them a receip how they could implement the check to be correct, but you have no way of checking whether they actually follow that receip. Given all past experiences I'd bet you can write whatever you want in your new standards document, no implementor will replace their (seemingly working, but insecure) PKCS #1 1.5 implementation as long as it works, just because you say they have to do it in a different way than they did in the past. > The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA > signatures is that one can clearly distinguish "wrong public key" > from "signature does not fit plaintext" errors, and loosing this > capability makes certain kinds of programming goofs (plus a few > admin configuration goofs) much harder to distinguish from > data corruption during transfer. Actually I see this as a disadvantage. Separating different error states has been the source of a whole number of vulnerabilities. The original Bleichenbacher attack (and all its variants including drown) is based on separating different errors, the Vaudenay attack is. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
pgpYHTQr5FQIB.pgp
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
