W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2014

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 29 Apr 2014 22:22:49 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25431-7213-fWi4gU7j2g@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431

--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
Agreed, unwrapKey is inherently flawed with RSAES.

In an ideal world, it would be possible to use the encrypt/decrypt primitives
in a manner similar to that described in RFC 5246, Section 7.4.7.1. However, as
currently specified, a padding error is distinguishable from success by virtue
of the promise being rejected versus an ArrayBuffer being allocated. This
provides a timing bias that could be used to exploit an implementation.

We "could" potentially mitigate this by having RSAES explicitly take a length
of the expected data size as an input. The UA would then generate & allocate a
random ArrayBuffer of that length, R, prior to performing the operation. It
would then perform the RSAES operation, check the padding, and check the size.
If any of these failed, it would use R as the ArrayBuffer return, otherwise, it
would use the decrypted data.

This would allow a construct like those described, but will force key data to
be exposed to JS. Of course, something like that described in 7.4.7.1
inherently requires the PMS be exposed to JS (unless a TLS-specific
PreMasterSecret alg is implemented), due to the need to inject the
ClientHello.client_version into the first two octets.

The alternative is of course one that will make some happy - remove RSAES
entirely - but I'm curious if there is a way to permit the 'safe [albeit
dangerous]' use.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 29 April 2014 22:22:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC