Ascon demo release, JSON files, and intermediate values

[Ross, Noah G. (Fed)]

Hello, Ascon is now available on our demo server. The modes included are: AEAD128, Hash256, XOF128, and CXOF128. Attached are some sample JSON files that would be used on the ACVP server.  For those unfamiliar with the CAVP file formats, the prompt.json file contains properties describing a series of tests within a test group, labeled with a test group identifier, tgId. Individual inputs are provided as test cases, labeled with a test case identifier, tcId. The expectedResults.json contains the outputs associated with the prompt.json. In other words, tcId 1 from the prompt.json will produce the content in tcId 1 from the expectedResults.json. Both sets are combined in the internalProjection.json, also identified with a tcId. Additionally, there are intermediate value files attached to assist in debugging.

[Anjan Roy]

Dear NIST,

Thank you very much for producing the KATs. Hoping to see the standard published soon.

Regards,

Anjan Roy

On Fri, 25 Apr 2025, 01:29 'Ross, Noah G. (Fed)' via lwc-forum, <lwc-...@list.nist.gov> wrote:

Hello, Ascon is now available on our demo server. The modes included are: AEAD128, Hash256, XOF128, and CXOF128. Attached are some sample JSON files that would be used on the ACVP server.  For those unfamiliar with the CAVP file formats, the prompt.json file contains properties describing a series of tests within a test group, labeled with a test group identifier, tgId. Individual inputs are provided as test cases, labeled with a test case identifier, tcId. The expectedResults.json contains the outputs associated with the prompt.json. In other words, tcId 1 from the prompt.json will produce the content in tcId 1 from the expectedResults.json. Both sets are combined in the internalProjection.json, also identified with a tcId. Additionally, there are intermediate value files attached to assist in debugging.

--
To unsubscribe from this group, send email to lwc-forum+...@list.nist.gov
Visit this group at https://groups.google.com/a/list.nist.gov/d/forum/lwc-forum
To unsubscribe from this group and stop receiving emails from it, send an email to lwc-forum+...@list.nist.gov.

[Mark Wagner]

Dear NIST,

Thanks for posting the KATs. I have incorporated many of them into my unit tests.

However, I may have found an issue with the AEAD nonce-masking tests.

For example, consider AEAD test case #170.

When I use the secondKey as the nonce mask, my test fails. However, if I ignore the secondKey and go without nonce masking, the test passes. So, it is like the NIST implementation does not support nonce-masking.

I am not sure if all the nonce-masking tests behave this way, but #170 does.

For your information, when I use the secondKey as the nonce mask, I get this:
ct = 1BBD78F87BF5D799DCCEBD049810FF713148C710F92310641F68A249FD734742BDB337B7C9F8ECE07042E8CE0A3A3F3E
tag = EB62E012B11BEC33

Perhaps another lwc-forum member could confirm or deny this result.

Best,
Mark Wagner

[Mark Wagner]

Quick follow-up to my post above concerning AEAD test case #170.

I realize now that this is a decrypt test case, so for the chosen ciphertext, the expected result is the specified plaintext and tag.

However, I used the specified plaintext as the chosen value and then did a full encrypt/decrypt loopback on that value. This produced the ciphertext and tag I included in the post. Naturally, decrypt re-produced the original plaintext but with the same tag as encrypt. So, to me, the mismatched values where the ciphertext and tag.

This does not change the root issue that nonce masking was not performed as expected. However, I realize now that this may have caused some confusion.

Regards,

Mark Wagner

[Celi, Christopher T. (Fed)]

Hi Mark,

 

Thanks for letting us know. We’ve identified the fix and are putting together a new set of test vectors along with intermediate values and some other related fixes. You can expect some updated files next week. This only impacted cases where “supportsNonceMasking” was set to true. It was not an error in the Ascon implementation but in the code calling it, leading to the wrong nonce value being stored in the JSON.

 

Thanks,

Chris Celi

CAVP Program Manager

[Markku-Juhani O. Saarinen]

Hello,

Thanks for posting these; I recently tried them and didn't find any correctness issues. 

But unless I am missing something, the tests may be missing crucial coverage of the authentication function: Ascon-AEAD128 tests (in gen-val/json-files/Ascon-AEAD128-SP800-232) only contain valid authentication tags. Essentially, a broken implementation whose AEAD decryption function would not verify the authentication would pass all of the tests. Recall that Algorithm 4, Ascon-AEAD128.dec, should return "fail" in there is a tag mismatch. 

The comparable AEAD tests in ACVP-AES-GCM-1.0 do have negative test cases (and hence, testing coverage of message authentication); for the decryption function expectedResults.json contains both "pt: <something>" and "testPassed: false" cases.

ps. I don't know if fractional-byte ADs and ciphertexts are very useful in practice -- very few APIs support them. However, I suppose that's fine as long as an Ascon implementation can be certified (with some caveat), even if it supports only full-byte lengths.

Cheers,

-markku

[Celi, Christopher T. (Fed)]

Hi Markku,

 

Decryption fail tests on AEAD128 were added recently and are being published soon.

 

In terms of supporting bit-oriented inputs instead of just byte-oriented inputs, we can confirm that the very large majority of implementations use bytes only. This is perfectly fine for testing because you can specify that when registering for the tests. The CAVP is compelled to implement the entire standard and offer validation testing for it.

 

Thanks,

Chris Celi

CAVP Program Manager

 

[niux_d...@icloud.com]

Thanks for the official test vectors. Minor nitpick here.

While testing for Ascon-Hash256, I run into massive failures that I thought was a regression at the beginning before I realized that those failing tests were bit-oriented whereas my implementation is byte-oriented.

I know Ascon is meant for constrained environments like this, but can NIST provide more byte-oriented test cases? Ascon-based satellite ultimately have to interoperate with other hosts through the network in the end, which in majority of cases are octet-oriented.

Thank you for your attention.

DannyNiu/NJF.

2025年4月25日 05:28，'Ross, Noah G. (Fed)' via lwc-forum <lwc-...@list.nist.gov> 写道：

[Anjan Roy]

Totally agree. Having more test vectors, where input/ output lengths are multiple of 8, would be really helpful. Right now that number is low.

Kind regards,

Anjan Roy

[Celi, Christopher T. (Fed)]

Hi,

The CAVP always publishes pre-generated tests vectors here: https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files. 

Thanks,

Chris Celi

CAVP Program Manager

[niux_d...@icloud.com]

I should probably send this on a different thread and with a different title. Computer-based systems need byte-oriented test vectors; bit-string vectors are useful for satellite systems that're e.g. 4-bit, etc. but ultimately they need to interoperate with hosts over networks that're typically octet-oriented. 

Some existing vectors even have odd bit-length, which frankly aren't very useful.

Would appreciate some update on this part, Chris.

The CAVP always publishes pre-generated tests vectors here: https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files. 

Thanks,

Chris Celi

CAVP Program Manager

[Celi, Christopher T. (Fed)]

Hi,

Because it is allowed in the standard, the CAVP will support it. Attached is a set of test vectors for all four Ascon algorithms with only byte-oriented lengths. 

Thanks,

Chris

[Anjan Roy]

Dear Chris,

Thanks for sharing these new software friendly  test-vectors. My C++ `constexpr` header-only library implementation @ https://github.com/itzmeanjan/ascon is passing them.

In case one needs to parse internalProjection.json to simpler key-value pair text format, I've utility Python scripts @ https://github.com/itzmeanjan/ascon/tree/d236f533f44c3c172347586e8b94dd245dae0c1b/kats/scripts.

Thanks,

Anjan