Skip to content

ed25519, ristretto: more test coverage - #271

Open
tob-scott-a wants to merge 1 commit into
C2SP:mainfrom
tob-scott-a:tests/from-sodium-compat
Open

ed25519, ristretto: more test coverage#271
tob-scott-a wants to merge 1 commit into
C2SP:mainfrom
tob-scott-a:tests/from-sodium-compat

Conversation

@tob-scott-a

Copy link
Copy Markdown
Contributor

Adds 146 regression vectors derived from cryptographic boundary fixes in sodium_compat v2.5.1 and v2.5.2, using vector-forge:

  • 59 Ed25519 small- and mixed-order subgroup cases
  • 34 Ed25519-to-X25519 conversion cases
  • 42 ChaCha20/XChaCha20 counter carry and overflow cases
  • 4 Ristretto255 scalar-inversion cases
  • 7 Secretstream counter and rekey state checkpoints

This also adds four schemas for the new vector formats.

The main idea behind this PR was to write stable test vectors to exercise the attack surface in those releases so that other implementations that currently test with Wycheproof can ensure they are resilient to similar bugs.

@cpu

cpu commented Aug 21, 2026

Copy link
Copy Markdown
Member

Thank you! This is in my list to review when I'm back from a short vacation, later next week.

@cpu cpu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Here's a bit of feedback.

It might also be nice to update README.md with the new coverage.

Comment on lines +76 to +80
"generatorVersion": {
"type": "string",
"description": "DEPRECATED: prefer \"source\" property in test group",
"deprecated": true
},

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add this for new schemas (same feedback for the other new schema files).

},
"curve": {
"enum": [
"ristretto255"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be nicer to avoid single-value enums here (and for operation).

@@ -0,0 +1,109 @@
{

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can drop the _v1 portion of the file name for these new schemas. The only reason some of the files have that today is that there used to be a testvectors/ schema and a testvectors_v1/ schema for some types, but we've removed all the testvectors/ stuff.

"resultScalar": {
"type": "string",
"format": "HexBytes",
"description": "the expected inverse; omitted for invalid tests"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can encode this "required except for invalid" notion into the schema itself. I think the chunked encryption schema has an example.

Same feedback for the other instances.

"publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=\n-----END PUBLIC KEY-----\n",
"tests": [
{
"tcId": 152,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be misunderstanding but I think tcIds 152 .. 180 would be better as result: acceptable with a flag instead of result: invalid. AFAIU RFC 8032 verification satisfies these vectors and this is encoding a stricter subgroup policy.

As a concrete example, upstream libsodium 1.0.18 accepts 160..180, neither that version or current master performs a full subgroup validation.

WDYT? Am I missing something?

"inonce": {
"type": "string",
"format": "HexBytes",
"description": "the 12-byte logical internal nonce"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow why this is 12 bytes instead of 8. It looks like all of the values have a four trailing zero bytes. I thought the nonce construction was counter[4] || inonce[8].

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants