New API Proposal: PBKDF2 #98
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 |
|
@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. |
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. |
|
@Lukasa ping for this PR 🙂 |
|
Just a note that I’m on vacation right now so I can’t review, but will review when I’m back. |
Hello, perhaps you have already rested and can take a closer look at this pull request 🙃 |
|
@admkopec thank you for your work and patience, I hope this pull request will be accepted before the whole world switches to argon2 or scrypt |
| /// - outputByteCount: The length in bytes of resulting symmetric key. | ||
| /// - rounds: The number of rounds which should be used to perform key derivation. | ||
| /// - Returns: The derived symmetric key. | ||
| public static func deriveKey<Passphrase: DataProtocol, Salt: DataProtocol>(from password: Passphrase, salt: Salt, using hashFunction: HashFunction, outputByteCount: Int, rounds: Int) throws -> SymmetricKey { |
There was a problem hiding this comment.
This API generally looks good, but I'm wondering if we should add a minimum round count to avoid folks naively using the number 1. We should certainly add documentation suggesting a high round count (in the hundreds of thousands), but I can't see any world where we'd want to accept less than 1k.
If we have use-cases that absolutely need lower round counts I'd love to know, but those might be best served the way we serve RSA key sizes: with a second API that is a bit harder to justify typing.
There was a problem hiding this comment.
I do actually have such a use case. User+password authentication in Oracle typically encrypts the password with 4096 iterations. Hashes it alongside other data using SHA512, does a bit of CBC de- and encryption with it and some more data. And finally encrypts the end result using another 3 rounds of PBKDF2. (https://github.com/lovetodream/oracle-nio/blob/7fee78535f68c9f3a451beeed15483bc6ac2877b/Sources/OracleNIO/Messages/Coding/OracleFrontendMessageEncoder.swift#L926-L974)
It might not be the same for every version of Oracle because this is controlled by the db server, but I confirmed it is the default behaviour with Oracle 23ai (newest release).
There was a problem hiding this comment.
Ace, that's helpful. So I think that this then suggests we want two APIs, one like the one here and one closer that maybe uses the label unsafeUncheckedRounds (or similar).
My desire is to enable the use-case you have, while strongly discouraging users who pick up PBKDF2 without much thought from putting in extraordinarily low values.
There was a problem hiding this comment.
I added the unsafeUncheckedRounds API method and a guard check in the regular API method to throw an incorrect parameter size error whenever the rounds is less than 1000. Please verify if this is acceptable.
If we now have the unsafe API method, is the 1000 rounds requirement enough though, as it was proposed way back in original RFC with intent to increase number of rounds over time?
There was a problem hiding this comment.
Probably not. OWASP suggests a minimum round count of 210k for SHA512-based PBKDF2, and so maybe we should consider that the lower bound.
|
Apologies for the delays getting to this, this is now fairly high up my priority list so we should be able to get it in fairly soon. |
|
@swift-server-bot add to allowlist |
…dded a condition to not accept rounds under 1000 in regular API method
…s per OWASP recommendations) and iImproved methods' documentation to better describe these requirements.
|
There are a few very minor tweaks to the license headers, as shown in the failing GH workflow. Otherwise this is basically good to go! |
|
Actually, let's not bother with that: you've done more than enough to get this patch over the line. I've pushed a fix for those. |
I've proposed an implementation of PBKDF2 algorithm using the CryptoKit style. As per issue #59
Checklist
If you've made changes to
gybfilesI haven't made any changes to
gybfiles.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
SymmetricKeyfrom 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:
KDFnamespace withScryptstruct and anInsecurenamespace withPBKDF2struct 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.