Generate SP 800-232 compatible Ascon-AEAD128 test vectors

[smuellerDD]

As reported and validated in [1], the Ascon test vectors apply to the NIST finalist proposal of Ascon, but not SP800-232, i.e. the standardized version of AsconAEAD-128.

May I propose to include the updated Ascon vector set from [1]?

[1] bleichenbacher-daniel/Rooterberg#8

[cpu]

Thanks for reporting. I think short-term we could certainly clarify that the vectors in-repo are for a pre-standardization version to help avoid confusion. I also agree with you that having vectors for the standardized version would be an excellent contribution. Are you interested in making a PR?

May I propose to include the updated Ascon vector set from [1]?

As mentioned on the other issue, I don't believe that would be workable in the current state as the vectors in [1] are not under a compatible license. If they were available under an Apache-2.0 compatible license I would be happy to review a PR from you, or the original author that imports them. Ideally matching the general shape of the pre-existing vectors unless there was a strong reason it wasn't workable.

[cpu]

the Ascon test vectors apply to the NIST finalist proposal of Ascon, but not SP800-232

Just to verify: this applies to all of testvectors_v1/ascon80pq_test.json, testvectors_v1/ascon128_test.json, and testvectors_v1/ascon128a_test.json?

[cpu]

Just to verify: this applies to all of testvectors_v1/ascon80pq_test.json, testvectors_v1/ascon128_test.json, and testvectors_v1/ascon128a_test.json?

Answering my own question: yes, and AFAICT SP 800-232 only specified Ascon-AEAD128 based on the v1.2 Ascon128a. I don't think there's an equivalent to the 64-bit rate or 160-bit key variants. If I'm mistaken, constructive feedback on #263 is welcome. I have no direct experience with these lightweight cryptography algorithms.

I think it won't be especially difficult to generate similar SP 800-232 vectors, and I propose we do that under an unambiguous filename like testvectors_v1/ascon_sp800_232_aead128_test.json using the pre-existing schema aead_test_schema_v1.json. I don't know when I'll have time to tackle that personally (again, PRs welcome!), but in the meantime #263 can hopefully avoid further confusion. Once it lands I will re-title this issue as a request for SP 800-232 vectors

[smuellerDD]

SP800-232 only defines:

• Ascon-AEAD128 (using the Ascon sponge defined in v1.2 as Ascon128a)
• Ascon-Hash256, Ascon-XOF and Ascon-CXOF (using the Ascon sponge defined in v1.2 as Ascon128)

All other definitions in v1.2 are not in SP800-232.

Generating general vectors is kind of straight forward. But the question is which edge conditions are of interest and should be applied to the test vectors?

[cpu]

All other definitions in v1.2 are not in SP800-232.

Great, I think that matches what I described above👍

Generating general vectors is kind of straight forward. But the question is which edge conditions are of interest and should be applied to the test vectors?

As a starting point we could at least take the ascon128a_test.json testcases spit-out by the original gen_ascon.py but use a SP800-232 compatible implementation instead of v1.2 version. That would at least give equivalent coverage to what exists today for v1.2.

Beyond that, as an implementer of the algorithm you probably have a better sense than I do of what would be valuable edge conditions to test. When you were implementing the standard in LeanCrypto was there anything that stood out to you as an interesting edge case that could make a good testcase? I'm happy to do the gruntwork of translating things into the expected schema/format if that would be helpful.

[cpu]

@smuellerDD I used this as an excuse to experiment with Trail of Bits' tooling for generating vectors using existing implementations and mutation testing. Please take a look at #267 when you have a chance and let me know how LeanCrypto's implementation fares. I think the results are pretty good (and certainly better than no vectors at all!) but feedback is welcome.