| 01:25:56 | rusty: | So, is there a bitcoin *dev* conf in existence? It'd be fun to have some hacking sessions f2f. |
| 01:26:47 | sipa: | i wish there was |
| 01:28:01 | phantomcircuit: | how would you differentiate it from a normal conference |
| 01:28:17 | phantomcircuit: | entrance quiz? |
| 01:28:44 | sipa: | known speakers? |
| 01:29:04 | sipa: | no CEOs of companies wishing the enter the bitcoin parket as keynote |
| 01:29:06 | sipa: | *market |
| 01:31:00 | rusty: | phantomcircuit: low budget venue, invite only, just supply caffeine, couches and flights for poor hackers :) |
| 01:31:21 | BlueMatt: | rusty: please organize one! |
| 01:31:28 | sipa: | * sipa would attend |
| 01:31:38 | rusty: | Ha! I've organized my conference for this lifetime :) |
| 01:31:38 | BlueMatt: | there is also fc, but thats much less dev and much more academic, and also less bitcoin-focused |
| 01:55:51 | kanzure: | "analysis of raft consensus" http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-857.pdf |
| 02:04:15 | Luke-Jr: | when my children move out (lol, 10 years from now at least), I could possibly host something :P |
| 02:07:06 | rusty: | Luke-Jr: Hmm, there are ~300 committers to bitcoin.git ... hope you have plenty of room :) |
| 02:07:19 | Luke-Jr: | wait, we have to invite rebroad? |
| 02:07:28 | Luke-Jr: | (joking) |
| 02:09:14 | gmaxwell: | The password hashing contest announced finalists at the beginning of the week. |
| 02:09:27 | gmaxwell: | I'm going to make this (not-proposal specific) post: https://0bin.zertrin.org/paste/c1c8f77f0cc7cd188180d6371ec4033149a60a94#rw1qtl76g5pFdSHD/9V4P53jwcF6WDdozVk0wVzyvd0= |
| 02:09:29 | sipa: | you understand rebroad is committer #17, right? :p |
| 02:09:35 | gmaxwell: | Anyone have any review or revisions I should make before posting it? |
| 02:09:50 | gmaxwell: | ( petertodd Luke-Jr sipa I expect may have thoughts) |
| 02:10:24 | sipa: | "a consumer of KDF functions", i now envision you as some devilish beast that eats KDFs for lunch |
| 02:10:30 | gmaxwell: | hahaha |
| 02:10:59 | Luke-Jr: | lol |
| 02:11:22 | sipa: | s/There/They're/ |
| 02:11:39 | sipa: | actually, s/There/There are/ |
| 02:12:05 | Luke-Jr: | * Luke-Jr suggests GDocs |
| 02:12:21 | sipa: | * sipa will reread while sober |
| 02:15:28 | gmaxwell: | No rush. I don't want to waste anyones time with something stupid. |
| 02:23:42 | rusty: | gmaxwell: A little meta: what exactly are you trying to achieve with this email? |
| 02:26:58 | Luke-Jr: | but seriously, GDocs would make review of something that long much easier than trying to figure out what each s// applies to |
| 02:28:36 | rusty: | gmaxwell: this is a group of people pretty dedicated to memory hardness. Your points are well made, but I'm not sure they will have any effect other than, y'know, starting a verbal war or getting you filtered out. |
| 02:29:00 | tromp_: | s/it's/its/ ecosystem |
| 02:31:09 | gmaxwell: | rusty: I'd like them to present better arguments for their security models. |
| 02:31:56 | gmaxwell: | e.g. as someone who has to make a choice now, I have reservations, and the only arguments they've given have a gaping hole in their analysis, big enough that choosing a snazzy function could have the opposite effect. |
| 02:32:36 | kanzure: | if they are predicated on memory hardness then they wouldn't care if memory hardness is insecure |
| 02:32:55 | phantomcircuit: | gmaxwell, so interesting idea |
| 02:33:03 | gmaxwell: | I think it's likely not the case that their output would really be worse. But like I was saying at the end, if a boring function gives me a direct energy related cost (even arguing from the lauder limit) thats adequate for security... seems foolish to use something snazzy that _might_ be weaker. |
| 02:33:04 | phantomcircuit: | i realized you can abuse bitcoin miners for password strengthening |
| 02:33:05 | rusty: | gmaxwell: OK, sure, but I doubt this would have that effect. Your points on minimum parameters and specifying delegation are concrete things on which they can act. |
| 02:33:08 | phantomcircuit: | er |
| 02:33:10 | phantomcircuit: | password hashing |
| 02:33:28 | gmaxwell: | phantomcircuit: you can indeed. |
| 02:33:52 | gmaxwell: | phantomcircuit: I've suggested before to a HW wallet maker wannabe that they also put a small mining chip in their wallet to use as a KDF. |
| 02:34:06 | gmaxwell: | but they ended up not delivering a product. |
| 02:34:52 | kanzure: | rusty: i am curious if you could give me an estimate as to how heavily political/politicized you think their response is going to be ? |
| 02:35:12 | gmaxwell: | kanzure: well the scrypt paper had a goal of attacker-cost. Which as good. But the analysis was incomplete because it ignored energy. Which turned out to be really significant, though even I didn't realize that until I was operating a farm of dozens of GPUs. |
| 02:35:34 | gmaxwell: | Many of the proposals submited, however, really are taking memory hardness to be axiomatic. |
| 02:36:21 | gmaxwell: | (the gpu comments: I paid more for power than all the hardware rather quicky, even with 5.5 cent power) |
| 02:36:24 | rusty: | kanzure: impossible to know. But generally if you tell people their core beliefs are wrong, the response is not positive. |
| 02:36:48 | kanzure: | strange that they have settled on memory hardness as a core belief. why not something more generic like "cryptography is cool, yo"? |
| 02:37:08 | gmaxwell: | Ah, hm. Maybe I need to rephrase. I actually don't know if the strategy is wrong. Only that there is a large unknown component, and it might be big enough to make it wrong. |
| 02:37:27 | gmaxwell: | kanzure: it's a fad. (maybe a good one, fads are not all bad) |
| 02:37:48 | kanzure: | yeah but it apparently makes this sort of review work more difficult |
| 02:38:02 | kanzure: | when you can't actually give your real thoughts etc |
| 02:38:35 | rusty: | gmaxwell: yes, this argument that attacker cost should include power is an important one, but I'd present it as a separate paper. That might have more effect (though more work to prepare). |
| 02:40:27 | gmaxwell: | I contacted the author of scrypt a while back and got a sort of 'hm. thats interesting. I didn't analyize that and really have no idea where to start.' figuring out the energy costs for custom hardware potentially using novel architectures is even harder than the gate costs. |
| 02:41:43 | rusty: | gmaxwell: well, we have a datum point now. Add an anecdote, and that makes it data. |
| 02:41:50 | gmaxwell: | I did some calculations and concluded that if the energy cost of the memory hard function is zero then at some level of attack amortization the memory hard function will lose against an energy hard function. But thats a stupid argument, since the energy costs are not zero. |
| 02:41:51 | petertodd: | gmaxwell: ethereum is trying to hire me to review ASIC hard PoW's; I'm working on figuring out how best to tell them "DOOOM! DOOOM!" |
| 02:42:30 | petertodd: | gmaxwell: I did after all manage to talk to some actual ASIC people who thought the whole idea was insane, and had so many crazy tricks up their sleeve for improving efficiency it wasn't funny |
| 02:43:09 | gmaxwell: | I'm more of a uses-all-of-the-buffalo school of KDF functions (e.g. use everything the user can tolerate you using, so the attackers costs are maximized). The memory-hard school is partially overlapping, traditional KDFs leave the memory unused... but only partially. Mostly the preference for memory is that memory hardness seems to get less benefit from specialization, at least specialization th |
| 02:43:15 | gmaxwell: | at has been seen so far. (though I mention TSV and CRAM as specializations that should help these functions). |
| 02:44:22 | petertodd: | yeah, KDFs are fortunately a subtlely - but importantly so - different beast as changing a KDF constantly isn't so bad |
| 02:45:10 | phantomcircuit: | gmaxwell, i dont think we've yet seen a sophisticated implementation of memory hard functions in an ASIC |
| 02:45:26 | gmaxwell: | I think if one wanted to do a ruthless but not really useful analysis, one could assume zero costs nano constructors that churn out comptronium. And so the only costs would be lauder-limit energy, in which case I suspect most of these functions would lose very badly to sha256-pbkdf2, owing to many many fewer bitflips within $user_tolerance ms. |
| 02:45:31 | phantomcircuit: | (i also kind of doubt we ever will, but hey maybe i can get some alt to donate a few million bucks) |
| 02:46:11 | gmaxwell: | petertodd: well maybe.. consider things like encrypted wallet backups.. you really don't want a ton of KDFs there. |
| 02:46:15 | petertodd: | phantomcircuit: we will when someone gives an incentive to make one... and the theoretical stuff you can do to defeat memory hardness is pretty remarkable |
| 02:46:29 | petertodd: | gmaxwell: you mean in terms of compatibility? |
| 02:46:37 | gmaxwell: | I expect that whatever comes out of this will get used in things like next generation ZK PAKE schemes. (srp implementations IIRC use this laughable sha1) |
| 02:46:57 | rusty: | gmaxwell: my advice is (FWIW) to simply comment on the stuff they can fix, which may get results. Handle the attack on their canon separately. |
| 02:47:07 | gmaxwell: | petertodd: I mean no one wants to implement 20 different KDFs in their wallet reader... and there is a real cost in the format to being able to signal a lot of different functions, etc. |
| 02:47:10 | petertodd: | ZK PAKE? zero-knowledge password-authentication-key-encryption? (I totally made that up) |
| 02:47:21 | gmaxwell: | hah so close. |
| 02:47:30 | gmaxwell: | Password authenticated key exchange. |
| 02:47:34 | gmaxwell: | SRP is an example. |
| 02:48:01 | petertodd: | well, no-one wants too... but it's possible, unlike in a consensus system - ethereum has the insane idea of "we'll just change the PoW every few years" |
| 02:48:13 | gmaxwell: | E.g. something that mutually authenticates you and a sever, in zero knoweldge so a MITM learns nothing, and results in both sides learning a shared key. |
| 02:48:35 | gmaxwell: | yes indeed, well I think the KDF stuff is pretty different than POW in a number of ways. |
| 02:48:44 | petertodd: | why would a kdf get involved? |
| 02:49:13 | gmaxwell: | petertodd: Because if you steal the servers secrets (password database) you can grind the password. So it's nice if there is expensive preprocessing of the password to slow that down. |
| 02:49:39 | petertodd: | and you can't just grind the password on the client and authenticate with the result of that? |
| 02:50:14 | gmaxwell: | Client doesn't learn anything from the interaction that lets them grind, except interactively with the server (which you can lockout or rate limit). They know it or they don't. |
| 02:50:46 | petertodd: | hmm, I must be missing something on how exactly this is supposed to work... |
| 02:51:47 | gmaxwell: | User provides a password. His software does some crypto magic. There is a multi-round protocol with a server that depends on discrete log security. The server has some values which are analogous to a hashed password. |
| 02:52:25 | gmaxwell: | The protocol is such that the client and server 'know' the same underlying password, and they learn that and a key. Or they don't and they learn nothing they didn't know before the protocol started. |
| 02:53:20 | petertodd: | ok, so why not grind weak_pw -> strong_random_password client side and then use that as the password for the protocol? |
| 02:54:11 | gmaxwell: | petertodd: oh absolutely. Thats what one should do. And I was saying that likely the outcome of this contest is a function people will be proposing for that application in standards as an outer layer to a ZK-PAKE scheme. |
| 02:54:21 | gmaxwell: | oh grind. |
| 02:54:31 | gmaxwell: | you can do that but each attempt requires interaction with the server. |
| 02:54:42 | gmaxwell: | Which means it's not very bruteforce useful, since the server can rate limit the requests. |
| 02:55:04 | gmaxwell: | or ban the requesting party or lockout the account. |
| 02:55:48 | gmaxwell: | You'd want a strong KDF here not to help the normal case, which has strong security from the ZK-PAKE. ... but for the eventuality that the server gets hacked and someone gets the database. |
| 02:55:57 | gmaxwell: | And then they can simulate the server as fast at they like. |
| 02:58:29 | gmaxwell: | In any case, I didn't push more for scrypt when we added wallet encryption to bitcoin core (though I did get it a strong KDF) because I was not sure about the security argument, the extra required code, and the timing sidechannels. |
| 02:58:54 | gmaxwell: | Fortunately many of the proposals can be implemented free of timing sidechannels. \O/ |
| 02:59:34 | gmaxwell: | But the rest seems to have no improvement in the last three years. ... somewhat the opposite in fact: there are remarkably efficient asics for the litecoin POW function. |
| 03:02:02 | petertodd: | still not seeing the security model here, or what exactly the ZK PAKE is trying to achieve |
| 03:06:54 | petertodd: | anway, ACK your letter |
| 04:33:48 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 06:20:59 | Greed`: | Greed` is now known as Greed |
| 07:34:23 | Greed`: | Greed` is now known as Greed |
| 07:50:50 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:05:15 | morgan.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:15 | morgan.freenode.net: | Users on #bitcoin-wizards: andy-logbot soundx damethos grau NewLiberty gues____ grandmaster2 bit2017 Baz___ wallet42 cbeams Aquent jaekwon todaystomorrow paveljanik Flyer9933 Greed tacotime guest8584 op_null ahmed_ lnovy TheSeven ryanxcharles spinza prodatalab PaulCapestany PRab Shiftos Luke-Jr eristisk nuke1989 mortale Emcy espes__ bramc jgarzik tdlfbx Iriez Dr-G orw_ www1 heath mappum go1111111 waxwing Graftec midnightmagic Grishnakh jchp dansmith_btc eordano postpre |
| 09:05:15 | morgan.freenode.net: | Users on #bitcoin-wizards: OneFixt luny ebfull nullbyte shesek wumpus dgenr8 mkarrer jbenet btcdrak hollandais nsh gribble zwischenzug HaltingState phantomcircuit gwillen Nightwolf gazab Tjopper Anduck adlai Guest4661 Dyaheon null_radix kyletorpey samson_ hashtag_ cfields digitalmagus8 c0rw1n stonecoldpat gmaxwell SubCreative [\\\] pigeons copumpkin Transisto isis tromp andytoshi lechuga_ bobke coutts CryptOprah artifexd Muis hguux_ michagogo kumavis nickler |
| 09:05:15 | morgan.freenode.net: | Users on #bitcoin-wizards: gavinandresen Hunger- NikolaiToryzin warptangent Fistful_of_Coins koshii HM2 paperbot kefkius zibbo maaku epscy Cory LarsLarsen Guest38445 coryfields iddo otoburb_ kinlo azariah4_ fenn bosma iambernie mr_burdell yoleaux btc__ Graet Logicwax pi07r Meeh DoctorBTC K1773R nanotube kanzure arowser1 berndj lclc s1w Eliel_ LaptopZZ sneak harrigan JonTitor sl01 sipa Alanius MRL-Relay fluffypony BlueMatt a5m0 asoltys smooth amiller danneu catcow |
| 09:05:15 | morgan.freenode.net: | Users on #bitcoin-wizards: TD-Linux ryan-c roasbeef harrow warren BrainOverfl0w phedny huseby Keefe helo jaromil BigBitz [d__d] so crescendo petertodd throughnothing Apocalyptic optimator_ Taek mmozeiko comboy poggy Krellan tromp_ bbrittain wizkid057 burcin @ChanServ BananaLotus livegnik AdrianG |
| 09:54:18 | lclc: | lclc is now known as lclc_bnc |
| 11:13:57 | Fullbreed: | hi |
| 11:17:23 | Fullbreed: | anyone there |
| 11:17:25 | Fullbreed: | Fullbreed has left #bitcoin-wizards |
| 12:14:16 | todays_tomorrow: | todays_tomorrow is now known as todaystomorrow |
| 15:08:05 | wallet42: | wallet42 is now known as Guest58134 |
| 15:08:05 | wallet421: | wallet421 is now known as wallet42 |
| 15:16:51 | wallet42: | wallet42 is now known as Guest13055 |
| 15:16:51 | wallet421: | wallet421 is now known as wallet42 |
| 19:42:50 | Greed`: | Greed` is now known as Greed |
| 22:44:07 | RedFade: | RedFade has left #bitcoin-wizards |
| 22:56:10 | kyletorpey: | kyletorpey has left #bitcoin-wizards |