New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New API Proposal: PBKDF2 #98
base: main
Are you sure you want to change the base?
Conversation
Can one of the admins verify this patch? |
7 similar comments
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
Can one of the admins verify this patch? |
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. |
} | ||
} | ||
|
||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#endif | |
#endif |
@Lukasa any other updates or thoughts on this? This is the one thing stopping me from switching fully to |
any updates ? |
Not at this time, I'm afraid. |
Sorry for the delay here. Yes, I'm open to taking a PR for PKBDF2 with the following notes:
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 |
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 |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! Some initial notes in the diff. I've mostly restrained my review to the product code for now, I'll review the tests later.
|
||
extension KDF.Insecure { | ||
/// An implementation of PBKDF2 key derivation function. | ||
public struct PBKDF2<H: HashFunction> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we don't actually support user-specified hash functions, I don't think we should take a hash function as a generic argument. We should instead use a public struct
as an extensible enum and take that as an argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it took so long, is there any reason for using public struct
over public enum
in this situation? I have currently provided a public enum
for this purpose.
Sources/_CryptoExtras/Key Derivation/PBKDF2/BoringSSL/PBKDF2_boring.swift
Outdated
Show resolved
Hide resolved
Sources/_CryptoExtras/Key Derivation/PBKDF2/BoringSSL/PBKDF2_boring.swift
Outdated
Show resolved
Hide resolved
Sources/_CryptoExtras/Key Derivation/PBKDF2/BoringSSL/PBKDF2_boring.swift
Outdated
Show resolved
Hide resolved
Sources/_CryptoExtras/Key Derivation/PBKDF2/BoringSSL/PBKDF2_boring.swift
Outdated
Show resolved
Hide resolved
Sources/_CryptoExtras/Key Derivation/PBKDF2/BoringSSL/PBKDF2_commoncrypto.swift
Show resolved
Hide resolved
Sources/_CryptoExtras/Key Derivation/Scrypt/BoringSSL/Scrypt_boring.swift
Outdated
Show resolved
Hide resolved
Sources/_CryptoExtras/Key Derivation/Scrypt/BoringSSL/Scrypt_boring.swift
Outdated
Show resolved
Hide resolved
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. |
Once again I am very sorry for the delay. I have implemented suggestions from the review. @Lukasa, Please take a look if it is acceptable now. |
I've proposed an implementation of PBKDF2 algorithm using the CryptoKit style. As per issue #59
Checklist
If you've made changes to
gyb
filesI 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 withScrypt
struct and anInsecure
namespace withPBKDF2
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.