--- Log opened Mon Oct 14 00:00:08 2013
01:03 < BlueMatt> sipa: :(
02:28 < warren> sipa, gmaxwell : http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02751.html  should we go ahead with a BIP number assigned?
02:36 < BlueMatt> why can you have NODE_BLOOM && !NODE_NETWORK?
02:36 < BlueMatt> that makes no sense
02:37 < BlueMatt> if you are gonna relay something, you better check it first
02:37 < warren> BlueMatt: It is not clear why NODE_NETWORK exists, maybe it was just an example?
02:38 < BlueMatt> well, ok, my point is that that bip as written clearly says you can relay without having full verification
02:38 < BlueMatt> which is evil
02:42 < warren> BlueMatt: I agree that part really wasn't necessary to mention in the BIP.
02:54 < warren> hmm, what was the original purpose of NODE_NETWORK?
02:55 < warren> as there really aren't any service bits, there's no example code of how they're supposed to be used.
03:09 < sipa> i think we need to diversify node bits further
03:10 < sipa> as nodenetwork implies both relying of new block and historical storage pf everything
03:10 < sipa> either of these combined with nodebloom makes sense
03:10 < sipa> spv nodes do neither
03:13 < warren> ah
03:13 < warren> sipa: then the pruned proposals have talked about partial blocks available ... how would you advertise which?
03:16 < sipa> i'm just disagreeing with BlueMatt that Bloom without Network is meaningless... once we have pruning
03:25 < warren> sipa: we intend on launching pruned + expiration sometime after bitcoin 0.9, with the pruned part being submitted to bitcoin.  are the pruned proposals written spelling out all the diverisified node bits?
03:26 < sipa> there were objections to my proposal earlier
03:28 < warren> where was the proposal and objections?
03:28 < warren> I don't even know where to look. =)
03:35 < sipa> proposal was on the mailing list
03:35 < sipa> but it doesn't really matter, we just need to start talking about itt again i guess
--- Log closed Mon Oct 14 09:13:21 2013
--- Log opened Mon Oct 14 09:13:35 2013
14:23 < BlueMatt> sipa: ok, though, again, the bip as stated is very misleading
14:24 < BlueMatt> sipa: "may have data that its peers may be interested in, but is not a full node"
14:25 < jgarzik> BlueMatt, RE relay, the current code is pretty stupid, and just offers everything to all connected, unless something changed in the past year or so...
14:25 < jgarzik> regardless of what a spec says
14:26 < BlueMatt> yep
16:57 < maaku> possible academic weakness in linux /dev/{u,}random: http://eprint.iacr.org/2013/338.pdf
16:59 < gmaxwell> maaku: yea, that paper was making the rounds a couple months ago. It's boring though.
16:59 < sipa> BlueMatt: not sure why that is misleading?
17:00 < BlueMatt> sipa: it seems to indicate that you may want to relay unconfirmed data
17:00 < gmaxwell> it basically shows that if an attacker somehow knows the whole internal state of the rng (how?) he can trick the entropy estimator that he's been adding entropy when he really hasn't so the system will continue to return numbers he can derive... so long as he's the only input (how?).
17:00 < sipa> BlueMatt: well, if it's ambiguous itneeds improvement :)
17:05 < jgarzik> maaku, is that what Bruce S is on about?
17:07 < gmaxwell> (Not that I'm a huge fan of linux's /dev/random ... but god knows it's probably impossible to improve now since everyone would assume every effort to do so was an attempt to backdoor it :P)
17:09 < maaku> jgarzik: yes
17:21 < gmaxwell> maaku: IIRC that paper recommends replacing /dev/random with something is very much like AES-GCM (incrementing the galois counter by new random data that comes in). Paranoid people have already called out using AES stream ciphers as CSPRNGs in the context of the intel stuff. So their proposal is unlikely to be attractive to too many.
17:24 < maaku> gmaxwell: i see
18:42 < warren> jgarzik: do you have to mail your passport along with the application?
18:44 < gmaxwell> warren: apparently you do, intern in the office here went to china and had to send him his actual passport. They turned it around right away though.
21:42 < HM3> gmaxwell, more reason to move to schnorr-esque signatures that don't require absolute randomness for signing i guess?
21:44 < HM3> I'd be more worried about Windows RNG than Linux's
21:44 < HM3> I'm sure i read an article some time ago that illustrated with bitmaps that Windows' had patterns
21:47 < HM3> nevermind, i think maybe it was PHP
21:54 < HM3> yep PHP, but Windows did have RNG flaws some time ago. According to Matt Green Windows uses FIPS 186-2
22:06 < gmaxwell> HM3: that irrelevant, you don't need randomness for DSA, and if your system RNG is bad you're already screwed (because your keys will be bad)
22:15 < jgarzik> warren, a good question
22:15 < jgarzik> warren, my FB is recommending Travista
22:15 < jgarzik> er, Travisa
22:27 < maaku> fraudian slip?
22:36  * jgarzik isn't sure what Freud would think of a vista
22:36 < jgarzik> unless you mean to imply I am using Windows Vista, which I assure you I would never do...
22:38 < HM3> gmaxwell, what do you mean randomness isn't needed for DSA?
22:38 < HM3> although i agree with your other point
22:39 < gmaxwell> HM3: You use derandomized DSA.
22:39 < HM3> but that's not DSA is it
22:39 < gmaxwell> It's indinguishable from DSA.
22:40 < HM3> and what's the magic ingredient to derandomize it?
22:40 < gmaxwell> and in particular, you don't need to go about deploying _yet another_ cryptosystem to use it.
22:40 < gmaxwell> HM3: http://tools.ietf.org/html/rfc6979
22:41 < gmaxwell> HM3: effectively, K = HMAC(message,private_key)
22:42 < HM3> that's basically what Schnorr did
22:42 < HM3> and why I suggested Schnorr signatures
22:42 < HM3> Schnorr predates DSA
22:42 < HM3> It's also what djb did in Ed25519
22:43 < gmaxwell> HM3: Yes, I know.
22:43 < gmaxwell> (and you can find me pointing to Ed25519 in arguing to do this prior to RFC6979)
22:43 < gmaxwell> In any case, you don't need to change anything about the cryptosystem, require any upgrade, or create any incompatiblity in order to do that.
22:43 < HM3> true
22:44 < gmaxwell> (and if you want you can also do HMAC(message||nonce,private_key) to belt and suspenders it... though you lose the auditablity value of determinism)
22:44 < HM3> it's a bit grotty though
22:45 < warren> jgarzik: it's quite a mess.  You can't mail the application, you must apply at a consulate in person or have someone else (usually an a visa agent) do it for you.
22:45 < warren> jgarzik: if you aren't near one of the consulates there are some companies that will charge you money to do it...
22:47 < HM3> gmaxwell, the schnorr construction is just cleaner algebraically, and I like that you can't do public key recovery
22:48 < gmaxwell> ::shrugs:: Not really more than anything else that does the same thing, and its compatible.
22:48 < gmaxwell> HM3: yea, sure, I like schnorr too, but randomness isn't an argument for it.
22:49 < HM3> the lack of a need for a perfect RNG during signing is
22:50 < gmaxwell> HM3: DSA and Schnorr are the same in that regard. You derandomize them both under the same method
22:50 < HM3> sure but schnorr requires that construction to work
22:51 < gmaxwell> HM3: no they don't, go look at the schnorr patent. It's described using a random k.
22:52 < HM3> no I mean Schnorr is H(m||rG) and during verification you have to compute the candidate rG and recalculate H(m||rG)
22:52 < warren> "go look at the * patent" told to another engineer is wise?
22:53 < HM3> in DSA you just check, if i remember correctly, that sG is correct
22:53 < gmaxwell> warren: it's expired. Also, you need to go turn in your JD if you think it's not, see in re seagate. :)
22:54 < gmaxwell> (otherwise my response would have been "forget about it, it's patented")
22:55 < HM3> anyway. keeping DSA has no more merit than replacing it if you you plan on breaking compatibility anyway. but it's a fair point that you can derandomize DSA if you don't
22:55 < jgarzik> warren, yep, like Travisa ;p
22:55 < jgarzik> warren, communist state was never destined to make life easy and efficient
22:55 < warren> jgarzik: oh, they do F visas?  didn't see that option
22:56 < warren> jgarzik: I like how easy and efficient things are here.
22:57 < gmaxwell> HM3: hm, why do you say that recovery isn't possible in Schnorr? I believe it is, in fact.
22:57 < HM3> doubtful
22:58 < HM3> sipa agreed with me months ago when i asked him as well :P
22:58 < HM3> Appeal to authority! appeal to authority
22:59 < HM3> s = k - xe
22:59 < HM3> sG = kG - xeG
22:59 < HM3> you know eG and sG but not kG (which is r)
23:00 < HM3> and you know e = H(M||r)
23:00 < HM3> and obviously not xG (the key you're trying to recover)
23:01 < gmaxwell> HM3: You know r.
23:01 < HM3> nah, r isn't part of the sig
23:01 < gmaxwell> pray tell how you compute H(M||r) without it in the verifier?
23:02 < HM3> you calculate candidate r
23:02 < HM3> then compute H(M||r) and compare with e, which = H(M||r)
23:02 < warren> Don't worry, only *hard* math is patentable subject matter.  Not abstract ideas.
23:02 < HM3> I don't know why Wikipedia uses such silly letters
23:03 < HM3> r should be for the randomly selected number damnit
23:03 < gmaxwell> HM3: ah right, you recover r.
23:03 < HM3> gmaxwell, right, but you need the public key you're verifying against to do it
23:04 < HM3> in DSA you s = (1/k) * (H(M) + xr)
23:04 < HM3> and r = kG anyway
23:04 < gmaxwell> well thats a bummer then, minus one for Schnorr signatures. :P
23:04 < HM3> so it's fairly redundant
23:04 < HM3> gmaxwell, but DSA is broken if there's a collision on your hash function :P
23:06 < gmaxwell> so is schnorr, I take your signature and rebind it onto M' where H(M'||r) == H(M||r). :P
23:06 < HM3> if you were stupid and used a raw SHA instead of HMAC, then trick you in to signing 2 length extended messages such that there was a collision,  I can work out your privy
23:06 < HM3> gmaxwell, yes but it wouldn't reveal the private key like DSA would
23:07 < HM3> even your derandomized DSA would if you used H(priv || H(M)) instead of H(priv || M) for the rerandomization bit
23:08 < gmaxwell> Fair enough. I'm not going to argue that you don't need to bother with the private key if you can just rebind, because, I realize that collisions in reality are never quite that freeform. :)
23:09 < HM3> nobody has broken anything decent collision wise yet anyway have they?
23:09 < warren> gmaxwell: thanks for in re seagate, not sure how I didn't see this before.
23:11 < gmaxwell> HM3: sure, md5, though not second-preimages on a arbritaryly selected input.
23:12 < gmaxwell> HM3: I'm busy chastizing myself because I'm usually irritated by people who refuse to distinguish theoretical security from pratical security, and I did almost make that counterargument to you in earnest.
23:13 < HM3> I saw that SHA-3 got knocked down a bit during recent standardisation
23:14 < gmaxwell> HM3: IIRC Schnorr also has nice threshold signatures, alas.
23:14 < HM3> they cut some bit lengths
23:14 < gmaxwell> HM3: yea, they changed the input rate. Which was kinda surprising, because capacity was specifically cited as a reason to exclude cubehash from the final round.
23:15 < HM3> did they give a reason?
23:15 < gmaxwell> Sure, speed.
23:15 < HM3> Pish
23:15 < gmaxwell> Its not entirely unreasonable.
23:15 < gmaxwell> But I was surprised.
23:16 < gmaxwell> DJB did some saber rattling on the NIST list to adjust the capacity to a fixed 576 bits (so a constant 1024 bit input rate)— which is sort of a middle ground (more security for the orignal proposal at 256 bits output, less than the original proposal for 512 bit output). Doesn't sound like NIST or the Keccak team like the proposal. .. but NIST went quiet with the government shutdown.
23:17 < gmaxwell> For small inputs (e.g. <1024 bits) it doesn't matter.
23:19 < HM3> maybe when they reopen they'll forget they made the change
23:19 < gmaxwell> it's kinda irritating that the NIST list is closed-access. I see that the wikipedia sha-3 article mentions this discussion but has no citation.
23:19 < gmaxwell> well the change apparently was proposed by the Keccak team, which is totally believable the original capacity was the minimum nist required.
23:19 < gmaxwell> DJB basically said FUCK YOU to that requirement and refused to meet it in his proposal, and... well. :P
23:20 < gmaxwell> the other hashes met the requirement but many of then whined.
23:20 < HM3> Good old DJB
23:20 < HM3> I find his written material very accessible
23:21 < gmaxwell> esp having 512 bits of preimage security for the 512 bit hash required >1024 bits of state (in addition to the update state) which was getting a bit burdensome.
23:22 < gmaxwell> the DJB proposed modification to sha3 would have the nice side effect of making it always process 1024 bits at a time, regardless of the output size.  On that basis I like it.
23:22 < HM3> and presumably that allows for optimisation
23:23 < gmaxwell> (currently it does something like 1344 bits at a time for 256 bit output, and 1088 bits at a time for 512 bit output)
23:23 < gmaxwell> well it simplifies implementations at least, might also make hardware versions that do both sizes easier.
23:24 < HM3> 1337 bits would have been better
23:24 < gmaxwell> I am imagining millions of duck sized engineers stabbing you in the foot.
23:26 < HM3> ah well, i must retire to bed
23:26 < HM3> i'll take that duck sized engineer thing with me
--- Log closed Tue Oct 15 00:00:11 2013