[{"author": "Christopher Patton", "text": "Howdy!<br/>", "time": "2022-03-24T13:30:37Z"}, {"author": "Robin Wilton", "text": "Hi everyone<br/>", "time": "2022-03-24T13:30:49Z"}, {"author": "Bob Moskowitz", "text": "For only 30min then off to the dentist and listen to the recording later.&nbsp;&nbsp;:(<br/>", "time": "2022-03-24T13:31:35Z"}, {"author": "Alexey Melnikov", "text": "Any note takers?<br/>", "time": "2022-03-24T13:31:59Z"}, {"author": "Christopher Patton", "text": "i can do it<br/>", "time": "2022-03-24T13:32:06Z"}, {"author": "Christopher Patton", "text": "but someone will have to take over<br/>", "time": "2022-03-24T13:32:12Z"}, {"author": "Christopher Patton", "text": "during my talk<br/>", "time": "2022-03-24T13:32:17Z"}, {"author": "Robin Wilton", "text": "Thanks both!<br/>", "time": "2022-03-24T13:32:20Z"}, {"author": "Robin Wilton", "text": "I can help Rich while you're speaking, if that's necessary.<br/>", "time": "2022-03-24T13:32:35Z"}, {"author": "Thom Wiggers", "text": ":wave:<br/>", "time": "2022-03-24T13:33:35Z"}, {"author": "sftcd", "text": "a constructive agenda-bash!<br/>", "time": "2022-03-24T13:34:53Z"}, {"author": "John Preu\u00df Mattsson", "text": "raft-mattsson-cfrg-det-sigs-with-noise-04 is not exipred<br/>", "time": "2022-03-24T13:36:06Z"}, {"author": "Stanislav Smyshlyaev", "text": "<a href=\"https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel\" rel=\"nofollow\">https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel</a><br/>", "time": "2022-03-24T13:41:31Z"}, {"author": "Christopher Wood", "text": "The review panel archive is public: <a href=\"https://mailarchive.ietf.org/arch/browse/crypto-panel/\" rel=\"nofollow\">https://mailarchive.ietf.org/arch/browse/crypto-panel/</a><br/>", "time": "2022-03-24T13:41:32Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Yeah, passing control of the live slide deck is a pretty neet feature.<br/>", "time": "2022-03-24T13:43:49Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "As I understand things, you couldn't do that in webex or zoom.<br/>", "time": "2022-03-24T13:44:03Z"}, {"author": "sftcd", "text": "@kaduk: yeah it's neat, I guess it may take a while to be better known<br/>", "time": "2022-03-24T13:44:52Z"}, {"author": "Colin Perkins", "text": "I was impressed by how well it worked in the plenary yesterday too - it's very handy<br/>", "time": "2022-03-24T13:44:56Z"}, {"author": "Rene Struik", "text": "stebila<br/>", "time": "2022-03-24T13:47:27Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "It may also take a while for the \"local mute\" functionality to be<br/>better known, though it only applies in some limited cases.<br/>", "time": "2022-03-24T13:48:42Z"}, {"author": "Richard Barnes", "text": "this seems similar to the BIP32 key derivation stuff?<br/>", "time": "2022-03-24T13:50:39Z"}, {"author": "Richard Barnes", "text": "<a href=\"https://river.com/learn/terms/b/bip-32/\" rel=\"nofollow\">https://river.com/learn/terms/b/bip-32/</a><br/>", "time": "2022-03-24T13:50:51Z"}, {"author": "Richard Barnes", "text": "<a href=\"https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki\" rel=\"nofollow\">https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki</a><br/>", "time": "2022-03-24T13:51:16Z"}, {"author": "Thom Wiggers", "text": "BIP32 was mentioned as an application earlier<br/>", "time": "2022-03-24T13:51:40Z"}, {"author": "Richard Barnes", "text": "ah, thanks, i missed the start<br/>", "time": "2022-03-24T13:51:50Z"}, {"author": "cabo", "text": "(What happened to ## 14:35 - Chris Wood, \"Discussion of pseudocode in CFRG drafts\" (15 mins) agenda item?)<br/>", "time": "2022-03-24T13:51:59Z"}, {"author": "Tommy Pauly", "text": "That got moved to the end<br/>", "time": "2022-03-24T13:52:14Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "agenda-bashed to the end<br/>", "time": "2022-03-24T13:52:15Z"}, {"author": "sftcd", "text": "chris volunteered to put it at the end to keep time for tech topics<br/>", "time": "2022-03-24T13:52:16Z"}, {"author": "Thom Wiggers", "text": "Got moved to the end<br/>", "time": "2022-03-24T13:52:16Z"}, {"author": "cabo", "text": "Thanks!<br/>", "time": "2022-03-24T13:52:33Z"}, {"author": "Thom Wiggers", "text": "Great presentation<br/>", "time": "2022-03-24T13:55:52Z"}, {"author": "sftcd", "text": "working on this seems like a good idea<br/>", "time": "2022-03-24T13:56:04Z"}, {"author": "sftcd", "text": "I don't know if this scheme is the place to start (not doubting it, just my ignorance)<br/>", "time": "2022-03-24T13:56:25Z"}, {"author": "Frederic Jacobs", "text": "Related key attacks issue: <a href=\"https://github.com/chris-wood/draft-dew-cfrg-signature-key-blinding/issues/14\" rel=\"nofollow\">https://github.com/chris-wood/draft-dew-cfrg-signature-key-blinding/issues/14</a><br/>", "time": "2022-03-24T13:58:48Z"}, {"author": "Christopher Patton", "text": "Thanks! This does sound like interesting work.<br/>", "time": "2022-03-24T13:58:57Z"}, {"author": "Frederic Jacobs", "text": "<a href=\"https://github.com/tfpauly/privacy-proxy/issues/166\" rel=\"nofollow\">https://github.com/tfpauly/privacy-proxy/issues/166</a><br/>", "time": "2022-03-24T13:59:02Z"}, {"author": "Christopher Wood", "text": "@Chris: <a href=\"https://github.com/chris-wood/draft-dew-cfrg-signature-key-blinding/commit/ecbe553cf39390b68f79032ce1203fca28ec09e5\" rel=\"nofollow\">https://github.com/chris-wood/draft-dew-cfrg-signature-key-blinding/commit/ecbe553cf39390b68f79032ce1203fca28ec09e5</a> is the ECDSA \"tweak\"<br/>", "time": "2022-03-24T13:59:50Z"}, {"author": "Christopher Wood", "text": "TL;DR: instead of BlindPublicKey(pk, skB) = ScalarMult(pk, skB)<br/>", "time": "2022-03-24T14:00:06Z"}, {"author": "Christopher Wood", "text": "It's BlindPublicKey(pk, skB) = ScalarMult(pk, HashToScalar(skB))<br/>", "time": "2022-03-24T14:00:13Z"}, {"author": "Phillip Hallam-Baker", "text": "Why does a key exchange protocol require a signature scheme?<br/>", "time": "2022-03-24T14:00:55Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "authentication :)<br/>", "time": "2022-03-24T14:01:20Z"}, {"author": "Phillip Hallam-Baker", "text": "Authentication is implicit in the proof of knowledge of the key exchange private key<br/>", "time": "2022-03-24T14:01:52Z"}, {"author": "Scott Fluhrer", "text": "If you're in a server-client model (where the server has signficant resources), would one-way authentication work?<br/>", "time": "2022-03-24T14:02:03Z"}, {"author": "Scott Fluhrer", "text": "That would assume that the server doesn't care who the client is, of course.&nbsp;&nbsp;Don't know if that fits in the LAKE model...<br/>", "time": "2022-03-24T14:04:30Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "(to be clear, EDHOC is basically a SIGMA-type protocol)<br/>", "time": "2022-03-24T14:05:02Z"}, {"author": "Phillip Hallam-Baker", "text": "@scott, you definitely want mutual authentication. But the Signal approach works without any signature scheme<br/>", "time": "2022-03-24T14:05:18Z"}, {"author": "Thom Wiggers", "text": "Rene is glitching a lot<br/>", "time": "2022-03-24T14:06:41Z"}, {"author": "Alexey Melnikov", "text": "Rene your audio was very noisy<br/>", "time": "2022-03-24T14:06:57Z"}, {"author": "Michael B", "text": "Rene can you write in the chat?<br/>", "time": "2022-03-24T14:07:03Z"}, {"author": "Frederic Jacobs", "text": "Just a note, algorithms don't get DPA-attacked. Implementations are.<br/>", "time": "2022-03-24T14:07:20Z"}, {"author": "Scott Fluhrer", "text": "Of course, some algorithms are much friendlier to DPA-protected implementations...<br/>", "time": "2022-03-24T14:07:52Z"}, {"author": "Yoav Nir", "text": "Seems weird to me to make RSA the MTI algorithm in 2022.&nbsp;&nbsp;As for ECDSA, I don't think P-256 is viable for some of the vendors because of CNSA<br/>", "time": "2022-03-24T14:08:11Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "If we're asking everyone to implement it, it seems like the operative<br/>question is which one is the hardest to mess up badly while<br/>implementing<br/>", "time": "2022-03-24T14:08:17Z"}, {"author": "Yoav Nir", "text": "Meh, I've never found it remotely difficult to write buggy code<br/>", "time": "2022-03-24T14:08:45Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "\"hardest\" is a relative term ;)<br/>", "time": "2022-03-24T14:09:06Z"}, {"author": "Scott Fluhrer", "text": "Actually, what we want is to make it hard to accidentally write code that \"almost works\" - that is, it interoperates nicely, but is insecure<br/>", "time": "2022-03-24T14:09:42Z"}, {"author": "Michael StJohns", "text": "Q: are deterministic EC signature systems less robust than random signature schemes as a general matter?<br/>", "time": "2022-03-24T14:10:03Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I think you have to specify what variables you are measuring<br/>variations on, to measure \"robustness\", at least in this space<br/>", "time": "2022-03-24T14:10:37Z"}, {"author": "Yoav Nir", "text": "Besides, how many bits would we specify now for RSA?&nbsp;&nbsp;Are 4096 enough?<br/>", "time": "2022-03-24T14:11:00Z"}, {"author": "Michael StJohns", "text": "@kaduk - fair, but given the constraints that SF stated?&nbsp;&nbsp;e.g. generic small device possibly vulnerable to fault detection?<br/>", "time": "2022-03-24T14:12:18Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Yeah, we could probably write up a specific list of variables for the<br/>constraints Stephen presented.&nbsp;&nbsp;Actually making the list seems like an<br/>exercise we should perform.<br/>", "time": "2022-03-24T14:13:15Z"}, {"author": "kivinen", "text": "Small battery powered devices are quite easy to mess up from the powerside, i.e., measure the power consumption and lower the voltage as needed etc... <br/>", "time": "2022-03-24T14:13:21Z"}, {"author": "John Preu\u00df Mattsson", "text": "EDHOC do have a mode with implicit authentication using only ECDHE, i.e. no signatures. I think the problem is legacy. People want to use certificates and it is not always possible to get a X.509 certificate with a ECDHE key.<br/>", "time": "2022-03-24T14:13:56Z"}, {"author": "Phillip Hallam-Baker", "text": "@yoav, I think the current CABForum requirement is at 3072 or whatev. But that is still not as good as Ed25519<br/>", "time": "2022-03-24T14:14:19Z"}, {"author": "Christopher Patton", "text": "@Bart: Did I get this right in the notes? \"DPA attacks exploit non-determnisim, but other, simpler attacks do not\"<br/>", "time": "2022-03-24T14:14:40Z"}, {"author": "John Preu\u00df Mattsson", "text": "It is 3072 for code signing. 2048 for TLS server<br/>", "time": "2022-03-24T14:14:41Z"}, {"author": "Michael StJohns", "text": "@kaduk - or the reverse - assumptions on implementation environment for various levels of security?<br/>", "time": "2022-03-24T14:14:58Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "sure<br/>", "time": "2022-03-24T14:15:27Z"}, {"author": "John Preu\u00df Mattsson", "text": "I think 3072 is a good level for anything new using RSA.<br/>", "time": "2022-03-24T14:15:32Z"}, {"author": "Britta Hale", "text": "@Philip: the Signal approach has no mutual authentication - i.e. trust-on-first-use. The only time it gets mutual authentication is through comparison of the numeric codes via a trusted medium (in-person or via website posting and using that as a TTP). Post on a website is essentially broadcasting the claim, which is arguably worse for privacy. A mutual authentication *option* (not necessarily this as MTI, but an option) that does not do that may be beneficial for some applications.<br/>", "time": "2022-03-24T14:16:08Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "@John I'm failing to find the relevant message from Ilari quickly.&nbsp;&nbsp;Do<br/>you remember why there was not a universal recommendation to do the<br/>option including both deterministic and random input?<br/>", "time": "2022-03-24T14:16:43Z"}, {"author": "Scott Fluhrer", "text": "I personally don't see the point of RSA keys larger than 3072; with current algorithms, we can't get enough computation to break that (so larger keys are no more secure); against Quantum Computers, larger keys are only marginally more secure than 3072, so there is little gain there.<br/>", "time": "2022-03-24T14:17:19Z"}, {"author": "Phillip Hallam-Baker", "text": "@Britta, Signal's PKI is bjorked. I have no idea what they are trying to do or why. Telephone numbers? What the hell is a telephone?<br/>", "time": "2022-03-24T14:17:22Z"}, {"author": "Robin Wilton", "text": "@PHB What makes you think the number for my Signal account also works as a phone number??<br/>", "time": "2022-03-24T14:18:16Z"}, {"author": "sftcd", "text": "catching up on the chat now I'm back @ keyboard...<br/>", "time": "2022-03-24T14:19:09Z"}, {"author": "Richard Barnes", "text": "to be clear: not general MPC, just the MPC algorithms needed for PPM<br/>", "time": "2022-03-24T14:19:12Z"}, {"author": "sftcd", "text": "@yoav: I only really put RSA in there because the 1st paper I ref'd has such a nice description of a way to do fault injection (and use that to extract RSA signing key)<br/>", "time": "2022-03-24T14:19:46Z"}, {"author": "Britta Hale", "text": "@Philip: Agree on PKI in that. (You mentioned Signal as an alternative solution to blinding... there may not be a ideal solution to such use cases though.)<br/>", "time": "2022-03-24T14:20:05Z"}, {"author": "sftcd", "text": "@kaduk: I also think some guidance for implementors as to these issues would be great<br/>", "time": "2022-03-24T14:20:11Z"}, {"author": "Phillip Hallam-Baker", "text": "@Britta, that said, if Alice has public keypair {A, a} and Bob has {B, b} and Alice has a certificate for B and Bob has a certificate for A, and they both generate an ephemeral {X, x}, {Y, y} then a party can only calculate (H(x.A) + H(y.B)) if they know a and x or b. and y<br/>", "time": "2022-03-24T14:21:35Z"}, {"author": "Britta Hale", "text": "That argument relies on authentication of keys, e.g. through use of signatures.<br/>", "time": "2022-03-24T14:22:26Z"}, {"author": "sftcd", "text": "@kaduk/@msj: wrt guidance, I do wonder who'd be willing/capable of writing that and whether it could be done so as to be relevant for a reasonable while<br/>", "time": "2022-03-24T14:23:03Z"}, {"author": "Phillip Hallam-Baker", "text": "@Britta, the Signal key establishment protocol is sound, their PKI is just bizarre.<br/>", "time": "2022-03-24T14:23:35Z"}, {"author": "John Preu\u00df Mattsson", "text": "@kaduk<br/><a href=\"https://mailarchive.ietf.org/arch/msg/cfrg/GB4cZONhTMx5kDkWyQxEd_J5efU/\" rel=\"nofollow\">https://mailarchive.ietf.org/arch/msg/cfrg/GB4cZONhTMx5kDkWyQxEd_J5efU/</a><br/>\"Random, noisy and deterministic all have advantages and disadvantages.<br/>I think that:<br/>1) If you need one-pass operation, use random and harden against<br/>&nbsp;&nbsp; fault attacks (as one-pass needs random, and random is vulernable<br/>&nbsp;&nbsp; to fault attacks).<br/>2) Otherwise, If you have physically secure hardware, use deterministic.<br/>3) Otherwise use noisy.\"<br/>So, the only reason to do 1) and not 2) would be performance. Could be discussed if that performance gain is needed. For small messages it might not do a big difference.<br/>", "time": "2022-03-24T14:24:16Z"}, {"author": "Deb Cooley", "text": "reading way back.... @John&nbsp;&nbsp;it should be virtually impossible to get a certificate for an ECDHE key.... way easier to get one for ECDH.&nbsp;&nbsp;But that it normally problematic for other reasons.<br/>", "time": "2022-03-24T14:24:40Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Thanks John!<br/>", "time": "2022-03-24T14:24:53Z"}, {"author": "Britta Hale", "text": "@Philip: Signatures are what give a better PKI.<br/>", "time": "2022-03-24T14:25:06Z"}, {"author": "Phillip Hallam-Baker", "text": "@Britta, Trust providers need signature keys. Keys used for key signing should never be used for any other purpose.<br/>", "time": "2022-03-24T14:27:58Z"}, {"author": "Phillip Hallam-Baker", "text": "OCB mode... out of patent now<br/>", "time": "2022-03-24T14:38:33Z"}, {"author": "Britta Hale", "text": "@Philip: Authentication binding of the PKI key(s) to the KE. ;)<br/>", "time": "2022-03-24T14:39:12Z"}, {"author": "Scott Fluhrer", "text": "Why is this attack specific to GCM?&nbsp;&nbsp;If the attacker controls both the encryptor and decryptor, can't the attacker replace the algorithms used to anything the attacker finds convienent.<br/>", "time": "2022-03-24T14:43:08Z"}, {"author": "Christian Veenman", "text": "Good question, I am wondering that as well, but that might be my lack of expertise in this field<br/>", "time": "2022-03-24T14:44:02Z"}, {"author": "John Preu\u00df Mattsson", "text": "@scott I wonder the same. Good if somebody raise their hand and ask.<br/>", "time": "2022-03-24T14:44:39Z"}, {"author": "Juhamatti Kuusisaari", "text": "The idea was apparently that it can be with MITM only in the device without control of encryptor or decryptor.<br/>", "time": "2022-03-24T14:45:15Z"}, {"author": "Massimiliano Pala", "text": "@Scott: The attack needs to stay in the same parameters of the original communication channel.<br/>", "time": "2022-03-24T14:47:51Z"}, {"author": "Benson Muite", "text": "yes<br/>", "time": "2022-03-24T14:48:43Z"}, {"author": "John Preu\u00df Mattsson", "text": "To give guidance on how to input several keys in your KDF might be a good idea. What anout KMAC?<br/>", "time": "2022-03-24T14:54:33Z"}, {"author": "Richard Barnes", "text": "does this expand to n-KDF in the obvious way?<br/>", "time": "2022-03-24T14:54:59Z"}, {"author": "Joachim Fabini", "text": "@Scott: first: we assumed that the encrypted text is not touched. Assume the attacker is on the path and not co-located with the sender. In this case there's no way to modify the encrypted message C such that the compromised receiver can reconstruct it. However the AuthTag is available.<br/>", "time": "2022-03-24T14:59:16Z"}, {"author": "Phillip Hallam-Baker", "text": "If I was going to change my KDF at all, I would also move to KMAC<br/>", "time": "2022-03-24T14:59:28Z"}, {"author": "Bart Preneel", "text": "@Christopher: DPA attacks rely on a function that takes a key and a varying input.&nbsp;&nbsp;SPA may be helped by determinism (repeating the same calculation allows averaging out noise). Fault attacks can also benefit from determinism.&nbsp;&nbsp;Secure implementations can be written for both. See also <a href=\"https://www.ietf.org/id/draft-mattsson-cfrg-det-sigs-with-noise-04.html\" rel=\"nofollow\">https://www.ietf.org/id/draft-mattsson-cfrg-det-sigs-with-noise-04.html</a><br/>", "time": "2022-03-24T15:01:24Z"}, {"author": "Frederic Jacobs", "text": "Chris Brzuska on the n-PRF&nbsp;&nbsp;<a href=\"https://mailarchive.ietf.org/arch/browse/mls/?index=IzktKGmKW06r8wNA5fwXueRIiXo\" rel=\"nofollow\">https://mailarchive.ietf.org/arch/browse/mls/?index=IzktKGmKW06r8wNA5fwXueRIiXo</a><br/>", "time": "2022-03-24T15:02:47Z"}, {"author": "John Preu\u00df Mattsson", "text": "+1 for KMAC going forward<br/>", "time": "2022-03-24T15:06:21Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "KMAC is probably worth reading up in general<br/>", "time": "2022-03-24T15:06:39Z"}, {"author": "Phillip Hallam-Baker", "text": "KMAC is Spongeworthy<br/>", "time": "2022-03-24T15:06:43Z"}, {"author": "Christopher Wood", "text": "@Nimrod, this paper in particular relies on the dual PRF property of HMAC, e.g., in the proof of thm 6.2: <a href=\"https://eprint.iacr.org/2020/1044.pdf\" rel=\"nofollow\">https://eprint.iacr.org/2020/1044.pdf</a><br/>", "time": "2022-03-24T15:07:17Z"}, {"author": "Thom Wiggers", "text": "(Extensions/variants of that work, such as the analysis of KEMTLS also use dual-PRF of HKDF)<br/>", "time": "2022-03-24T15:09:35Z"}, {"author": "Phillip Hallam-Baker", "text": "@Christopher, the high level point here is that when HMAC and HKDF were designed, we were not doing routine proofs of correctness for crypto protocols. So this was not a major concern. Now we do and it is.<br/>", "time": "2022-03-24T15:10:57Z"}, {"author": "Christopher Wood", "text": "I'm not disagreeing, I'm simply observing that we seemingly rely quite heavily on this property, and I would like to understand the implications on past analyses if the claims do not hold. In particular, can the proofs be recovered?<br/>", "time": "2022-03-24T15:12:50Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "As a protocol engineer, I'm sitting here pondering how much faster the<br/>cipher needs to be in order for it to be worth trying to implement and<br/>deploy it into an existing ecosystem.<br/>", "time": "2022-03-24T15:14:50Z"}, {"author": "Russ Housley", "text": "What is the ask of CFRG?<br/>", "time": "2022-03-24T15:14:53Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I believe I saw (on the agenda, maybe?) that the ask was for<br/>adoption and publication<br/>", "time": "2022-03-24T15:15:52Z"}, {"author": "Frank Denis", "text": "Correct, this is a call for adoption by CFRG.<br/>", "time": "2022-03-24T15:16:10Z"}, {"author": "Joachim Fabini", "text": "@Jonathan: very good observation, indeed. I'd just like to add that on this behalf we \"sacrifice\" part of the available authTag to include a specific bit pattern/hash. In our proof-of-concept the compromised receiver checks the specific pattern - on match, it infers on a subliminal message and applies the *en*cryption mechanism. Otherwise it infers on a legitimate tag and proceeds with *de*cryption, so a faulty AuthTag will result in the expected CKDM reject. Apologies, time was too short to go into implementation details.<br/>", "time": "2022-03-24T15:16:39Z"}, {"author": "Phillip Hallam-Baker", "text": "@kaduck, I am not comfortable with GCM. So it is a somewhat different calculation<br/>", "time": "2022-03-24T15:17:17Z"}, {"author": "Phillip Hallam-Baker", "text": "@kaduck, on the other hand, I already have OCB<br/>", "time": "2022-03-24T15:17:29Z"}, {"author": "Christopher Wood", "text": "A call for adoption seems appropriate<br/>", "time": "2022-03-24T15:17:31Z"}, {"author": "John Preu\u00df Mattsson", "text": "AEGIS seems like a good fit for CFRG. Speed is important.<br/>", "time": "2022-03-24T15:17:45Z"}, {"author": "Christopher Patton", "text": "Would be interesting to consider a nonce misuse resistant variant. If faster than AES-GCM-SIV, then could be worth standardizing as well<br/>", "time": "2022-03-24T15:17:47Z"}, {"author": "Britta Hale", "text": "Given how long AES has been around, a standardized alternative to it is valuable.<br/>", "time": "2022-03-24T15:17:49Z"}, {"author": "sftcd", "text": "having an RFC for this seems sensible, I'm not sure it'd displace gcm though<br/>", "time": "2022-03-24T15:17:56Z"}, {"author": "Christopher Patton", "text": "Yeah, unlikely in the near term for sure<br/>", "time": "2022-03-24T15:18:12Z"}, {"author": "Rich Salz", "text": "but if it can use AES-NI instructions, that's pretty cool.<br/>", "time": "2022-03-24T15:18:21Z"}, {"author": "Phillip Hallam-Baker", "text": "@sftcd wont displace in TLS but there are other oceans to boil<br/>", "time": "2022-03-24T15:18:31Z"}, {"author": "Clemens Fruhwirth", "text": "Rich Salz: It can, and that's what makes it fast in software<br/>", "time": "2022-03-24T15:18:34Z"}, {"author": "BEHCET SARIKAYA", "text": "not many people in the room but &gt;100 online<br/>", "time": "2022-03-24T15:18:41Z"}, {"author": "Rich Salz", "text": "yeah i get that.&nbsp;&nbsp;neat.&nbsp;&nbsp;<br/>", "time": "2022-03-24T15:18:55Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Yes, a different story for a greenfield scenario vs existing<br/>ecosystem, though still perhaps questions about whether it will get<br/>implemented+adopted<br/>", "time": "2022-03-24T15:19:08Z"}, {"author": "Bart Preneel", "text": "There is already some deployment f AEGIS.<br/>", "time": "2022-03-24T15:19:48Z"}, {"author": "BEHCET SARIKAYA", "text": "where?<br/>", "time": "2022-03-24T15:20:47Z"}, {"author": "Frank Denis", "text": "AEGIS128L is 2.5x faster than AES-GCM (Zig implementation vs OpenSSL 3 implementation) on Rocket Lake. It's also extremely simple to implement.<br/>", "time": "2022-03-24T15:20:48Z"}, {"author": "Frank Denis", "text": "There are already deployments of AEGIS, in spite of a proper specification.<br/>", "time": "2022-03-24T15:21:01Z"}, {"author": "Clemens Fruhwirth", "text": "Armando: It makes a great replacement for AES-GCM, so we assume that wherever it is to be deployed, we have some silicon that can do the AES round function reasonably fast. If you have restricted silicon space, then probably the design from the lightweight competition is a better replacement.<br/>", "time": "2022-03-24T15:21:09Z"}, {"author": "Scott Fluhrer", "text": "Random AEGIS question: how friendly is it to a hardware-based pipeline (&gt;400gbps) implementation<br/>", "time": "2022-03-24T15:21:14Z"}, {"author": "Frank Denis", "text": "Linux kernel (for dm-crypt), libsodium, zig standard library, glorytun, routers from the OVH network<br/>", "time": "2022-03-24T15:21:39Z"}, {"author": "BEHCET SARIKAYA", "text": "running code as important for an RG?<br/>", "time": "2022-03-24T15:23:08Z"}, {"author": "John Preu\u00df Mattsson", "text": "Good idea to registrer compact representation for HPKE<br/>", "time": "2022-03-24T15:23:08Z"}, {"author": "Clemens Fruhwirth", "text": "Scott: Here are some implementations on FPGAs <a href=\"https://cryptography.gmu.edu/athenadb/fpga_auth_cipher/results/706\" rel=\"nofollow\">https://cryptography.gmu.edu/athenadb/fpga_auth_cipher/results/706</a> . It is a 10x improvement compared to AES-GCM in throughput/area metric, so hardware-based pipelines achieving 400gpbs should cheaper to realized than with AES-GCM.<br/>", "time": "2022-03-24T15:23:13Z"}, {"author": "Phillip Hallam-Baker", "text": "Did Stephen just shorten x25519 to x259? We should do that.<br/>", "time": "2022-03-24T15:24:47Z"}, {"author": "cabo", "text": "I head x509 :-)<br/>", "time": "2022-03-24T15:25:06Z"}, {"author": "sftcd", "text": "nah, I just mumbled<br/>", "time": "2022-03-24T15:25:06Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "x259 would make me think Wolf 359, but I bet that's just me...<br/>", "time": "2022-03-24T15:25:28Z"}, {"author": "cabo", "text": "Do we have to bundle all three extensions into one work item?<br/>", "time": "2022-03-24T15:25:56Z"}, {"author": "cabo", "text": "I'd like to have compact relatively quickly.<br/>", "time": "2022-03-24T15:26:09Z"}, {"author": "sftcd", "text": "I guess what I think I just suggested is moving hpke to standards-track in ietf somewhere but not sure if I really think that's a good or bad idea (worth pondering though) as most of Dan's stuff is maintainence<br/>", "time": "2022-03-24T15:26:11Z"}, {"author": "sftcd", "text": "there'll also be the usual PQC crowd piling on too I bet<br/>", "time": "2022-03-24T15:26:28Z"}, {"author": "Michael Fountaine", "text": "I think curves over Z(2^5 - 9) may be vulnerable to subgroup attacks :) <br/>", "time": "2022-03-24T15:26:38Z"}, {"author": "Rich Salz", "text": "Sorry for the interrupt, that was a bit rude.<br/>", "time": "2022-03-24T15:27:06Z"}, {"author": "Thom Wiggers", "text": "HPKE will probably need PQ work and all the authenticated bits in it assume DH\u2019s properties afaik\u2026<br/>", "time": "2022-03-24T15:27:10Z"}, {"author": "Christopher Patton", "text": "there's also Chris Wood's talk<br/>", "time": "2022-03-24T15:27:59Z"}, {"author": "Phillip Hallam-Baker", "text": "@Michael, 23 is prime. What more do you want?<br/>", "time": "2022-03-24T15:29:17Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "BTW, the IESG has an action item open to get DEs for the registries<br/>from RFC 9180<br/>", "time": "2022-03-24T15:29:25Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "group of order 23 sounds like a small group to me...<br/>", "time": "2022-03-24T15:29:43Z"}, {"author": "Benson Muite", "text": "Thanks<br/>", "time": "2022-03-24T15:30:12Z"}, {"author": "Robin Wilton", "text": "Thanks everyone - fascinating as usual!<br/>", "time": "2022-03-24T15:30:12Z"}]