RFR: 8132330: Ineffective SecureRandom usage in RSA encoding with PKCS1Padding

[Sergey Kuksenko]

The same as before. We will request a new portion of random bytes.

On 08/07/2015 01:41 PM, David Schlosnagle wrote:
> What happens in the case Where there are not enough non-zero random
> bytes in the new version?
>
> On Wednesday, August 5, 2015, Sergey Kuksenko
> <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>
>     Hi All,
>
>     Please review changes to the following performance improvement:
>
>     https://bugs.openjdk.java.net/browse/JDK-8132330
>
>     Webrev: http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/
>
>     Sponsorship is required.
>
>     ------
>     Currently sun.security.rsa.RSAPadding::padV15 uses fixed size (64
>     bytes) buffer for obtaining random bytes from SecureRandom.
>     Here we got two sources of inefficiency:
>     - when length of required padding is greater than 64 -> several
>     calls of SecureRandom.nextBytes are required that increases
>     contention blocking on SecureRandom
>     - when length of required padding is less than 64 it causes
>     unnecessary overhead (e.g. nextBytes for 16 bytes is 4x times faster
>     than for 64 bytes)
>
>     Suggested performance improvement shows RSA encoding (public key)
>     speedup:
>     - 10%-18% when NativePRNG SecureRandom is used,
>     - 5%-7% when SHA1PRNG is used.
>
>
>     --
>     Best regards,
>     Sergey Kuksenko
>

-- 
Best regards,
Sergey Kuksenko