-
Notifications
You must be signed in to change notification settings - Fork 159
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
Add ML-DSA post-quantum signatures to _CryptoExtras
#267
base: main
Are you sure you want to change the base?
Conversation
…`PublicKey` extraction from `PrivateKey` non-throwing
…ror thrown by `CBB_init`
Hi @Lukasa, thank you very much for the quick feedback and directions. I think I fixed most of your requested changes, but I have some problems with the DER and PEM representations. Please let me know if the other changes I made are valid and how I could fix the PEM/DER issue. |
Update with latest `main` commits
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 your fixes, I've left some more notes.
Regarding PEM/DER, right now there is no PEM/DER format for these keys. The only format that is in a final standard is the "raw" format, which is defined in NIST spec FIPS 204 § 7.2. This is what I believe BoringSSL uses today, and that is roughly analogous to the "raw" representation Crypto uses for EC keys.
The most likely source of a spec for DER formatted keys is going to be draft-ietf-lamps-dilithium-certificates. This has defined a tentative private key format and profile for an SPKI public key as well as matching signature format. However, this is non-final, so I don't think we need to implement them at this time. We can stick with the raw representation until the IETF is closer to an answer, or until there's an interoperability need.
If there does become an interoperability need, we can use swift-asn1 to provide the representation, as we do for the EC keys in Crypto.
func signature(for data: some DataProtocol, context: [UInt8]? = nil) throws -> Signature { | ||
let output = try Array<UInt8>(unsafeUninitializedCapacity: Signature.bytesCount) { bufferPtr, length in | ||
let result = data.regions.first!.withUnsafeBytes { dataPtr in | ||
if let context { |
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.
It might be nice to hide this branch in a helper function, something like:
extension Optional where Wrapped == ContiguousBytes {
func withUnsafeBytes<ReturnValue>(_ body: (UnsafeRawBufferPointer) throws -> ReturnValue) rethrows -> ReturnValue {
if let self {
return try self.withUnsafeBytes { try body($0) }
} else {
return try body(UnsafeRawBufferPointer(start: nil, count: 0))
}
}
}
This lets us get a single call to MLDSA65_sign
which makes this code nicer to follow and ensures we don't mix up arguments.
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.
Would this be ok? (Also using your withUnsafeBytes
function)
context.map { Data($0) }.withUnsafeBytes { contextPtr in
CCryptoBoringSSL_MLDSA65_verify(
self.pointer,
signaturePtr.baseAddress,
signaturePtr.count,
dataPtr.baseAddress,
dataPtr.count,
contextPtr.baseAddress,
contextPtr.count
)
}
static let bytesCount = Backing.bytesCount | ||
|
||
fileprivate final class Backing { | ||
let pointer: UnsafeMutablePointer<MLDSA65_private_key> |
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.
This needs to be private
. It's not acceptable for us to access the raw pointer directly, we need to use a with
method to do it.
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.
So should I add a method to PrivateKey.Backing
like this one?
func withUnsafePointer<T>(_ body: (UnsafePointer<MLDSA65_private_key>) throws -> T) rethrows -> T {
try body(self.pointer)
}
Add support for ML-DSA post-quantum digital signatures inside
_CryptoExtras
.Checklist
If you've made changes to
gyb
files.script/generate_boilerplate_files_with_gyb
and included updated generated files in a commit of this pull requestMotivation:
With the advent of quantum computing, the mathematical foundations on which the cryptographic protocols in use today are based have been questioned, as they can easily be circumvented and violated by quantum computers.
While waiting for the creation of quantum computers that work at full capacity, and to protect network communications from "Harvest Now, Decrypt Later" attacks, the cryptographic community is working on post-quantum cryptography algorithms, which work on the traditional computers we use today, but are resistant to future attacks by quantum computers.
One of these algorithms is ML-DSA (AKA Dilithium), a module lattice-based signature scheme standardized by NIST in FIPS 204, that is available inside BoringSSL.
By including ML-DSA inside Swift Crypto, we can get closer to normalizing quantum secure algorithms and start implementing them into our apps and libraries to make them quantum-proof.
Modifications:
Added a
MLDSA
enum inside the_CryptoExtras
module with correspondingPrivateKey
,PublicKey
andSignature
structs that use BoringSSL methods to produce and verify ML-DSA-65 digital signatures, with the code style of other signature schemes in the library.Added tests that cover use cases of the ML-DSA scheme, including test vectors taken from the BoringSSL repo (extracted from a
.txt
file and encoded in JSON).Result:
ML-DSA-65 digital signatures can be created and verified with Swift Crypto.