Visitar URL original
SLH-DSA support · Issue #14419 · pyca/cryptography · GitHub
Skip to content

SLH-DSA support #14419

Open
Open

Description

@DarkaMaul

In order to add the support for SLH-DSA in cryptography, I've started to work on adding the test vectors.

However, this PQ algorithm has a signature size issue.

The test vectors from NIST are quite heavy:

Of note, wycheproof has no test vectors for SLH-DSA.

I know the trailofbits/go-slh-dsa uses as tests the full JSON files, but I'm unsure if we want to commit 70 MB of test files in this repo.

If we limit our support to BoringSSL (headers), then we can significantly trim down the number of test vectors:

  • sigVer vectors for SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-256f (the only two parameter sets BoringSSL exposes).
  • Pure, external interface only (matching what SLHDSA_*_verify accepts).
  • 14 tests per parameter set, mix of valid and invalid signatures.
  • Total size: about 1.8MB

It excludes:

  • keyGen vectors: BoringSSL API does not expose a way to generate a key from a seed
  • sigGen vectors: BoringSSL only supports randomized signing - deterministic vectors cannot be verified
  • other parameter sets
  • prehash vectors
  • internal vectors

But, if / when we support another backend (e.g. OpenSSL), we would have to extend those test vectors.

I see several paths forward (rough size estimates in parentheses):

  • Keep the whole vectors files (unnecessarily large)
  • Keep the whole vectors files but trim down internal and prehash versions (15MB)
  • Keep only 2 tests per parameter set, down from 14 (3MB)
  • Keep only 1 test per parameter set (1.5MB)
  • Trim the test vectors to only test the prefix/suffix of the signature (?) - the most compact, but also somewhat unsatisfying

Activity

  1. reaperhulk commented on Mar 4, 2026

    @reaperhulk
    Member

    This is fine as a tracking issue, but given limited maintainer bandwidth let's focus on landing ML-DSA with a single backend before moving to another algorithm.

  2. DemiMarie commented on Mar 5, 2026

    @DemiMarie

    Is BoringSSL going to be preferred going forward?

  3. dataCenter430 commented on Mar 9, 2026

    @dataCenter430

    hey, @DarkaMaul thanks for reporting this.
    If you're comfortable, I'd love to take this. Or are you on it?

  4. DarkaMaul commented on Mar 10, 2026

    @DarkaMaul
    ContributorAuthor

    If you're comfortable, I'd love to take this. Or are you on it?

    I've actually already started digging into this one - happy to see it through. I'll post updates here as I make progress!

  5. mschulz-at-hilscher commented on Jun 16, 2026

    @mschulz-at-hilscher

    Please also support HashSLH-DSA.

  6. DarkaMaul commented on Jun 18, 2026

    @DarkaMaul
    ContributorAuthor

    As part of the discussion in #14700

    I searched to see where the support for SLH-DSA landed:

    It is missing from:

    • AWS-LC (the search returns no results)
    • LibreSSL

    I have opened an issue in AWS-LC to ask if they plan to implement it: aws/aws-lc#3305

  7. jakemas commented on Jul 14, 2026

    @jakemas

    Yep, on roadmap for aws-lc!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions