Skip to content
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

Password based KDF #59

Closed
jmjauer opened this issue Dec 16, 2020 · 0 comments · Fixed by #98
Closed

Password based KDF #59

jmjauer opened this issue Dec 16, 2020 · 0 comments · Fixed by #98

Comments

@jmjauer
Copy link

jmjauer commented Dec 16, 2020

New API Proposal: Password based KDF

Motivation:

Currently no password based KDF is available. This is required for tasks like generating a AES key from a password.

Importance:

Without it, generating crypto keys from a password is not possible.

@admkopec admkopec mentioned this issue Dec 9, 2021
4 tasks
@Lukasa Lukasa linked a pull request Oct 18, 2024 that will close this issue
4 tasks
Lukasa pushed a commit that referenced this issue Oct 18, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant