--- Log opened Fri Sep 06 00:00:11 2013
11:07 < HM> the crypto debates with the latest SNowden revelations are so fascinating
11:07 < HM> *Snowden
11:08 < HM> It's kind of shocking to see Schneier outright saying he doesn't trust ECs like NIST P-521
11:15 < gmaxwell> HM: I don't think he was saying that.
11:15 < sipa> because of nist, or because of ec, or because of the p?
11:15 < gmaxwell> also IIRC P-521's parameters are the result of a nothing-up-my-sleeve procedure.
11:15 < sipa> indeed
11:15 < sipa> secp256k1 is much more "constructed" afaik
11:16 < gmaxwell> This isn't to say that they didn't have enough design control to steer it into something that they could optimize for.
11:16 < gmaxwell> But its not obvious how.
11:18 < HM> hmm, well maybe Schneier is misinformed
11:18 < HM> he said on his blog in response to a comment that he doesn't trust the constants out of NIST
11:18 < HM> specifically with regard to P-521
11:18 < jgarzik> are secp256k1 constants out of NIST?
11:18  * jgarzik never researched the "construction"
11:18 < gmaxwell> Yes.
11:19 < gmaxwell> hm actually they may be out of certicom ultimately.
11:20 < gmaxwell> so CSE instead of NSA. :P
11:20 < HM> lol
11:20 < gmaxwell> In any case, there isn't any known way that the public parameter choices could be backdooring these systems.
11:20 < sipa> yes, nist didn't standardize secp256k1 afaik
11:20 < gmaxwell> So I would be concerned that any _other_ random choice would be just as bad.
11:21 < sipa> only secp256r1, which they call p-256
11:22 < gmaxwell> It appears the secp256k1 was also selected using basically the same nothing up my sleeve technique. (just motified to produce curves with the fast implementation)
11:24 < gmaxwell> Hm. I take that back.
11:24 < gmaxwell> thats odd that they didn't do that.
11:25 < gmaxwell> then again the form constrains the design space a fair amount.
11:30 < HM> well it's enjoyable reading the pandemonium
11:31 < jgarzik> if forced, could we come up with our own curve parameters?  or switch to djb's favorite curve?
11:31 < gmaxwell> jgarzik: it's a softforking change to add another checksig.
11:31 < jgarzik> yes
11:32 < gmaxwell> Though I'd prefer that we not uberparanoia with yet another ECC implementation, and just stick in lamport signatures as the oh-shit fallback.
11:32 < jgarzik> I consider it akin to replacing SHA256
11:32 < gmaxwell> well a complete replacement of sha256 is a hardforking change.
11:32 < HM> I doubt the NSA are going to waste their time on Bitcoin, it's more a concern if any advances they have tucked away become public
11:32 < gmaxwell> a CHECKSIG2 we could have deployed and usable in a month.
11:35 < gmaxwell> (lamport having the benefit of being immune to any DLP or EC related weakness, and giving a pat answer to quantum computer fud, plus a trivial implementation is still ultra fast.  Downside: big signatures.)
11:47 < HM> Lamport still relies on solid hash functions
11:47 < HM> Pretty much everything touching crypto seems to use a hash function at some point, so they're obvious targets
11:49 < gmaxwell> HM: sure, but no ecdsa implementation is useful without a strong hash function. Besides, hash functions never get broken in a way that would break lamport.
11:51 < gmaxwell> Nothing is certian of course, but at least it's completely orthorgonal.
11:51 < gmaxwell> or as near as completely as anything is.
11:51 < gmaxwell> and has a trivial implementation. (well, I'd like to use some compression that makes it slightly less trivial.)
11:52 < HM> But can't keypairs only be used once?
11:53 < HM> publishing a public key requires trust, so having to do it regularly is undesirable
11:55 < gmaxwell> HM: nah, you just make a public key a tree of public keys. They have a finite lifespan but you can make it large.
11:55 < gmaxwell> e.g. 1024 uses.
11:56 < gmaxwell> or with the imbalanced tree thing I suggested make it very large while only making heavy reuse bit.
11:56 < gmaxwell> er big.
11:56 < HM> meh
11:56 < HM> I guess if you got 1024 uses you could use your final message to publish a new public key
11:57 < gmaxwell> e.g. 32768 reuses, but uses 1-4 are only one extra hash each.
20:52  * amiller starts writing about the parking meter fee model
--- Log closed Sat Sep 07 00:00:14 2013