[
https://issues.apache.org/jira/browse/NIFI-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Witt resolved NIFI-3116.
-------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0
+1 merged to master.
[~jtstorck] if you are in a position to include this in 1.4.0 please do so . If
you do choose to do so please change the fix version from 1.5.0 to 1.4.0.
Thanks
> 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
> Fix For: 1.5.0
>
>
> 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)
