While the scale-up in the replacement of ECDH for key exchange happens at scale with the hybrid replacement using ECDH and ML-KEM, we do not see such an advancement with digital certificates. This means that the digital trust element of the Internet is open to quantum-computer risks.

So perhaps one of the most significant advances in digital trust on the Internet within the past decade or so is … RFC 10073: Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for Use in X.509 Public Key Infrastructure [here]:

This pairs the public keys of RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, or Ed448 with ML-DSA (Module-Lattice-Based Digital Signature Algorithm using X.509 digital certificates. Our digital certificates are going to get a whole lot larger.

Overall, with digital signing, we have a public key and a private key, and where we sign a hash of a message with the private key to create the signature, and then verify the signature with the associated public key:

One problem we have is how do we trust the public key from the entity? For this, Alice will pass her public key to a trusted entity (Trent), and then who creates a digital certificate with her public key, and then signs it with his own private key. When Bob receives the certificate, he will verify the trustworthiness of the digital certificate using Trent’s public key (and which he will already have in his trusted certificate store):

Alice will then sign messages for Bob using her private key, and then Bob checks this against her trusted public key. The X.509 certificate is thus fundamental in this, as it allows Alice’s public key to be trusted.

Basic steps

The basic steps involve in creating the traditional key pair (such as with RSASSA-PSS) and ML_DSA is:

Composite-ML-DSA<OID>.KeyGen() -> (pk, sk)

Input: None
Output: (pk, sk) The composite key pair.

1. Generate component keys.
mldsaSeed = Random(32)
(mldsaPK, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed)
(tradPK, tradSK) = Trad.KeyGen()

2. Check for component key generation failure.
if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK):
output "Key generation error"

3. Output the composite public and private keys.
pk = SerializePublicKey(mldsaPK, tradPK)
sk = SerializePrivateKey(mldsaSeed, tradSK)
return (pk, sk)

Here we see that a 32-byte seed value is used to create the ML-DSA key part, and that a traditional public key method also creates another key pair. The public keys are then serialised together, and the private keys also. When we export the certificate, we will only export the public keys, and keep the private keys secret.

When the digital certificate is signed:

Composite-ML-DSA<OID>.Sign(sk, M, ctx) -> s

Inputs: 
Explicit inputs: sk Composite private key consisting of signing private keys
for each component.

M The message to be signed, an octet string.

ctx The application context string used in the composite

signature combiner, which defaults to the empty string.

And then to sign, we take the traditional private key (tradSK) and the ML-DSA private key (mldsaSK) and sign the digital certificate (M’). We then serialise these two signatures together:

mldsaSig = ML-DSA.Sign( mldsaSK, M', mldsa_ctx=Label )
tradSig = Trad.Sign( tradSK, M' )



s = SerializeSignatureValue(mldsaSig, tradSig)

The output (s) is then used as the signature for the hybrid certificate.

Key and signature sizes

Unfortunately, the key and signature sizes will increase, and where we will move from 64 bytes for an ECDSA signature to 2,208 bytes for the dual public keys with ML-DSA-65:

Method                    Public key size    Private key size   Signature size  Security level
------------------------------------------------------------------------------------------------------
ML-DSA 44                 1,312              2,528              2,420         1 (128-bit) Lattice
ML-DSA 65                 1,952              4,000              3,293         3 (192-bit) Lattice
ML-DSA 87                 2,592              4,864              4,595         5 (256-bit) Lattice

RSA-2048                  256                256                256
ECC 256-bit                64                 32                256

The signature sizes will increase to, and from 256 bytes for ECDSA to 3,549 bytes for dual signing. Overall, the supported signatures will be:

sa-MLDSA44-RSA2048-PSS-SHA256 |
sa-MLDSA44-RSA2048-PKCS15-SHA256 |
sa-MLDSA44-Ed25519-SHA512 |
sa-MLDSA44-ECDSA-P256-SHA256 |
sa-MLDSA65-RSA3072-PSS-SHA512 |
sa-MLDSA65-RSA3072-PKCS15-SHA512 |
sa-MLDSA65-RSA4096-PSS-SHA512 |
sa-MLDSA65-RSA4096-PKCS15-SHA512 |
sa-MLDSA65-ECDSA-P256-SHA512 |
sa-MLDSA65-ECDSA-P384-SHA512 |
sa-MLDSA65-ECDSA-brainpoolP256r1-SHA512 |
sa-MLDSA65-Ed25519-SHA512 |
sa-MLDSA87-ECDSA-P384-SHA512 |
sa-MLDSA87-ECDSA-brainpoolP384r1-SHA512 |
sa-MLDSA87-Ed448-SHAKE256 |
sa-MLDSA87-RSA3072-PSS-SHA512 |
sa-MLDSA87-RSA4096-PSS-SHA512 |
sa-MLDSA87-ECDSA-P521-SHA512,

We can see that RSA-2K/3K/4K-PSS and RSA-2K/3K/4K-PCKSv15 are supported for RSA signatures , and Ed25519, P256 and Brainpool P384 as elliptic curve signatures — along with ML-DSA-44, ML-DSA-65 and ML-DSA-87 signatures.

The supported hybrid public keys are:

pk-MLDSA44-RSA2048-PSS-SHA256 |
pk-MLDSA44-RSA2048-PKCS15-SHA256 |
pk-MLDSA44-Ed25519-SHA512 |
pk-MLDSA44-ECDSA-P256-SHA256 |
pk-MLDSA65-RSA3072-PSS-SHA512 |
pk-MLDSA65-RSA3072-PKCS15-SHA512 |
pk-MLDSA65-RSA4096-PSS-SHA512 |
pk-MLDSA65-RSA4096-PKCS15-SHA512 |
pk-MLDSA65-ECDSA-P256-SHA512 |
pk-MLDSA65-ECDSA-P384-SHA512 |
pk-MLDSA65-ECDSA-brainpoolP256r1-SHA512 |
pk-MLDSA65-Ed25519-SHA512 |
pk-MLDSA87-ECDSA-P384-SHA512 |
pk-MLDSA87-ECDSA-brainpoolP384r1-SHA512 

Pre-hashing

In the ML-DSA method, we can create a pre-hash of a message and then use this to create a digital signature. Normally, in a digital signature, Bob will take a message (M) and then pass this and his private key (sk) to a signature method for:

Sig=Sign(sk,M)

and where we pass the message to the signature method, and which will then take a hash of the message and produce the signature:

Press enter or click to view image in full size

But, what if the message is large and we are using a limited processing device? Well, for this, we could perform the hashing outside the signature method, and thus perform a pre-hashing process, and pass the pre-hash into the signature method:

Sig=Sign(sk,H(M))

and where the message value passed will be much smaller than a large method. This will help with the buffering requirement for the signature method, and where we typically will just require 32 bytes (for a 256-bit hash) or 64 bytes (for a 512-bit hash):

These days, a typical hash is produced by SHAKE256, and where we output a 512-bit hash value

With SHAKE256, we have an XOF function; where we can create any length of hash. Normally, for a Pre-hash, this is a 512-bit hash.

Pre-hashing reduces the burden on the signer

The great advantage of a Pre-hash is that we can use a powerful CPU to generate the Pre-hash and then pass it to a limited processing device, such as a smart card. It is unlikely that the smart card will have a great deal of memory to buffer a large message. In this case, the smart card has a private key stored, and then where a powerful CPU computes a Pre-hash and then passes this to the smart card, and which then returns the signature based on the Pre-hash, the signing method and the private key:

Press enter or click to view image in full size

Supporting other cryptographic hashing methods in signature

Another advantage of using a pre-hash is that we might want to use a new cryptographic function that is not supported by the signature method. For example, we might want to use Blake2b for our signature. For this, we can then create a Blake2b Pre-hash:

Overcoming forgery attacks

One problem is that we need to make sure that the verification process knows about the pre-hash and where a pre-hash needs to be created before the verification process. This can lead to a forgery attack. Luckily this can be overcome by using domain separation. With this, we add a context (ctx), and where the Pre-hash is computed with:

H = hash(M) using SHAKE256 with 512-bit output

S = sign( 0 || OID(SHAKE256 with 512-bit output) || ctx || H )

In this case we identify the SHAKE256 with a 512-bit output with its OID in the message password to the signature production. The normal signature would then just be:

S = sign(1 || ctx || M )

The method of using the OID and Pre-hash is defined in the ML-DSA specification [here]:

Conclusions

The specification of RFC 10073 is a massive step forward and should allow the Internet to migrate its trust infrastructure from our traditional public key methods to hybrid ones, and then to eventually drop the requirements for traditional public key signatures. One thing that is for sure is that certificates will get a whole lot larger, and that the migration can now properly start at scale, so there are no more excuses for delaying.

One of the Greatest Changes in Digital Trust in Decades: Hybrid Digital Certificates was originally published in ASecuritySite: When Bob Met Alice on Medium, where people are continuing the conversation by highlighting and responding to this story.

Old methods … new hacks!

I often get offers for cryptography/blockchain jobs. Some of these are genuine, but many are fake. In one case, I received the most amazing job opportunity in cryptography research and which paid around $650K and where I could work from Edinburgh:

To me, it was obvious to me that an AI agent had scanned my profile and created the best job ever for me, and communicated with me by email. I then asked to speak to the sender of the email on LinkedIn (to show if I was speaking to a human or not), but that was rejected (even though the “person” has a LinkedIn profile):

And then the scammer was worried that LinkedIn was full of scammers:

So, to see how the scam worked, I sent my long academic CV, and the person responded to say that the CV needed work, and that I needed to contact an external company to create a new one for me, and which would be focused on the job:

There in was the scam. For a fee an external company would create a CV for me for a job that has never existed. So I replied:

And so it went on, and where it became increasingly obvious that I was speaking to an AI agent over email:

and so it went on:

The Binance hack

The Guardian has now outlined an HR scam that went so much deeper [here]. In 2026, within the Binance hack ($6.3bn), an employee within Binance’s cryptowallet team was tricked into installing a backdoor Trojan (June 2026) and which exposed an employee’s role and the other members in the team. This then led to a series of bogus job interviews. For this, a fake project director contacted another engineer in the team on a legitimate job-hunting platform. The first-round video interview then involved a sham HR representative, and then the second-round interview on a chat app involved the “chief executive” of a fictitious company. At this interview, the person was tricked into downloading malware onto their computer.

On 20 October, the adversary compromised the target’s computer and an internal AI tool. This gained access to the engineer’s IT infrastructure and to a second wallet developer. Just nine days after this, the adversary then used the second developer’s computer and the compromised ⁠credentials from the first engineer to run a malicious script for the attack [1].

Basically, what we see here is old methods — HR scams and malware downloads — and a new hack. To lose $6.3bn from hot wallets is unbelievable, and where the human weaknesses of clicking on links to download malware and the desire for a new job led to the largest hack ever! Basically, we are flawed, and as long as there are humans in an organisation, there will be major weaknesses.

References

[1] Hackers behind $6.3bn Binance heist ‘used malware and bogus job interviews’, https://www.theguardian.com/profile/danmilmo, The Guardian, 2026

Beware of Job Recruitment Scams, Malware and AI Compromises … Your Company Could Lose Billions was originally published in ASecuritySite: When Bob Met Alice on Medium, where people are continuing the conversation by highlighting and responding to this story.