Using more than one mode in an app

[carl-wallace]

I set out to use this library in a certificate validation library but ran into issues trying to support any of modes 2, 3 and 5. I refactored a fork of the library to use proc macros to allow generating independent implementations and changed the features so all three can be used simultaneously. A copy is here: https://github.com/carl-wallace/dilithium/tree/macros. I have confirmed I can verify certificate signatures for each mode in a WASM project, but have not done any testing beyond that as yet. Any thoughts on the desire to use > 1 mode (did I miss something that made that possible as it was?) or on using proc macros to achieve this end?

[mberry]

Any thoughts on the desire to use > 1 mode

Definitely, it's been long on the list, not just for Dilithium but also Kyber/Sphincs, hopefully all in a consistent manner.

In sphincs there's a draft approach using const generics which is a messy solution in the current state of const generics where you need explicit trait bounds bubbling up, in the extreme case leading to api function signatures like this:

  fn sign(sig: &mut[u8], msg: &[u8], keypair: Keypair<F128>) 
  where [(); F128::CRYPTO_PUBLICKEYBYTES]:,
        [(); F128::CRYPTO_SECRETKEYBYTES]:,
        [(); F128::SPX_BYTES]:,
        [(); F128::SPX_N]:,
        [(); 2*F128::SPX_N]:,
        [(); F128::SPX_WOTS_LEN]:,
        [(); F128::SPX_DGST_BYTES]:,
        [(); F128::WOTS_STACK_LEN]:,
        [(); F128::SPX_FORS_MSG_BYTES]:,
        [(); F128::SPX_TREE_HEIGHT * F128::SPX_N + F128::SPX_WOTS_BYTES]:,
        [(); F128::SPX_FORS_HEIGHT]:,
        [(); F128::FORS_STACK_LEN]:,
        [(); F128::SPX_ADDR_BYTES + 2 * F128::SPX_N]:,
        [(); F128::SPX_ADDR_BYTES + 1 * F128::SPX_N]:,
        [(); F128::SPX_ADDR_BYTES + F128::SPX_FORS_TREES * F128::SPX_N]:,
        [(); F128::SPX_ADDR_BYTES + F128::SPX_WOTS_LEN * F128::SPX_N]:,
        [(); (F128::SPX_WOTS_LEN2 * F128::SPX_WOTS_LOGW + 7) / 8]:,
  {

Obviously that's not a good outcome, but it works and allows all modes to be used concurrently.

The other options are code duplication or macros, as you've done here. Const generics was what I'd hoped for but as time goes on I'd really like to get it done and not sure about the timeline for removing explicit bounds, if it ever comes.

Duplication isn't desirable from a maintainer point of view, 3x the number of LOC helps no one, but it would be simple to implement.

That leaves macros, which seem the reasonable compromise here. I'm not entirely sold on proc over declarative macros though. I've had a read over your code and it looks good, but do we really to bring in syn and quote to get this done? Quite sure this could all be done inline without resorting to the heavy-handedness of proc macros.

[carl-wallace]

Thanks for the reply. I initially set out to identify what all would need to be parameterized from the api level down but that exploded pretty quickly so I shifted over to procmacros. That approach fell together pretty quickly. It could be tightened up but I tried to retain the existing code and structure to as great an extent as possible. I will give a look at whether declarative macros can work and will look at sphincs more closely (but it will likely be a few weeks before I get to it). Do you know of any pure Rust Falcon implementations by chance?

On other note, there were apparently some changes in the draft NIST standard for Dilithium (at least). So some code that had been successfully interoperating with other implementations both with your code and PQClean fails now against implementations that have been updated (which is only BouncyCastle so far in this hackathon group). Thanks again.

[mberry]

Fair enough, can see proc macros being easier to implement. I'll have to check out the changes, assume you mean for ML-DSA here? There's been no new commits on the pq-crystals repo or changes in the KAT's in a long time. Don't know any falcon implementation, I started on one a while ago but it got put on the backburner. Falcon is bit harder to implement than any of the others.

…

---- On Tue, 03 Oct 2023 18:34:45 +0800 ***@***.*** wrote ---- Thanks for the reply. I initially set out to identify what all would need to be parameterized from the api level down but that exploded pretty quickly so I shifted over to procmacros. That approach fell together pretty quickly. It could be tightened up but I tried to retain the existing code and structure to as great an extent as possible. I will give a look at whether declarative macros can work and will look at sphincs more closely (but it will likely be a few weeks before I get to it). Do you know of any pure Rust Falcon implementations by chance? On other note, there were apparently some changes in the draft NIST standard for Dilithium (at least). So some code that had been successfully interoperating with other implementations both with your code and PQClean fails now against implementations that have been updated (which is only BouncyCastle so far in this hackathon group). Thanks again. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>