[
https://issues.apache.org/jira/browse/NIFI-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reopened NIFI-1240:
---------------------------------
Depending on the Sun JCE provider requires that the Sun provider be installed
on the system. IBM JRE systems can have Sun JCE added, but this is not expected
behavior.
In this scenario, the SecureRandom is only used to generate a salt for key
derivation in password-based encryption and the salt is passed with the cipher
text, so different versions of SecureRandom on different installations is not a
concern.
Please revert the change to explicitly require "SUN" JCE.
> 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
>
> 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)
