--- Log opened Thu Dec 19 00:00:08 2013 00:53 < nanotube> gmaxwell: http://qdb.us/64573 about that riddle. :) 00:55 < Emcy> http://it.slashdot.org/story/13/12/18/2122226/scientists-extract-rsa-key-from-gnupg-using-sound-of-cpu well shit 01:23 < maaku> adam3us Luke-Jr: there are interesting applications of proof-of-stake if it can be divorced from mining reward 01:24 < maaku> imho proof of stake should never have been tangled up in block generation or mining subsidy 05:30 < adam3us> gmaxwell: btw much further up, about gpg noise attack, mentioned bitcoin signature is not timing resistant, yet another reason for non-address reuse; however chain-codes weaken that, exfiltrate the chain code from network computer, and timing/sound recover one public or private derived key to the point of recovery, and game over. 05:31 < adam3us> gmaxwell: at least the public & private derived HD sub-keys are probably randomized enough via HMAC that accumulative timing attack seems unlikely; also the whole thing yet another argument for Bernstien's EdDSA (aka EC Schnorr) as it has no timing attack (no private key dependent branches), though deterministic DSA also fixes that 06:19 < adam3us> about the 1:1 peg discussed yesterday, so far it seems like because btc2->btc1 flow is authorized by spv proof, that the entire alt is only good to spv security level. can this be improved to full node security? seems to imply full nodes need to be on both networks. 06:20 < adam3us> also if there is no native reward whats the motive to merge mine the btc2 - only btc2 network tx fees. isnt that vulnerable to incentive attacks as fees are 2-3% of reward. like ghash.io level pool could be paid to forge spv and succeed enough of time to make that an economically rational theft attack 07:31 < Hunger-> hi 07:37 < adam3us> hi 11:23 < andytoshi> http://crypto.stackexchange.com/questions/12425/why-are-the-lower-3-bits-of-curve25519-ed25519-secret-keys-cleared-during-creati 11:38 < phantomcircuit> adam3us, iirc that requires you to do a lot of private key ops 11:46 < TD> the latest academic paper on bitcoin leaves a lot to be desired 11:47 < TD> http://eprint.iacr.org/2013/829.pdf - i sent them some corrections 11:48 < andytoshi> i read the first few paragraphs and decided to ignore that one ... thanks for the vigilance 11:49 < phantomcircuit> TD, sorry to be annoying but can you check that pm 11:50 < TD> i didn't see it actually, poor irc client ui my end it seems .. 12:01 < helo> have altcoins implemented many items from https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas ? 12:02 <@gmaxwell> helo: For the most part altcoins don't implement ideas. They search and replace strings. 12:02 < TD> sometimes, for added excitement, they search and replace hash algorithms or fee schedules. 12:02 < TD> but that's rare 12:02 < helo> those are some really neat ideas... it's a shame 12:03 < TD> with proof of stake and prime coin being notable exceptions 12:04 <@gmaxwell> TD: good email. ... I did learn one thing from the paper, although even in that it was wrong: They pointed out that if you send funds to a reused address it identifies your change. ... which isn't correct because some clients reuse their change addresses (doh), but igoring that its another example of how one person's reuse can thwart someone elses good practices that I hadn't considered. 12:04 < helo> i doubt most of the altcoin devs have the skill to implement them correctly (i doubt i do either), but it seems like they'd at least try 12:09 < petertodd> gmaxwell: speaking of, I think as a general principle we want to encourage address re-use for any application where public info allows for address linkage anyway; address re-use is a way of letting others easily know the address is *not* private 12:10 < petertodd> gmaxwell: e.g. for coinjoin you can better protect your privacy sometimes by avoiding joins with parties that have re-used addresses in some cases. 12:11 <@gmaxwell> I dunno, public info isn't equally distributed. I'd rather be deanonymized by a forum post than data in the blockchain. 12:11 <@gmaxwell> But I see your point. 12:11 < petertodd> Depends on the attacker - my suspicion is the type that will do detailed tx linkage analysis will also have databases of forum posts and p2pool share data. 12:12 <@gmaxwell> with blockchain.info my grandma is an attacker, though not a terribly effective one. 12:13 < petertodd> yeah 12:13 < petertodd> Would be nice if there was a way to mark a scriptPubKey as "We've made this unique, but the info required to link it is something the could find." 12:14 < petertodd> Where TLA \in (Cyber Grandmas of America, FBI, NSA, etc.) 12:23 < andytoshi> helo: IMO it'd be really frustrating to make big changes to bitcoind (though every day the devs make more progress toward modularity -- thanks guys!), so if you wanted to implement some serious ideas you'd be better off writing from scratch 12:23 < andytoshi> so there's not really anything between "zero work" and "a ton of work" 12:25 <@gmaxwell> meh, a number of those ideas would be quite selfcontained. 12:25 < helo> there is at least a similarly prohibitive steep gradient from "zero understanding" to "sufficient understanding" 12:26 <@gmaxwell> andytoshi: two additional features that might be interesting in your coinjoiner. The ability to give it an input with a threshold. E.g. join this if and only if you get at least 4 other things to join with... if I'm paying a fee to join I really don't want it to be some two party thing with some address reusing fool. :P 12:27 < andytoshi> gmaxwell: oh, good idea 12:27 <@gmaxwell> andytoshi: the other is that you probably should convert submitted signatures to canonical form... as differences in signatures might be privacy reducing to participants. 12:27 < andytoshi> right now i'm depending on "if you're ok using rawtx's, probably you aren't clueless" 12:28 < andytoshi> yes, good call, that also gels well with my true goal of "learn rust and understand bitcoin encoding in detail" 12:28 <@gmaxwell> In partcular the s/2 thing is enforced by bitcoin git but not 0.8.6 so their signatures are somewhat distinguishable. 12:28 <@gmaxwell> (for now it might be wise to randomize the s/2 characteristic, but later after 0.9 is out you should conver things to the canonical form) 12:29 <@gmaxwell> I'm not sure if anyone would submit to you padded r/s values or negative r/s values, but they might— some of the web signers in the past were broken. best to fix that. 12:30 < andytoshi> is the s/2 characteristic random now? istm if i'm publishing coinjoins with inconsistent signatures 12:30 < andytoshi> that screams "this is a coinjoin" 12:30 <@gmaxwell> yes its random now. 12:31 <@gmaxwell> bitcoin git produces signatures where S is always in the lower half. <=0.8.6 S is randomly in the upper or lower half. 12:31 < andytoshi> ok, thanks 12:32 <@gmaxwell> sadly the compressed vs uncompressed is a distinguisher but there isn't anything you can do about that. 12:33 <@gmaxwell> normal users also end up with a mix, so you having a mix doesn't distinguish it as a CJ, but it may hurt users privacy. 12:34 < andytoshi> ok, thanks 12:34 < andytoshi> maybe when i get time to do this 0.9 will be out .. it'll be 3-4 weeks 12:35 < andytoshi> i have been learning crypto 12 hours a day for the last week or two, but i have schoolwork to get on :} 12:36 <@gmaxwell> Certantly not a priority. 13:25 < maaku> very appropriate response to telegram : http://thoughtcrime.org/blog/telegram-crypto-challenge/ 13:29 <@gmaxwell> thats really quite brillant. 13:30 <@gmaxwell> I've suggested a thought expirement of the same ilk in the past— imagine bitcoin with the hashes replaced with md5 and the crypto replaced with 512 bit RSA. .. what is the security like? as a metric in how robust the overall system is to weak crypto. Neat to use that as a test of a test. 14:06 < phantomcircuit> maaku, i love that 14:07 < phantomcircuit> gmaxwell, as long as people didn't reuse addresses? still pretty secure 14:07 < phantomcircuit> neat 14:07 < phantomcircuit> i think the biggest issue there would be someone generating collisions with block hashes/transactions 14:07 <@gmaxwell> So cryptocurrencies which "fail inflationary"... which is a property that things like USD has, if you print really good fake USD .. well everyone takes the cost. Not the person that accepted the fake USD, at least not if its sufficiently good. 14:08 <@gmaxwell> phantomcircuit: yea, but that would mostly be a DOS vulnerablity and it would result in invalid data, so you could just ban peers that give it to you. 14:08 < phantomcircuit> right 14:08 < phantomcircuit> except now you need to have the full set of txids 14:08 < phantomcircuit> or actually you dont 14:08 <@gmaxwell> It would be totally plausable to make it so that if you get tricked by a recentl valid looking bitcoin fork, that both parties get paid. Thus moving the cost of such an attack to everyone holding bitcoin and not just the guy accepting it. 14:09 < phantomcircuit> as long as it's not in the utxo right now reusing a txid wouldn't break things 14:09 < phantomcircuit> theoretically 14:09 < phantomcircuit> gmaxwell, heh incentivize miners to intentionally build forks though 14:09 < phantomcircuit> incentive 14:09 < phantomcircuit> word* 14:10 <@gmaxwell> phantomcircuit: maybe. setting it up right might be tricky. 14:10 < phantomcircuit> heh understatement of the year goes tooooo 16:15 < nsh> ;;title http://thoughtcrime.org/blog/telegram-crypto-challenge/ 16:15 < gribble> Error: This url is not on the whitelist. 16:16 < nsh> nu 16:16 < nsh> "So Telegram developers, by way of a response, I have my own crypto cracking contest for you. Below is a horrifically bad “secure” protocol that wouldn’t last a second in a real world environment, but becomes “unbreakable” when presented in the exact same framework as the Telegram challenge." 16:16 < nsh> +1 17:20 < adam3us> phantomcircuit: what requires a lot of private key ops? 17:21 < brisque> adam3us: importing a deterministic wallet maybe? 17:22 < HM2> Moxie is grand 17:25 < brisque> Moxie has an incredibly awesome name. 17:26 < phantomcircuit> adam3us, signing 17:26 < HM2> Diffie said at an RSA conference, not sure if last or this year, that he thought Moxies name was a joke when they first met 17:27 < HM2> (they were talking about Convergence) 17:29 < HM2> I'm guessing Moxies challenge is actually pretty hard because 896bit RSA is reasonably outside computable for average readers 17:30 <@gmaxwell> HM2: his point was to make it clearly unacceptably insecure in serveral ways but still almost certant to not be broken in the context of the challenge. 17:30 <@gmaxwell> In reality such a system would be broken if it were used for a long time on something high value. 17:31 < HM2> right, if there's a time limit you can get away with weak crypto 17:31 < HM2> but i'm not sure how it's a fair comparison 17:32 <@gmaxwell> http://crypto.stackexchange.com/questions/12425/why-are-the-lower-3-bits-of-curve25519-ed25519-secret-keys-cleared-during-creati 17:32 <@gmaxwell> wtf are with the responses there? 17:32 < HM2> ah 17:33 < HM2> RSA is still more secure than I thought 17:33 < HM2> you can claim $75,000 for factoring 896 bit 17:33 < HM2> 768 bit was factored in Dec 2012, so Moxie has chosen that deliberately 17:34 <@gmaxwell> HM2: hm? the challenges were withdrawn. 17:34 < brisque> HM2: did he use the factored key in his challenge? 17:34 <@gmaxwell> HM2: sure he did. but at the same time we know that 896 is clearly achievable. 17:35 < HM2> sorry, you're right. 2010 17:35 < HM2> why did they retract the challenges? :S 17:35 < HM2> it seems people have been factoring the keys published under the challenge without the financial incentive 17:35 <@gmaxwell> Yes, they have been. 17:38 < HM2> I wonder if he really did dig up an instance of Dual_EC_DRBG to compute the super_secret 17:38 < HM2> I'd wager he didn't 17:38 < brisque> lots of things support EC_DRBG 17:38 < phantomcircuit> HM2, cat /dev/random on a recent but not too recent freebsd box isn't too hard 17:38 < brisque> he probably did, given the way the "contest" is presented 17:40 < brisque> this is something I thought of when helping somebody with their botched job of making a “paper wallet” before. they’d dropped the end off and I had to remake the hash portion for them to be able to import it. 17:40 < brisque> most of the problems people encounter seem to be with private keys, spending from them and screwing up the keys, not writing them down with capital letters, all very preventable errors. it seems to be proposed in the mailing list that the “import” will be removed and replaced with “sweep private key” which seems to fix many of these issues. 17:40 < brisque> could we go further, and make a paper wallet “token” system. the user selects an amount, and an address is created and the funds sent to them. the token is then presented for writing/printing/saving and not saved to the wallet. the token is armoured with a large amount of parity, enough to save the user if there is user created damage. it can only be spent from by destroying it by importing it, and the UI mak 17:40 < brisque> it removes a lot of the danger, and gives the users something useful at the end of it. is this madness, stupid, fantastic? I can’t quite decide. 17:41 < HM2> you should just send the keys to moonpig.com and have them sent to them on festive cards 17:41 < HM2> i'm sure they have an API 17:42 < brisque> HM2: a snowman with a carrot phallus, charming. 17:43 < HM2> you obviously made snowmans differently when you were younger to how I made mine 17:44 < brisque> it's one of the cards on the page you linked to 17:46 < HM2> you know, it occurs to me that you could can bruteforce moxies challenge 17:46 < HM2> feasibly 17:48 < brisque> you can brute force lots of things, that doesn't mean it's worth the money to 17:48 < HM2> he's not offering any money hah 17:49 < brisque> I meant it's not worth spending my money on EC2 instances 17:50 < phantomcircuit> HM2, bruteforce which part 17:52 < HM2> well i was thinking his message is only 16 bytes 17:52 < HM2> and its probably something fun 17:52 < HM2> or seasonal 17:52 < brisque> could just as well be /dev/random though 17:52 < HM2> it might even contain words from his post 17:52 < HM2> sure, but this is Moxie 17:53 < HM2> it doesn't help anyway 17:53 < HM2> he makes a good point 17:57 < phantomcircuit> HM2, come up with a message 17:57 < phantomcircuit> xor it against the cipher text 17:57 < phantomcircuit> present as key 17:58 < phantomcircuit> laugh as people who dont understand xor go wild 17:58 < HM2> heh 22:41 < Emcy> http://engineering.bittorrent.com/2013/12/19/update-on-bittorrent-chat/ anyone think this will be much cop? 22:41 < Emcy> seems like theyve just said "moar dht" again 22:42 <@gmaxwell> I wish them luck. 22:43 <@gmaxwell> I would certantly be happy if DHTs were the magical tools people often assume they are. The more systems that get built which fail obviously when the DHT doesn't work the more likely people will work out the issues. 22:44 <@gmaxwell> and even if it only hardly works, we can still abuse it for carrying bitcoin traffic. :P 22:44 < Emcy> haha 22:45 <@gmaxwell> (after all, when we have multiple transports no single one needs to be perfectly reliable) 22:45 < Emcy> their existing sync product uses dht too. They claim its secure and everything, but theres no way to really tell 22:47 < Emcy> i dont think bram cohen likes just throwing the complete spec out there anymore, after what happened with bittorrent 22:52 < nsh> what happened? people made clients? 22:53 < Emcy> basically 22:54 < Emcy> bittorrent has been trying to 'go legit' quite hard recently though 22:56 < nsh> hmm 23:02 < Emcy> http://engineering.bittorrent.com/2013/12/19/dht-bootstrap-update/ hmm thats more technical detail, theyre trying to harden dht against sybil 23:03 < Emcy> also open sourced the bootstrap server which is nice 23:11 <@gmaxwell> I think I'd mentioned before, but the businesses that screw with bittorrent for the recording companies and movie studios already pay ISPs for huge amounts of address space spread across many /8s and /16s as possible. 23:24 < Emcy> hmm 23:33 <@gmaxwell> maaku: wtf is a "varchar()" is it a null terminated string? 23:36 <@gmaxwell> maaku: because the size of your hashed nodes is always >512 bits, you'll be invoking the compression function twice. There may be some advantage in ordering the data so that the extra data is in the second compression function invocation, in order to use midstate compresison.. but I'm not sure, mostly I'm bringing it up to ask if you've already considered this. --- Log closed Fri Dec 20 00:00:12 2013