[Bug 25431] Error names allow RSAES-PKCS1-v1_5 oracle attack against wrapped keys

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431

--- Comment #13 from Graham Steel <graham.steel@inria.fr> ---
(In reply to Mark Watson from comment #9)
[..]
> 
> I'd be happy to be proven wrong, but I don't think what you say above is the
> whole story. The attack is based on the fact that the oracle reveals, when
> the padding check succeeds, that a chosen multiple of the plaintext lies
> within a known, simple, subset of the set of all possible plaintexts:
> specifically the subset with valid PKCS#1 padding. This is (roughly) 2^16
> smaller than the set of all plaintexts, because the first two bytes are 0x00
> and 0x02. If the oracle returns an error, little or nothing useful is
> revealed about the plaintext.
> 
> Now, it is clear that if the oracle instead reveals that a chosen multiple
> of the plaintext is both PKCS conforming *and* encodes a valid JWK or ASN.1
> structure then this success result reveals much more information about the
> plaintext. The set of possible plaintext values with both properties is much
> smaller.
> 
> However, multipliers with this property are much much harder to find. The
> _average_ amount of information revealed with each trip to the oracle is, I
> expect, much less, since most of the time you get a failure. I admit I don't
> have a proof of this, though. Do you have a proof of, or evidence for, the
> converse ?
> 
> Furthermore, it's not clear that the additional restriction of the possible
> plaintext set admits a practical exploitation except for the obvious one
> that the plaintext is a multiple of 125 (in the JWK case). It seems to me
> that a practical attack based on this would be something worthy of
> publication, not something we should assume / expect to exist.

Even if one could produce an implementation that doesn't leak by timing or some
other channel that the padding attack passed or failed, just the fact that the
final plaintext was a valid symmetric key of a particular length leaks enough
information to admit an attack requiring (for 1024 bit RSA) a median of roughly
12 million messages - that's around 2^{23}. See Bardou et al "Efficient Padding
Oracle Attacks.." CRYPTO 2012. This attack, like all others, will only get
better. 


> What I'm arguing against is the conjecture that it is so hard to design
> protocols with any practical application that we should not provide the
> primitive at all.


I believe there is excellent evidence to support the conjecture that it is too
hard to design a secure protocol with a practical application involving RSA
PKCS#1v1.5 to justify including this primitive. For example, TLS is probably
the most scrutinized protocol we know, and yet another vulnerability in a
widely deployed implementation relying on the RSA PKCS#1v1.5 padding oracle
attack was announced April 2014
(http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html ,
http://armoredbarista.blogspot.fr/2014/04/easter-hack-even-more-critical-bugs-in.html).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 13 May 2014 17:02:28 UTC