Post-quantum Aptos accounts via SLH-DSA-SHA2-128s signatures

AIP-137: Post-quantum Aptos accounts via SLH-DSA-SHA2-128s signatures

It’s like this: if you think quantum computers able to break 2048-bit cryptography within 3-5 years are a near-certainty, then I’d say your confidence is unwarranted.
[..]
On the other hand, if you think Bitcoin, and SSL, and all the other protocols based on Shor-breakable cryptography, are almost certainly safe for the next 5 years… then I submit that your confidence is also unwarranted.
Your confidence might then be like most physicists’ confidence in 1938 that nuclear weapons were decades away, or like my own confidence in 2015 that an AI able to pass a reasonable Turing Test was decades away.
It might merely be the confidence that “this still looks like the work of decades—unless someone were to gather together all the scientific building blocks that have now been demonstrated, and scale them up like a stark raving madman.”
The trouble is that sometimes people, y’know, do that.
— Scott Aaronson¹

Summary

This AIP proposes adding SLH-DSA-SHA2-128s² as the first post-quantum (PQ) signature scheme for Aptos accounts. This scheme was recently standardized as post-quantum by NIST in FIPS-205². Both its classical and quantum security rely solely on the security of the SHA2-256³ hash function.

[!NOTE] The v3.1 spec³ clarifies in Section 7.2.2 that the $n=16$ SHA2 variants use SHA2-256.

The spirit of this AIP is to conservatively-prepare for the looming threat of cryptographically-relevant quantum computers (CRQCs), should they materialize in the next decade or less.

Given how CRQCs timelines range anywhere from 5 to 50 years¹, this AIP’s “conservative” approach means:

• the security assumptions behind the PQ scheme are abundantly cautious: i.e., breaking them quantumly or classically would be an immense technological surprise
• efficiency can be sacrificed, in favor of security
• the complexity of integrating the PQ scheme in Aptos is low

In this sense, this AIP finds SLH-DSA to be an ideal candidate for such a conservative, quantum-proof, low-complexity deployment. In particular, the SLH-DSA family is appealing because it only relies on hash functions and is thus clearly not likely to be broken classically. (Furthermore, the relied-upon hash functions are already trusted today in the Aptos ecosystem.) This stands in contrast with other, more “aggressive”, PQ schemes, which rely on exotic assumptions that may not even be classically-secure (e.g., see the Rainbow discussion). As a result, such aggressive schemes need to be combined with a classically-secure scheme to mitigate risks, which increases complexity.

Out of scope

• ZKPoKs for key rotation in Aptos Move are out of scope: for now, key rotation will be done via the well-known private entry function: 0x1::aptos_framework::account::rotate_authentication_key_call.
• Aggressively-optimizing the choice of the signature scheme to maximize performance. This will be done later by adding more PQ schemes.

Impact

If we accept, deploy and enable this proposal, it would impact almost all of the Aptos ecosystem:

• Aptos full nodes and validators will need to be upgraded to support deserializing and verifying these new signatures
• Indexer needs to become aware of the new signature scheme
• Wallets may choose to implement support for this scheme
• Aptos SDK and CLI needs to add support for managing accounts and creating signatures using this new scheme
• (There may be other components that were missed.)

If we do not accept this proposal, it will leave us and our users open to technological surprise. In contrast, if accepted, Aptos governance can simply turn on post-quantum accounts as soon as rumors of a CRQC become sufficiently-worrisome. (Or, it can be turned on much earlier, to allow users to migrate when they deem it necessary.)

Alternative Solutions

While alternative PQ signature schemes would have smaller signature sizes and verification times, the SLH-DSA family in FIPS-205² is the most conservative choice security-wise: it relies solely on the (already-premised) security of SHA2-256.

This makes it an ideal candidate to easily mitigate against the possibility that a classical (not even quantum) adversary may break the supposedly-PQ-secure scheme. Such attacks have happened in the past on candidate PQ schemes: e.g., Rainbow, based on multivariate cryptography, was a NIST finalist yet it was completely broken on a commodity laptop in 2022⁴.

It also makes it a great choice for highly-conservative blockchain users who do not want to rely on new assumptions and/or aggressive parameterizations of novel, more-efficient, PQ signature schemes.

ML-DSA

In the future, we may choose to additionally-support a member of the ML-DSA family from FIPS-204⁵, since the combined public key and signature size will be half of SLH-DSA’s (e.g., ML-DSA-65 have 1,9252-byte pubkeys and 3,309-byte signatures). Another advantage of ML-DSA is that its signature verification time is even faster: it outperforms Ed25519’s⁶

As a disadvantage, ML-DSA’s security is based on the hardness of the module learning with errors (MLWE) problem, which is less conservative.

Falcon

Another candidate would be Falcon⁷, whose combined pubkey and signature size is $\approx$ 1.5 KiB. Furthermore, its verification time matches Ed25519 or is even faster. As disadvantages:

1. Falcon requires floating point arithmetic, which makes implementing it very error prone.
2. Falcon’s security relies on the hardness of SIS over NTRU lattices, which is less conservative.

Specification and Implementation Details

Notes:

• We use the SLH-DSA implementation in the slh-dsa crate⁸ from the RustCrypto/signatures⁹ ecosystem
• We implement the aptos-crypto traits for signatures, private keys and public keys.
• Currently, we use deterministic signing.
• We unit test for:
  • correctness (i.e., honestly-produced signatures pass verification)
  • SK, PK and signature (de)serialization work
  • key generation works
  • deterministic signing being enabled
• TODO: Give the name of the feature flag.

AIP-80 prefixes

AIP-80¹⁰ defines a prefix for each key type (private / public) and its scheme (e.g., Ed25519, SLH-DSA-SHA2-128s).

For our private keys, we propose:

"slh-dsa-sha2-128s-priv-"

While for our public keys:

"slh-dsa-sha2-128s-pub-"

Indexer support

For now, the TS SDK uses "slh_dsa_sha2_128s" as the scheme name, from the indexer’s PoV. See src/types/types.ts in aptos-ts-sdk once PR #802 merges:

export function anyPublicKeyVariantToString(variant: AnyPublicKeyVariant): string {
  switch (variant) {
    case AnyPublicKeyVariant.Ed25519:
      return "ed25519";
    case AnyPublicKeyVariant.Secp256k1:
      return "secp256k1";
    case AnyPublicKeyVariant.Secp256r1:
      return "secp256r1";
    case AnyPublicKeyVariant.Keyless:
      return "keyless";
    case AnyPublicKeyVariant.FederatedKeyless:
      return "federated_keyless";
    case AnyPublicKeyVariant.SlhDsaSha2128s:
      return "slh_dsa_sha2_128s";
    default:
      throw new Error("Unknown public key variant");
  }
}

48-byte SLH-DSA secret keys

[!WARNING] Hopefully, this is wrong, but: the FIPS standard suggests SKs are only 32 bytes by (I think) assuming that the PK is available and not lost. This is not only unfortunate, but also misleading and potentially-dangerous, as it incorrectly suggests that given such a 32-byte SK the PK can be derived from it, which is simply not true. And, without the PK, signatures cannot be created even though the (32-byte) SK is available. This would cause users who only back up their SK to permanently lose access to their funds.

Therefore, in this AIP and in our implementation, we work with the proper SK, which is actually 48 bytes as it additionally-includes the “PK seed” component from the public key, which is picked randomly and independently from the other SK components. This proper SK is sufficient for signing and thus for restoring access to the account (e.g., after recovering it from a mnemonic).

Support for BIP-32 HD wallets

[!WARNING] This will risk becoming non-standard as other chains and/or hardware wallets could also deploy SLH-DSA-SHA2-128s but choose to implement their own HD scheme.

For now, this is just an initial attempt at having something working, rather than the final HD scheme.

Our (temporary) decisions:

• We set the SLIP-0010¹¹ "Curve" parameter to "SLH-DSA-SHA2-128s seed"
• We leave the “curve order” n set to $2^{256}$
  • i.e., we work directly with the 32 byte sequences outputted by HMAC-SHA512 in BIP-32’s¹² CKDPriv
• We enforce hardened derivation only
  • This is natural, since there’s no key homomorphism (like Ed25519)
• We set:
  • the 16-byte SK seed and 16-byte PRF seed to the 32-byte secret key outputted by CKDPriv
  • the 16-byte PK seed to the first 16 bytes of the (potentially-public) “chain code” outputted by CKDPriv
    • TODO: Revise this since leaking the chain code will make it so that an adversary who has any leaked key in the BIP-32 tree of keys can obtain any other child key, it seems. (See here.) In fact, perhaps draw this tree to depict how it works for later reference.

[!WARNING] We need to reason about the security of using the chain code in this way.

In our TypeScript SDK, the implementation for deriving an SLH-DSA private key given a mnemonic-derived seed and a derivation path¹³ path looks like this:

    const { finalSecretKey, finalChainCode } = bip32derive("SLH-DSA-SHA2-128s seed", seed, path);

    // We derive our 48-byte SLH-DSA key (three 16-byte seeds) from:
    //  - the 32-byte BIP-32-derived, secret key
    //  - the first 16 bytes of the BIP-32-derived chain code

    // First 32 bytes from the derived secret key
    const slhDsaPrivateKey = new Uint8Array(48);
    slhDsaPrivateKey.set(finalSecretKey, 0);

    // Last 16 bytes from the derived chain code
    slhDsaPrivateKey.set(finalChainCode.slice(0, 16), 32);

PRs

[!NOTE] PRs checked with ‘x’ have been merged.

• Add SLH-DSA-SHA2-128s (FIPS 205) to aptos-crypto (#18293)
• Add SLH-DSA-SHA2-128s TXN authenticator (#18300)
• Add SLH-DSA-SHA2-128s signatures to TS SDK (#802)
• Add indexer support
• Update Aptos docs
• Add CLI support
• TODO: Add future PRs here.

Testing

Testing plan:

• unit tests for the signature scheme
• e2e smoke test ensuring that TXN signatures (do not) verify when the feature is (not) enabled
• API test
• e2e test using the SDK
• e2e test using CLI

Benchmarks

Signature sizes are 7,856 bytes. They are large, but not impractical.

Public key sizes are 32 bytes.

Secret key sizes are 48 bytes.

The scheme is sufficiently-fast to be used on Aptos.

x86_64 single-threaded benchmarks:

slh_dsa/sha2-128s/sig_deserialize
                        time:   [1.8641 µs 1.9651 µs 2.0566 µs]
                        thrpt:  [486.24 Kelem/s 508.88 Kelem/s 536.45 Kelem/s]

slh_dsa/sha2-128s/pk_deserialize
                        time:   [80.803 ns 96.276 ns 120.82 ns]
                        thrpt:  [8.2768 Melem/s 10.387 Melem/s 12.376 Melem/s]

slh_dsa/sha2-128s/sign_32_bytes
                        time:   [284.77 ms 284.97 ms 285.30 ms]
                        thrpt:  [3.5051  elem/s 3.5091  elem/s 3.5117  elem/s]

slh_dsa/sha2-128s/verify_32_bytes
                        time:   [291.21 µs 294.23 µs 297.16 µs]
                        thrpt:  [3.3651 Kelem/s 3.3987 Kelem/s 3.4339 Kelem/s]

In particular, signature verification times are 5x slower than Ed25519 on x86_64:

ed25519/sig_verify_struct
                        time:   [60.211 µs 60.236 µs 60.265 µs]
                        thrpt:  [16.593 Kelem/s 16.601 Kelem/s 16.608 Kelem/s]

[!NOTE] To replicate these single-threaded benchmarks:
cd aptos-core/crates/aptos-crypto/
$ cargo bench -- slh_dsa/sha2-128s
$ cargo bench -- ed25519/sig_verify

[!NOTE] For more PQ signature schemes benchmarks see (1) this public GitHub repo by Project 11⁶ and (2) this PQC Suite B README¹⁴.

Risks and Drawbacks

Aptos network performance impact

TXN signatures will be larger: 7,856 bytes for the actual signature and 32 bytes for the public key: 82 $\times$ larger than Ed25519 (64 + 32 bytes) and 23 $\times$ larger than a KeylessSignature ($\approx$ 294 + 52 bytes).

If PQ accounts become popular, then P2P and validator network traffic would increase, potentially leading to congestion.

The historical state of the Aptos chain would also become larger.

Fortunately, both can be mitigated against via adequate gas pricing and by adding support for faster, more succinct PQ schemes. (Recall that the gas cost of an Aptos TXN is already computed as a function of its size, including the signature size.)

This AIP’s main argument is that this loss in performance is reasonable given:

1. the uncertainty around CRQCs
2. the uncertainty behind some novel assumptions and/or parameterizations of PQ schemes
3. the complexity of some PQ schemes (e.g., Falcon)
4. the conservative nature of SLH-DSA’s assumption: it relies solely on the security of the SHA2 hash function.

Reiterating: more efficient schemes that make more exotic cryptographic assumptions can be deployed later (see Alternative Solutions).

[!NOTE] To replicate the KeylessSignature sizes:
$ cd aptos-core/types/src/keyless/
$ cargo test -- test_keyless_groth16_sizes --ignored --nocapture

Backwards compatibility

This proposal can impact backward compatibility if deployed recklessly without feature gating. Naturally, we do feature gate our implementation.

Theoretically-bounded # of signatures

While the signature scheme is “stateless” (like Ed25519), it only supports signing $\le 2^{64}$ messages. Nonetheless, as clarified in FIPS-205, even “if a key pair were used to sign 10 billion ($10^{10}$) messages per second, it would take over 58 years to sign $2^{64}$ message².”

Efficiency within hardware wallets

It is very important that Aptos account signature schemes, such as the one proposed here be hardware-wallet friendly Hardware wallets are one of the few ways in which Aptos users can more effectively secure their accounts to prevent key leak, key theft and key loss.

Unfortunately, currently, hardware wallets are low-CPU, low-memory environments that may have trouble executing the SLH-DSA signing algorithm.

Dicussions on the bitcoindev@googlegroups.com mailing list¹⁵ suggest that, for a Trezor Model T wallet, it takes 75 seconds to create one SLH-DSA-SHA2-128s signature. The full benchmarks can be found here but are partially replicated below for posterity:

Operation or property	FN-DSA-512	ML-DSA-44	SLH-DSA-SHA2-128s	SLH-DSA-SHA2-128f
NIST security category16	1	2	1	1
generate_keypair	2,000 ms / 20 kB	21 ms / 42 kB	9,800 ms / 3.3 kB	150 ms / 3 kB
sign	510 ms / 44 kB	78 ms / 55 kB	75,000 ms / 10 kB	3,600 ms / 20 kB
verify	7.0 ms / 5.0 KB	21 ms / 36 kB	75 ms / 2.0 kB	210 ms / 2.6 kB
Secret key size	1281 B	2560 B	64 B	64 B
Public key size	897 B	1312 B	32 B	32 B
Signature size	666 B	2420 B	7856 B	17088 B
Full implementation size	61 kB	15 kB	13 kB	13 kB
Verification implementation size	11 kB	11 kB	11 kB	11 kB
Hash implementation size	4.7 kB	5.6 kB	8.2 kB	8.2 kB
Hash function used	SHAKE-256	SHAKE-128,256	SHA-256	SHA-256

Notes:

• The SLH-DSA-SHAKE2 numbers, excluded above, are several times slower than the SHA2 ones.
• FN-DSA-1024 (Falcon?) runs out of memory
• ML-DSA-65 and 87 run out of memory

Security Considerations

The SLH-DSA signature scheme family was selected precisely due to its conservative approach to security. Since this family only relies on hash functions, it remains classically-secure under the same assumptions used throughout the Aptos ecosystem. Crucially, it also remains quantum-secure, unless better attacks that outperform Grover’s search are discovered.

Choice of hash function

The SHA2 variant of SLH-DSA was chosen due to its higher verification speed when compared to the SHAKE variants (e.g., see Macbook Pro M1 Max benchmarks¹⁷).

[!WARNING] This was the case on ARM, but we should also confirm on x86_64, while accounting for hardware acceleration differences. For example, the SPHINCS⁺ reference implementation¹⁸ with AVX2 instructions could be used.

One could argue that the Keccak sponge-based SHAKE variants are more secure since they do not rely on Merkle-Damgaard. This is up for debate.

Lastly, there are faster variants based on Blake3 being worked on. These are not standardized but may reach wide adoption due to their higher efficiency. If so, they can be proposed as a separate scheme in their own AIP.

Side-channel and fault attacks

The NIST submission³ states that SLH-DSA (referred to as “SPHINCS+”) is naturally free of secret-dependent branches or memory accesses:

Typical implementations of SPHINCS⁺ are naturally free of any secret dependent branches or secretly indexed loads or stores. SPHINCS⁺ implementations are thus free of the two most notorious sources of timing variation. An exception is potentially SPHINCS⁺-Haraka, because Haraka is based on AES.

Importantly, this AIP does not propose the Haraka variant.

Regarding differential power and EM attacks, the NIST submission³ also says:

We expect that any implementation of SPHINCS⁺ without dedicated protection against differential power or electromagnetic radiation (EM) attacks or against fault-injection attacks will be vulnerable to such attacks. Deployment scenarios of SPHINCS⁺ in which an attacker is assumed to have the power to mount such attacks require specially protected implementations. [..] One additional line of defense against such advanced implementation attacks is included in the specification of SPHINCS⁺, namely the option to randomize the signing procedure via the value OptRand.

This additional line of defense is referred to as hedged signing in FIPS-205² and is currently disabled in our implementation but could easily be enabled.

“The difficulty of protecting SPHINCS+ from side-channel attacks is mostly determined by the difficulty of protecting a keyed hash implementation from side-channel attacks.”¹⁹

In this sense, this AIP seeks to encourage discussion around whether the deployment scenario (e.g., software wallets, hardware wallets, web-based wallets) allow for differential power / EM attacks or for fault attacks. (Recall the discussion board is here.)

Future Potential

One possibility is that a CRQC does not materialize in the next 5 years yet a lot of concerned Aptos users have nonetheless chosen to use this scheme. The end result is that Aptos becomes an overall less efficient network. Fortunately, this is easy to detect and address by adding more efficient PQ schemes and increasing the gas cost of SLH-DSA, forcing users to migrate.

Another possibility is that a CRQC does materialize sooner than expected. In that case, our users are either already rotated to this PQ scheme, or can rotate when they find out.

In summary, there is both:

• positive potential of protecting the Aptos network in case of technological surprise
• low chance of negative potential of slowing down the Aptos network, if too many users enable the PQ scheme and the Aptos network is too slow in introducing faster PQ schemes

Timeline

Suggested implementation timeline

Milestones:

• Add support in the aptos-crypto crate
• Feature-gated Aptos VM signature verification logic for these new PQ accounts
• TypeScript SDK support
• Support to derive SKs from mnemonics
• Feature-gated gas pricing for the new signature verification logic
• CLI support: key generation, key storage and signing
• Indexer support
• Developer documentation

Suggested developer platform support timeline

See milestones above.

Suggested deployment timeline

In the next year, there is no urgency to deploy this on any of the networks.

Nonetheless, we can target a preliminary devnet deployment early next year.

Open Questions (Optional)

Q0: Threshold-friendly signature schemes

TODO: Address the difficulty of thresholdizing hash-based signature schemes.

Q1: How to best-implement HD wallet support for this scheme?

This is important as it allows software wallets to derive PQ accounts for their users using pre-existing mnemonics.

One desiderata would be to maximize our chances of compatibility with future implementations in hardware wallets.

The difficulty is that we are proverbially “shooting in the dark:” it’s difficult to fathom what hardware wallet implementors like Ledger or Trezor will choose to do.

Q2: Should we use hedged (randomized) signing or deterministic signing (currently-enabled)?

Hedged signing would add a layer of protection against differential power / EM attacks³. See discussion in the security section.

It is unclear what would be lost by enabling it, beyond some level of conceptual simplicity.

Q3: Should BHT-style²⁰ quantum attacks on hash functions simply be dismissed?

They do not seem to be considered in the NIST submission³. Perhaps their impracticality may be the reason?²¹

Q4: To what extent are RowHammer attacks on SLH-DSA concerning?

e.g., a recent paper²² shows RowHammer software-only attacks can be used to forge signatures.

However, the paper cites these kinds of attacks as being applicable to other PQ schemes such as ML-DSA and Falcon. It may be that assuming the attacker is co-located on the same core with the victim is simply too powerful.

Footnotes

1. Quantum Investment Bros: Have you no shame?, Scott Aaronson, Nov. 20th, 2025 ↩ ↩²

2. FIPS 205: Stateless Hash-Based Digital Signature Standard; by National Institute of Standards and Technology (NIST); 2024 ↩ ↩² ↩³ ↩⁴ ↩⁵

3. SPHINCS+ – Submission to the 3rd round of the NIST post-quantum project. v3.1; by Jean-Philippe Aumasson, Daniel J. Bernstein, Ward Beullens, Christoph Dobraunig, Maria Eichlseder, Scott Fluhrer, Stefan-Lukas Gazdag, Andreas Hülsing, Panos Kampanakis, Stefan Kölbl, Tanja Lange, Martin M. Lauridsen, Florian Mendel, Ruben Niederhagen, Christian Rechberger, Joost Rijneveld, Peter Schwabe, Bas Westerbaan; 2022; [URL] ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

4. Breaking Rainbow Takes a Weekend on a Laptop; by Ward Beullens; 2022, [URL] ↩

5. FIPS 204: Module-Lattice-Based Digital Signature Standard; by National Institute of Standards and Technology (NIST); 2024 ↩

6. Post-Quantum Signature Scheme Benchmarks; Conor Deegan @ Project 11 ↩ ↩²

7. Falcon: Fast-Fourier Lattice-based Compact Signatures over NTRU ↩

8. slh-dsa crate ↩

9. RustCrypto/signatures ↩

10. AIP-80: Standardize Private Keys, Greg Nazario, 2024 ↩

11. SLIP-0010: Universal private key derivation from master private key ↩

12. BIP-32: Hierarchical Deterministic Wallets ↩

13. Multi-Account Hierarchy for Deterministic Wallets ↩

14. PQC Suite B: Faster Post-Quantum Cryptography with BLAKE3 ↩

15. conduition’s reply in “Hash-Based Signatures for Bitcoin’s Post-Quantum Future” ↩

16. Post-Quantum Cryptography - Security (Evaluation Criteria); by National Institute of Standards and Technology (NIST); 2017 ↩

17. Post-quantum signature schemes: Performance of RustCrypto/signatures, Alin Tomescu, 2025 ↩

18. sphincs/sphincsplus ↩

19. Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process; Gorjan Alagic, David Cooper, Quynh Dang, Thinh Dang, John M. Kelsey, Jacob Lichtinger, Yi-Kai Liu, Carl A. Miller, Dustin Moody, Rene Peralta, Ray Perlner, Angela Robinson, Daniel Smith-Tone, Daniel Apon; July 5th, 2024 ↩

20. Quantum cryptanalysis of hash and claw-free functions; by Brassard, Gilles and Høyer, Peter and Tapp, Alain; in SIGACT News; 1997; [URL] ↩

21. Cost analysis of hash collisions : will quantum computers make SHARCS obsolete?, by Daniel J. Bernstein, 2009, [URL] ↩

22. SLasH-DSA: Breaking SLH-DSA Using an Extensible End-To-End Rowhammer Framework, by Jeremy Boy and Antoon Purnal and Anna Pätschke and Luca Wilke and Thomas Eisenbarth, 2025 ↩