feedback from CFRG

Folks:

Below is the first response I've received from my asking the CFRG for
feedback. The authors are accomplished cryptographers with many
publications in the field of cryptography, including several
publications that take break existing standards by taking advantage of
PKCS#1 v1.5's weakness. Note well that they offer to write some text
for us! I suggest we take them up on that offer.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com

------


From: Tibor Jager <tibor.jager@gmail.com>
Subject: Re: [Cfrg] call for review: Web Cryptography API
Date: Thu, 20 Sep 2012 16:14:57 +0200
Cc: Kenny Paterson <Kenny.Paterson@rhul.ac.uk>,
 Juraj Somorovsky <juraj.somorovsky@rub.de>
To: zooko@zooko.com

Dear Zooko,

we received your request to review the Web Cryptography API Spec. We
would like to provide some comments that you may hopefully find
helpful.

We noted that the standard contains some legacy crypto algorithms,
which have well-known serious weaknesses but are (unfortunately) still
widely used. These weaknesses frequently lead to attacks on systems
that naively use these algorithms.

For instance, several works [Ble98,BFKST12,JSS12, ...] demonstrate the
vulnerability of RSA PKCS#1 v1.5 to variants of Bleichenbacher's
attack in various (practical and widely-used) applications. Using
PKCS#1 v1.5 in a secure way is highly non-trivial and often
impossible, in particular in Web-based applications. Moreover, it is
known that the pure availability of PKCS#1 v1.5 encryption may also
spoil the security of other algorithms, like RSA-OAEP or
RSASSA-PKCS1-v1_5 signatures.

Similarly, unauthenticated block-cipher modes of operation, like CTR
and CBC, have in the past been shown to enable "padding-oracle"-like
attacks, for instance in [Vau02,DR'10,DR'11,JS'11,AP'12, ...]. These
modes of operation should not be used without additional security
measures. An appropiate measure is a message authentication code,
which should be computed over the ciphertext and must be verified by
the receiver.

Actually we would like to recommend that these legacy ciphers are
removed from the standard. While in some special cases countermeasures
against the known attacks are possible, implementing these is highly
non-trivial and error-prone, thus much harder than implementing new
libraries supporting secure algorithms. Even worse, in many examples
there exists no countermeasure.

However, we understand that this may be impossible, for instance due
to interoperability reasons. If these weak algorithms are not removed,
then we recommend that at least a section is added to the spec, which
mentions the problems with these legacy schemes and recommends
preferable choices of algorithms. This would serve as a code of
practice for developers, which are not familiar with the most recent
literature on attacks in applied cryptography.
If you are interested, we could provide a draft of this section.

Kind regards,
Juraj, Kenny, Tibor


[Ble98] Daniel Bleichenbacher. Chosen Ciphertext Attacks Against
Protocols Based on the RSA Encryption Standard PKCS #1. CRYPTO 1998.

[BFKST12] Romain Bardou, Riccardo Focardi, Yusuke Kawamoto, Lorenzo
Simionato, Graham Steel, Joe-Kai Tsay. Efficient Padding Oracle
Attacks on Cryptographic Hardware. CRYPTO 2012.

[JSS12] Tibor Jager, Sebastian Schinzel, Juraj Somorovsky.
Bleichenbacher's Attack Strikes again: Breaking PKCS#1 v1.5 in XML
Encryption. ESORICS 2012.

[Vau02] Serge Vaudenay. Security Flaws Induced by CBC Padding -
Applications to SSL, IPSEC, WTLS .... EUROCRYPT 2002.

[DR'10] J. Rizzo T. Duong. Practical Padding Oracle Attacks. Black Hat
Europe 2010 and USENIX WOOT 2010.

[DR'11] Thai Duong, Juliano Rizzo. Cryptography in the Web: The Case
of Cryptographic Design Flaws in ASP.NET. IEEE Symposium on Security
and Privacy 2011.

[JS'11] Tibor Jager and Juraj Somorovsky. How to break XML Encryption.
ACM CCS 2011.

[AP'12] N.J. AlFardan and K.G. Paterson. Plaintext-Recovery Attacks
Against Datagram TLS. NDSS 2012.

Received on Thursday, 20 September 2012 15:24:30 UTC