Add ML-DSA post-quantum signatures to _CryptoExtras

[fpseverino]

Add support for ML-DSA post-quantum digital signatures inside _CryptoExtras.

Checklist

• I've run tests to see all new and existing tests pass
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

If you've made changes to gyb files

• I've run .script/generate_boilerplate_files_with_gyb and included updated generated files in a commit of this pull request

Motivation:

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 MLDSA65 enum inside the _CryptoExtras module with corresponding PrivateKey, PublicKey and Signature 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.

[fpseverino]

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.
Unlike RSA, where there are clear BoringSSL methods for generating and parsing them, I can't find any for ML-DSA. Maybe there are some generic ones? Or a pure Swift implementation (perhaps with swift-asn1) is possible/required?

Please let me know if the other changes I made are valid and how I could fix the PEM/DER issue.
Thanks again for the help!

[Lukasa]

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.

[Lukasa]

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.

[fpseverino]

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
    )
}

[Lukasa]

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.

[fpseverino]

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)
}

[Lukasa]

We can use the rawRepresentation.regions.count == 1 dance here too, instead of the flatMap.

[fpseverino]

When I rewrite it like

let bytes: ContiguousBytes = rawRepresentation.regions.count == 1 ? rawRepresentation.regions.first! : Array(rawRepresentation)
try bytes.withUnsafeBytes { buffer in
    var cbs = CBS(data: buffer.baseAddress, len: buffer.count)
    guard CCryptoBoringSSL_MLDSA65_parse_private_key(self.pointer, &cbs) == 1 else {
        throw CryptoKitError.internalBoringSSLError()
    }
}

an error on the CBS init appears, on buffer.baseAddress: Cannot convert value of type 'UnsafeRawPointer?' to expected argument type 'UnsafePointer<UInt8>?' because initializer 'init(data:len:)' was not imported from C header.

Changing it to CBS(data: buffer.baseAddress?.assumingMemoryBound(to: UInt8.self), len: buffer.count) seems to work, is it fine?

[Lukasa]

It is not, but we don't need it. We want to use a withMemoryRebound(to:) instead. This dance should probably also be wrapped up in a helper function to avoid distracting in the flow here.

[Lukasa]

I don't think this type is pulling its weight, honestly. Right now there's only a "raw" ML-DSA signature format, and so we should treat this more like we treat Curve25519, where the output of the signing operation is just Data.

[fpseverino]

There's an annoying thing in the signature and isValidSignature methods that I don't know how to solve:

I wanted to give a separate generic type to the context argument, like Curve25519 (and now also MLDSA65) do for the data and signature arguments, but since it is nil by the default the compiler can't infer it.
The solution in place right now is to use the same generic type as data.

[Lukasa]

Thanks for this, and sorry for the delay in review! Generally I'm really happy with how this looks. I've left a few notes in the diff.

[Lukasa]

Let's make this private to prevent misuse.

[fpseverino]

I marked this fileprivate (even though its class already is) because it's used in the public key backing

[Lukasa]

Let's make this two methods: one which takes a context explicitly, and one that doesn't. That allows us to add a separate generic type parameter for the context.

[Lukasa]

Let's split this into two methods, rather than taking the context as an optional. That will let us give the context its own generic type parameter.

[Lukasa]

OK, two very minor nits and then I think we're good to go. I'll also kick the tests off here so we have that information.

[Lukasa]

Ok, this looks really nice. Thanks for your hard work here @fpseverino! ✨

[fpseverino]

Thank you @Lukasa for all the help and guidance you have given me!