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
<[email protected] <mailto:[email protected]>> 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

Reply via email to