[{"author": "Phillip Hallam-Baker", "text": "

Sign in to the tool or else we end up in a telephone box in Brisbane

", "time": "2023-11-10T12:02:44Z"}, {"author": "Phillip Hallam-Baker", "text": "

Sign in to the tool or else we end up in a telephone box in Brisbane

", "time": "2023-11-10T12:03:39Z"}, {"author": "Mike Ounsworth", "text": "

Yeah, but those can be fairly large.
\nUntitled.jpg

\n
", "time": "2023-11-10T12:03:44Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Mike Ounsworth Tried that, works less well than you might think https://www.hallambaker.com/Images/DrWho/Tardis/TARDIS2016.jpg

\n
", "time": "2023-11-10T12:05:38Z"}, {"author": "Daniel Gillmor", "text": "

The bathroom of one of my local brooklyn bars (now closed, sadly): tardis loo

\n
", "time": "2023-11-10T12:10:42Z"}, {"author": "Daniel Gillmor", "text": "

slide 9 says ML-SLH -- i 'm assuming that meant SLH-DSA

", "time": "2023-11-10T12:15:56Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

slide 9 says ML-SLH -- i 'm assuming that meant SLH-DSA

\n
\n

Yes, typo.

", "time": "2023-11-10T12:18:09Z"}, {"author": "Britta Hale", "text": "

Daniel Gillmor said:

\n
\n

slide 9 says ML-SLH -- i 'm assuming that meant SLH-DSA

\n
\n

Machine Learning - Signatures by Leveled Hypotheses

", "time": "2023-11-10T12:18:10Z"}, {"author": "Britta Hale", "text": "

Britta Hale said:

\n
\n

Daniel Gillmor said:

\n
\n

slide 9 says ML-SLH -- i 'm assuming that meant SLH-DSA

\n
\n

Machine Learning - Signatures by Leveled Hypotheses

\n
\n

Maybe Linked - Signatures that are Layered are Happier

", "time": "2023-11-10T12:20:46Z"}, {"author": "Stephen Farrell", "text": "

the mics are really not picking up if mouths are anyway far away

", "time": "2023-11-10T12:23:00Z"}, {"author": "John Gray", "text": "

Yes, that was a typo in my slides, sorry about that.... Still getting used to the Name change... That was the SLH-DSA.... My bad.

", "time": "2023-11-10T12:28:04Z"}, {"author": "Britta Hale", "text": "

It is fun to have an easter egg typo in the slideset to keep us on our toes...

", "time": "2023-11-10T12:29:28Z"}, {"author": "Jonathan Hoyland", "text": "

What would you say about the security properties of a mixed chain? A chain is only as strong as its weakest link, no?

", "time": "2023-11-10T12:30:23Z"}, {"author": "Yoav Nir", "text": "

I don't think documents can get published when they reference \"living documents\".

", "time": "2023-11-10T12:32:08Z"}, {"author": "Mike Ounsworth", "text": "

Jonathan Hoyland said:

\n
\n

What would you say about the security properties of a mixed chain? A chain is only as strong as its weakest link, no?

\n
\n

You could say something like \"An End Entity certificate using a traditional algorithm MAY be considered to have sufficient strength if its lifetime is sufficiently short that a quantum cryptanalytic attack cannot realistically be performed before the certificate expires; for example an RSA2048 certificate with a 1 hour expiry time, provided that its long-lived signer is using a sufficiently strong PQ algorithm.\"

\n

There are also interesting properties to consider between the algorithm used to sign the cert, and the algorithm used to sign revocation information about that cert.

", "time": "2023-11-10T12:34:45Z"}, {"author": "Jonathan Hoyland", "text": "

Given clock drift can be over 24h in the wild I'd like to see a realistic use case where a 1h cert could be used.

", "time": "2023-11-10T12:35:41Z"}, {"author": "Mike Ounsworth", "text": "

They exist.
\nI want to sign this document with a one-time key.
\nHere's a 30s lifetime cert.
\nGreat, I signed the document with it.

", "time": "2023-11-10T12:36:23Z"}, {"author": "Jonathan Hoyland", "text": "

But actually, now I think on it, you could use channel bindings to prove that \"as long as one cert is secure all certs were used honestly\".

", "time": "2023-11-10T12:36:39Z"}, {"author": "Britta Hale", "text": "
There are also interesting properties to consider between the algorithm used to sign the cert, and the algorithm used to sign revocation information about that cert.\n
\n

Good point ... the security properties in a case like this could very much complicate the security guarantees.

", "time": "2023-11-10T12:39:10Z"}, {"author": "Florence D", "text": "

I think in the terminology draft we wouldn't say much about the security properties of a mixed chain, because it's so broad. Probably something about it being context and implementation dependent.

", "time": "2023-11-10T12:41:57Z"}, {"author": "Britta Hale", "text": "

It might be something for the 'PQ for engineers' draft, since that is focused on guidance,and tradeoffs would be relevant there.

", "time": "2023-11-10T12:43:03Z"}, {"author": "Daniel Gillmor", "text": "

re: name changes: new draft revisions are very cheap. please refresh to the current names, without waiting for Falcon to be renamed.

", "time": "2023-11-10T12:43:07Z"}, {"author": "Mike Ounsworth", "text": "

@Florence D I suggest that two types of \"mixed chains\" should be defined:
\n1) the direct line of keys-that-sign-other-keys (aka certificate chains) use different algorithms.

\n

2) The ancillary stuff like signed revocation status messages, signing or revocation requests, transport encryption of private keys, etc, use different algorithms.

", "time": "2023-11-10T12:44:13Z"}, {"author": "Nicola Tuveri", "text": "

RE:PQC for engineers

\n

can you elaborate on what is intended to be done about text regarding HW-acceleration for PQ?

", "time": "2023-11-10T12:45:48Z"}, {"author": "Rohan Mahy", "text": "

:musical_notes: letting the days go by :musical_notes:

", "time": "2023-11-10T12:46:33Z"}, {"author": "Mike Ounsworth", "text": "

Nicola Tuveri said:

\n
\n

RE:PQC for engineers

\n

can you elaborate on what is intended to be done about text regarding HW-acceleration for PQ?

\n
\n

Is that a MIC question?

", "time": "2023-11-10T12:46:37Z"}, {"author": "Nicola Tuveri", "text": "

Not really, the presenter mentioned that the point was raised by Paul (which one)?

", "time": "2023-11-10T12:47:11Z"}, {"author": "Ben S", "text": "

Should have got in the mic line, but I think I disagree that we need to explicitly list the differences between Kyber and ML-KEM in the engineers draft. My interpretation of the audience of the draft is that it's significantly composed of people who haven't really followed PQ at all, and so adding a bunch of technical details of \"here's how Kyber differs from ML-KEM\" is going to be just noise

", "time": "2023-11-10T12:49:13Z"}, {"author": "Thom Wiggers", "text": "

+++ ^

", "time": "2023-11-10T12:49:28Z"}, {"author": "Mike Ounsworth", "text": "

To me, the differences between \"Kyber\" and \"ML-KEM\" are like the differences between \"Rijndael\" and \"AES\". 6 months from now, nobody will care.

", "time": "2023-11-10T12:50:27Z"}, {"author": "Thom Wiggers", "text": "

Nicola Tuveri said:

\n
\n

RE:PQC for engineers

\n

can you elaborate on what is intended to be done about text regarding HW-acceleration for PQ?

\n
\n

There was a question on the mailing list if it makes sense to add something about HW implementations of PQ (compared to pre-quantum); I consulted with PQShield hardware engineering who told me \"it's impossible to write an answer to this question\"

", "time": "2023-11-10T12:50:40Z"}, {"author": "Thom Wiggers", "text": "

full answer on the mailing list

", "time": "2023-11-10T12:51:06Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Well Rijndael with 128-bit blocks is identical to AES. Kyber is not identical to ML-KEM. I think you should only talk about Kyber if you mean the pre-standard version. That applies 6 months from now as well.

", "time": "2023-11-10T12:52:19Z"}, {"author": "Peter Campbell", "text": "

@Mike I think the point was that if your protocol assumed a property of Kyber that ML-KEM no longer provides, then you probably need to go back and check that everything is still ok.

", "time": "2023-11-10T12:52:37Z"}, {"author": "Phillip Hallam-Baker", "text": "

So, where does an OID for 'Hybrid ECDSA+Dilithium- SHA256' fit?

", "time": "2023-11-10T12:52:58Z"}, {"author": "Phillip Hallam-Baker", "text": "

Weak or strong?

", "time": "2023-11-10T12:53:08Z"}, {"author": "Mike Ounsworth", "text": "

Peter Campbell said:

\n
\n

@Mike I think the point was that if your protocol assumed a property of Kyber that ML-KEM no longer provides, then you probably need to go back and check that everything is still ok.

\n
\n

Agreed, but that's a \"PQC-for-IETF-Designers\" concern, not a \"PQC-for-Engineers\" concern.

", "time": "2023-11-10T12:53:16Z"}, {"author": "Peter Campbell", "text": "

Yeah, maybe.

", "time": "2023-11-10T12:53:44Z"}, {"author": "John Preu\u00df Mattsson", "text": "
\n

So, where does an OID for 'Hybrid ECDSA+Dilithium- SHA256' fit?

\n
\n

I think such an OID should not be used and should be replaced with OIDs for ML-DSA.

", "time": "2023-11-10T12:53:59Z"}, {"author": "Britta Hale", "text": "

Phillip Hallam-Baker said:

\n
\n

So, where does an OID for 'Hybrid ECDSA+Dilithium- SHA256' fit?

\n
\n

It depends on how the certificate keys are bound. Two separate certificates: weak (at best). One cert with both keys: possibly strong. (We are in discussion with the authors of that draft.)

", "time": "2023-11-10T12:54:05Z"}, {"author": "Florence D", "text": "

Phillip Hallam-Baker said:

\n
\n

So, where does an OID for 'Hybrid ECDSA+Dilithium- SHA256' fit?

\n
\n

These aren't properties you can apply to OIDs, they need to be applied to at least the signature as a whole, and perhaps to the signature in a protocol or format (e.g. certificate)

", "time": "2023-11-10T12:54:06Z"}, {"author": "Rohan Mahy", "text": "

Differences between Kyber and ML-KEM
\nimage.png

\n
", "time": "2023-11-10T12:54:07Z"}, {"author": "Thom Wiggers", "text": "

The property of Kyber that is discussed is a fairly niche property (hashing in the ciphertext to the shared secret) that has pretty much only accidentally turned out to be useful when writing KEM combiners. In general, ML-KEM is stil IND-CCA2 and I think that going really deep on this property is weird because other KEM will not have this.

", "time": "2023-11-10T12:54:30Z"}, {"author": "Rohan Mahy", "text": "

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf#subsection.1.3

", "time": "2023-11-10T12:54:36Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Florence D , the OIDs are bound into the signature in most schemes

", "time": "2023-11-10T12:54:47Z"}, {"author": "Mike Ounsworth", "text": "

Thom Wiggers said:

\n
\n

The property of Kyber that is discussed is a fairly niche property (hashing in the ciphertext to the shared secret) that has pretty much only accidentally turned out to be useful when writing KEM combiners. In general, ML-KEM is stil IND-CCA2 and I think that going really deep on this property is weird because other KEM will not have this.

\n
\n

I've got a slide on that in my talk at the end of PQUIP.

", "time": "2023-11-10T12:55:09Z"}, {"author": "Florence D", "text": "

Sure. The \"most\" is important though. It depends on the signature scheme.

", "time": "2023-11-10T12:55:21Z"}, {"author": "Phillip Hallam-Baker", "text": "

So when you sign with RSA, you sign over a tuple of the oid of the hash scheme plus the hash

", "time": "2023-11-10T12:55:40Z"}, {"author": "Thom Wiggers", "text": "

in particular, hashing in the ciphertext helps with the IND-CCA security of combiners; so it's nice that Kyber gave you that but the \"other half\" of the combiner (e.g. DH) _would not_ have this for free.

", "time": "2023-11-10T12:55:41Z"}, {"author": "Ira McDonald", "text": "

Would commenters please speak to the mic? The recording will be inscrutable as is.

", "time": "2023-11-10T12:56:52Z"}, {"author": "Yoav Nir", "text": "

@Ira I'm remote and I'm hearing fine. The recording should be similar

", "time": "2023-11-10T12:57:32Z"}, {"author": "Yoav Nir", "text": "

There's still the issue that remote speakers are much louder than local.

", "time": "2023-11-10T12:57:49Z"}, {"author": "Deb Cooley", "text": "

It is quiet in the room unless they eat the mic.

", "time": "2023-11-10T12:58:03Z"}, {"author": "Britta Hale", "text": "

Phillip Hallam-Baker said:

\n
\n

So when you sign with RSA, you sign over a tuple of the oid of the hash scheme plus the hash

\n
\n

This describes the OID as part of the message (since it is signed) - it is an important distinction since it is not bound to the signature (beyond what a message is).

", "time": "2023-11-10T12:59:07Z"}, {"author": "Ira McDonald", "text": "

Sorry but I am not hearing most of the commenters just fine.

", "time": "2023-11-10T12:59:10Z"}, {"author": "Phillip Hallam-Baker", "text": "

Seems to me that going for the strongest form of non-separability commits to creating new crypto schemes that may well turn out to have holes

", "time": "2023-11-10T12:59:12Z"}, {"author": "Rohan Mahy", "text": "

Mike Ounsworth said:

\n
\n

Thom Wiggers said:

\n
\n

The property of Kyber that is discussed is a fairly niche property (hashing in the ciphertext to the shared secret) that has pretty much only accidentally turned out to be useful when writing KEM combiners. In general, ML-KEM is stil IND-CCA2 and I think that going really deep on this property is weird because other KEM will not have this.

\n
\n

I've got a slide on that in my talk at the end of PQUIP.

\n
\n

Engineers have had this question and are going to continue to have this questions. I'd propose we need to add something in the engineers/implementers draft like:
\n\"Even though ML-KEM removes an extra form of security provided by the Kyber algorithm, its use in the following IETF protocols still has this property...\"

", "time": "2023-11-10T12:59:27Z"}, {"author": "Jonathan Hoyland", "text": "

Yoav Nir said:

\n
\n

There's still the issue that remote speakers are much louder than local.

\n
\n

I think it might just be some people sound loud no matter where they are :flushed: :sweat_smile:

", "time": "2023-11-10T12:59:51Z"}, {"author": "Peter Campbell", "text": "

@Thom In general, you are losing robustness (https://ia.cr/2021/708) which might have been more useful than just for the KEM combiner.

", "time": "2023-11-10T13:00:00Z"}, {"author": "Britta Hale", "text": "

Phillip Hallam-Baker said:

\n
\n

Seems to me that going for the strongest form of non-separability commits to creating new crypto schemes that may well turn out to have holes

\n
\n

It can actually be done blackbox (even to blackbox component implementations). It just depends on the schemes involved/desired.

", "time": "2023-11-10T13:01:00Z"}, {"author": "Britta Hale", "text": "

So getting stronger security does not necessarily demand new standards/algorithms. But having a list of security properties (this draft) allows for a clearer comparison of options.

", "time": "2023-11-10T13:01:59Z"}, {"author": "Ben S", "text": "

Rohan Mahy said:

\n
\n

Mike Ounsworth said:

\n
\n

Thom Wiggers said:

\n
\n

The property of Kyber that is discussed is a fairly niche property (hashing in the ciphertext to the shared secret) that has pretty much only accidentally turned out to be useful when writing KEM combiners. In general, ML-KEM is stil IND-CCA2 and I think that going really deep on this property is weird because other KEM will not have this.

\n
\n

I've got a slide on that in my talk at the end of PQUIP.

\n
\n

Engineers have had this question and are going to continue to have this questions. I'd propose we need to add something in the engineers/implementers draft like:
\n\"Even though ML-KEM removes an extra form of security provided by the Kyber algorithm, its use in the following IETF protocols still has this property...\"

\n
\n

I think it really depends what definition of \"engineer\" you're using. My view is that people who aren't cryptographers shouldn't have to care too much about that stuff.

", "time": "2023-11-10T13:02:37Z"}, {"author": "Mike Ounsworth", "text": "

Bury it in protocols and crypto libs where a small number of experts can get it right, and then developers don't need to think about it.

", "time": "2023-11-10T13:04:24Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Britta Hale For the sequential constructs, maybe, but you probably need to bind to the keys at multiple points you wouldn't normally expect to... But for the simultaneous verification, looks to me like that is a whole new signature scheme

", "time": "2023-11-10T13:04:24Z"}, {"author": "Britta Hale", "text": "

Phillip Hallam-Baker said:

\n
\n

Britta Hale For the sequential constructs, maybe, but you probably need to bind to the keys at multiple points you wouldn't normally expect to... But for the simultaneous verification, looks to me like that is a whole new signature scheme

\n
\n

For simultaneous verification many cases do make minor changes (i.e. an extra value hashed such that both sigs verify simultaneously). In a few cases (e.g. if you wanted RSA-Dilithium or RSA-Falcon for any reason), simultaneous verification blackbox is actually possible. But agreed that stronger binding in general means it is trickier to find a blackbox way of doing it.

", "time": "2023-11-10T13:07:37Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Britta Hale Very likely, I am taking 'simultaneous' more seriously. I agree it is possible to build a system that makes it difficult to muck up. But making it impossible .... there be dragons.

", "time": "2023-11-10T13:10:01Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Britta Hale I think that rather than trying to make a bright shiny object, we return to the security requirements of the applications that result in the requirement for a hybrid signature. In most cases it will turn out to be need for backwards compatibility and the separability will be moot. In others, there will be either regulation or not being confident of *-DSA

", "time": "2023-11-10T13:13:39Z"}, {"author": "Florence D", "text": "

@Phillip Hallam-Baker This draft is about laying out the concepts, it doesn't make a judgement call on any of the properties being \"better\" or \"worse\".

", "time": "2023-11-10T13:14:33Z"}, {"author": "Rohan Mahy", "text": "

Ben S said:

\n
\n

Rohan Mahy said:

\n
\n

Mike Ounsworth said:

\n
\n

Thom Wiggers said:

\n
\n

The property of Kyber that is discussed is a fairly niche property (hashing in the ciphertext to the shared secret) that has pretty much only accidentally turned out to be useful when writing KEM combiners. In general, ML-KEM is stil IND-CCA2 and I think that going really deep on this property is weird because other KEM will not have this.

\n
\n

I've got a slide on that in my talk at the end of PQUIP.

\n
\n

Engineers have had this question and are going to continue to have this questions. I'd propose we need to add something in the engineers/implementers draft like:
\n\"Even though ML-KEM removes an extra form of security provided by the Kyber algorithm, its use in the following IETF protocols still has this property...\"

\n
\n

I think it really depends what definition of \"engineer\" you're using. My view is that people who aren't cryptographers shouldn't have to care too much about that stuff.

\n
\n

Then tell them that so they don't worry about it!

", "time": "2023-11-10T13:17:06Z"}, {"author": "Britta Hale", "text": "

@Phillip Hallam-Baker Indeed! There are definitely dragons! (I believe that we made and broke over 70+ algorithm combiners before finding provably secure ways of building ones that get simultaneous verification). If you take a look at section 4.2 here (https://eprint.iacr.org/2023/423.pdf) you can see that if the final verification step is a hash - and depending on the two algorithms used - it is quite possible: one signature masks part of the the other.

\n

But that is all discussion for a CFRG draft if there is interest, not this security goal document. For this one, it is important to know what security type a given implement is achieving. It could be very problematic if someone thought they had SNS security, for instance, but really was only getting WNS.

", "time": "2023-11-10T13:17:51Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Florence D Understood. But when have we ever proposed a scale and not decided to take it to 11 ?

", "time": "2023-11-10T13:17:51Z"}, {"author": "John Preu\u00df Mattsson", "text": "

I hope most (or all) IETF protocols will used the cfrg-kem-combiners.

", "time": "2023-11-10T13:19:05Z"}, {"author": "Phillip Hallam-Baker", "text": "

why ct_i || rlen(ct_i) etc?
\nSurely the length goes first or people can play games....

", "time": "2023-11-10T13:20:11Z"}, {"author": "Britta Hale", "text": "

@Phillip Hallam-Baker Also, there are use cases that do not need backwards compatibility and where hybrids will be quite necessary... we cannot discount that based on irrelevance in some other cases.

", "time": "2023-11-10T13:20:48Z"}, {"author": "Richard Barnes", "text": "

pls stop changing things kthx

", "time": "2023-11-10T13:24:28Z"}, {"author": "Jonathan Hoyland", "text": "

The more I learn about crypto the less I believe I understand.

", "time": "2023-11-10T13:24:36Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland When you understand nothing, you will understand everything.

", "time": "2023-11-10T13:25:55Z"}, {"author": "Deb Cooley", "text": "

@Jonathan +1000000

", "time": "2023-11-10T13:26:09Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland What is the sound of one MAC, MAC-ing

", "time": "2023-11-10T13:26:12Z"}, {"author": "Aron Wussler", "text": "
\n

why ct_i || rlen(ct_i) etc?

\n
\n

Right encoding from the end also prevents games. Note that FixedInfo is required to be fixed length

", "time": "2023-11-10T13:27:05Z"}, {"author": "Aron Wussler", "text": "

(And this construction does not require to know the length of the ciphertext beforehand)

", "time": "2023-11-10T13:28:59Z"}, {"author": "Peter Campbell", "text": "

@Mike Excellent presentation!

", "time": "2023-11-10T13:29:24Z"}, {"author": "Mike Ounsworth", "text": "

Phillip Hallam-Baker said:

\n
\n

why ct_i || rlen(ct_i) etc?
\nSurely the length goes first or people can play games....

\n
\n

To facilitate streaming APIs; this way you can feed the ct into your hash function piecewise as you receive it. If we put the length first then the receiver needs to store the entire CT until it has gotten to the end and knows the length.

", "time": "2023-11-10T13:30:53Z"}, {"author": "Phillip Hallam-Baker", "text": "

Oh, I see, it is ct_i, not h(ct_i)

", "time": "2023-11-10T13:34:36Z"}, {"author": "Britta Hale", "text": "

+1 Deb!

", "time": "2023-11-10T13:35:18Z"}, {"author": "Phillip Hallam-Baker", "text": "

SHA-3 is getting about because of use as a KDF

", "time": "2023-11-10T13:36:05Z"}, {"author": "Thom Wiggers", "text": "

Isn't this a CFRG / pqc-forum discussion

", "time": "2023-11-10T13:38:35Z"}]