[{"author": "Daniel Gillmor", "text": "

just wanted to say that this \"Guidelines for writing cryptography specifications\" draft is really great guidance. even when it seems obvious it's really helpful to set these things down clearly and explicitly.

", "time": "2023-03-31T00:38:51Z"}, {"author": "Massimiliano Pala", "text": "

+1

", "time": "2023-03-31T00:40:39Z"}, {"author": "Mike Ounsworth", "text": "

+1 to Nick's \"how to write crypto specifications\" draft

", "time": "2023-03-31T00:42:13Z"}, {"author": "Benson Muite", "text": "

+1

", "time": "2023-03-31T00:50:16Z"}, {"author": "Aron Wussler", "text": "

I would definitely keep negative test vectors, but they might misleading making an implementer that they covered all edge cases

", "time": "2023-03-31T01:20:45Z"}, {"author": "Jeremie Miller", "text": "

IANA test vector registry? :)

", "time": "2023-03-31T01:21:31Z"}, {"author": "Mike Ounsworth", "text": "

Move test vectors to an (IETF-owned) github repo?

", "time": "2023-03-31T01:22:00Z"}, {"author": "Daniel Gillmor", "text": "

I just want to make sure the test vectors are available as reliably as the draft itself.

\n

Github could go away, or lock out the IETF from their repos, etc

", "time": "2023-03-31T01:22:34Z"}, {"author": "Daniel Gillmor", "text": "

(maybe not! if we're ok being all-in on github anyway, then i guess it's not much different)

", "time": "2023-03-31T01:24:21Z"}, {"author": "Yoav Nir", "text": "

Implementers don't look at IANA's website. That's why RFCs say \"IANA has assigned the id 17 to the BLABLA payload\" rather than \"check out IANA's registry for the id of BLABLA\". Similarly, we don't want to require them to go to github.

\n

The test vectors should be in the draft itself, perhaps in an appendix.

", "time": "2023-03-31T01:24:54Z"}, {"author": "Aron Wussler", "text": "

+1

", "time": "2023-03-31T01:25:33Z"}, {"author": "Daniel Gillmor", "text": "

i wonder whether the datatracker could have \"auto-collapsed\" sections to avoid scaring people, and \"page count\" stats could show the length without the collapsed sections. I'd love it if the test vectors in draft-ietf-lamps-header-protection didn't make the draft so scarily long.

", "time": "2023-03-31T01:26:29Z"}, {"author": "Mike Ounsworth", "text": "

Right. I'm having the same issues with the LAMPS composites draft where the sample PEM public keys will end up being well over 50% of the page length. Is that really helpful or just noise?

\n

In particular, SPHINCS+ signature samples are multiple pages each (and a pain in the butt to copy out of the draft cause you've got to remove newlines, page footers, etc)

", "time": "2023-03-31T01:30:04Z"}, {"author": "Yoav Nir", "text": "

Collapsing appendices seems to be a tractable thing

", "time": "2023-03-31T01:30:22Z"}, {"author": "David Waite", "text": "

I prefer the additional RFC approach for test vectors, personally

", "time": "2023-03-31T01:30:39Z"}, {"author": "Daniel Gillmor", "text": "

@David Waite for all test vectors, or just for negative test vectors?

", "time": "2023-03-31T01:31:03Z"}, {"author": "David Waite", "text": "

examples in the main RFC also exposed as positive test vectors in the second.

", "time": "2023-03-31T01:32:39Z"}, {"author": "David Waite", "text": "

so the test vectors doc is a superset, with values in the main document there to serve an illustrative purpose

", "time": "2023-03-31T01:33:59Z"}, {"author": "Mike Ounsworth", "text": "

David Waite said:

\n
\n

so the test vectors doc is a superset, with values in the main document there to serve an illustrative purpose

\n
\n

I like that.

", "time": "2023-03-31T01:34:15Z"}, {"author": "Aron Wussler", "text": "

I don't really see the negative side of having a long RFC, with test vectors in an appendix.I would see an advantage in having the vectors draft published later for additional scrutiny (or gather additional feedback on the vectors themselves), but once the RFC is set, it makes sense to have all material in a single place

", "time": "2023-03-31T01:37:15Z"}, {"author": "Alexey Melnikov", "text": "

FYI, in real time transcription Alexey Melnikov should be replaced with Stanislav Smyshlyaev.

", "time": "2023-03-31T01:38:47Z"}, {"author": "Daniel Gillmor", "text": "

I do think that positive test vectors should be cleanly and clearly separated from negative test vectors. and each negative test vector should be clearly annotated with what specifically has gone wrong, and a reasonable way for how the failure should present in the abstract API

", "time": "2023-03-31T01:43:14Z"}, {"author": "Christopher Wood", "text": "

Wycheproof is a good example of what negative test vectors can look like, including the additional context that DKG mentions.

", "time": "2023-03-31T01:44:11Z"}, {"author": "Daniel Gillmor", "text": "

seems like a pattern we should hash out in Nick's guidelines draft

", "time": "2023-03-31T01:44:22Z"}, {"author": "Christopher Wood", "text": "

Indeed!

", "time": "2023-03-31T01:46:19Z"}, {"author": "Christopher Wood", "text": "

Citing Wycheproof as a positive example for others to follow.

", "time": "2023-03-31T01:46:37Z"}, {"author": "Armando Faz-Hern\u00e1ndez", "text": "

negative test vectors allow to spot common errors often made by implementers.

", "time": "2023-03-31T01:49:12Z"}, {"author": "Mike Ounsworth", "text": "

[appsec testing hat]
\nIt's staggering the number of times that I find unit or functional tests with robust positive tests and absolutely no negative test cases. I often frame this as \"quality tests\" vs \"security tests\". If you don't have any tests for \"This had better not work\", then you haven't done any security testing.

", "time": "2023-03-31T01:51:46Z"}, {"author": "Richard Barnes", "text": "

love when the happy path is the fast path

", "time": "2023-03-31T01:56:19Z"}, {"author": "Tim Geoghegan", "text": "

+1 to Chris, it's totally fine for VDAF to allow for more aggregators than DAP does

", "time": "2023-03-31T02:03:46Z"}, {"author": "Richard Barnes", "text": "

\"2 servers should be enough for everybody!\"

", "time": "2023-03-31T02:03:49Z"}, {"author": "Daniel Gillmor", "text": "

was there a memo that every cfrg slide deck MUST include art from randall munroe?

", "time": "2023-03-31T02:08:14Z"}, {"author": "Deb Cooley", "text": "

it is a good question

", "time": "2023-03-31T02:08:33Z"}, {"author": "Aron Wussler", "text": "

That should go in the guidance as well

", "time": "2023-03-31T02:09:11Z"}, {"author": "Stavros Kousidis", "text": "

Yes, there is a reason: We are heavily relying on the random oracle properties of Keccak.

", "time": "2023-03-31T02:11:01Z"}, {"author": "Richard Barnes", "text": "

sorry, errant click

", "time": "2023-03-31T02:11:38Z"}, {"author": "Phillipp Schoppmann", "text": "

Regarding SHA3 vs SHA2: We also went for SHA3 in some parts of VDAF, because it defines an extendable output function that we use to instantiate a random oracle (with variable-length output), and it was faster than HKDF+SHA2. But we'd also be very interested if there is an efficient SHA2 based construction.

", "time": "2023-03-31T02:14:40Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

was there a memo that every cfrg slide deck MUST include art from randall munroe?

\n
\n

I wonder if Randall Munroe knows that his art appears all over crypto conference slides? I imagine he would not be displeased.

", "time": "2023-03-31T02:22:04Z"}, {"author": "Richard Barnes", "text": "

i would note that the HPKE IANA registries are Specification Required, so there's no need for CFRG to take any action in order to register the code points

", "time": "2023-03-31T02:22:13Z"}, {"author": "Massimiliano Pala", "text": "

Thank you!

", "time": "2023-03-31T02:24:04Z"}, {"author": "Kazue Sako", "text": "

Thank you!

", "time": "2023-03-31T02:24:13Z"}, {"author": "Daniel Gillmor", "text": "

I've just posted this about test vectors: https://github.com/ietf-tools/datatracker/issues/5457

", "time": "2023-03-31T02:24:22Z"}]