[ 
https://issues.apache.org/jira/browse/HBASE-14089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628892#comment-14628892
 ] 

Andrew Purtell edited comment on HBASE-14089 at 7/15/15 10:47 PM:
------------------------------------------------------------------

>From that link you cited:

bq. /dev/random is unambiguously the better choice for cryptography

This is true. The fact /dev/random BLOCKS if there is insufficient entropy is a 
good thing for cryptographic applications. 

Anyway, with this patch I am removing a use of SecureRandom (aka /dev/random) 
from a place in the code that doesn't need cryptographically strong randomness. 
 Using -Djava.security.egd=file:/dev/./urandom would have a global effect not 
good where we use SecureRandom with cryptography. Why not just +1 (smile) ? 




was (Author: apurtell):
>From that link you cited:

bq. /dev/random is unambiguously the better choice for cryptography

With this patch I am removing a use of SecureRandom (aka /dev/random) from a 
place in the code that doesn't need cryptographically strong randomness. 

Using -Djava.security.egd=file:/dev/./urandom would have a global effect not 
good where we use SecureRandom with cryptography.



> Remove unnecessary draw of system entropy from RecoverableZooKeeper
> -------------------------------------------------------------------
>
>                 Key: HBASE-14089
>                 URL: https://issues.apache.org/jira/browse/HBASE-14089
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>            Priority: Minor
>             Fix For: 2.0.0, 0.98.14, 1.2.0, 1.1.2, 1.3.0, 1.0.3
>
>         Attachments: HBASE-14089.patch
>
>
> I had a look at instances where we use SecureRandom, which could block if 
> insufficient entropy, in the 0.98 and master branch code. (Random in contrast 
> is a PRNG seeded by System#nanoTime, it doesn't draw from system entropy.) 
> Most uses are in encryption related code, our native encryption and SSL, but 
> we do also use SecureRandom for salting znode metadata in 
> RecoverableZooKeeper#appendMetadata, which is called whenever we do setData. 
> Conceivably we could block unexpectedly when constructing data to write out 
> to a znode if entropy gets too low until more is available. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to