swift-crypto
swift-crypto copied to clipboard
apple
New API Proposal: PBKDF2
I've proposed an implementation of PBKDF2 algorithm using the CryptoKit style. As per issue #59
Checklist
- [x] I've run tests to see all new and existing tests pass
- [x] I've followed the code style of the rest of the project
- [x] I've read the Contribution Guidelines
- [x] I've updated the documentation if necessary
If you've made changes to gyb files
I haven't made any changes to gyb files.
New API Proposal: Password based KDF #59
Motivation:
I've added a proposed implementation of PBKDF2, as per proposal in issue #59 to allow easy creation of SymmetricKey from relatively low entropy data sets, such as user provided passwords.
Importance:
This API change is attempting to simplify the creation of SymmetricKeys from user entered passwords. It uses an ageing algorithm – PBKDF2, but it is still widely supported and popular. A newer algorithm – scrypt is added as a better, more secure alternative.
Modifications:
I've proposed a new API: KDF namespace with Scrypt struct and an Insecure namespace with PBKDF2 struct with associated hash function and a single static method which takes a passphrase and salt, the size of the resulting key in bytes and optionally the number of rounds to use in the PBKDF2 algorithm.
In the case of scrypt algorithm there is no associated hash function due to the nature of the algorithm, the single static method takes passphrase and salt, the size of the resulting key in bytes and optionally: the number of rounds, block size and parallelism factor.
I implemented this functions using both CommonCrypto and BoringSSL where available.
The function names and parameters are heavily influenced by current HKDF implementation.
Additionally, I've added test cases to test the proposed API. I've decided to use test vectors described in RFC6070 for PBKDF2 and test vectors described in RFC7914 for scrypt.
Result:
This will add a new API to _CryptoKitExtras.
It follows the naming conventions from CryptoKit's HKDF implementation.
Thanks for filing this! I wanted to let you know that I've seen it, and I'm going to discuss with my colleagues to work out whether PBKDF2 is a good fit here.
Possibly Argon2 might be a better choice here, but due to its lack of support in both CommonCrypto and BoringSSL, I decided to implement PBKDF2 instead. Please let me know when you decide, if PBKDF2 should be added here.
@Lukasa any other updates or thoughts on this? This is the one thing stopping me from switching fully to swift-crypto from other third-party packages.
There is a discussion about this going on here. @Lukasa, how do you want to continue? Maybe @admkopec has time to move this to _CryptoExtas? I'm open to help, both in this case and in adding alternatives, if there's anything I can do.
Sorry for the delay here. Yes, I'm open to taking a PR for PKBDF2 with the following notes:
- The API surface should be added in
_CryptoExtras. - PBKDF2 should be namespaced under a
KDFnamespace - PBKDF2 should be further namespaced under an
Insecurenamespace withinKDF, to discourage its use - A version of
scryptshould be added as well
Is that acceptable?
Would again advocate for an Argon2 implementation, even if it’s just wrapping the reference C implementation for now.
I'll start moving the implementation over to _CryptoExtras and will take a look at scrypt. But as for the better alternative, I'd still vote for Argon2 over scrypt to be honest even if it would mean adding an external dependency to _CryptoExtras.
even if it would mean adding an external dependency to
_CryptoExtras
While I'm sure that there are more performant implementations, the reference implementation hasn't been updated in 3 years and the algorithm is final at this point, so you could probably even just copy the source directly into _CryptoExtras and avoid the external dependency. I've been running a project with basically that exact setup for a few years with no issues, running on both Mac and Linux.
I'm open to us adding Argon2, though I want to have a discussion with my colleagues about whether the reference implementation is the right way to do that. But for now let's focus on PBKDF2 and scrypt: one problem at a time!
Perfect answer, please implement already, we've been waiting for over 2 years. We are not comfortable including openssl header in our code. Just do it please, we'd rather start writing code on Rust than wait another 2 years for Argon2
@Lukasa I've implemented the changes you suggested. Please verify if this is an acceptable solution.
Hi @admkopec, can you please tell me if this pullrequest will be developed further ?
@nerzh Yes, sorry for the delay, a more urgent thing came up on my side. I'll implement the necessary changes as soon as I get a chance to get back to this PR.
@admkopec glad to hear you have plans to complete this much needed PR. Thanks for the quick response.