[
https://issues.apache.org/jira/browse/NIFI-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180885#comment-16180885
]
ASF subversion and git services commented on NIFI-3116:
-------------------------------------------------------
Commit 2c1f5b49e449d34c030080ee46b6b580772c5378 in nifi's branch
refs/heads/master from [~alopresto]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=2c1f5b4 ]
NIFI-3116 This closes #2108. Added initial regression test for StringEncryptor
to ensure continued functionality during removal of Jasypt.
Added external compatibility regression test for StringEncryptor to ensure
continued functionality during removal of Jasypt.
Documents custom salt lengths and iteration counts for each encryption method.
Added (ignored) failing tests for keyed encryption (Jasypt does not support
keyed encryption).
Changed StringEncryptor to non-final class and added protected default
constructor.
Added failing test for initialization status.
Added utility methods in CipherUtility.
Moved PBE cipher providers (and tests) from nifi-standard-processors to
nifi-security-utils module.
Implemented PBE and keyed encryption/decryption logic.
Moved Scrypt unit test back into scrypt package.
Resolved test failures in limited strength cryptographic environment.
Implemented keyed encryption/decryption and enabled unit tests.
Removed Jasypt dependency from production scope (kept in test scope for
backward compatibility tests).
Signed-off-by: joewitt <joew...@apache.org>
> Remove Jasypt library
> ---------------------
>
> Key: NIFI-3116
> URL: https://issues.apache.org/jira/browse/NIFI-3116
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 1.1.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Labels: encryption, kdf, pbe, security
>
> The [Jasypt|http://www.jasypt.org/index.html] library is used internally by
> NiFi for String encryption operations (specifically password-based encryption
> (PBE) in {{EncryptContent}} and sensitive processor property protection). I
> feel there are a number of reasons to remove this library from NiFi and
> provide centralized symmetric encryption operations using Java cryptographic
> primitives (and BouncyCastle features where necessary).
> * The library was last updated February 25, 2014. For comparison,
> BouncyCastle has been [updated 5
> times|https://www.bouncycastle.org/releasenotes.html] since then
> * {{StandardPBEStringEncryptor}}, the high-level class wrapped by NiFi's
> {{StringEncryptor}} is final. This makes it, and features relying on it,
> difficult to test in isolation
> * Jasypt encapsulates many decisions about {{Cipher}} configuration,
> specifically salt-generation strategy. This can be a valuable feature for
> pluggable libraries, but is less than ideal when dealing with encryption and
> key derivation, which are in constant struggle with evolving attacks and
> improving hardware. There are hard-coded constants which are not compatible
> with better decisions available now (i.e. requiring custom implementations of
> the {{SaltGenerator}} interface to provide new derivations). The existence of
> these values was opaque to NiFi and led to serious compatibility issues
> [NIFI-1259], [NIFI-1257], [NIFI-1242], [NIFI-1463], [NIFI-1465], [NIFI-3024]
> * {{StringEncryptor}}, the NiFi class wrapping {{StandardPBEStringEncryptor}}
> is also final and does not expose methods to instantiate it with only the
> relevant values (i.e. {{algorithm}}, {{provider}}, and {{password}}) but
> rather requires an entire {{NiFiProperties}} instance.
> * {{StringEncryptor.createEncryptor()}} performs an unnecessary "validation
> check" on instantiation, which was one cause of reported issues where a
> secure node/cluster blocks on startup on VMs due to lack of entropy in
> {{/dev/random}}
> * The use of custom salts with PBE means that the internal {{Cipher}} object
> must be re-created and initialized and the key re-derived from the password
> on every decryption call. Symmetric keyed encryption with a strong KDF (order
> of magnitude higher iterations of a stronger algorithm) and unique
> initialization vector (IV) values would be substantially more resistant to
> brute force attacks and yet more performant at scale.
> I have already implemented backwards-compatible code to perform the actions
> of symmetric key encryption using keys derived from passwords in both the
> {{ConfigEncryptionTool}} and {{OpenSSLPKCS5CipherProvider}} and
> {{NiFiLegacyCipherProvider}} classes, which empirical tests confirm are
> compatible with the Jasypt output.
> Additional research on some underlying/related issues:
> * [Why does Java allow AES-256 bit encryption on systems without JCE
> unlimited strength policies if using
> PBE?|https://security.stackexchange.com/questions/107321/why-does-java-allow-aes-256-bit-encryption-on-systems-without-jce-unlimited-stre]
> * [How To Decrypt OpenSSL-encrypted Data In Apache
> NiFi|https://community.hortonworks.com/articles/5319/how-to-decrypt-openssl-encrypted-data-in-apache-ni.html]
> * [d...@nifi.apache.org "Passwords in
> EncryptContent"|https://lists.apache.org/thread.html/b93ced98eff6a77dd0a2a2f0b5785ef42a3b02de2cee5c17607a8c49@%3Cdev.nifi.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
