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 MLDSA 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]

Nice, we're getting a lot closer here!

[Lukasa]

I think we can make this a touch more efficient. We can store both of these fields in their useful formats. For the private key, we can just have a var key: MLDSA65_private_key, and then derive pointers as needed.

For the seed, we can use a withUnsafeTemporaryAllocation and then directly create a Data from it. Data is the format we need elsewhere anyway.

[fpseverino]

This means that we don't need a Backing class?

[Lukasa]

Technically it does, but we should keep it to avoid us abusing the power of @_implementationOnly.

[Lukasa]

Same note here, we can store the MLDSA64_public_key directly inline here.

[Lukasa]

Do we want module here?

[fpseverino]

I added it just to complete the ML-DSA acronym, maybe I could add an hyphen between it and lattice to make it clearer, as in the FIPS title

[Lukasa]

I don't think we need an unsafeTemporaryAllocation. We can just zero-initialize the value self.key = .init() and then take a pointer to it.

[fpseverino]

Got it. I also tried to remove the seed's unsafeTemporaryAllocation by passing to the BoringSSL function an empty [UInt8] var and then initializing the Data object from it, but I encountered some seg faults in testing