[
https://issues.apache.org/jira/browse/NIFI-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037885#comment-15037885
]
Adam Taft commented on NIFI-1240:
---------------------------------
Specifying the provider and algorithm helps with predictable encryption across
JVMs and fast failure if a provider/algorithm is not available. However, as
Andy mentioned, in this case it's simply being used to generate a random salt
that's being passed on the wire. The part that would need to be consistent
between two clients in this class is the definition of the Cipher algorithm and
provider, not the salt generator.
I agree with Aldrin, I think in this case, it's safe to use the default
constructor of SecureRandom, since its usage doesn't require consistency on the
other end. That's my read, for what it's worth.
> SecureRandom is improperly seeded with current time
> ---------------------------------------------------
>
> Key: NIFI-1240
> URL: https://issues.apache.org/jira/browse/NIFI-1240
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 0.4.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Critical
> Labels: easyfix, security
> Fix For: 0.4.0
>
> Attachments:
> 0001-NIFI-1240-removing-explicit-reference-to-SUN-provide.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In PasswordBasedEncryptor.java, java.security.SecureRandom is used to
> generate a salt for key derivation. However, the SecureRandom instance is
> seeded by System.getCurrentTimeInMillis(), which is not random and is
> predictable. Instead, we should allow SecureRandom to seed itself by calling
> SecureRandom.nextBytes().
> The instance accessor should also explicitly specify "SUN" as the
> cryptographic service provider to avoid default CSP issues.
> "First, while it is good that the code explicitly specifies the instance of
> SecureRandom to be SHA1PRNG (because a call to .getInstance() will return
> whatever the Java properties specify), to be completely explicit, it should
> be .getInstance("SHA1PRNG", "SUN") because the Java cryptographic service
> provider (CSP) should be selected. On most systems this will default to Sun,
> but it can conceivably cause issues if a different CSP is prioritized.
> Second, seeding the SecureRandom with the current time is most definitely not
> random and is predictable. SecureRandom.nextBytes() actually self-seeds if
> the instance had not previously been seeded, and this manual seeding is
> decreasing the entropy used. These two issues will be resolved in an upcoming
> release, but are not related to the encryption issue we are addressing now."
> The fix is very simple. I have searched the project and this is the only use
> of SecureRandom which is manually seeded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
