How do we store varying secret key sizes

[taudor]

We don't track for Dilithium the short secret key size (96 bytes, see Specification, section 3.1). We should either remove the benchmarks with short_sk or add the additional parameter sets.

[taudor]

@dingens suggested that we remove the benchmarks and add the short key sizes to the corresponding parameter sets as comment.

[benj-zen]

I'd rather add the missing parameter sets, since it gives an interesting time-space tradeoff.

[dingens]

This is a general issue not only about dilithium.

The main problem is that we have somewhat over-simplified our data model by storing the secret key size as a property of the parameter set, when in fact it can vary between implementations. The comment way I suggested is how we "solved" this for most of the other schemes.

I don't think adding a separate parameter set is a good way. We'd have a ton of additional parameter sets that are not really separate parameter sets because they are interoperable.

I'd stick with the simple one KAT is one paramset rule. I tend to think secret key size is not among the important factors for selecting a scheme (memory usage is more critical and we don't store that a lot currently), so it's enough to just store some well balanced sk size (as chosen by the authors) and go with that.

If we want to store more data but without changing the scheme too much*, we could add field minimum_sk and times/{sign,dec}_from_minimum.
(* which would mean a) (cleanest) adding it to a new object which depends on impl and paramset, or b) (a little redundant but avoiding a new object) adding it to bench). That'd complicate quite some things so I don't think that's worth it.