[{"author": "Lorenzo Miniero", "text": "

Are the mics in the room turned on? We don't get any audio from there

", "time": "2024-03-18T03:01:51Z"}, {"author": "Deirdre Connolly", "text": "

No audio from Nick

", "time": "2024-03-18T03:02:23Z"}, {"author": "Robert Moskowitz", "text": "

Hear you now.

", "time": "2024-03-18T03:02:25Z"}, {"author": "Daniel Gillmor", "text": "

i can hear nick

", "time": "2024-03-18T03:02:32Z"}, {"author": "Deirdre Connolly", "text": "

hm

", "time": "2024-03-18T03:02:36Z"}, {"author": "Martin Thomson", "text": "

This room is pretty sparse. RWC has hit this group pretty hard.

", "time": "2024-03-18T03:03:46Z"}, {"author": "Christopher Patton", "text": "

Plenty of folks online, MT

", "time": "2024-03-18T03:04:08Z"}, {"author": "Deirdre Connolly", "text": "

different computer has audio :skull:

", "time": "2024-03-18T03:04:29Z"}, {"author": "Christopher Patton", "text": "

(but yeah that has been a problem two years in a row)

", "time": "2024-03-18T03:04:32Z"}, {"author": "Martin Thomson", "text": "

couldn't be bothered to take a short flight @chris?

", "time": "2024-03-18T03:04:35Z"}, {"author": "Christopher Patton", "text": "

lol

", "time": "2024-03-18T03:04:41Z"}, {"author": "Lorenzo Miniero", "text": "

The speaker mic is turned off

", "time": "2024-03-18T03:04:46Z"}, {"author": "Christopher Patton", "text": "

yes

", "time": "2024-03-18T03:04:59Z"}, {"author": "Lorenzo Miniero", "text": "

(sorry, wrong chat :D )

", "time": "2024-03-18T03:05:01Z"}, {"author": "Daniel Gillmor", "text": "

we can hear fine

", "time": "2024-03-18T03:05:01Z"}, {"author": "Tim Geoghegan", "text": "

Yes I can hear the chairs

", "time": "2024-03-18T03:05:03Z"}, {"author": "Deirdre Connolly", "text": "

:+1:

", "time": "2024-03-18T03:05:09Z"}, {"author": "Lorenzo Miniero", "text": "

Yes, apologies for the confusion, I'm in 7 zulip rooms :)

", "time": "2024-03-18T03:05:22Z"}, {"author": "Martin Thomson", "text": "

only 7?

", "time": "2024-03-18T03:05:33Z"}, {"author": "Daniel Gillmor", "text": "

slacker

", "time": "2024-03-18T03:05:39Z"}, {"author": "Lorenzo Miniero", "text": "

Ys, no session in M1 right now :D

", "time": "2024-03-18T03:05:48Z"}, {"author": "Martin Thomson", "text": "
", "time": "2024-03-18T03:08:16Z"}, {"author": "Robert Moskowitz", "text": "

Compared to LAMPS????

", "time": "2024-03-18T03:09:26Z"}, {"author": "Christopher Patton", "text": "

Yes, thank you panel members.

", "time": "2024-03-18T03:10:03Z"}, {"author": "Daniel Gillmor", "text": "

+1 thanks!

", "time": "2024-03-18T03:10:12Z"}, {"author": "Martin Thomson", "text": "

when will we need the third block of zero padding?

", "time": "2024-03-18T03:13:08Z"}, {"author": "Mike Ounsworth", "text": "

Christopher Patton said:

\n
\n

This is shaping up to be quite the ruckus of a CFRG

\n
\n

For the record, I am only a semi-willing participant :octopus:

", "time": "2024-03-18T03:13:15Z"}, {"author": "Christopher Patton", "text": "

Are ETSI SAGE and 3GPP already implementing/deploying this?

", "time": "2024-03-18T03:25:56Z"}, {"author": "Deirdre Connolly", "text": "

My upcoming slides: https://datatracker.ietf.org/meeting/119/materials/slides-119-cfrg-ml-kem-for-hpke-03

\n

I share them up front as I will probably be going quite fast to leave room for questions

", "time": "2024-03-18T03:29:42Z"}, {"author": "Deirdre Connolly", "text": "

And because I made too many slides \ud83e\udee0

", "time": "2024-03-18T03:29:55Z"}, {"author": "Robert Moskowitz", "text": "

I need short tags for this over constrained aviation RF links.

", "time": "2024-03-18T03:30:04Z"}, {"author": "Robert Moskowitz", "text": "

I have drafts in DRIP that benefit from short tags.

", "time": "2024-03-18T03:31:55Z"}, {"author": "Mike Ounsworth", "text": "

I support registering pure Base mode ML-KEM for HPKE.
\nThis is a needed document. Thanks @Deirdre Connolly for getting a draft out.

", "time": "2024-03-18T03:35:07Z"}, {"author": "John Gray", "text": "

+1 Mike

", "time": "2024-03-18T03:38:01Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Christopher Patton said:

\n
\n

Are ETSI SAGE and 3GPP already implementing/deploying this?

\n
\n

ETSI SAGE has done specifications and 3GPP is working on specifications. Unclear when implementation/deployment/use will happen. Companies might have started HW implementations.

", "time": "2024-03-18T03:39:18Z"}, {"author": "Christopher Patton", "text": "

Good to know, thanks!

", "time": "2024-03-18T03:40:39Z"}, {"author": "Daniel Gillmor", "text": "

thank you for this analysis, @Dierdre! this is incredibly valuable work.

", "time": "2024-03-18T03:47:22Z"}, {"author": "Christopher Patton", "text": "

+1 super helpful

", "time": "2024-03-18T03:47:31Z"}, {"author": "Martin Thomson", "text": "

I like this idea. Has anyone done some work for AuthKEM?

", "time": "2024-03-18T03:47:37Z"}, {"author": "Deirdre Connolly", "text": "

lol i barely made time

", "time": "2024-03-18T03:47:41Z"}, {"author": "Christopher Patton", "text": "

I'd favor tweaking HPKE.

", "time": "2024-03-18T03:47:41Z"}, {"author": "Daniel Gillmor", "text": "

it's called an RFC because we are requesting comments. this is exactly the kind of comments we want

", "time": "2024-03-18T03:47:56Z"}, {"author": "Martin Thomson", "text": "

The idea of ExpandExtract being moved out of the per-KEM module seems right to me.

", "time": "2024-03-18T03:47:57Z"}, {"author": "Daniel Gillmor", "text": "

I'm for HPKE2

", "time": "2024-03-18T03:48:13Z"}, {"author": "Martin Thomson", "text": "

The change would be consistent with all current HPKE implementations.

", "time": "2024-03-18T03:48:28Z"}, {"author": "Daniel Gillmor", "text": "

how would it be consistent?

", "time": "2024-03-18T03:48:53Z"}, {"author": "Martin Thomson", "text": "

It is just that you would require that all new suites are structured in a specific way if they were used with HPKEv1

", "time": "2024-03-18T03:48:57Z"}, {"author": "Daniel Gillmor", "text": "

ah, the interface is the same, you mean

", "time": "2024-03-18T03:49:19Z"}, {"author": "Martin Thomson", "text": "

RIght now we have Encap = X, Y, Z. We change that so that HPKE includes the Y, Z part.

", "time": "2024-03-18T03:49:24Z"}, {"author": "Martin Thomson", "text": "

No, completely, 100% compatible.

", "time": "2024-03-18T03:49:31Z"}, {"author": "Martin Thomson", "text": "

But where it would be currently valid to define a KEM for 9180 that did not do ExtractExpand as described, that would not be possible in the revised version.

", "time": "2024-03-18T03:50:10Z"}, {"author": "Martin Thomson", "text": "

However, you could still use an existing version of HPKE, IFF the new KEM was defined to include the ExtractExpand piece when implemented against 9180.

", "time": "2024-03-18T03:50:46Z"}, {"author": "Christopher Patton", "text": "

this is a bit more than registering a codepoint, but I think it's worth the effort

", "time": "2024-03-18T03:51:47Z"}, {"author": "Martin Thomson", "text": "

9180bis is how we might deal with this, but concretely we would not need to revise the wire protocol

", "time": "2024-03-18T03:52:13Z"}, {"author": "Stephen Farrell", "text": "

yeah please don't start a 9180bis

", "time": "2024-03-18T03:52:38Z"}, {"author": "Martin Thomson", "text": "

there is a risk that someone defines a KEM for 9180 that doesn't conform to the form described, but that would simply burn a codepoint

", "time": "2024-03-18T03:52:41Z"}, {"author": "Jonathan Hoyland", "text": "

What does it return if all/many strings are equally common?

", "time": "2024-03-18T03:56:41Z"}, {"author": "Tim Geoghegan", "text": "

All strings which occur t or more times will be revealed to the collector

", "time": "2024-03-18T03:57:09Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Hoyland it tends to get very expensive if all strings hit the threshold

", "time": "2024-03-18T03:57:12Z"}, {"author": "Martin Thomson", "text": "

these protocols work best if the distribution of heavy hitters is sparse

", "time": "2024-03-18T03:57:28Z"}, {"author": "Jonathan Hoyland", "text": "

So this protocol could, in theory, leak all the data in full?

", "time": "2024-03-18T03:57:52Z"}, {"author": "Tim Geoghegan", "text": "

Yes, but hopefully the participating servers would refuse to run the protocol with t = 1

", "time": "2024-03-18T03:58:34Z"}, {"author": "Martin Thomson", "text": "

yes, or at least the sums/counts for all strings

", "time": "2024-03-18T03:58:36Z"}, {"author": "Daniel Gillmor", "text": "

the servers decide what t is set to? or can the clients refuse to participate based on the choice of t?

", "time": "2024-03-18T03:59:04Z"}, {"author": "Tim Geoghegan", "text": "

@MT revealing that some string occurs n times also reveals that the string exists in the set

", "time": "2024-03-18T03:59:06Z"}, {"author": "Martin Thomson", "text": "

I would argue for DP on the output, but that's hard

", "time": "2024-03-18T03:59:12Z"}, {"author": "Tim Geoghegan", "text": "

@Daniel Gillmor there are various schemes such as taskprov that attempt to expose such parameters to clients, but there's no way to prove to clients that the servers are using one value of t or another

", "time": "2024-03-18T03:59:39Z"}, {"author": "Daniel Gillmor", "text": "

hrm, that is disappointing

", "time": "2024-03-18T04:00:15Z"}, {"author": "Martin Thomson", "text": "

typical deployments would have the servers with a minimum t and clients picking t

", "time": "2024-03-18T04:00:21Z"}, {"author": "Tim Geoghegan", "text": "

Similarly, DAP aggregators are required to refuse to aggregate unless some minimum number of contributions is reached. Clients can be looped in on that threshold, but the servers can always defect on it.

", "time": "2024-03-18T04:00:35Z"}, {"author": "Jonathan Hoyland", "text": "

@Tim Geoghegan no way, or is it just annoying?

", "time": "2024-03-18T04:00:40Z"}, {"author": "John Gray", "text": "

@Dierdre, It sounds like a higher level wrapper around the KEM that adds in the cipherText and publicKey could be devised. It would have to have the same API as the KEM so it would fit into 9180. So essentially a transform that adds the required properties. Then no changes needed to 9180. So would a safe KEM wrapper for 9180 be a potential draft?

", "time": "2024-03-18T04:00:58Z"}, {"author": "Jonathan Hoyland", "text": "

For example, why couldn't you use ZKPs to prove the server was using a particular value?

", "time": "2024-03-18T04:01:10Z"}, {"author": "Tim Geoghegan", "text": "

No scheme that I know of, I'd love to hear of ways to cryptographically commit to things like heavy hitters threshold or anonymity set size

", "time": "2024-03-18T04:01:21Z"}, {"author": "Martin Thomson", "text": "

well, isn't it the case that servers executing with t < minimum is a specific collusion case that we don't defend against

", "time": "2024-03-18T04:01:25Z"}, {"author": "Martin Thomson", "text": "

if the servers are willing to collude, then they can just reveal inputs at that point

", "time": "2024-03-18T04:01:38Z"}, {"author": "Daniel Gillmor", "text": "

@John Gray: if you did that then the key schedule from existing HPKE deployments would actually change, no?

", "time": "2024-03-18T04:01:41Z"}, {"author": "Tim Geoghegan", "text": "

It's a very important property of VDAFs that the clients speak once

", "time": "2024-03-18T04:01:42Z"}, {"author": "Daniel Gillmor", "text": "

@Martin, that makes sense: it's another kind of server collusion

", "time": "2024-03-18T04:02:43Z"}, {"author": "Tim Geoghegan", "text": "

@Martin yes I was going to say all that. Very important to remember that attacks that require both servers to defect and/or collude with each other are not in the threat model

", "time": "2024-03-18T04:03:34Z"}, {"author": "Deirdre Connolly", "text": "

Well, currently RFC 9180 is unsafe against these re-encapsulation attacks (or other attacks, eg McEliece) as currently written, because it only requires IND-CCA2 security for KEM ciphersuites beyond DHKEM. So I think it would be a new version/change/RFC 9180bis or whatever, not just an optional wrapper (beyond the ML-KEM-specific wrapper I linked for use with HPKE 'v1', aka RFC 9180 as it currently is)

", "time": "2024-03-18T04:04:01Z"}, {"author": "Martin Thomson", "text": "

@Tim Geoghegan I have collusion in my threat model, but I don't expect to have technical controls that prevent it :)

", "time": "2024-03-18T04:04:05Z"}, {"author": "Tim Geoghegan", "text": "

Uh, fine, yeah, it's in the threat model, but that part of the threat model just says \"you are screwed\"

", "time": "2024-03-18T04:04:26Z"}, {"author": "Martin Thomson", "text": "

I prefer to say \"we write a contract\"

", "time": "2024-03-18T04:05:01Z"}, {"author": "Christopher Patton", "text": "

THANKS

", "time": "2024-03-18T04:05:14Z"}, {"author": "Christopher Patton", "text": "

yes

", "time": "2024-03-18T04:05:45Z"}, {"author": "Daniel Gillmor", "text": "

we hear you fine

", "time": "2024-03-18T04:05:48Z"}, {"author": "Rich Salz", "text": "

Martin Thomson said:

\n
\n

I prefer to say \"we write a contract\"

\n
\n

\"out of band' has a long and noble history :)

", "time": "2024-03-18T04:07:45Z"}, {"author": "Christopher Patton", "text": "

\"noble\" :D

", "time": "2024-03-18T04:09:16Z"}, {"author": "Martin Thomson", "text": "

how do you send a value of 99 when the modulus is 23?

", "time": "2024-03-18T04:11:02Z"}, {"author": "Christopher Patton", "text": "

well that's clearly a typo

", "time": "2024-03-18T04:11:38Z"}, {"author": "John Gray", "text": "

@DKG, I haven't thought about the key schedule. I was just thinking a KEM shaped wrapper that could add in whatever properties may be missing may be useful. On the other hand I could be totally wrong, it just seems like an interesting idea that might be worth thinking about. I thought I heard Dierdre mention a wrapper, and that is where my mind went.

", "time": "2024-03-18T04:11:56Z"}, {"author": "Martin Thomson", "text": "

I propose that all examples use the Mersenne prime 2^5-1.

", "time": "2024-03-18T04:12:13Z"}, {"author": "Christopher Patton", "text": "

Write a draft!

", "time": "2024-03-18T04:12:32Z"}, {"author": "Daniel Gillmor", "text": "

@John Gray, i might not be using the right terms either: i think the point is if we just call this new HPKE-shaped thing \"HPKE\" then existing HPKE implementations and deployment with existing codepoints won't actually do the same thing (even though they'll be safe because they use DHKEM, which doesn't need this extra safety)

", "time": "2024-03-18T04:13:30Z"}, {"author": "Deirdre Connolly", "text": "

John Gray said:

\n
\n

@DKG, I haven't thought about the key schedule. I was just thinking a KEM shaped wrapper that could add in whatever properties may be missing may be useful. On the other hand I could be totally wrong, it just seems like an interesting idea that might be worth thinking about. I thought I heard Dierdre mention a wrapper, and that is where my mind went.

\n
\n

The alternative to my (wrapped) ML-KEM ciphersuite document would be a change to HPKE, that makes the ciphersuite-KEM wrapped by default, but not optional

", "time": "2024-03-18T04:13:35Z"}, {"author": "Tim Geoghegan", "text": "

I don't know that this would need to be in the PPM charter, explicitly. IIUC the documents in PPM wouldn't need to change substantially to require supporting these ML model training use cases.

", "time": "2024-03-18T04:15:28Z"}, {"author": "Daniel Gillmor", "text": "

@Dierdre do you mean \"wrapped by default, but optional\" (meaning that the existing HPKE ciphersuites are retconned to be \"unwrapped\", and all new ciphersuites should be wrapped)

", "time": "2024-03-18T04:15:53Z"}, {"author": "Christopher Patton", "text": "

Thanks Martin!

", "time": "2024-03-18T04:16:03Z"}, {"author": "Christopher Patton", "text": "

I think PPM's purpose is to develop tools for solving lots of measurement problems, not necessarily just those envisioned by a charter. Training a machine learning model certainly fits, in my opinion.,

", "time": "2024-03-18T04:17:51Z"}, {"author": "Deirdre Connolly", "text": "

Daniel Gillmor said:

\n
\n

@Dierdre do you mean \"wrapped by default, but optional\" (meaning that the existing HPKE ciphersuites are retconned to be \"unwrapped\", and all new ciphersuites should be wrapped)

\n
\n

Ah no, it would basically make all ciphersuite KEMs (except DHKEM) be wrapped, always

", "time": "2024-03-18T04:18:07Z"}, {"author": "Martin Thomson", "text": "

yeah, I think that this is within scope for PPM, but there are interesting questions about how to set design goals

", "time": "2024-03-18T04:18:17Z"}, {"author": "Daniel Gillmor", "text": "

@Dierdre, i think we're saying the same thing :)

", "time": "2024-03-18T04:18:32Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Daniel Gillmor said:

\n
\n

@Dierdre do you mean \"wrapped by default, but optional\" (meaning that the existing HPKE ciphersuites are retconned to be \"unwrapped\", and all new ciphersuites should be wrapped)

\n
\n

Ah no, it would basically make all ciphersuite KEMs (except DHKEM) be wrapped, always

\n
\n

If also wrapping DHKEM is easier, that would be extra unnecessary work, but fine

", "time": "2024-03-18T04:19:07Z"}, {"author": "Deirdre Connolly", "text": "

Daniel Gillmor said:

\n
\n

@Dierdre, i think we're saying the same thing :)

\n
\n

:spidermen-pointing:

", "time": "2024-03-18T04:19:36Z"}, {"author": "Christopher Patton", "text": "

What sorts of questions?

", "time": "2024-03-18T04:19:51Z"}, {"author": "Junye Chen", "text": "

Martin Thomson
\n21:11
\nhow do you send a value of 99 when the modulus is 23?

", "time": "2024-03-18T04:20:11Z"}, {"author": "Christopher Patton", "text": "

Martin Thomson said:

\n
\n

yeah, I think that this is within scope for PPM, but there are interesting questions about how to set design goals

\n
\n

What sorts of questions

", "time": "2024-03-18T04:20:21Z"}, {"author": "Martin Thomson", "text": "

@Christopher Patton one thing we keep coming back to with lately is the balance of work between client and server. That is, how much proving and sending does the client have to do.

", "time": "2024-03-18T04:21:10Z"}, {"author": "Junye Chen", "text": "

Suppose we use one byte for each entry in the gradient and send it, and client can theoretically send a value between 0 and 255. The field modulus may be smaller than the max value available given the number of bytes.

", "time": "2024-03-18T04:21:13Z"}, {"author": "Martin Thomson", "text": "

Consider the Prio+ paper, which reduces client communication greatly, but involves server-server communication to compensate.

", "time": "2024-03-18T04:21:44Z"}, {"author": "Tim Geoghegan", "text": "

Does PINE change the distribution of work between clients and server?

", "time": "2024-03-18T04:22:24Z"}, {"author": "Martin Thomson", "text": "

@Junye Chen but presumably your two shares are individually less than q (23), so at worst you have a contribution of 44, not 99.

", "time": "2024-03-18T04:22:31Z"}, {"author": "Martin Thomson", "text": "

@Tim Geoghegan my understanding is that it puts some more responsibility on the clients, in terms of producing the FLP.

", "time": "2024-03-18T04:23:01Z"}, {"author": "Christopher Patton", "text": "

Tim Geoghegan said:

\n
\n

Does PINE change the distribution of work between clients and server?

\n
\n

PINE doesn't change the way work is distributed compared to Prio3.

", "time": "2024-03-18T04:23:11Z"}, {"author": "Martin Thomson", "text": "

This is not a shocking departure from what we already have in Prio, of course.

", "time": "2024-03-18T04:23:21Z"}, {"author": "Martin Thomson", "text": "

@Alexey Melnikov NO SYMPATHY

", "time": "2024-03-18T04:23:40Z"}, {"author": "Tim Geoghegan", "text": "

Yeah, exactly. The really disruptive thing would be if clients ever had to speak more than once in a protocol.

", "time": "2024-03-18T04:24:05Z"}, {"author": "Christopher Patton", "text": "

@Martin Thomson Prio+ uses different cryptographic techniques that may in fact be applicable to the same problem. The goal here was to build a protocol from federated learning using the tools we know how to use. I don't know that there's a better way to do it?

", "time": "2024-03-18T04:24:12Z"}, {"author": "Deirdre Connolly", "text": "

weeeeee hybrid KEMs :shuffle:

", "time": "2024-03-18T04:24:25Z"}, {"author": "Alexey Melnikov", "text": "

@Martin Thomson: why am I not surprised ;-)?

", "time": "2024-03-18T04:24:37Z"}, {"author": "Daniel Gillmor", "text": "

the title slide makes it sound like someone wants to hybridize P-256 and RSA together. please no!

", "time": "2024-03-18T04:24:53Z"}, {"author": "Tim Geoghegan", "text": "

But in any case I find it plausible that there might be some ML specific considerations that PPM might need to weigh, maybe documents to draft that advise on how to use things like DAP for ML. So in that lens it makes sense to me for PPM to sorta formally decide if it wants to be responsible for ML work.

", "time": "2024-03-18T04:25:00Z"}, {"author": "Deirdre Connolly", "text": "

Daniel Gillmor said:

\n
\n

the title slide makes it sound like someone wants to hybridize P-256 and RSA together. please no!

\n
\n

ha I also thought this :D

", "time": "2024-03-18T04:25:13Z"}, {"author": "Martin Thomson", "text": "

Aww, I want to talk about hybrid signing. ECDSA+RSA-SSA hybrid sounds delightful.

", "time": "2024-03-18T04:25:15Z"}, {"author": "Jonathan Hoyland", "text": "

Wait

\n

Deirdre Connolly said:

\n
\n

Daniel Gillmor said:

\n
\n

the title slide makes it sound like someone wants to hybridize P-256 and RSA together. please no!

\n
\n

ha I also thought this :D

\n
\n

Wait, it isn't suggesting that?

", "time": "2024-03-18T04:25:43Z"}, {"author": "Junye Chen", "text": "

@Martin Thomson, ah good point. I think we probably should change the example to [44, 0, 1] in the draft as well :) @Christopher Patton

", "time": "2024-03-18T04:25:49Z"}, {"author": "Deirdre Connolly", "text": "

ECDSA && RSA-SSA && EdDSA && ML-DSA && SQIsign &&&&&

", "time": "2024-03-18T04:25:55Z"}, {"author": "Christopher Patton", "text": "

Tim Geoghegan said:

\n
\n

But in any case I find it plausible that there might be some ML specific considerations that PPM might need to weigh, maybe documents to draft that advise on how to use things like DAP for ML. So in that lens it makes sense to me for PPM to sorta formally decide if it wants to be responsible for ML work.

\n
\n

There will absolutely be a need for differential privacy. Beyond that I don't think there's anything to say: DAP/VDAF are just part of the plumbing that we need to build in order to make machine learning more private.

", "time": "2024-03-18T04:26:17Z"}, {"author": "Martin Thomson", "text": "

@Deirdre Connolly Maybe add a keyed mac and alg=none

", "time": "2024-03-18T04:26:23Z"}, {"author": "Deirdre Connolly", "text": "

I've fielded lots of requests for X-Wing but with P-256 instead, definitely ack'ing Mike's points

", "time": "2024-03-18T04:28:31Z"}, {"author": "John Gray", "text": "

@DKG and @Dierdre, do you think a KEM wrapper potentially might have additional utility outside of 9180? If we think some KEM's are 'unsafe' in certain usages (like you highlighted in 9180 today), then would wrapping it up in a spiderman super-power costume help? :)

", "time": "2024-03-18T04:28:55Z"}, {"author": "Deirdre Connolly", "text": "

(it basically requires a little proof )

", "time": "2024-03-18T04:28:58Z"}, {"author": "Martin Thomson", "text": "

Are these smartcards getting ML-KEM?

", "time": "2024-03-18T04:29:13Z"}, {"author": "John Gray", "text": "

@Mike, our first PKI at Entrust was in 1994... :)

", "time": "2024-03-18T04:29:18Z"}, {"author": "Deirdre Connolly", "text": "

John Gray said:

\n
\n

@DKG and @Dierdre, do you think a KEM wrapper potentially might have additional utility outside of 9180? If we think some KEM's are 'unsafe' in certain usages (like you highlighted in 9180 today), then would wrapping it up in a spiderman super-power costume help? :)

\n
\n

Hm. Interesting.

\n

Looking at <range of protocols>, this may be overkill

", "time": "2024-03-18T04:30:13Z"}, {"author": "Yoav Nir", "text": "

The hybrid doesn't need to soak in QA?

", "time": "2024-03-18T04:30:28Z"}, {"author": "Yoav Nir", "text": "

(and get certified)?

", "time": "2024-03-18T04:30:42Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

John Gray said:

\n
\n

@DKG and @Dierdre, do you think a KEM wrapper potentially might have additional utility outside of 9180? If we think some KEM's are 'unsafe' in certain usages (like you highlighted in 9180 today), then would wrapping it up in a spiderman super-power costume help? :)

\n
\n

Hm. Interesting.

\n

Looking at <range of protocols>, this may be overkill

\n
\n

Eg some protocols don't have to worry about this at all (TLS 1.3, they do the right thing by default)

", "time": "2024-03-18T04:30:57Z"}, {"author": "Deirdre Connolly", "text": "

:fire::fire::fire:

", "time": "2024-03-18T04:31:24Z"}, {"author": "Massimiliano Pala", "text": "

Depending on how you do hybrids you can keep the FIPS certification for the quantum-vulnerable algorithm and still get lower risks of compromise, until protocols can get updated.

", "time": "2024-03-18T04:31:43Z"}, {"author": "David Benjamin", "text": "

RSAES-PKCS1-v1_5 is simply a broken primitive, and known to be broken since 1998. We absolutely should not be adding it to anything at this point.

", "time": "2024-03-18T04:31:52Z"}, {"author": "Daniel Gillmor", "text": "

there are many elliptic curve codebases available without writing them yourself

", "time": "2024-03-18T04:32:50Z"}, {"author": "Martin Thomson", "text": "

if you have to break the seal to add ML-KEM, I doubt that certifying ML-KEM AND P-256 (or whatever) is not that much more expensive than adding ML-KEM

", "time": "2024-03-18T04:34:55Z"}, {"author": "Daniel Gillmor", "text": "

@Martin, i agree. i'd need to hear stronger motivations to be convinced

", "time": "2024-03-18T04:35:34Z"}, {"author": "Tim Geoghegan", "text": "

Unless the ML-KEM and P-256 modules separately undergo FIPS certification?

", "time": "2024-03-18T04:35:35Z"}, {"author": "John Gray", "text": "

Thanks David, so what are your thoughts on RSA-OAEP? I agree PKCS1.5 shouldn't be used anymore, but everyone seems to keep using it... :(

", "time": "2024-03-18T04:35:38Z"}, {"author": "Martin Thomson", "text": "

the advice I would give is: bind your output shared secret to the KEM secret, the KEM public key, and the KEM ciphertext. Otherwise, go forth and be fruitful.

", "time": "2024-03-18T04:36:05Z"}, {"author": "Yoav Nir", "text": "

I remember FIPS certification being like a black hole, in that it sucks in more and more chunks of code. You rarely manage to keep relevant stuff outside the boundary

", "time": "2024-03-18T04:36:33Z"}, {"author": "David Benjamin", "text": "

Strongly agreed. Keep in mind that the existing keys are irrelevant here. You already should not be using the same keys for the classical half of hybrid half and your standalone things.

", "time": "2024-03-18T04:36:36Z"}, {"author": "Deirdre Connolly", "text": "

If you do what Martin says you will be in a good place

", "time": "2024-03-18T04:36:47Z"}, {"author": "Deirdre Connolly", "text": "

as opposed to the Bad Place

", "time": "2024-03-18T04:36:56Z"}, {"author": "Martin Thomson", "text": "

Deirdre Connolly said:

\n
\n

If you do what Martin says you will be in a good place

\n
\n

Advice to live by in many ways.

", "time": "2024-03-18T04:37:08Z"}, {"author": "Massimiliano Pala", "text": "

Migration requires a lot of work and we need tools. Especially for early adopters. This is a real problem, that needs tools that can help with the difficulty of the world-wide process. Finance, Governments, Critical Infrastructure, and Healthcare need cost-effective tools. There are plenty of use-cases, but for some reason it seems many IETF contributors are not familiar with the need, advocated by ... every single early adopter :)

", "time": "2024-03-18T04:37:33Z"}, {"author": "Daniel Gillmor", "text": "

ROT13 AEAD!

", "time": "2024-03-18T04:37:35Z"}, {"author": "Yoav Nir", "text": "

No. 3-ROT13!

", "time": "2024-03-18T04:38:01Z"}, {"author": "Martin Thomson", "text": "

People inclined to do inadvisable things are not going to change based on words that are written in an RFC.

", "time": "2024-03-18T04:38:01Z"}, {"author": "Rich Salz", "text": "

John Gray said:

\n
\n

Thanks David, so what are your thoughts on RSA-OAEP? I agree PKCS1.5 shouldn't be used anymore, but everyone seems to keep using it... :(

\n
\n

David wrote the draft that has TLS 1.3 back away from OAEP and admit that PKCS1.5 exists.

", "time": "2024-03-18T04:38:21Z"}, {"author": "Martin Thomson", "text": "

In some cases, words in RFCs that suggest not to do something were the cause of people doing inadvisable things.

", "time": "2024-03-18T04:38:32Z"}, {"author": "David Benjamin", "text": "

No, Rich, you're confusing PSS and OAEP, and the signature vs. encryption scheme.

", "time": "2024-03-18T04:38:46Z"}, {"author": "Rich Salz", "text": "

Dang, you're right.

", "time": "2024-03-18T04:38:56Z"}, {"author": "David Benjamin", "text": "

RSASSA-PKCS1-v1_5, the signature scheme, is a little fiddly but not horrible. RSAES-PKCS1-v1_5, the encryption scheme, is totally bust.

", "time": "2024-03-18T04:39:25Z"}, {"author": "Rich Salz", "text": "

Is it too late for me to still blame jetlag?

", "time": "2024-03-18T04:39:49Z"}, {"author": "David Benjamin", "text": "

Eh, even without jetlag it's easy to mix them up. It's really unfortunate the names are so similar. :-D

", "time": "2024-03-18T04:40:15Z"}, {"author": "Robert Moskowitz", "text": "

It IS late, Rich...

", "time": "2024-03-18T04:40:17Z"}, {"author": "Yoav Nir", "text": "

I'd blame being upside down

", "time": "2024-03-18T04:40:39Z"}, {"author": "Junye Chen", "text": "

@Tim > Does PINE change the distribution of work between clients and server? The distribution of work is still very similar to Prio3's, it depends on the constraints the verifiers are checking. We have some computation cost analysis in Lemma 3.12 of our paper https://arxiv.org/pdf/2311.10237.pdf. By invoking this lemma, the advantage of a PINE solution is the number of variables involved in the constraints is much smaller, roughly ~O(d*log(d)), where d is dimension, vs a Prio3 solution (e.g. Prio3FixedPointBoundedL2VecSum) would require ~O(d*num_frac_bits * log(d * num_frac_bits), where num_frac_bits is the precision of the gradient entries.

", "time": "2024-03-18T04:41:11Z"}, {"author": "Massimiliano Pala", "text": "

Interesting last comment - is anybody THINKING about secondary markets and how long it will take there...? Ahhhh...

", "time": "2024-03-18T04:41:51Z"}, {"author": "Deirdre Connolly", "text": "

@Massimiliano Pala I'm thinking that they migrate once and maybe that's directly to PQ-only :eyes:

", "time": "2024-03-18T04:42:38Z"}, {"author": "Massimiliano Pala", "text": "

As it was said in the queue, there is a lot of work to do in many protocols... :)

", "time": "2024-03-18T04:42:49Z"}, {"author": "John Gray", "text": "

Its hard to know what the lifetime will be. A sunset window of 2030 makes sense, but if they are getting used you know it will take longer for people to stop using them.

", "time": "2024-03-18T04:42:54Z"}, {"author": "Massimiliano Pala", "text": "

@deirdre

", "time": "2024-03-18T04:42:58Z"}, {"author": "Jonathan Hoyland", "text": "

That's what I'm worried about. We want it to be totally clear this is a brief transition step, not a valid longterm state

", "time": "2024-03-18T04:42:58Z"}, {"author": "Daniel Gillmor", "text": "

the secondary markets are the reason to not bless a scheme-that-must-die-soon, right?

", "time": "2024-03-18T04:43:32Z"}, {"author": "Jonathan Hoyland", "text": "

I mean diediedie drafts (sadly) don't make stuff disappear from the Internet

", "time": "2024-03-18T04:43:52Z"}, {"author": "Robert Moskowitz", "text": "

Once deployed in some of these situations, it will take a major forest fire to kill them.

", "time": "2024-03-18T04:44:01Z"}, {"author": "David Benjamin", "text": "

John Gray said:

\n
\n

Thanks David, so what are your thoughts on RSA-OAEP? I agree PKCS1.5 shouldn't be used anymore, but everyone seems to keep using it... :(

\n
\n

RSA-OAEP is fine, but I think the broader point is more important. The evidence needed here isn't \"look lots of people use RSA keys today and they move slowly\". It's specifically why shipping new code for ML-KEM+RSA is easier than shipping new code for ML-KEM+X25519. Bearing in mind that you have to ship a blob of new code anyway, you already cannot reuse your keys, and there are plenty of small X25519 implementations out there that you can drop in next to the ML-KEM code.

", "time": "2024-03-18T04:44:06Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

the title slide makes it sound like someone wants to hybridize P-256 and RSA together. please no!

\n
\n

Oops. Yeah. Bad title.

", "time": "2024-03-18T04:45:19Z"}, {"author": "Daniel Gillmor", "text": "

i just thought you were warming up the crowd so they wouldn't be upset with the actual proposal

", "time": "2024-03-18T04:46:44Z"}, {"author": "Nick Sullivan", "text": "

One of the historical reasons to support RSA along with ECC when ECC is available had to do with how different distros approached the ECC IPR issue (some stripped ECC from crypto libs). This is less of an issue today given the patent expirations.

", "time": "2024-03-18T04:47:41Z"}, {"author": "Jonathan Hoyland", "text": "

Did the Inria folks take their model past draft-18?

", "time": "2024-03-18T04:47:57Z"}, {"author": "Mike Ounsworth", "text": "

David Benjamin said:

\n
\n

RSAES-PKCS1-v1_5 is simply a broken primitive, and known to be broken since 1998. We absolutely should not be adding it to anything at this point.

\n
\n

I mean yes, I'm not arguing that point. I'm arguing that providing an ML-KEM + RSA-PKCS1 hybrid helps people get off it faster.

", "time": "2024-03-18T04:47:57Z"}, {"author": "John Gray", "text": "

@Dierdre I was thinking in regards to the kemrecipientInfo draft. The draft requires IND-CCA2 KEMS will be used and that is discussed in the security considerations. If for whatever reason IND-CCA2 isn't good enough maybe such a wrapper be a potential mitigation.. We already added in an optional value to KDF input (ukm), so we should be covered in any regard but perhaps that could be another option. There are likely other protocols out there as well...

", "time": "2024-03-18T04:48:43Z"}, {"author": "David Benjamin", "text": "

I mean, the whole point of hybridizing is to hedge against ML-KEM being maybe broken. Why in the world would we hedge it with something that is known to be broken? Don't bother hedging at that point.

", "time": "2024-03-18T04:48:50Z"}, {"author": "Mike Ounsworth", "text": "

Martin Thomson said:

\n
\n

the advice I would give is: bind your output shared secret to the KEM secret, the KEM public key, and the KEM ciphertext. Otherwise, go forth and be fruitful.

\n
\n

Right. That's what we call a \"hybrid KEM combiner\" though, right?

", "time": "2024-03-18T04:48:51Z"}, {"author": "Massimiliano Pala", "text": "

@deirdre if that needs to be, that is fine. But are we all really ok in not even considering the issue? I think it would be great if there were people who are willing to try to look at the problems differently than we did in the past? I just wanted to provide a different point of view that, unfortunately, is often ignored by us technologist... :(

", "time": "2024-03-18T04:50:09Z"}, {"author": "David Benjamin", "text": "

(Or, better, hedge it with something more reasonable. I hear X25519 is pretty nice. :wink: )

", "time": "2024-03-18T04:50:14Z"}, {"author": "Rich Salz", "text": "

<delete, replacing>

", "time": "2024-03-18T04:51:56Z"}, {"author": "John Gray", "text": "

\"Daniel Gillmor said:
\nthe title slide makes it sound like someone wants to hybridize P-256 and RSA together. please no!\"
\n Actually.... I've already created keys and certs of this type... but purely for theoretical purposes... :)

", "time": "2024-03-18T04:51:56Z"}, {"author": "Rich Salz", "text": "

David Benjamin said:

\n
\n

I mean, the whole point of hybridizing is to hedge against ML-KEM being maybe broken. Why in the world would we hedge it with something that is known to be broken?

\n
\n

Because it's not really hedging, in the way we've been doing it to date. Its adding a likely approved algorithm, outside the FIPS module boundary, as a way to protect a deployed base.

", "time": "2024-03-18T04:52:46Z"}, {"author": "Mike Ounsworth", "text": "

David Benjamin said:

\n
\n

John Gray said:

\n
\n

Thanks David, so what are your thoughts on RSA-OAEP? I agree PKCS1.5 shouldn't be used anymore, but everyone seems to keep using it... :(

\n
\n

RSA-OAEP is fine, but I think the broader point is more important. The evidence needed here isn't \"look lots of people use RSA keys today and they move slowly\". It's specifically why shipping new code for ML-KEM+RSA is easier than shipping new code for ML-KEM+X25519. Bearing in mind that you have to ship a blob of new code anyway, you already cannot reuse your keys, and there are plenty of small X25519 implementations out there that you can drop in next to the ML-KEM code.

\n
\n

Simply put: risk. Remember that enterprise risk decisions are often not made by cryptographers, but by operations engineers, business people or politicians. They see \"new crypto\" and think \"CVEs\". They see \"new crypto coupled with your well-tested crypto\" and their blood pressure comes down 10 points.

", "time": "2024-03-18T04:52:51Z"}, {"author": "Kris Kwiatkowski", "text": "

I fully agree with Mike and a need to integrate with older schemes. My employer is in a Post-Quantum business and we often see people want to add PQ on top of existing crypto, simply because thats trusted and running for very long. Addinf PQ is a huge risk, taking addtional risk (like adding new implementation of X25519) is not desirable. Its worth to remember that crypto often implemented in HW with things like DPA resistance.

", "time": "2024-03-18T04:53:28Z"}, {"author": "Daniel Gillmor", "text": "

it's 2024. by the time they deploy this it will be 2026. at what point does x25519 become not \"new crypto\"?

", "time": "2024-03-18T04:53:58Z"}, {"author": "Deirdre Connolly", "text": "

Massimiliano Pala said:

\n
\n

@deirdre if that needs to be, that is fine. But are we all really ok in not even considering the issue? I think it would be great if there were people who are willing to try to look at the problems differently than we did in the past? I just wanted to provide a different point of view that, unfortunately, is often ignored by us technologist... :(

\n
\n

Going directly to PQ-only basically because the cost of doing a hybrid transition and then _another_ transition to PQ-only (which would be the ideal final state eventually) may happen just because many users of these protocols aren't in a position to do multiple transitions, not because we don't try to make it possible, i think

", "time": "2024-03-18T04:54:05Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

it's 2024. by the time they deploy this it will be 2026. at what point does x25519 become not \"new crypto\"?

\n
\n

It's \"new crypto\" if I have to open a .c file and type new code.

", "time": "2024-03-18T04:54:23Z"}, {"author": "Daniel Gillmor", "text": "

i mean, it's new to this implementer, maybe. but the existing codebases available under very permissive licensing terms are probably more robust than some legacy RSA codebase

", "time": "2024-03-18T04:54:42Z"}, {"author": "Daniel Gillmor", "text": "

please don't type in this code :)

", "time": "2024-03-18T04:55:28Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Massimiliano Pala said:

\n
\n

@deirdre if that needs to be, that is fine. But are we all really ok in not even considering the issue? I think it would be great if there were people who are willing to try to look at the problems differently than we did in the past? I just wanted to provide a different point of view that, unfortunately, is often ignored by us technologist... :(

\n
\n

Going directly to PQ-only basically because the cost of doing a hybrid transition and then _another_ transition to PQ-only (which would be the ideal final state eventually) may happen just because many users of these protocols aren't in a position to do multiple transitions, not because we don't try to make it possible, i think

\n
\n

Of course there may be parties that go to hybrid and never leave...

", "time": "2024-03-18T04:55:34Z"}, {"author": "Robert Moskowitz", "text": "

No May about it.

", "time": "2024-03-18T04:57:05Z"}, {"author": "Christopher Patton", "text": "

@Mohammad Jauhar there are a few other small changes between 18 and RFC.

", "time": "2024-03-18T04:57:09Z"}, {"author": "Deirdre Connolly", "text": "

:wave:

", "time": "2024-03-18T04:57:13Z"}, {"author": "Mike Ounsworth", "text": "

@Deirdre Connolly Just to be clear, we should probably state \"migrate to PQ-hybrid and then PQ'-only\" where PQ may or may not be equal to PQ' -- ie by the time we get to the \"migrate-out\", lattices may or may
\nnot still be the thing.

", "time": "2024-03-18T04:57:17Z"}, {"author": "Nick Sullivan", "text": "

\"Of course there may be parties that go to hybrid and never leave...\" - This seems like a likely outcome. Moving from hybrid to pure PQ is strictly worse from a theoretical security perspective, and only slight improvements in perf. Not a great motivator historically.

", "time": "2024-03-18T04:57:25Z"}, {"author": "Robert Moskowitz", "text": "

night all.

", "time": "2024-03-18T04:57:30Z"}, {"author": "John Gray", "text": "

Thanks for the great chat everyone, and such a great session! I almost feel like I'm in Australia.... :)

", "time": "2024-03-18T04:57:40Z"}, {"author": "Muhammad Sardar", "text": "

sorry, I think I lost connection for a while.

", "time": "2024-03-18T04:57:53Z"}]