00:02:17 | hulkhogan_: | wee, -wizards logs are back up, thx andytoshi! |
00:04:54 | andytoshi: | hulkhogan_: fyi my logs are pretty patchy and hard to search .. the botbot.me ones are much more robust. (if that's what you mean, thx, but i have nothing to do with them..) |
00:05:45 | hulkhogan_: | well, sadly the botbot logs are only up until a year or so; bitcoinstats has -dev logs from '11 or so, but thats just for -dev only |
00:06:11 | hulkhogan_: | (unless i've missed where botbot.me keeps their archived stuff) |
00:08:19 | andytoshi: | yeah, we didn't have botbot until a year or so. if my archives are ever down feel free to let me know at apoelstra@wpsoftware.net |
00:08:49 | frankenmint: | is andytoshi real or a bot? |
00:08:54 | frankenmint: | sorry I have to ask |
00:09:00 | hulkhogan_: | awesome yes, i will definitely shoot you a ping if they do :) |
00:10:54 | andytoshi: | frankenmint: bots can be real |
00:11:11 | frankenmint: | sorry, does andytoshi have sentience? |
00:11:17 | frankenmint: | seems to :) |
00:12:12 | andytoshi: | ;) |
00:12:33 | andytoshi: | (and yes, i'm a real person. you can google the name in my /whois to get way too much information on me if you like) |
00:14:17 | kanzure: | real is just a matter of perspective |
00:24:47 | bassguitarman: | bassguitarman has left #bitcoin-wizards |
01:06:14 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
02:42:15 | nsh: | .wik Hyperreality |
02:42:16 | yoleaux: | "In semiotics and postmodernism, hyperreality is an inability of consciousness to distinguish reality from a simulation of reality, especially in technologically advanced postmodern societies." — http://en.wikipedia.org/wiki/Hyperreality |
02:43:54 | nsh: | i was about to idly muse "If only we had more cryptographers who were semioticians" and while i was still wondering what on earth that would even mean, i saw this sentence in the WP article: "Some famous theorists of hyperreality/hyperrealism include Jean Baudrillard, Albert Borgmann, Daniel J. Boorstin, Neil Postman, and Umberto Eco." |
02:44:05 | nsh: | (NB: d.j.boorstin) |
06:49:27 | Bosnia: | Bosnia is now known as bosma |
06:55:54 | ThomasV: | gmaxwell: your opinion on https://github.com/spesmilo/electrum/issues/507 ? |
06:59:19 | gmaxwell: | ThomasV: that complaint is somewhat misunderstanding /dev/urandom (and CSPRNGs) in general. There isn't such a thing as "low on entropy" for such constructs, so long as its ever had sufficent entropy gathered (e.g. 128+ bits) the output will forever be unpredictable-- barring an improbable brake of the interior cryptographic function (and in the case of that you're likely screwed regardless). Wh |
06:59:25 | gmaxwell: | at actually _is_ an interesting concern is when the rng has never been initilized at all, linux has a newish syscall that has flags for precisely that case. |
07:00:06 | gmaxwell: | most of the code out there for "move the mouse around" and such is really horrifying. (e.g. some bitcoin key generator thing simply polled the mouse position a couple times in a tight loop and then combined that with the time.....) |
07:03:00 | ThomasV: | oh I thought the "mouse moving" was only going to act on /dev/random's entropy estimate |
07:03:19 | gmaxwell: | Basically, the urandom behavior is really what virtually everything wants. Except for this corner case around initial startup. Really it should be changed to block in that case, but it cant because userspace starts reading it super early in boot and would get stuck. |
07:04:23 | gmaxwell: | ThomasV: nah thats not reliable. at all. sadly, no reason to believe the mouse activity will be credited against it. Linux went through a cycle of removing randomness credits from drivers for a number of years until it got to a point where basically only the timer interrupt added "randomness". |
07:04:37 | gmaxwell: | Seems to have gotten somewhat better recently. |
07:04:52 | ThomasV: | I see |
07:05:43 | ThomasV: | "please generate timer interrupts to increase your entropy" :) |
07:06:24 | ThomasV: | gmaxwell: did you know the page I linked at the bottom? is it correct? |
07:11:45 | DougieBot5000_: | DougieBot5000_ is now known as DougieBot5000 |
07:13:02 | gmaxwell: | looking at it now, haven't seen it before. Yes, it's correct (it simplifies the design of the linux randomness infrastructure, but it points out the simplification) |
07:13:18 | gmaxwell: | It's also correct about other people's opinions on the subject. |
07:15:04 | gmaxwell: | Realistically for our usage in generating 'long term' keys perhaps the cost of /dev/random makes sense: just because we shouldn't be wasting our time arguing with panicing frightened users, and there is little risk of the user bypassing the randomness when it does actually block. (I qualify long term keys because all other places where our program use randomness should _not_ use /dev/random, be |
07:15:10 | gmaxwell: | cause the blocking will be problematic for sure and may lead to crazy bypassing) |
07:18:00 | ThomasV: | ok.. do you mind if I paste your irc answer there? |
07:18:42 | gmaxwell: | Not at all. |
07:21:01 | gmaxwell: | Another point that page doesn't point out is that if you do have an application for an information theoretic RNG source, linux /dev/random is very likely non-sutable. Even if there is adequate entropy in it, the output may be still structured enough to make it distinguishable from random to a computationally unbounded attacker. |
07:21:53 | gmaxwell: | (Thats not our application set in any case; but it's probably an argument that /dev/random basically shouldn't exist. The only applications it might be better for it's still not sutiable for.) |
07:23:49 | gmaxwell: | To clarify what thats all about: There are some cryptosystems which are secure even against an attacker with infinite computing power; a one time pad is an obvious example though there are other ones. For those properties to hold, the randomness must have no mathmatical structure at all. Running lots of real randomness through sha1 likely gives it mathmatical structure that an attacker with infin |
07:23:55 | gmaxwell: | ite computing power could exploit, even if you had plenty of randomness to begin with. |
07:26:52 | ThomasV: | gmaxwell: how could they exploit it in that case? is there a known algorithm for that, or is it just a theoretical bound? |
07:27:33 | gwillen: | gmaxwell: he does actually say "If you really need information-theoretically secure random numbers (you don't!), and that's about the only reason why the entropy of the csprngs input matters, you can't use /dev/random, either!" |
07:31:01 | rusty: | rusty has left #bitcoin-wizards |
07:35:22 | phantomcircuit: | gmaxwell, the tests applied to the output of an rng likely enforce something similar, no? |
07:35:48 | phantomcircuit: | if a hw rng output nothing but 11111 im guessing nobody would believe it was random despite that being technically a possible result |
08:05:16 | orwell.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 |
08:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot CoinMuncher frankenm_ prodatalab__ grandmaster DougieBot5000 gielbier hktud0 Mably dc17523be3 antanst b_lumenkraft arubi fanquake priidu kgk GAit jtimon sadoshi TheSeven Dr-G felipelalli d1ggy hashtag_ Sub|afk rustyn jrayhawk zmachine sparetire_ akrmn DrWat spinza copumpkin thrasher` Relos cdecker Tiraspol Starduster bsm117532 Apocalyptic lnovy p15 harrigan andytoshi go1111111 scoria stonecoldpat gavinandresen brand0 larraboj |
08:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: ttttemp_ bedeho2 PaulCape_ OneFixt luny` melvster Logicwax superobserver kyletorpey hulkhogan_ antgreen LeMiner justanotheruser gmaxwell metamarc vonzipper mappum isis MoALTz PRab Jouke Pan0ram1x weex harrow gnusha alferz mkarrer Adlai tromp__ nsh triazo jonasschnelli mountaingoat CryptoGoon wizkid057 Luke-Jr berndj leakypat pollux-bts bosma platinuum Oizopower jmcn_ jbenet HM dasource waxwing btcdrak tucenaber kyuupichan helo Taek ebfull |
08:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: hashtagg Madars crowleyman iddo mengine GreenIsMyPepper amiller sneak epscy adams__ wiz michagogo mikolalysenko artifexd dansmith_btc lmacken dgenr8 c0rw|zZz Cory nickler yrashk cfields Krellan_ stevenroose coryfields Meeh catlasshrugged cryptowest_ Alanius null_radix kanzure bliljerk_ azariah tromp_ warptangent sparetire davout comboy TD-Linux yorick crescend1 veox mm_1 theymos Zouppen huseby _whitelogger wumpus binaryatrocity heath |
08:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: BananaLotus maaku face_ [d__d] optimator Eliel narwh4l lmatteis koshii mr_burdell throughnothing_ elastoma fluffypony Fistful_of_Coins yoleaux Jaamg se3000 xabbix mariorz catcow a5m0_ smooth dignork runeks Sqt poggy livegnik K1773R petertodd richardus nephyrin phedny so BrainOverfl0w @ChanServ gwillen kinlo sl01 STRML espes AdrianG luigi1111 Anduck BlueMatt midnightmagic otoburb kumavis starsoccer d9b4bef9 gribble jessepollak ryan-c Keefe |
08:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: indolering Graet jaromil sturles [ace] merlincorey Iriez EasyAt morcos CryptOprah s1w roasbeef eric sdaftuar Xzibit17 warren Muis forrestv nanotube ajweiss guruvan SwedFTP pigeons afdudley phantomcircuit |
09:00:30 | fluffypony: | zomg are we doing /dev/urandom discussions again? |
09:01:39 | fluffypony: | phantomcircuit: did you see the classic comment on Bitcointalk? |
09:02:07 | fluffypony: | I'll have to find a cached version |
09:03:15 | fluffypony: | https://web.archive.org/web/20150517052034/https://bitcointalk.org/index.php?topic=1005487.0 |
09:03:18 | fluffypony: | first reply |
09:05:54 | fluffypony: | wb ThomasV |
09:05:57 | phantomcircuit: | qahah |
09:06:09 | LeMiner2: | LeMiner2 is now known as LeMiner |
09:06:12 | ThomasV: | hi fluffypony |
09:08:02 | ThomasV: | what's up? |
09:13:27 | fluffypony: | just responding to that github issue |
09:13:28 | fluffypony: | to add some thoughts |
10:11:31 | ThomasV: | fluffypony: I was disconnected when you responded I guess |
11:40:30 | helo: | helo is now known as texas |
11:40:34 | texas: | texas is now known as helo |
15:49:21 | jae: | jae is now known as Guest96981 |
17:06:52 | gielbier: | gielbier is now known as UreCEO |
17:07:06 | UreCEO: | UreCEO is now known as gielbier |
18:43:03 | lnovy: | lnovy is now known as zz_lnovy |
20:06:46 | frankenm_: | frankenm_ is now known as frankenmint |
23:20:29 | wallet42: | wallet42 is now known as Guest67953 |
23:20:30 | wallet421: | wallet421 is now known as wallet42 |
23:37:50 | Taek: | http://www.theverge.com/2015/4/12/8392769/nsa-front-door-access-encryption-key |
23:38:01 | Taek: | "I don’t want a back door," Rogers said. "I want a front door. And I want the front door to have multiple locks. Big locks." |
23:38:11 | Taek: | In general I'm against backdoors of any kind |
23:38:35 | Taek: | but I wonder if there isn't a way to add a 'front door' that has a computational barrier |
23:38:46 | Taek: | perhaps, a standard secret key that works as normal, |
23:39:07 | Taek: | and then a govt secret key that's known, but can't be used without scanning a 2^64 search space or something |
23:39:34 | Taek: | This would make mass surveilance prohibitively expensive, but still enable the government to access specific targets |
23:39:43 | Taek: | which is something I think the general populace would be in favor of |
23:40:21 | Taek: | it also makes it less exciting for attackers to compromise the govt's secret key, because instead of compromising anything, it's still expensive to access any particular communication |
23:42:03 | Taek: | one risk with such a scheme is us getting to a point where 2^m is no longer very expensive at all, but thanks to slow legislation we can't increase 'm' |
23:47:10 | tdryja: | Taek: Those specific targets can simply use regular old RSA/AES/Whatever before encrypting with the front-doored system. |
23:47:53 | tdryja: | it would then take 2**64 time to discover not the plaintext, but another layer of encryption |
23:48:01 | gmaxwell: | Taek: you mean like https://eprint.iacr.org/2003/058.pdf |
23:48:41 | gmaxwell: | (though note, the scheme discussed in that paper is weaker than the authors thought) |
23:51:31 | gmaxwell: | at tdryja points out, it's pointless though for positive uses. And any 'feasble but costly' can easily get reduced to a very minor speedbump by building a bunch of custom hardware and amortizing the attack cost across many attacks. |
23:52:26 | Taek: | tdryja: that would provide an interested counter-play: hide full encryption under weak encryption, and then let the LEA waste resources on something they couldn't crack anyway |
23:53:31 | gmaxwell: | thats what he was sawying. :) |
23:53:51 | zooko`: | That's approximately what the initial "export grade crypto" intention was. |
23:53:56 | zooko`: | and get off my lawn. :-( |
23:53:58 | gmaxwell: | (thats also a general example of why any kind of escrow or 'front door' approach is unwise.) |
23:53:59 | zooko`: | zooko` is now known as zooko |
23:54:08 | Taek: | oh got it |
23:54:10 | zooko: | * zooko laughs. |
23:54:47 | gmaxwell: | (because the supposid high value targets that justify the enormous civil rights risk of undermining private communication can so easily just encrypt inside and then they have perfect cover traffic too.) |
23:56:36 | tdryja: | Diffie said something like this at a talk a few weeks ago |
23:57:13 | tdryja: | It would seem to quickly devolve into law enforcement opening all the "front doors" all the time |
23:57:31 | tdryja: | just to make sure there wasn't another locked door which they couldn't open behind it |
23:57:45 | zooko: | Diffie |
23:57:45 | zooko: | https://www.youtube.com/watch?v=W9HimLksMkA&app=desktop |
23:58:05 | zooko: | I love that guy. |
23:58:17 | gmaxwell: | and they can't even really check that, because so long as you don't need a hugely high bandwidth channel; strong steganography is an obvious enough tool. |
23:58:30 | zooko: | I've had the honor of meeting him a few times. |
23:59:33 | gmaxwell: | So, what you have to admit is that you want backdoors to catch idiots (and orgs so massive that idiocy is unavoidable) because the non-idiots will encrypt inside and stego. But of course there are lots of other ways to fight idiots. |
23:59:56 | gmaxwell: | (or that you don't want to fight specific threats at all, but actually just want it to monitor random people...) |