Andy LoPresto created NIFI-3116:
-----------------------------------
Summary: 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
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]
* [[email protected] "Passwords in
EncryptContent"|https://lists.apache.org/thread.html/b93ced98eff6a77dd0a2a2f0b5785ef42a3b02de2cee5c17607a8c49@%3Cdev.nifi.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
