[
https://issues.apache.org/jira/browse/NIFI-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15129771#comment-15129771
]
ASF GitHub Bot commented on NIFI-1257:
--------------------------------------
Github user alopresto commented on the pull request:
https://github.com/apache/nifi/pull/201#issuecomment-179003037
The current state of the code passes on Java 7 and 8 with unlimited
strength cryptographic jurisdiction policies installed (Travis includes these).
I am resolving some tests which would fail on a vanilla JVM without these
policies installed and will push these fixes.
I also discovered some inconsistencies in the `BouncyCastle` implementation
of certain PBE ciphers that can exceed the key strength limit even when using
the correct key length if the underlying password length exceeds an
undocumented inner limit. This was originally recorded in
[NIFI-1255](https://issues.apache.org/jira/browse/NIFI-1255) but I have added a
custom validator temporarily and added further documentation to that ticket.
> Provide additional KDFs for EncryptContent
> ------------------------------------------
>
> Key: NIFI-1257
> URL: https://issues.apache.org/jira/browse/NIFI-1257
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 0.4.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Critical
> Labels: encryption, security
> Fix For: 0.5.0
>
>
> Currently, the two key derivation functions (KDF) supported are NiFi Legacy
> (1000 iterations of MD5 digest over a password and optional salt) and OpenSSL
> PKCS#5 v1.5 (a single iteration of MD5 digest over a password and optional
> salt).
> Both of these are very weak -- they use a deprecated cryptographic hash
> function (CHF) with known weakness and susceptibility to collisions (with
> demonstrated attacks) and a non-configurable and tightly coupled iteration
> count to derive the key and IV.
> Current best practice KDFs (with work factor recommendations) are as follows:
> * PBKDF2 with variable hash function (SHA1, SHA256, SHA384, SHA512, or
> ideally HMAC variants of these functions) and variable iteration count (in
> the 10k - 1M range).
> * bcrypt with work factor of 12 - 16
> * scrypt with work factor of (2^14 - 2^20, 8, 1)
> The salt and iteration count should be stored alongside the hashed record
> (bcrypt handles this natively).
> Notes:
> * http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/
> * http://blog.ircmaxell.com/2012/12/seven-ways-to-screw-up-bcrypt.html
> *
> http://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
> *
> http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256/3993#3993
> *
> http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415
>
> *
> http://web.archive.org/web/20130407190430/http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
> *
> https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2015/march/enough-with-the-salts-updates-on-secure-password-schemes/
> * http://www.tarsnap.com/scrypt.html
> * http://www.tarsnap.com/scrypt/scrypt.pdf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
