Gemss #79
Gemss #79
Conversation
new security noition: EUF-CMA
There was a problem hiding this comment.
See comments below. There's mainly one thing I'd like to change about the flavors, see below, and a couple minor things.
I've looked at some of the benchmark numbers and all those I checked differ from those in the specs I have here (from NIST, same as the one in the pdf I just added in the last commit), so I assume it's not a typo but we have different versions. Where is your pdf from?
| classical: 128 | ||
| quantum: 174 | ||
| nist category: 1 | ||
| failure probability: -24204404 |
There was a problem hiding this comment.
For signature schemes, I think it is always possible to detect a failure and create a second signature, thus effectively reaching a zero failure probability. Unfortunately, they don't talk about this in the specs. Did you have a look at the implementation, by chance?
| @@ -0,0 +1,3 @@ | |||
| name: GeMSS | |||
There was a problem hiding this comment.
It seems to me that the "colors" are not really separate flavors (they don't differ in anything but the numbers), but rather just "groups" of parameter sets. At least, the data you've entered is the same everywhere. It looks like the implementations are also all the same, correct?
I'd suggest we merge them into one flavor. (That should be quickly done by some copy'n'pasting. I can do it if you like. I like hacking around with sed ;) )
There was a problem hiding this comment.
Where is the documentation what flavours are for? Like, what is our intention, when to use flavours?
There was a problem hiding this comment.
Yeah, R&S have already mentioned this, there's indeed a lack of documentation here.
Basically, what we thought about when making up the separation was that there's things that are
- more different than just parameter sets
- but still belong together somehow
for example, because they have a differing API (for example a passively secure PKE (KTM) and an actively secure KEM built upon the former), or completely different and incompatible implementations (for example, one scheme using AES and one using Shake). The latter is not a harsh definition, this could also be implemented as parameter sets, but we thought it's clearer when we call them flavors).
Because the red/blue/vanilla GeMSS schemes only differ in the numbers, it's a quite clear case of parameter sets. What is different between them is just how strict they are in the qubits<->category relation. (Personally, I'd expect NIST to opt for one "color" (=calculation method) and throw out the rest anyways)
There was a problem hiding this comment.
If you can do it easily, I would prefer if you do it.
The other changes are done.
There was a problem hiding this comment.
Done. In fact, it didn't even involve sed, just renaming and moving :)
|
I used the data given in https://www-polsys.lip6.fr/Links/NIST/changes_round2_V2.pdf |
No description provided.