--- Log opened Mon Dec 02 00:00:25 2013
00:43 < gmaxwell> so for those who haven't been watching, it appears someone may have used cloudflare's special relationship with a certificate authority to compromise even ssl access to bitcointalk.org.
00:44 < gmaxwell> There is a CA which will make a cert for any domainname pointed at a cloudflare IP in DNS and give it to cloudflare. So you get a really fast "change domain name" to "intercept SSL invisibly" escilation.
00:44 < gmaxwell> ISTM it would be pretty easy to reduce the risk of the existing CA infrastrcuture substantially with some help from bitcoin.
00:44 < BlueMatt> lol, wow
00:45 < gmaxwell> We could require that all CA's publish lists of all the certs they issue. And the lists get hash commitments in bitcoin. And then sites hand out certs with a proof that they were in the published list.
00:45 < gmaxwell> That would largely remove the concern that CA's were secretly issuing certs that they ought not be issuing.
00:47 < gmaxwell> BlueMatt: well it's less horrifying than you might think it is: right now _many_ CAs will give a cert to anyone who can drop a file at http://domain/some_random_filename.txt  (note: http not https) so DNS control == cert already, but historically that took ~24 hours.
00:47 < gmaxwell> the cloudflare thing means you can do it in minutes.
00:47 < gmaxwell> so, e.g. you can do it to a running site and not be noticed.
00:48 < gmaxwell> in any case, we don't know for sure if a cert was ever issued for bitcointalk.org, because,— of course, no normal browser logs the damn fingerprints.
00:48 < BlueMatt> well, ok, yes, but that doesnt mean its any less horrifying
00:49 < gmaxwell> and we can't tell except by asking the CA that cloudflare partners with.
00:51 < phantomcircuit> gmaxwell, a nice blog post about that would be hilarious
00:52 < gmaxwell> phantomcircuit: well I'm going to try to get Theymos to ask Chrome and Firefox to pin the bitcointalk.org CA.  Which will be halarious. "Yea, sure, we're a small site, but we've actually been abused this way; something you can't say for many other things that are pinned"
00:52 < phantomcircuit> lol
00:52 < phantomcircuit> Login temporarily discouraged
00:52 < phantomcircuit> lol
00:53 < gmaxwell> phantomcircuit: well the evil dns has not timed out yet, so users may not know if they're on the authentic site or not.
01:34 < midnightmagic> what does a cloudflare incoming connection appear to be to the end-server?
01:35 < phantomcircuit> midnightmagic, from cloudflare
01:36 < phantomcircuit> you can actually put in any ip address you want and cloudflare will gladly proxy requests for you
01:36 < phantomcircuit> including the freenode webchat
01:36 < phantomcircuit> so it's pretty easy to pretend to be cloudflare
01:36 < midnightmagic> name-based virtualhost for incoming cloudflare, plus catch-call?
01:37 < midnightmagic> "You are connecting via cloudflare. Please bug your ISP to update their name servers."
01:39 < phantomcircuit> midnightmagic, doing ip address -> ASN# is not trivial
01:46 < midnightmagic> phantomcircuit: ASN#?
01:47 < phantomcircuit> midnightmagic, basically like ISP number
01:51 < midnightmagic> Ah, that ASN. As in used in BGP routing..
01:51 < midnightmagic> I see. You're implying there are unpredictable IP addresses coming in from cloudflare.
05:44 < TD> gmaxwell: http://www.certificate-transparency.org/
05:45 < TD> gmaxwell: i think i mentioned that in my payment protocol FAQ. forcing CA's to publish certs they make is on the long term roadmap and is very likely to happen, it's funded, CA's are getting on board with it, it'll be in Chrome, etc
05:45 < TD> anyway, i fail to see what cloudfare has to do with this. if you lose control of DNS it's game over. it was ever thus and it's hard to see how else it could be.
05:46 < TD> your domain name IS your identity, that's why companies like Google use companies like MarkMonitor to defend their DNS registrations.
05:46 < TD> phantomcircuit: it's not that hard if you have the data set, it's only a few megabytes. i've implement IP to ASN mapping code a few times. the dataset can be obtained from a looking glass (or if you're big enough to have your own routers with BGP sessions, just downloaded directly from that)
05:53 < TD> gmaxwell: also if you look at the chrome pinning list, it's got all kinds of tiny sites in, even peoples blogs and stuff. AGL runs the list, he is very much an old school cypherpunk type, I doubt  we'd have any problem getting on the list
05:53 < TD> gmaxwell: but HSTS would be a pre-requisite, i think
05:56 < midnightmagic> TD: can any old joe-blow still grab a copy of the global routing table?
05:58 < TD> it's not exactly a secret. i'm sure you can find copies somewhere. if you want to do one-off queries that's easy, lots of ISPs run looking glass servers. they don't usually allow a full download though
05:58 < TD> the registrations (as opposed to what's actually being announced) are also available from IANA and other places if you ask nicely. you have to fill out a form and convince them you're not a spammer, basically
05:59 < midnightmagic> I seem to recall there was a way you could just randomly register an ASN as yourself and piggyback off the backbone types..
05:59 < TD> e.g. http://lg.level3.net/bgp/lg_bgp_main.php
06:01 < midnightmagic> The above.net crazies used to be pretty solicitous when they discovered you knew what BGP was.
06:01 < warren> TD: bitcointalk added HSTS today
06:02 < midnightmagic> well. how about that. above.net is gone as of last year and I didn't know it.
06:02 < TD> warren: good
06:02 < warren> i don't know if he did it correctly
06:02 < TD> warren: i hope they also get a better registrar .... and we should consider moving bitcoin.org as well. iirc it's with the same guys
06:03 < TD> midnightmagic: full downloads available here: http://www.ripe.net/data-tools/stats/ris/ris-raw-data
06:04 < midnightmagic> TD: ah nice, thanks man.
06:05 < warren> TD: I think they are moving to another registrar
06:05 < TD> warren: it looks correct to me
06:05 < warren> TD: what does he need to do to get chrome pinning?
06:05 < TD> warren: however it would not help in this case. HSTS simply says "SSL must be used and it must not be self signed". In this case SSL was used but it was being provided by a MITM. there's really no magic fix for losing control over DNS. never ever let that happen
06:06 < warren> TD: pinning would help though
06:08 < TD> yes
06:08 < TD> the process for pinning is basically, file a bug in the chromium bug tracker and ensure agl sees it, as far as I understand
06:09 < warren> TD: can you help after the bug is filed?
06:09 < warren> TD: is it a pain to get unpinned, to update the cert later?
06:10 < TD> or just email agl@chromium.org
06:10 < TD> you pin the public key hash
06:10 < TD> so the cert can change but they key cannot
06:10 < warren> ooh
06:11 < TD> if the key is compromised, then i guess you have to ask agl for another update. given how often bitcointalk has got hacked, i'm not sure he'd be thrilled by this idea - the fact that it still runs on an obsolete closed source copy of SMF is kind of embarrassing.  but theymos could ask.
06:11 < TD> http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json
06:11 < TD> btw bitcointalk should probably also be forcing subdomains, even though they aren't used today.
06:11 < TD> in future he might want to change that
06:11 < warren> TD: I personally secured the new server
06:11 < TD> http://dev.chromium.org/sts
06:12 < TD> that's good to hear
06:12 < warren> TD: I couldn't guard against their registrar getting hacked though
06:12 < TD> unfortunately, i tend to assume anything written in PHP is automatically riddled with basic security holes. except maybe facebook.
06:12 < warren> TD: I crafted the new server to asssume the PHP still has backdoors ...
06:12 < TD> well the bar is always being raised. there are special registrars that have better security policies. obviously the anonymousspeech one isn't such a company
06:12 < TD> yeah. that's the best way.
06:12 < warren> no outgoing connections, no connect to local sockets
06:13 < warren> no writing to filesystem
06:13 < TD> cool
06:13 < warren> well, the forum has disabled features now
06:13 < TD> yeah. i saw i can't change the profile picture anymore
06:13 < warren> but it isn't hacked now, AFAIK
06:15 < TD> is it hosted on a dedicated machine ?
06:20 < warren> TD: on digitalocean of course =)
06:20 < TD> a VPS provider?
06:21 < fagmuffinz_> digital ocean is the shit
07:08 < fagmuffinz_> I've gotta say getting chef and capistrano to play nicely on Windows has been a royal pain in the ass
11:56 < gmaxwell> td: the only real difference the cloudflare part makes is that it makes it much faster. I tried simulating the attack previously but it was harder to do secretly because I had to proxy the site for almost 30 hours... and I also had to have another host to proxy it on, etc.  with the cloudflare its made somewhat easier to do without being noticed (though they seem to have failed), because someones providing the proxy for you and you ...
11:56 < gmaxwell> ... don't have as long a window you need to run it on. OTOH, you don't get a copy of the certificate yourself.
14:00 < phantomcircuit> gmaxwell, try it again with startssl they issue certs within a few minutes during israeli business hours
15:12 < nsh> <nsh> so i had another look at the work of Eli Ben-Sasson, et al., which seems to have progressed a little since his talk at the bitcoin conference on Succinct Computational Integrity and Privacy. does anyone know if any efforts are underway to do some proof-of-concept for short verification of proofs of blockchain integrity for e.g. SPV clients?
15:12 < nsh> [..]  this paper seems to have enough skeleton for a scaled-down PoC: http://eprint.iacr.org/2013/507.pdf
15:13 < nsh> i think the circuit-building part of the key-generation is RAM-limited atm, so it might be (more) tractable to try with smaller chainstate distances
15:14 < nsh> (~1000 constraints per cycle iirc)
15:15 < gmaxwell> nsh: there are some annoying performance issues, e.g. sha256 implemented in tinyram is about 100x more gates than a straightforward circuit compiler version of it. Though I suppose that wouldn't get in the way of a test too much.
15:15  * nsh nods
15:16 < nsh> i suspect there is still room for optimizations though. i haven't managed to see how the circuits look in practice yet
15:16 < nsh> the stated performance of tinyRAM is pretty impressive (
15:17 < nsh> ~3-5x slowdown relative to x86
15:17 < gmaxwell> I've spent more time looking at the GGPR pairing based zk-SNARK though it's only smoke-and-mirrors publically verifyable, the linear PCP that eli et. al. have written more about is probably a better match to what we need but I haven't seen as much concrete performance numbers for it.
15:18  * nsh nods
15:18 < gmaxwell> nsh: well, sha256 has all those circular rotations, which don't express compactly in tinyram. and every tinyram cycle is ~1000 gates.
15:18 < nsh> hmmm
15:19 < gmaxwell> the tinyram stuff makes a lot of sense when you have control flow though.  In any case, a first prototype should absolutely be done via tinyram.
15:19 < nsh> right
15:20 < nsh> there was also mention of "non-standard assumptions" that were slightly glossed in this talk: http://www.youtube.com/watch?v=nS3smRAfUd8
15:20 < nsh> want to look into those a bit more
15:21 < gmaxwell> the non-standard assumptions is the non-falsifyability problem that all succinct NP argument systems have.
15:22 < nsh> hmm
15:22 < gmaxwell> The problem is that you can't prove it black-box reducable to any simple cryptographic assumption because you can imagine a black box system breaker that only lies in cases where no polytime bounded user could distinguish the lie. It's a kind of wanky argument.
15:23  * nsh muses
15:23 < gmaxwell> nsh: the key thing to watch out for is that the people working on this stuff frequently use a security model we'd consider generally stupid.
15:23 < nsh> which is?
15:24 < gmaxwell> Basically— first you can have systems which are only designated verifier— any interactive system is like this.  A singler verifier gets convined of the proof but the proof is not transferable to other parties.  Obviously thats not useful to us. The alternative to designated verifier is publically verifyable…
15:24 < nsh> right
15:24 < nsh> but you still require a trusted generator of prover and verifier keys
15:25 < gmaxwell> well there is a bunch of "publically verifyable" work where it's assumed that all the verifiers have a common reference string. Some magical data which was securely generated which they trust.
15:25  * nsh nods
15:25 < gmaxwell> right. which is crap for us, generally.
15:25 < nsh> mmmm
15:26 < gmaxwell> There are systems which are publically verifyable without that assumption, but they are not as popular with the theoretical cryptographers mostly because they depend on fiat shamir, so they are secure only in the random-oracle model.
15:26  * nsh notes to google
15:27 < andytoshi> is there a good paper which explains the random-oracle model and how it relates to real life?
15:27 < gmaxwell> Eli has been working with two different backends— one based on the GGPR work which is CRS-publically-verifyable and perfect zero knoweldge. And aparently one which is based on fiat-shamir transforms of some linear pcp. which should be verifyable without a CRS, though its not quite perfect zero knoweldge.
15:27 < gmaxwell> though the proofs would be larger (tens of kilobytes), though I expect more rapidly verifyable.
15:28 < nsh> hmm
15:28 < nsh> (CRS being common reference string, i presume)
15:28 < gmaxwell> right.
15:29 < gmaxwell> I think for us, especially for blockchain proofs, we'd prefer the later assumption. We're already slathered with random oracle assumptions. Also, we can do some novel things to boost the security of fiat-shamir-transform proofs that basically no other system can do.
15:29 < nsh> i guess generating and distributing the CRS isn't much different, security-wise than what's being done now with the blockchain torrents?
15:29 < nsh> but it's not ideal
15:29 < gmaxwell> nsh: eek. no. The blockchain torrents are completely untrusted and might as well be maliciously generated. We verify them.
15:29 < nsh> hmm, right
15:30 < gmaxwell> CRS = if you have the secret you can trivally (at least in the case of GGPR) generate fake proofs.
15:30 < nsh> oh, that's an issue
15:31 < nsh> what novel things can we do to boost the fiat-shamir-tranform security?
15:31 < gmaxwell> plus, you need a new CRS if you change the circuit. Which is a bit lame.
15:31 < Luke-Jr> someone mailed me ants o.o
15:31  * nsh nods
15:31 < Luke-Jr> http://flickr.com/gp/52549449@N05/54iQ5S
15:31 < gmaxwell> Luke-Jr: antminer?
15:31 < Luke-Jr> gmaxwell: no, real ants
15:31 < nsh> lol
15:31 < Luke-Jr> they crawl aroudn
15:32 < nsh> heh
15:33 < gmaxwell> Fita-shamir-transform basically amounts to "construct a hashtree over your data, use the hashroot to select which parts of the data to disclose" .. if the data in question is a probablistically checkable proof, you get a compact proof out of it.  You have to expand the number of points you disclose because an attacker could keep retrying junk proof until he got one that happened to pick points that pass.
15:33 < nsh> hmm
15:34 < gmaxwell> nsh: what we can do in bitcoin is commit to a fiat-shamir hashroot in a block, then use a the successful block hash to pick the disclosed points. Because mining a block takes a whole lot of computation, its now _much_ harder to grind on your proof.. so you can disclose fewer points for equal security.
15:34 < nsh> ah, i think i see
15:34 < nsh> that's neat
15:34 < gmaxwell> though the reduction is probably not that great in practice, maybe you can halve the proof size that way.
15:34  * nsh nods
15:35 < gmaxwell> (also, it makes the proofs weaker against people with extreme hashpower ... but then again bitcoin kinda fails if those parties exist)
15:35 < nsh> right
15:38 < nsh> andytoshi: http://crypto.stackexchange.com/questions/879/what-is-the-random-oracle-model-and-why-is-it-controversial // http://en.wikipedia.org/wiki/Random_oracle // http://cseweb.ucsd.edu/~mihir/papers/ro.pdf
15:39 < nsh> http://blog.cryptographyengineering.com/2011/09/what-is-random-oracle-model-and-why.html // http://blog.cryptographyengineering.com/2011/10/what-is-random-oracle-model-and-why.html
15:42 < gmaxwell> Did andytoshi ask something here? /me doesn't see
15:44 < nsh> <andytoshi> is there a good paper which explains the random-oracle model and how it relates to real life?
15:47 < andytoshi> thx nsh
15:47 < nsh> np
15:47 < andytoshi> gmaxwell: i had just arrived, maybe my arrival did not reach your part of the network?
15:48 < gmaxwell> oh, it was here, I just missed it completely.
17:38 < amiller> Secure Multiparty Computations on BitCoin http://eprint.iacr.org/2013/784
17:38 < amiller> this is a pretty great paper
17:39 < amiller> this is the first time someones given a pretty clear way that bitcoin solves a problem that people in crypto theory would like to have solved
17:39 < amiller> fairness in multiparty computations, basically
17:39 < amiller> we've basically talked about all of these things before
17:39 < gmaxwell> amiller: yea, so it's generalizing the iddo stuff on the forum?
17:39 < amiller> yeah exactly
17:40 < gmaxwell> is it a pure theory paper or did they implement something?
17:40 < amiller> they say they implemented it all and used eligius to get the transactions in
17:40 < amiller> we should be able to track those down!
17:40 < gmaxwell> What MPC system are they using?
17:41 < nsh> "Abstract: itCoin is a decentralized digital currency, introduced in 2008...." bloody scamcoin pushers....
17:41 < amiller> Blum's coin flipping is all
17:41 < amiller> ah they actually give the transactions they use
17:41 < amiller> as blockchain.info indices
17:41 < amiller> https://blockchain.info/tx-index/97079150
17:42 < gmaxwell> ugh.
17:42 < gmaxwell> why would they do that... derp
17:42 < amiller> saves space :p
17:42 < amiller> (i see nothing wrong with that, tbh)
17:42 < gmaxwell> amiller: it'll be lost forever if bc.i reindexes again.
17:43 < amiller> well we should tag the paper with whatever relevant transactions they acutally have
17:43 < gmaxwell> those indexes are not determinstic.
17:44 < amiller> ok well besides that
17:45 < amiller> they didn't need to use any generic mpc compilers like garbled circuits or whatever, their example is just the coin flip game like iddo's protocol, so they used a preexisting coin flip mpc protocol
17:45 < amiller> but their general statement is about any MPC
18:19 < hno> nsh, itCoin is only a copy-paste typo in the online abstract and meant to say BitCoin.
18:19  * nsh nods, smiles
18:20 < gmaxwell> amiller: I expect iddo will be unhappy with that paper.
18:20 < gmaxwell> amiller: it doesn't really go too much further than the coinflip stuff other than to note that it could be applied more generally. And I assume iddo was working on a similar paper.
18:21 < nsh> link/ref for iddo's work?
18:25 < nsh> also a discussion on mitmtalk now: https://bitcointalk.org/index.php?topic=355174.0
18:25 < nsh> oh, that was you amiller
18:29 < gmaxwell> amiller: I edited your post to add some hyperlinks. I hope you don't mind.
18:55 < amiller> np gmaxwell
18:55 < amiller> i think i'll email them and suggest they review iddo's forum post
18:55 < amiller> btc community is basically doing a terrific job of publishing and archiving all these ideas where they're trivial to cite and in fact people build on each other's work quite well
18:56 < Luke-Jr> terrific? more like terrible :P
18:56 < nsh> amiller, where's iddo's forum post pls?
18:57 < Luke-Jr> at least on my part
18:57 < gmaxwell> nsh: I added links to amiller's post. Reload.
18:57 < nsh> oh, thanks
18:57 < gmaxwell> Luke-Jr: people post ideas, they're clearly explained— or if not, people ask questions and explinations are forthcoming.
18:57 < gmaxwell> Luke-Jr: people are building of each others work and cooperating.
18:58 < gmaxwell> The work isn't super rigorous or deep, but it's making a lot of progress.. and it even sometimes has implementations— which is something you can't say for many academic works.
19:01 < Luke-Jr> gmaxwell: a lot of the time it's just IRC chatter; even for forum stuff, it's hard to remember where what was said
19:50 < gmaxwell> Hm. I wonder if it's possible to get mintchip to do a hashlocked transaction.
19:50 < gmaxwell> If it could you could do secure btc/mintchip.
19:52 < phantomcircuit> gmaxwell, secure ish
19:53 < gmaxwell> well unless it could do timelock you'd have holdup risk.
23:27 < gmaxwell> In which I attempt a trustlessness smackdown: https://bitcointalk.org/index.php?topic=355016.msg3802226#msg3802226
--- Log closed Tue Dec 03 00:00:27 2013