IETF
cfrg
cfrg@jabber.ietf.org
Tuesday, April 29, 2014< ^ >
Room Configuration
Room Occupants

GMT+0
[18:53:52] sftcd joins the room
[19:01:02] dkg joins the room
[19:01:25] ekr@ecotroph.net joins the room
[19:01:29] <ekr@ecotroph.net> I am on.
[19:01:39] <dkg> i am on as well (via phone)
[19:01:43] <dkg> i can hear :)
[19:07:33] <sftcd> why bother fixing that ?
[19:11:09] Russ Housley joins the room
[19:11:42] wwhyte joins the room
[19:12:05] Paul Hoffman joins the room
[19:12:13] sean.turner@jabber.psg.com joins the room
[19:12:19] djb joins the room
[19:15:37] <sftcd> suite-B is national specific, albeit important
[19:15:58] <ekr@ecotroph.net> sftcd: totally
[19:16:17] <Paul Hoffman> Also, we suck at predicting what NIST will do. Even NIST sucks at that.
[19:16:19] <ekr@ecotroph.net> I think it's really FIPS which is most relevant, because there are so many standards which refer to FIPS
[19:16:23] <ekr@ecotroph.net> Paul: totally
[19:17:33] <ekr@ecotroph.net> Glad to see Tanja on the call
[19:18:09] <sftcd> yeah that was the point of the call really, to get the likes of IETFers and real crypto folk at one time
[19:20:51] hyperelliptic joins the room
[19:21:26] <hyperelliptic> Hi, this is Tanja Lange joining
[19:21:31] rsalz joins the room
[19:23:17] <sftcd> is that R6 really doable in practice?
[19:23:31] <djb> as a webex newbie i observe that there's also a webex chat window; any preferences between that one and this one?
[19:23:37] <Russ Housley> I think we need to support FIPS approved curves, at least the prime ones, even if we pick another on as mandatory-to-implement
[19:23:52] <sean.turner@jabber.psg.com> @djb usually it's this one
[19:23:53] <sftcd> @djb: this ones is better for me, webex is on my phone
[19:23:54] <Paul Hoffman> djb: This one is much bigger. That turns out to be important.
[19:23:59] <ekr@ecotroph.net> I think this one.
[19:24:23] <sftcd> and this is also better since not everyone knows about it:-)
[19:24:39] <djb> :-)
[19:25:16] <Russ Housley> @djb: XMPP (the standard being used here) has many more clients, which let's people pick their fav interface
[19:25:36] <djb> sure; but it seems there are many more people on the webex system than have joined here
[19:26:47] <hyperelliptic> slides are invisible here
[19:27:44] <Paul Hoffman> @djb People often can only handle listening, and ignore the IM during meetings.
[19:28:23] <rsalz> @Paul, or vice-versa.
[19:28:42] <sftcd> often jabber is much more fun (for boring concalls)
[19:28:48] <sean.turner@jabber.psg.com> :)
[19:29:46] <sftcd> anyway, back to my earlier question: Is David's R6 requirement actually feasible?
[19:30:08] <sftcd> R6 was the one to interop with current <something> for new curves via parameters I think
[19:30:48] <djb> side comment: the 5-year suggestion is interesting ... but ecc cryptanalysis is always looking beyond particular curves, very much the same way that people developing factoring algorithms are always looking beyond factoring one particular N=pq
[19:31:37] <dkg> it seems like we'd lose several of the advantages of the 25519 proposals if we tried to pack them into the parameterized ECC space in current protocols (if it's even possible to do)
[19:31:58] <sftcd> and who'd want it anyway?
[19:32:05] <djb> there's certainly a conflict between R6 code reuse and R1 simplicity
[19:32:39] sftcd would ditch R6 I think
[19:33:51] <djb> fun fact: if you look at the curves in "openssl ecparam -list_curves" you are actually looking at curves implemented in multiple ways
[19:34:20] <djb> "wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field" is actually exactly the same curve as nist p-224 but has a different code base
[19:34:29] <Paul Hoffman> @djb: exactly. And no one in the application space knows this. Trying to do R6 is a waste of effort.
[19:34:47] Karen O'Donoghue joins the room
[19:35:05] <sean.turner@jabber.psg.com> I have no doubt that any curve we pick will ensure it gets even more review than it already got
[19:35:30] <sftcd> how long might that take I wonder (can you TLS WG chairs race the crypto folks:-)
[19:35:49] <wwhyte> It might make sense to provisionally pick a curve, thereby encouraging review, then wait for say three years before locking it down
[19:36:00] <ekr@ecotroph.net> wwhyte: what would that actually mean?
[19:36:02] <Paul Hoffman> @sean: not necessarily. DNSSEC allowed GOST two years ago, and there has been almost nothing new published on them since.
[19:36:08] <ekr@ecotroph.net> I mean, as soon as we assign the code point, people will use it
[19:36:14] <dkg> if we wait three years to lock it down, there will be another 5 years for deployment rollout
[19:36:15] <sftcd> right probably before
[19:36:17] <ekr@ecotroph.net> perhaps even before as soon :)
[19:36:41] <wwhyte> So some people are saying it'll take eight years and some are saying it'll take -1?
[19:36:43] <dkg> if we want wide deployment any time in the near future, we need to pick something sooner tha n3 years
[19:36:51] <dkg> wwhyte: i'm saying for wide deployment
[19:36:54] <rsalz> At London IETF, Kenny P said that's the current state:  academic cryptog's find TLS interesting, but won't start focusing on it until it's standardized.
[19:37:00] <wwhyte> If we want something secure, shouldn't we ensure good scrutiny?
[19:37:04] <sean.turner@jabber.psg.com> @paul: had the other curve been a non-national curve I bet it might have been different
[19:37:07] <sftcd> browsers will probably do it anyway unless there's serious pushback
[19:37:12] <rsalz> That's better then it used to be but, present company excepted, still a ways to go for wide pre-publication review.
[19:37:16] <ekr@ecotroph.net> sftcd: I think that's quite likely
[19:37:46] <hyperelliptic> sftcd: google has already moved with Chrome
[19:38:32] synp joins the room
[19:38:32] <sftcd> yep, but that have in the past unmoved back on stuff too, its good that we try be diligent here regardless
[19:38:39] <sftcd> s/that/they/
[19:40:52] <Paul Hoffman> I note that no one here seems to be caring about what René is saying.
[19:41:14] <sftcd> I guess its reasonable for CFRG though, not of much IETF interest I agree
[19:41:20] <ekr@ecotroph.net> I don't think that CFRG needs to pick something today, but if it doesn't happen sometime in the next 6 months or so, I think the security area groups will need to look at picking something directly.
[19:41:35] <ekr@ecotroph.net> maybe 6 months is too short or too long, but some finite time
[19:41:44] <sftcd> and if IETF does it we're not qualified
[19:42:00] <Paul Hoffman> NIST already ran away from EC_DRBG, but some other SDOs seem to be hanging on.
[19:42:06] <sftcd> really? who
[19:42:22] <hyperelliptic> no surprise if Blackberry does
[19:42:29] <Paul Hoffman> ISO, I thought. That is, it was done in parallel with ISO.
[19:42:31] <hyperelliptic> they have a patent on using alternative P and Q
[19:42:39] <sftcd> sheesh
[19:42:44] <hyperelliptic> it's still in ANSI and ISO
[19:43:02] sftcd won't lose sleep over that
[19:43:22] <ekr@ecotroph.net> I do kind of feel like this is not the optimal use of time
[19:43:27] <hyperelliptic> Problem is that I thought it was dead in 2007, couldn't have been more wrong
[19:43:51] <hyperelliptic> but yes, way to fix it (imho) is to remove it
[19:43:56] <hyperelliptic> and kill with fire
[19:44:07] <sean.turner@jabber.psg.com> It'll take ISO years to get rid of it - they've got a cycle on which they publish
[19:44:12] <Paul Hoffman> Tanja: welcome to the IETF. There are many ways to be more wrong every year.
[19:44:21] <hyperelliptic> ;-)
[19:44:27] mark joins the room
[19:44:30] <sftcd> do ISO make washing machines?
[19:44:39] <sean.turner@jabber.psg.com> time machines too
[19:44:46] <sftcd> handy for IPR that
[19:46:11] <djb> there was an impressive change between dan brown's late-december message praising the security of Dual EC and his message a few days later saying that he had reconsidered. what had happened in the meantime was tanja tracking down (and announcing for a crowd of thousands at ccc) the brown-vanstone patent application on (1) exploiting the Dual EC back door and (2) protecting against the back door
[19:46:14] <Russ Housley> Just because there is an ISO number for it, does not mean that people are actually using it
[19:46:50] <Paul Hoffman> @Russ: hopefully true. But hard to measure.
[19:47:02] <Paul Hoffman> People using it are not about to admit it any more.
[19:47:36] <sftcd> if someone would just give us the backdoor number we'd be able to check
[19:47:42] <hyperelliptic> :-)
[19:47:55] <hyperelliptic> List of validated implementations still grew recently
[19:48:08] <Russ Housley> @Paul: If they are, I hope they are not using the default parameters
[19:48:36] Kathleen Moriarty joins the room
[19:48:48] <Paul Hoffman> @Russ: if they are still using it, I would bet they *are* using the default parameters because they are afraid to step away from the earlier guidance.
[19:49:14] <Paul Hoffman> Good, no questions.
[19:49:28] <synp> Assuming Rene is right in making dual-EC secure, I still don't get why I'd prefer that to one of the others
[19:49:50] <sean.turner@jabber.psg.com> well one for the chat room: do we need an EC-based random number generator?
[19:49:58] <sftcd> I don't
[19:50:28] <wwhyte> Nope
[19:50:33] Olafur Gudmundsson joins the room
[19:50:34] <Paul Hoffman> Npe
[19:51:01] <hyperelliptic> For the vendor list see
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
[19:51:05] <Russ Housley> @Sean: It is too slow
[19:51:10] <synp> Nah, I'll just use C's rand(). What could possibly go wrong...
[19:51:31] <hyperelliptic> sean.turner@jabber.psg.com: no
[19:51:50] <Paul Hoffman> Tanja: Those are people who *might* expose it in their implementations. Smart ones have already ripped them out.
[19:51:52] <sftcd> there were no slides here or?
[19:51:56] <ekr@ecotroph.net> there are no slides
[19:52:06] <djb> he announced that he doesn't have slides
[19:52:25] <Paul Hoffman> You can keep your FIPS certificate if you remove a subset of the features that were tested.
[19:52:29] <sftcd> I should listen more;-)
[19:55:33] <hyperelliptic> Paul Hoffman: that doesn't explain validations getting added as late as March which include Dual EC
[19:55:56] <Paul Hoffman> Tanja: actually it does. The lead time for a certificate is about a year.
[19:55:58] <dkg> sounds like we lost dan brown
[19:56:14] <sftcd> we lost a sparse bit
[19:56:24] <djb> comment i just typed into the webex chat: the 2008 koblitz-koblitz-menezes paper, section 11, contains five counterexamples to dan brown's assertion that random curve choices are more secure
[19:57:28] <Paul Hoffman> Unfortunately, I need to split for a second meeting. Party on, y'all. I'll listen to the recording later.
[19:57:30] Paul Hoffman leaves the room
[19:58:34] <djb> comment continued: in these five examples, under perfectly believable hypotheses, random curve choices are _less_ secure. i'm not aware of any papers disputing any of the examples
[19:59:11] <sftcd> was there much crypto work on this nothing-up-my-sleeve stuff before recently? other than ad-hoc I mean
[19:59:15] <ekr@ecotroph.net> djb: you should raise this point when he is done
[19:59:21] <ekr@ecotroph.net> I mean verbally
[19:59:37] <hyperelliptic> Brainpool is from 2005
[20:00:02] <hyperelliptic> in DE/Europe we've been raising concerns over the NIST curves for a long time
[20:00:03] <sftcd> right, but did they generate the params that way based on some theory or just for fun
[20:00:54] <hyperelliptic> the motivation was to show that there is nothing hidden in those numbers
[20:01:18] <hyperelliptic> on http://safecurves.cr.yp.to/rigid.html
[20:01:32] jimsch1 joins the room
[20:01:52] <hyperelliptic> we argue that this still allows for some freedom (=possibility to get in curves with backdoors)
[20:01:55] <sftcd> sure, just wondering if that nothing-hidden principle was common among crypto folk since when
[20:01:58] <hyperelliptic> but significantly less so
[20:02:28] <hyperelliptic> let me start with the opposite: in 1999 it was already pointed out that the NIST/NSA approach is not confidence inspiring
[20:02:32] <wwhyte> I know Don Johnson was very emphatic on the point when I sat in on X9 meetings in 2004-2006
[20:02:49] <hyperelliptic> wwhyte: can you expand on that?
[20:03:29] <wwhyte> I don't remember the details, unfortunately, I was mainly focusing on getting NTRU standardized
[20:03:51] <wwhyte> But at the time Don hammered away on our parameter generation algorithms -- "How can you be sure these weren't cooked?" he would say
[20:04:11] <hyperelliptic> so, what did he say about the NIST curves?
[20:04:23] <wwhyte> So generating parameters in a verifiably pseudorandom way mattered to him
[20:04:32] <hyperelliptic> did he fall for the 'provably randomly generated' argument?
[20:04:39] <wwhyte> I don't remember exactly what he said about the NIST curves. It seems that maybe he did
[20:04:43] <wwhyte> fall for it
[20:04:56] <hyperelliptic> SECG had comments like that
[20:05:07] <hyperelliptic> NIST doesn't have these claims
[20:05:11] <wwhyte> There wasn't concern about the NIST curves that I noticed
[20:05:31] <hyperelliptic> Shortly after the NIST curves were announced, 1999 Scott pointed out that the curves were not in fact verifiably random:
    Now if the idea is to increase our confidence that these curves are therefore completely randomly selected from the vast number of possible elliptic curves and hence likely to be secure, I think this process fails. The underlying assumption is that the vast majority of curves are "good". Consider now the possibility that one in a million of all curves have an exploitable structure that "they" know about, but we don't.. Then "they" simply generate a million random seeds until they find one that generates one of "their" curves. Then they get us to use them. And remember the standard paranoia assumptions apply - "they" have computing power way beyond what we can muster. So maybe that could be 1 billion.
[20:05:38] <wwhyte> There *was* concern about Dual EC DRBG, but mainly about it being slow and biased -- this was before the 2007 presentation
[20:06:02] <wwhyte> Where's that quote from Scott come from?
[20:06:05] <hyperelliptic> Link to Mike Scott's comment http://safecurves.cr.yp.to/refs.html#1999/scott-curves
[20:06:24] <wwhyte> Oh, Mike Scott, sorry, thought you meant Scott Vanstone, that would have been odd.
[20:06:40] <sftcd> quite different
[20:06:48] <hyperelliptic> ah, sorry, no (was just pasting from our page)
[20:06:54] <wwhyte> Yes!
[20:07:35] <wwhyte> I see that that Mike Scott post quotes Don Johnson, who at the time was with Certicom IIRC, so that answers your question about Don and the NIST curves too
[20:07:36] <sftcd> goodman Mike! he never did trust govts:-)
[20:07:52] <hyperelliptic> :-)
[20:07:55] <sftcd> used to be some choice comments in the miracl code
[20:08:36] <hyperelliptic> wwhyte: I know Don's position but was wondering how this came up in the meetings
[20:09:05] <Russ Housley> Compression has Certicom IPR disclosures
[20:09:06] <wwhyte> We were discussing the NTRU parameter generation algorithm
[20:09:45] <wwhyte> Don wanted to ensure that the output was pseudorandom, we had to explain that it was deterministic
[20:09:52] <wwhyte> No random seed necessary
[20:11:29] <djb> IPR: ecc compression to just x was published in 1985; more general ecc compression was published in 1992. there's a patent from 1994 on a specific compression method, but (1) this method isn't any of the methods watson is talking about and (2) the patent expires this year
[20:12:01] <djb> and it's a bit hard to take certicom's IPR disclosures seriously when they claim IPR on ecc with bellbottoms (rfc 6090)
[20:12:49] <sftcd> so just to be sure to be sure when watson says 128 he means what Ekr meant by 256
[20:13:04] <djb> he means 2^128 time to break
[20:13:13] <Russ Housley> @djb: This year is quite soon
[20:13:47] <ekr@ecotroph.net> I should have said the 128-bit security level rather than the 256
[20:13:58] <sean.turner@jabber.psg.com> IANAL: on the expiry I'd heard Jan and then somebody else told me July
[20:14:00] <ekr@ecotroph.net> I meant curve sizes of 256 and 512
[20:14:01] <djb> ok, i guess watson is making the same expiration point now
[20:15:07] <sftcd> I'd like to get why the "...to TLS" was said ther
[20:15:14] <sftcd> later is fine though
[20:15:46] <djb> good question
[20:15:48] Paul Lambert joins the room
[20:16:19] <sean.turner@jabber.psg.com> I think he said the Cheon paper doesn't apply to TLS .. why I'd like to hear too
[20:17:00] <sftcd> thanks dkg, my audio is via wifi/webex/whatever and usually sucks outbound
[20:17:10] <djb> ah, two separate questions: one is why cheon doesn't apply to tls (here i agree); the other is why he was just talking about tls (offhand i can't think of any other ietf protocols where cheon matters)
[20:18:40] <hyperelliptic> pronounced 'salt'
[20:19:19] <ekr@ecotroph.net> Just to recap my point on the call, it's possible that TLS would reuse the same point for semi-static ECDHE
[20:19:33] <ekr@ecotroph.net> I'm not trying to say anything about there being an attack
[20:19:49] <sftcd> s/mime presumably worse then?
[20:19:50] <djb> cheon needs much more than reuse: it needs someone to take a point Q and give you back the point sQ where s is your long-term secret
[20:19:53] <sftcd> potentially
[20:20:17] <ekr@ecotroph.net> djb: yeah, so I'm not trying to say anything about the cheon attack.
[20:20:20] <djb> cheon uses this to compute sQ, ssQ, sssQ, ssssQ, etc.
[20:20:33] <ekr@ecotroph.net> maybe this was two narrow a point to try to make
[20:22:13] <sftcd> 42-slides warning:-)
[20:22:46] <djb> maybe the broader point everyone can agree on is that we need to protect long-term keys; short-term keys might be safer (and allow forward secrecy) but we aren't doing our jobs if we merely protect short-term keys and ignore the long-term keys
[20:23:35] <hyperelliptic> "Curve choice should be done to avoid disasters"
[20:24:54] Paul Hoffman joins the room
[20:26:57] <djb> "s-bit security" on this slide is again meaning 2^s time to break
[20:27:38] <djb> e.g., s around 128 for nist p-256 or the 256-bit brainpool curve or curve25519
[20:28:38] <ekr@ecotroph.net> Thanks. That's a helpful way to characterize it.
[20:32:31] <djb> more translations: "variable-base" means generating an ECDH secret key (you receive a public key Q, compute sQ, of course also hash that) whereas "fixed-base" is generating your public key in the first place (compute sG where G is a standard base point; this is faster)
[20:33:09] <Paul Hoffman> Points to @djb for the subtitles here.
[20:33:14] <djb> for long-term keys variable-base is the only thing that matters, but for ephemeral keys you'd typically do just one fixed-base and one variable-base
[20:34:47] <sftcd> is any of this visible in protocol or it this implementation only ?
[20:35:20] <djb> as an implementor you can certainly compute your public key sG using a generic function for sQ; just plug in Q=G
[20:35:30] <Paul Hoffman> @sf: there are speed differences that are visible when running.
[20:37:43] <Paul Hoffman> For example, in DNSSEC, resolvers are doing a zillion signature validations, so they worry about validation time.
[20:38:42] <sftcd> that's ok, I thought I heard him about to argue that a common impl. of field arithmetic ought be standardised
[20:42:37] <sftcd> just me or did it go quiet?
[20:42:45] <dkg> i can still hear him
[20:42:56] <sftcd> I'll reconnect
[20:46:48] <hyperelliptic> discussion currently happening in the other chat
[20:47:13] <dkg> will the other chat be logged or published someplace we can read it later?
[20:47:14] <Paul Hoffman> Yup. This is typical of WebEx in the IETF. :-(
[20:47:44] <Paul Hoffman> The other chat won't be loggeed unless someone grabs it and pastes it somewhere.
[20:47:58] <dkg> :(  so much for being "on the record"
[20:49:17] <hyperelliptic> could somebody do the cut-and-paste?
[20:49:27] <hyperelliptic> (we have the WebEx on a separate laptop)
[20:49:29] <djb> retyping some comments i typed in that chat (harder than copy and paste since we're running webex on a throwaway windows laptop): (1) terminology nitpick: the word "complete" is not being used correctly here; i agree that patrick is alluding to a complete single-scalar-multiplication method but the addition per se is not complete
[20:49:55] <djb> (2) more serious objection: the assertion of producing only half of all public keys is incorrect, and is already addressed in the original curve25519 paper
[20:50:30] <djb> mike hamburg then asked: is there any reason to set the high bit? i mean, the montgomery ladder works in constant tim even if the high bit is clear, right?
[20:51:19] <djb> my answer: yes, there is a reason to set the high bit; yes, a simple implementation of the montgomery ladder works in constant time no matter what happens to the high bit; the reason that the high bit is useful is that it also allows other common implementation strategies to run in constant time
[20:52:17] <Paul Hoffman> Then Watson asked: What is the wire format for hybrid 2? Is it twisted Edwards y only, or something else?
[20:52:35] <Paul Hoffman> (Glad that we're copying stuff here; this is archived automatically)
[20:52:57] <hyperelliptic> I assume that's a question for Patrick, wasn't covered by his slides
[20:54:11] sftcd joins the room
[20:55:04] <Olafur Gudmundsson> cut from WebEx chatroom: from Michael Hamburg to Everyone:
The goal of Goldilocks is not to target 192-bit security, but to have the biggest field that's >=192-bit security at a given performance level.
[20:56:03] sftcd leaves the room
[20:57:00] <ekr@ecotroph.net> do we know who this is?
[20:57:22] <Paul Hoffman> Ekr: Michael Hamburg
[20:58:30] <ekr@ecotroph.net> Thanks!
[20:58:45] <djb> if i'm hearing correctly, patrick is referring to DH shared-secret computation as a "very restricted case"
[21:02:32] <djb> and now he's referring to some patents that actually expired years ago
[21:03:04] <Paul Hoffman> @Dan: doesn't matter, given that they were probably never valid anyway. Scared is scared.
[21:04:15] <sftcd> isn't it practically as hard to change the primes as anything else ?
[21:04:16] <djb> but the fear factor changes when the patents expire
[21:05:13] <Paul Hoffman> @Dan: if only that were true. Vendors' fears ramp down very slowly.
[21:07:10] jimsch1 leaves the room
[21:07:11] <Paul Hoffman> (Pasting for the record)
[21:07:14] <Paul Hoffman> from Kohei KASAMATSU to Everyone:
Does the scope of this meeting include pairing friendly curves?
(I understood that Patrick Longa’s scope does not include pairing friendly curves)
I believe that we need to separate the discussion on security of normal curves and pairing friendly curves and the security requirement of pairing friendly curves should not be included in this discussion. Because these requirements of normal curves and pairing friendly curves are different. (DDH is not satisfied in pairing friendly curves, we use pairing based cryptography based on decisional bilinear diffie-hellman assumption, decision linear assumption and so on)
[21:07:51] <Russ Housley> @Stephen:  people spend a lot of time optimizing the modular reduction, so if the NIST prime is used in another curve, this investment can be preserved.  Picking a different prime means doing this optimization for another prime.
[21:08:42] <djb> i disagree: a very simple curve25519 implementation is faster than openssl's optimized nist p-256 implementation
[21:08:43] <sftcd> right, so if you change the primes, you change a lot of code and the protocol code points, the only diff is that you don't need new point representations in the protocols, or is that right?
[21:09:00] <Paul Hoffman> Tanja: we can't hear you.
[21:09:43] <hyperelliptic> sorry for that
[21:09:50] <hyperelliptic> typing in parallel here
[21:10:00] <Paul Hoffman> I'll relay: I'm loud.
[21:10:04] <hyperelliptic> the question is what patrick meant by taking the rigidity even further
[21:10:15] <Paul Hoffman> Ah, he got it.
[21:10:17] <sftcd> parallel and elliptic at once, cool
[21:11:18] <hyperelliptic> Dan's typing over there: we all agree that there is a small amount of wiggle room,
[21:11:45] <hyperelliptic> however, efficiency provides the best tool we have to quantitatively limit this wiggle room
[21:12:24] <hyperelliptic> T: quantify: how many curves you could generate with this setup
[21:18:05] <hyperelliptic> there are FPGA implementation (verilog)
[21:18:08] <hyperelliptic> of Curve25519
[21:18:26] <hyperelliptic> team is Tim Gueneysu + student
[21:18:47] <hyperelliptic> for smaller devices (ARM etc.) we have numbers in eBACS
[21:18:53] <hyperelliptic> bench.cr.yp.to
[21:19:15] <hyperelliptic> result of the FPGA paper was :smaller and faster than NIST P-256
[21:21:48] <djb> what i typed in the chat after that: also had a followup comment to the code-availability question for bigger processors: we run a big benchmarking site http://bench.cr.yp.to that has collected more than 1000 implementations of various functions from various people
[21:21:51] <djb> all public, all verifiable
[21:21:58] <djb> varying in whether it's industrial-strength code
[21:25:10] <sftcd> ssh coders are waiting to push their stuff into release apparently
[21:25:11] <hyperelliptic> I typed over there: 1. depends on the implementation; Weierstrass curves are more error prone in implementations
[21:25:28] <hyperelliptic> and many NIST curves have problems to be properly implemented and SCA resistant
[21:25:32] <sftcd> so silence for me == safe to ok their codepoints
[21:25:35] <hyperelliptic> Oh, no!
[21:25:42] <Paul Hoffman> Tanja: "in implementations" is really hard to measure.
[21:25:45] <hyperelliptic> NSA is endorsing Curve25519
[21:25:51] <sftcd> oops;-)
[21:26:15] <sftcd> I'm ok with silence being a yes for the ssh codepoint
[21:26:39] <Paul Hoffman> @SF: yes, silence is good enough
[21:27:00] <sftcd> that'll also stop SM bugging me which is good:-)
[21:27:31] <hyperelliptic> sftcd: do you know what code base they are using?
[21:28:13] <hyperelliptic> chat discussions are somewhat diverging; anybody able to cut and paste?
[21:28:26] <sftcd> I don't offhand, lemme to look at a mail
[21:30:53] <hyperelliptic> for the reference: Dan is typing in the other chat http://nacl.cr.yp.to/valid.html  Cryptography in NaC
[21:32:33] <sftcd> @tanja: James Cloos on the ssh list asked about the codepoint for ed25519, can't find the archive for that ex-WG list
[21:33:16] <sftcd> so sorry not sure what code they use
[21:34:38] <Paul Hoffman> Massive paste from the other chat. This may or may not work.
[21:34:41] <Paul Hoffman> from DJB and Tanja Lange to Everyone:
ok
from DJB and Tanja Lange to Everyone:
djb here, terminology nitpick: the word "complete" is not being used correctly here; i agree that patrick is alluding to a complete single-scalar-multiplication method but the addition per se is not complete
from DJB and Tanja Lange to Everyone:
djb here, more serious objection: the assertion of producing only half of all public keys is incorrect, and is already addressed in the original curve25519 paper
from Michael Hamburg to Everyone:
Is there even any reason to set the high bit?  I mean, the Montgomery ladder works in constant time even if the high bit is clear, right?
from DJB and Tanja Lange to Everyone:
yes, setting high bit allows a wider range of safe implementation strategies (even though it's not necessary for one good strategy)
from DJB and Tanja Lange to Everyone:
sorry, i realize that the target of the yes can be misunderstood. trying again: yes, there is a reason to set the high bit; yes, a simple implementation of the montgomery ladder works in constant time no matter what happens to the high bit; the reason that the high bit is useful is that it also allows other common implementation strategies to run in constant time
from Watson Ladd to Everyone:
What is the wire format for hybrid 2? Is it twisted Edwards y only, or something else?
from Michael Hamburg to Everyone:
The goal of Goldilocks is not to target 192-bit security, but to have the biggest field that's >=192-bit security at a given performance level.
from Uri to Everyone:
I personallu would rather not have to deal with small torsion points and their consequences.
from Hannes Tschofenig to Everyone:
Tanja had some questions during talk and I want to hear the response from Patrick.
from Hannes Tschofenig to Everyone:
I also have a question: I would like to know whether Patrick had released his code somewhere because I would like to run it on Cortex M3
from Kohei KASAMATSU to Everyone:
Does the scope of this meeting include pairing friendly curves?
(I understood that Patrick Longa’s scope does not include pairing friendly curves)
I believe that we need to separate the discussion on security of normal curves and pairing friendly curves and the security requirement of pairing friendly curves should not be included in this discussion. Because these requirements of normal curves and pairing friendly curves are different. (DDH is not satisfied in pairing friendly curves, we use pairing based cryptography based on decisional bilinear diffie-hellman assumption, decision linear assumption and so on)
from Michael Hamburg to Everyone:
The biggest problem with NIST primes in my experience is that they are designed for radix-2^32, which will necessitate carry chains, and also causes lots of shifting on 64-bit.  It's better on many platforms to use a radix like 2^51 or 2^56 to avoid carry chains.  The worst offender is P256, which unfortunately is also the most commonly used one.
from Hannes Tschofenig to Everyone:
Tanja, your line was breaking up
from DJB and Tanja Lange to Everyone:
trying the chat
from DJB and Tanja Lange to Everyone:
the question is what patrick meant by taking the rigidity even further
from DJB and Tanja Lange to Everyone:
djb here: we all agree that there's a small amount of wiggle room. however, efficiency provides the best tool that we have to quantitatively limit this wiggle room.
from Uri to Everyone:
DJB, could you please type?
from DJB and Tanja Lange to Everyone:
for curve25519 there's a verilog implementation, not optimized for the low-frequency cpus in sensor networks but won't be hard to optimize for that
from Hannes Tschofenig to Everyone:
That's also my interest and that's why I have asked for availability for the code
from DJB and Tanja Lange to Everyone:
also had a followup comment to the code-availability question for bigger processors: we run a big benchmarking site http://bench.cr.yp.to that has collected more than 1000 implementations of various functions from various people
from DJB and Tanja Lange to Everyone:
all public, all verifiable
from DJB and Tanja Lange to Everyone:
varying in whether it's industrial-strength code
from sftcd to Everyone:
getting late here... general discussion time?
from DJB and Tanja Lange to Everyone:
T: depends on the implementation
from DJB and Tanja Lange to Everyone:
Weierstrass more error prone in implementations
from DJB and Tanja Lange to Everyone:
and many NIST curves have problems to be properly  implemented
from DJB and Tanja Lange to Everyone:
and SCA resistant
from Kevin Igoe to Everyone:
I vote in favor of the security of curve25519
from Uri to Everyone:
Are there attacks against, e.g., P256?
from DJB and Tanja Lange to Everyone:
djb here: criteria such as twist security are flunked by the nist curves
from Uri to Everyone:
My question is not what it flunks - can you successfully attack it?
from DJB and Tanja Lange to Everyone:
real attacks such as the recent benger-et-al. attack are caused directly by the difficulty of implementing the old curves properly
from Watson Ladd to Everyone:
No. But there are attacks on bad implementations, which are annoyingly common. Also, NIST is slow: the curve you don't use because it is too slow is a problem.
from Uri to Everyone:
And you cannot implement Edwards curve badly?
from DJB and Tanja Lange to Everyone:
edwards curves avoid many important traps
from Watson Ladd to Everyone:
You can, but it's much easier to do it right. Avoid variable time loads and you are good
from DJB and Tanja Lange to Everyone:
it's not just how easy the right implementation is; it's also making screwups harder
from DJB and Tanja Lange to Everyone:
yes, best spec is in Cryptography in NaCl
from DJB and Tanja Lange to Everyone:
http://nacl.cr.yp.to
from Watson Ladd to Everyone:
what about Edwards?
from Uri to Everyone:
NaCl did not run successfully on Mac OS X out of box.
from Kevin Igoe to Everyone:
Eric et al: do still you want some feedback on Suite B?
from DJB and Tanja Lange to Everyone:
the spec includes highly portable interoperable code in multiple languages
from Watson Ladd to Everyone:
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf
from Uri to Everyone:
My personal preference: Short Weierstrass form, pseudo-Mersenne primes as Patrick described, coefficients as Patrick described.
from DJB and Tanja Lange to Everyone:
Tanja here: Uri, how do you secure that?
from DJB and Tanja Lange to Everyone:
Crypto in NaCl is nacl.cr.yp.to/valid.html
from Yoav Nir to Everyone:
Uri: so if short weierstrass form, any reason to go for something other that P-256?
from Watson Ladd to Everyone:
My recommendation: Ed25519, Ed488-Goldilocks, something bigger if anyone wants it
from Uri to Everyone:
By having competent people doing the work, and other competent people reviewing it.
from Patrick Longa to Everyone:
Uri, you can refer to our paper to achieve secure, high-perf Weierstrass implementation
[21:34:57] <hyperelliptic> thanks for pasting!
[21:35:11] <Paul Hoffman> (Surprised that worked…)
[21:37:30] <Paul Hoffman> Oh, Ekr, you're so practical….
[21:37:48] <ekr@ecotroph.net> I try to be.
[21:37:52] <sftcd> and I'm gonna AD sponsor SM's SSH draft
[21:38:02] <ekr@ecotroph.net> sftcd: I certainly don't object to that
[21:38:35] <hyperelliptic> Ed25519
[21:38:36] <sftcd> here's where I hope someone who has clue says ed25519
[21:38:40] <sftcd> or barks:-)
[21:38:53] <hyperelliptic> done
[21:39:21] <hyperelliptic> but you can exclude me as biased
[21:39:41] <hyperelliptic> Watson Ladd on the other list also said Ed2219
[21:40:01] <hyperelliptic> Dan is typing a longer reasoning:
[21:40:43] <hyperelliptic> it's easy to to overlap code between Curve25519 and Ed25119 (although even done separately both are quite smal)
[21:41:11] <hyperelliptic> and there are big advantages of ed25519 as as a signature system beyond the curve25519 advantages
[21:41:21] <Paul Hoffman> Code overlap is good.
[21:42:06] <Paul Hoffman> Ekr: why more than 256?
[21:42:20] <djb> also typed "ed25519 is much faster than openssl ecdsa-nist-p-256 at verifying signatures"
[21:42:26] <Paul Hoffman> Shouldn't we just let the overly-paranoid deal with that on their own?
[21:43:12] <ekr@ecotroph.net> paul: it's just intuition, but my sense is that there are people who want  the 256-bit nominal security level
[21:43:37] <sftcd> what timeline does TLS need for 1.3?
[21:43:55] <sftcd> I think that should drive CFRG process here, since they can invent whatever process they want
[21:43:57] <ekr@ecotroph.net> sftcd: I don't think this is the long pole in the tent
[21:44:17] <Paul Hoffman> @Ekr: I'm sure there are, but do we care about them if it is going to make us do a lot more work?
[21:44:21] <sftcd> nah but you can give 'em a timeline that they can try meet, no?
[21:45:03] <sftcd> can we get a recording of that groan?
[21:45:17] <hyperelliptic> :-)
[21:46:04] <ekr@ecotroph.net> sftcd: well, it sure would be nice to have an answer by EOY, since it's just a matter of filling in some field in the spec.
[21:46:13] <ekr@ecotroph.net> And we're surely going to have ECDSA etc.
[21:46:38] <sftcd> do the httpbis people think they depend on tls1.3 to any extent?
[21:46:48] <Paul Hoffman> @SF: nope
[21:46:53] <ekr@ecotroph.net> sftcd: no.
[21:47:01] <sftcd> ok
[21:47:07] <synp> httpbis are supposed to be ready to ship before 1.3
[21:47:29] <hyperelliptic> I would be willing to read and comment,
[21:47:41] <hyperelliptic> but won't find time to write it
[21:47:54] <Paul Hoffman> Tanja: saying that out loud is useful.
[21:48:05] <hyperelliptic> please say it
[21:48:09] <hyperelliptic> our mike seems busted
[21:48:11] <sean.turner@jabber.psg.com> I noted it ;)
[21:48:17] <synp> We should combine the 25519 with ChaCha and Poly and call them "Suite-C" together
[21:48:28] <sftcd> before Toronto is speedy (which is good)
[21:48:39] <hyperelliptic> :-D not sure I agree with this pedigree
[21:48:40] <sean.turner@jabber.psg.com> I'll give it a shot
[21:50:20] <hyperelliptic> Not sure I could make the Toronto meeting; but would there be a chance to sneak in as external (without the fee that is ...)?
[21:50:43] <Paul Lambert> or "Not Suite B" (NSB)
[21:50:55] <Kathleen Moriarty> Remote attendees don't have to pay
[21:50:55] <Russ Housley> I need to drop off the call.  Thanks for all of the work being done here.
[21:51:30] <synp> C for civilian, as opposed to something that a semi-military agency tells us to use.
[21:51:43] <hyperelliptic> Kathleen Moriarty: remote = calling in? or = showing up without being standard member?
[21:51:45] <sftcd> Sweet-Y
[21:52:38] <Kathleen Moriarty> Calling in or remote attendance through meetecho (streaming, etc.)
[21:52:48] <Kathleen Moriarty> There are one day passes as well
[21:53:37] <Kathleen Moriarty> Rich Salz volunteered to help in the draft in the webex window
[21:55:34] <Paul Lambert> Suite-E for Edwards …
[21:55:39] <Paul Hoffman> Ekr: write it up and send it to the list.
[21:56:48] mark leaves the room
[21:57:03] Paul Lambert leaves the room
[21:57:03] ekr@ecotroph.net leaves the room
[21:57:05] sean.turner@jabber.psg.com leaves the room
[21:57:11] <hyperelliptic> bye
[21:57:17] <Paul Hoffman> One does wonder of Dave even knew we were here.
[21:57:20] Kathleen Moriarty leaves the room
[21:57:27] Olafur Gudmundsson leaves the room
[21:57:33] <sftcd> we were not here
[21:57:43] Paul Hoffman leaves the room
[21:57:48] rsalz leaves the room
[21:57:54] sftcd leaves the room
[21:58:01] synp leaves the room
[21:59:18] <hyperelliptic> who, me?
[22:00:19] Karen O'Donoghue leaves the room
[22:10:28] ekr@ecotroph.net joins the room
[22:39:04] dkg leaves the room: leaving
[22:40:37] hyperelliptic leaves the room
[22:45:00] wwhyte leaves the room
[22:45:01] wwhyte joins the room
[22:47:16] wwhyte leaves the room
[22:53:43] ekr@ecotroph.net leaves the room
[22:55:06] ekr@ecotroph.net joins the room
[22:55:25] djb leaves the room
[22:59:09] ekr@ecotroph.net leaves the room
[23:13:34] ekr@ecotroph.net joins the room
[23:14:06] ekr@ecotroph.net leaves the room
[23:22:16] ekr@ecotroph.net joins the room
[23:25:35] ekr@ecotroph.net leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!