What happens in the case Where there are not enough non-zero random bytes in the new version?<span></span><br><br>On Wednesday, August 5, 2015, Sergey Kuksenko <<a href="mailto:sergey.kuksenko@oracle.com">sergey.kuksenko@oracle.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
Please review changes to the following performance improvement:<br>
<br>
<a href="https://bugs.openjdk.java.net/browse/JDK-8132330" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8132330</a><br>
<br>
Webrev: <a href="http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/" target="_blank">http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/</a><br>
<br>
Sponsorship is required.<br>
<br>
------<br>
Currently sun.security.rsa.RSAPadding::padV15 uses fixed size (64 bytes) buffer for obtaining random bytes from SecureRandom.<br>
Here we got two sources of inefficiency:<br>
- when length of required padding is greater than 64 -> several calls of SecureRandom.nextBytes are required that increases contention blocking on SecureRandom<br>
- 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)<br>
<br>
Suggested performance improvement shows RSA encoding (public key) speedup:<br>
- 10%-18% when NativePRNG SecureRandom is used,<br>
- 5%-7% when SHA1PRNG is used.<br>
<br>
<br>
-- <br>
Best regards,<br>
Sergey Kuksenko<br>
</blockquote>