--- Log opened Wed Dec 18 00:00:05 2013
02:31 < gmaxwell> well pinocchio is only kinda public, the circuit generator is public, but without the underlying crypto libraries, it's not useful.
02:34 < gmaxwell> amiller: oh have they made the resot of pinocchio public now?
02:35 < gmaxwell> in any case, I think the obvious thing to do with pinocchio/friends is make a blind sin proof. Though I don't see how to do it without having an ecdsa verification under the proof... which is probably going to hurt a bit.
02:36 < gmaxwell> s/verification/signature/ in fact.
02:38 < gmaxwell> e.g. You make a proof of the statement    X  is the hash of a determinstic-signature of data Y, using a key, committed to by a SIN transaction paying >=Z in fees, spv connected to header Q.
02:39 < gmaxwell> Feed in the name of a site in Y "bitcoin talk" and X is an identity you use to log into the site that can be banned, and replacing it costs you Z bitcoin.
02:39 < gmaxwell> But the site learns nothing about which bitcoin were yours...  or nothing about identities you use on other sites !Y.
02:40 < gmaxwell> and if the proof takes a cpu hour to compute, well that actually doesn't reduce the usefulness all that much.
03:01 < BlueMatt> can I ask a dumb question?...whats a sin in this context?
03:02 < maaku> google identity protocol
03:02 < maaku> oh gribble's not here
03:03 < BlueMatt> ahh, ok
03:03 < BlueMatt> my google-fu was looking in the wrong places
03:03 < maaku> https://en.bitcoin.it/wiki/Identity_protocol_v1
03:03 < maaku> yeah
03:04  * maaku is still waiting for someone to come up with a v2 protocol so we can have a lively debate about the merits of original SIN
03:06 < BlueMatt> has anyone even started implementing identity protocol?
03:09 < BlueMatt> ahh, yes, there is
03:11 < BlueMatt> heh, ofc jgarzik wrote it in node.js...
03:33  * gmaxwell groans at maaku's pun
03:38 < BlueMatt> hey, its better than HD wallets
03:39 < gmaxwell> I continue to think HD wallets is a perfectly good name.
03:39 < BlueMatt> I continue to disagree (though considering how often I'm mia, thats rarely useful)
03:40 < gmaxwell> ;;ticker
03:40 < gribble> MtGox BTCUSD ticker | Best bid: 500.5, Best ask: 500.97, Bid-ask spread: 0.47000, Last trade: 500.97, 24 hour volume: 48505.69491744, 24 hour low: 500.5, 24 hour high: 774.9899, 24 hour vwap: 628.33712
03:40 < gmaxwell> oops wrong window. :P
03:40 < BlueMatt> well, thanks for reminding me to buy cheap coins :)
09:21 < jgarzik> maaku, gmaxwell: pun already made: http://garzikrants.blogspot.com/2013/08/original-sin.html
10:56  * Luke-Jr ponders how to respond to altoz this time.
11:12 < andytoshi> i think he's just going to keep claiming not to be able to read what you're saying
11:13 < andytoshi> if you PM him, idk if he'll receive the message if you're on his blacklist
11:34 < gmaxwell> Luke-Jr: I advise just dropping it.
12:12 < gmaxwell> Luke-Jr: I cracked his cryptosystem
12:12 < Luke-Jr> lol
12:12 < andytoshi> wow, nice
12:22 < gmaxwell> This is what I sent him:
12:23 < gmaxwell> Incidentally, I can compromise your cryptosystem for a single message with 2^64 known-ciphertext queries to a decryption oracle.  E.g. you run a server that decrypts messages and returns the results and I obtain the ciphertext of a message someone else created (which the oracle refuses to decrypt for me, otherwise this would be trivial), and after making ~2^64 queries to your decryption oracle I can decrypt the unknown message.
12:23 < gmaxwell> This isn't the most grievous of weaknesses, but its somewhat surprising, and I could imagine someone using this in a way which made it actually exploitable for something.
12:23 < gmaxwell> I'm being a bit oracular because I thought you might enjoy figuring out what I'm thinking.
12:24 < gmaxwell> (I was hoping it would be 2^32 queries— then it would be reasonable to put up demonstration code)
12:24 < gmaxwell> (alas)
12:25 < andytoshi> brute-forcing the keyspace would be 2^256?
12:27 < andytoshi> ah, no, he is using aes-128
12:28  * gmaxwell refrains from giving hints.
12:29 < Emcy> im just wondering what oracular means
12:29 < Emcy> guess synonym verbose
12:29 < andytoshi> Emcy: i think, you have to submit questions to gmaxwell, and he will decide whether to answer them
12:31 < andytoshi> or rather, altoz does
12:31 < gmaxwell> Emcy: Where I say that I'm being oracular, I'm referring to the point that oracles— of the classic sort— answer questions in riddles.
12:32 < Emcy> "In Classical Antiquity, an oracle was a person or agency considered to interface wise counsel or prophetic predictions or precognition of the future, inspired by the gods."
12:32 < Emcy> hmm thats my werd lernin for today
12:33 < Emcy> how dod you get to know so much about crypto? Do you have any formal math background?
12:33 < gmaxwell> In my attack description I'm using the world oracle in the sense used in cryptographic lit. ... an oracle is some black box that performs some function. E.g. a remote server that signs messages for you or decrypts things for you would be an example of an oracle.
12:35 < gmaxwell> well I majored in math before I dropped out of college... but no, I was just one of those annoying kids who read most of the books in the library and remembered a few of them.
12:36 < Emcy> hmm ok pretty cool
12:36 < Emcy> its one thing to learn the maths it another to break someone elses maths
12:37 < Emcy> i had a tutor once who impressed upon me the difference between learning by rote and the power of original thought
12:37 < Emcy> he said the former end up tutoring in college and the latter end up tenured in university
12:37 < gmaxwell> I think a lot of people are short changed by education which focuses on learning by rote.
12:38 < gmaxwell> haha
12:39 < gmaxwell> The annoying thing about breaking cryptosystems is that even when you find a neat flat it usually only gets you 99% of the way there, but you can't expand it to a full compromise because of some accidental detail which isn't _just right_ for the attack to work. In this case I think it would actually work (I guess I could go weaken it further to be completely sure).
12:40 < gmaxwell> s/flat/flaw/
12:40 < Emcy> is 2^64 queries to some soerver actually viable though
12:41 < gmaxwell> Yes it is, though not enough to demonstrate easily.
12:41 < gmaxwell> Or at least close enough to viable that its a surprising weakness.
12:41 < gmaxwell> Emcy: e.g. what if the "server" is a bitcoin trezor like device in your possession?
12:42 < Emcy> cry
12:42 < gmaxwell> But I mean that that often weaknesses are such that even allowing for "unreasonable" freedoms like 2^64 queries to a blackbox decryptor you still can't break it.
12:42 < Emcy> at least 2^64 packets over the actual internet though. Seems like a faff. Suppose you could be in no rush though
12:43 < gmaxwell> (It's hard to say if thats unreasonable or not, depends on the applications. Thats the bummer about generic constructs)
12:44 < gmaxwell> Emcy: yea, before I looked at the code again I thought it would be 2^32, in which case it would have been trivial even over the internet.
12:44 < Emcy> still i think 2^64 or 64 bits or whatever is not something you want to see in any cryptosystem any more afaik
12:44 < gmaxwell> right.
12:45 < Emcy> 2^32 is only like 4 billion right
12:45 < gmaxwell> Right.
12:46 < gmaxwell> If there is also a simple software bug I can reduce it to one query.
12:46 < andytoshi> Emcy: things like decryption-oracle attacks are fairly standard in cryptography and there is a lot written about them
12:46 < andytoshi> like "Random Oracles are Practical" by Bellare and Rogaway is a paper the wizards pointed me to
12:46 < Emcy> would that be how the wifi hacks work
12:46 < gmaxwell> But I suppose that for some definition of "bug" thats always the case, e.g. bug: gives up the private key.
12:47 < andytoshi> wifi attacks i think showed up on matthew green's blog..
12:47 < Emcy> you packet inject until you get enough back to recover the key
12:47 < Emcy> the router is the oracle?
12:48 < andytoshi> ah, yes
12:48 < andytoshi> http://blog.cryptographyengineering.com/2011/09/when-things-fall-apart-part-1.html
12:48 < gmaxwell> Emcy: yea, well, the wifi attacks are very specialized... WEP uses RC4 which is a stream cipher, you put in a key, it puts out an infinite stream of 'random' bits.  These bits get xored with the packets.
12:49 < gmaxwell> If RC4 were a perfect, you wouldn't be able to learn anything useful about the key just by knowing some of those random bits.
12:49 < gmaxwell> RC4 is far, far from perfect.
12:50 < gmaxwell> If you know some data in a packet, you can take an encrypted packet, xor it with the data you know, and you'll learn the output of RC4 in those known positions.
12:50 < gmaxwell> So the WEP attacks usually work by replaying an encrypted arp request (which you reconize by the size). The router acts as an orcale producing a stream of ARP replies which are encrypted.
12:51 < gmaxwell> But you know some bits of the arp replies because they're fixed in the packet syntax.
12:51 < Emcy> ha i was right
12:51 < gmaxwell> and some because they copy data from the arp request.
12:52 < gmaxwell> So you gather a bunch of rc4 output with different initilization vectors (incremented in every packet),  and you can setup a system of equations that derrives the key.
12:53 < gmaxwell> Nothing _quite_ so fancy is needed for this encrypted message thing.
12:54 < Emcy> what you described doesnt seem so fancy to me
12:54 < Emcy> just seems like pattern matching
12:55 < Emcy> you just need enough pattern
12:55 < gmaxwell> sure, the gist of it is simple, the math somewhat less so.
12:55 < Emcy> sure
12:56 < gmaxwell> I find that nothing accomplished by men is actually all that complicated once put into the right terms. Otherwise we couldn't accomplish it.
12:56 < Emcy> do we have any systems that are too complex for a single mind to grasp alone?
12:56 < Emcy> layout of a modern CPU perhaps
12:58 < gmaxwell> sure, but you break them down.
12:58 < gmaxwell> And all the parts are sensible in isolation, and the overall design— ignoring the details— is also sensible.
12:58 < gmaxwell> It's actually quite reasonable to build software systems which are vastly beyond the ability of one person to comprehend at least all at once.
12:59 < Emcy> yes, but things get interesting when someone goes wrong due to an emergent property of how the parts interact. And no one can figure it out because no human has the cubic centimetres of brain required......
13:00 < Emcy> i wonder if humans have a system like that anywhere
13:00 < Emcy> the OPERA neutrino thing maybe? that stumped em
13:01 < gmaxwell> Things like that crop up all over the place, we get them in Bitcoin... they show up in any sufficiently large piece of software or hardware design. In digital electronics you'll sometimes have problems when analog effects that you thought you could ignore crop up.
13:02 < Emcy> obviously its not such a big problem as i think then
13:02 < Emcy> are there any cryptosystems that are unkowable in full by human mind?
13:03 < gmaxwell> Well...
13:04 < gmaxwell> We depend on knowing the thing in order to make arguments for its security. Modern cryprosystems are build out of simple regular parts.  Otherwise if you make something too complex you'll miss a weakness which will be obvious to someone who 'looks at it from another angle'.
13:04 < gmaxwell> So all the primitives we use are quite simple and straighforward.
13:05 < gmaxwell> Though in more recent times people have been building taller towers, systems which are only simple if you abstract away the details.
13:05 < Emcy> but they dont always interact in the way you think they should.
13:06 < Emcy> perhaps one day we will throw together enough primitives that it will turn around and ask us for clemency.....
13:09 < andytoshi> Emcy: there is a good lesson about this in the history of tls
13:10 < andytoshi> http://blog.cryptographyengineering.com/2012/09/on-provable-security-of-tls-part-2.html
13:12 < Emcy> im sure it is provably secure, the auth part is letting it down badly though these days
13:13 < andytoshi> that link has a short blurb about the MAC fiasco in the 90's
13:14 < Emcy> wots taht
13:14 < Emcy> nm ill read
13:15 < andytoshi> it's a classic "things interact in surprising ways when you pile them on" story
13:15 < andytoshi> and the complexity of that probelm was not even very high..
13:17 < Emcy> from what ive seen almost no servers still dont use tls 1.2
13:18 < andytoshi> yeah, i don't think browsers will even accept tls 1.0
13:18 < Emcy> i always thought people used old shit because its been in the trenches longer than new shit.
13:19 < Emcy> i saw a server with tls 1.0 and 1024 rc4 or something recently
13:20 < Emcy> thats pretty bad
13:22 < Emcy> jesus christ it just rained the hardest its ever rained around here in 30 years
13:22 < Emcy> it was raining upwards.......
13:22 < Emcy> wall of water
13:23 < andytoshi> well, i am off to the airport, good talking to you guys
13:24 < Emcy> good flight
13:24 < Emcy> oh
13:34 < Emcy> god dammit planetside 2 has been down for hours
13:35 < Emcy> i spose thats why its free
13:56 < nsh> andytoshi, your link on tls -- reminds me of that scene from one of the hitch-hiker's guide books...
13:56 < nsh> "Arthur goes to the village. He finds a woman seer who swats at flies in front of a cave. She smells horrible. She does her dead goat-like animals. He helps her take her photocopy machine out into the sun because it is solar-powered. She hands the photocopies to him. It is the story of her life. He should read it and not make the decisions she made to end up alone..."
13:56 < nsh> ( http://www.bookrags.com/studyguide-mostly-harmless/chapanal005.html )
13:57 < nsh> someone should teach a remedial history of the internet, annotated at every point where we fucked it up
13:57 < nsh> in case we get a chance to start over at some point :)
14:51 < eclark> what do you think of **********DOGE*********
14:57  * nsh looks at eclark pointedly
16:59 <@gmaxwell> andytoshi, luke: I went and posted the description of my attack on that cryptosystem. (since he tried and didn't figure it out and asked me to explain it)
17:03 < jtimon> gmaxwell do you have a link?
17:05 <@gmaxwell> jtimon: https://bitcointalk.org/index.php?topic=374085.0
17:07 < jtimon> thanks
17:24 < nsh> i don't really understand the assumption that you'd want to have much correspondence with someone you just performed a pseudoanonymous one-time transaction with. i rarely feel the urge to call the hot-dog stand for a chat...
17:26 < helo> maybe authentication to some service that the one-time transaction paid for
17:26 < nsh> mmm
17:34 < helo> people generally handle their bitcoin private keys more securely than most other kinds of private keys, so services that are cobbled together ontop of bitcoin's PKI smell ultra-secure
17:36 < BlueMatt> heh, shit...they recovered rsa pgp private keys from the noise a cpu makes...
17:36 < nsh> yeah, was reading about that today
17:41 <@gmaxwell> BlueMatt: none of the crypto we use for bitcoin is timing/power side channel immune.
17:41 <@gmaxwell> I don't believe there exists constant time implementations of the primitives for secp256k1 at all right now.
17:41 < BlueMatt> gmaxwell: I didnt think they were, I just found this particular paper fun
17:42 < nsh> i wonder how much of the efficiency advantage of EC is lost with constant time primitives...
17:43 <@gmaxwell> nsh: the curve25519 stuff is constant time, and stupid fast... but its partly a result of having picked parameters with that in mind.
17:43 < nsh> hmmm, okay
17:44 < nsh> i wish djb would release the minimaLT code :/
18:06 <@gmaxwell> dear god.
18:06 <@gmaxwell> this guy is wasting unbounded amounts of my time in private message.
18:07 < BlueMatt> so ignore him?
18:07 < BlueMatt> or limit your bw
18:07 <@gmaxwell> I had hoped that I'd not be able to waste any time on him by dispatching luke to respond on the threat, but that ended up like a cesium / water reaction.
18:07 <@gmaxwell> s/threat/thread/
18:08 <@gmaxwell> dude is convinced he's going to revolutionize bitcoin with his grand ideas, but his only expirence is with bc.i.
18:08 <@gmaxwell> and he's all confused about how bitcoin works.
18:08 <@gmaxwell> and every exchange I have with him is revealing another understanding.
18:09 <@gmaxwell> like after message 6 I discover that he's planning on 'solving' the problem that the "messages in transactions are cleartext".
18:09  * nsh chuckles
18:09 < maaku> gmaxwell: there are a dozen people on bitcointalk like that
18:09 < maaku> if only the ignore bit were an option :\
18:09 <@gmaxwell> And the idea that a business that ships out goods to people would generate a new address for each payment seems to be completely foreign to him.
18:10 < BlueMatt> maaku: a dozen? really? theres like a few thousand...
18:10 < maaku> heh
18:10 <@gmaxwell> I could ignore him but I don't want him going and fucking stuff up with his earnest enthusiasm.
18:11 < nsh> there should be a crypto playpen tarpit for people
18:11  * maaku fully expects him to find some inestor willing to throw insane amount of money at his ideas
18:12 < BlueMatt> or...we could just let people implement dumb crypto primitives, and use idiots to steal coins from
18:14 <@gmaxwell> part of the problem, of course, is that even the broken and dumb ones are seldom so bad as to enable theft.
18:15 < BlueMatt> yup
18:15 <@gmaxwell> like— this guys busted ass cryptography still would take 2^64 queries to a decryption oracle to crack one message. Even if someone had convinced him to reduce the mac to 32 bits, it likely would have only rarely been a pratical attack.
18:16 <@gmaxwell> he also thinks he can do things with transaction "from" addresses.
18:16 < BlueMatt> how much would it cost to put an ad on bitcointalk that just says "THERE IS NO FROM ADDRESS, GET THAT THROUGH YOUR HEAD, IF YOU DONT GET IT, GO AWAY"
18:17 < nsh> ehehe
18:17 <@gmaxwell> BlueMatt: I wonder what the revenue stream from bc.i is? It can't be that great if its really just the ads and they don't have income from spying on people or whatever.
18:18 <@gmaxwell> We could raise money to buy it and shut it down.
18:18 <@gmaxwell> Without notice.
18:18 < BlueMatt> they have pretty reasonable vc funding iirc
18:18 < BlueMatt> so...they must have some business model, somewhere
18:18 <@gmaxwell> And a full screen "HA HA WE TOOK YOUR MONEY, YOU WERE AN IDIOT FOR USING A CENTERALIZED SERVICE"
18:18 <@gmaxwell> darn
18:18 < BlueMatt> even if its "down the road, we..."
18:18 <@gmaxwell> (3) profit.
18:21 < maaku> money up for grabs: https://telegram.org/crypto_contest
18:23 < maaku> http://core.telegram.org/techfaq
18:24 <@gmaxwell> uh.
18:24 <@gmaxwell> that seems really dishonest to me.
18:25 <@gmaxwell> it looks like the security is dependant on their server handing out the correct keys.
18:25 < BlueMatt> they claim you can also do dh p2p and then compare some image that represents the shared key or something
18:25  * BlueMatt didnt read closely, it just said "compare image after dh exchange"
18:28 <@gmaxwell> I wonder why they're using sha1, especially when they need 512 bits of KDF.
18:48 <@gmaxwell> I see that news.ycombinator.com has similar thoughts to me, https://news.ycombinator.com/item?id=6931457
18:51 < nsh> "Yeah, it's probably against the rules of the competition and will get you arrested if you try. But I think if someone does break into their central server and wins the competition that way, they should still be paid out."
18:51 < nsh> i like those odds!
18:53  * gmaxwell contemplates that google search you did earlier today in #bitcoin ... :P
18:54  * nsh smiles
18:55 <@gmaxwell> hm. I was trying to see what their physical location was, and it seems to be run by totally anonymous parties?
18:57 < nsh> can you sell on the google play store anonymously?
18:58 < nsh> LLCs are registered, but anyone can call themselves X LLC https://play.google.com/store/apps/developer?id=Telegram++LLC
19:00 < nsh> possibly William / Jordan A Baker http://trademarks.justia.com/860/10/telegram-86010749.html
19:00 < nsh> (no mention of encryption in the trademark application though)
19:01 < nsh> ( http://companies.findthecompany.com/l/32066563/Telegram-Llc-in-Wilmington-DE )
19:43 < adam3us> hmm this coinmessage thread is locked so i cant join in!  i was going to explain that what the sender claims is R.x from R=rP can be s st there is no solution to s=f(x) ie s is not on the curve.  he doesnt seem to get that (re comments about s being > n)
19:45 <@gmaxwell> I thought I mentioned x could be not on the curve! I think his code actually tests though.
19:47 < adam3us> gmaxwell: ok. just his response to your explaining that was "an invalid nonce means the attacker sends an x that's past p but less than 2^256." which is not the point at all!
19:47 <@gmaxwell> oh I didn't even notice that.
19:47 <@gmaxwell> (that he responded to that point)
19:48 < adam3us> gmaxwell: #11 - is it locked because he did that as the thread starter?
19:50 <@gmaxwell> No. I locked it because it was becoming a totally stupid war. If you'd like to post I can unlock it.
19:50 <@gmaxwell> I've been talking to the guy in PM and woah lots of misconceptions.
19:50 <@gmaxwell> adam3us: do you like my attack?
19:51 < adam3us> gmaxwell: yeah dont worry.  it was him creating the flame war.
19:52 <@gmaxwell> Is there any client that has a "message" field that autosubmits the message to bc.i?
19:53 <@gmaxwell> guy in PM is telling me that his desktop client has a "message" field that he thought showed up on bc.i.
19:53 < BlueMatt> probably, but dont know which
19:53 < BlueMatt> probably like the bc.i desktop client
19:53 < BlueMatt> "my browser is my desktop!"
19:55 < adam3us> gmaxwell: your attack, IECS R=rPQ, k1||k2=KDF(R), send R.x, c=E(k,m), MAC(k2,c); but i take it he used ctr mode for AES for E
19:55 < adam3us> gmaxwell: oops R=rQ rather
19:56 <@gmaxwell> Yup. he used counter mode and a 64 bit MAC.
19:56 <@gmaxwell> (at first I thought he used a 32 bit MAC and I was going to post a demonstration, alas... by random chance it wasn't quite that weak)
19:58 < adam3us> gmaxwell: actually that was also was wrong R=rQ, k1||k2=KDF(R) but send S.x from S=rG, c=E(k,m), MAC(k2,c) .. thats better
20:03 < adam3us> gmaxwell: ok so then you send S.x, c'=0, m=counter, and increase counter until it passes the mac.  consequently you get c=p xor E(k1,ctr0) and c'=p' xor E(k1,ctr0) and therefore c xor c' = p xor p'; and you know p' because the oracle told you so p = c xor c' xor p'.  qed :) nice
20:09 < adam3us> gmaxwell: btw i presume you are aware of http://eprint.iacr.org/2011/615.pdf because you mentioned the RSA problem, they provide a security argument for shared-key ECIES & ECDSA though unless there is some burning reason to reuse keys like you said that is a generically bad idea
20:09 < adam3us> gmaxwell: (we may even have discussed that paper here... i forget)
20:11 <@gmaxwell> Ah, I didn't recall any argument for shared-key ECIES & ECDSA... I didn't even look for one, because considering the state state of security proofs for ECDSA I didn't expect to find any.
20:11 <@gmaxwell> I don't think it's pratically insecure of course, but ... I was just pointing it out as a generally good pratice.
20:14 < adam3us> gmaxwell: agreed.  i would be worried about that argument and any assumptions it makes; sometimes proofs are artificial.  it seems inherently dangerous/fragile inviting people to ask you to answer challenges involving the same d as used in ECDSA - we know how fragile ECDSA is already without deterministic DSA! wouldnt take much to push it over the edge, just single bit here and there
20:16 <@gmaxwell> yea, esp with a small mac potentially allowing you to use a decryption thing as a multiplication oracle of some sort. ... though the hash and AES certantly help.
20:16 <@gmaxwell> the guy is busy arguing with me about address reuse in private message now.
20:17 < BlueMatt> :(
20:17 < BlueMatt> bitcoin.org/bitcoin.pdf
20:17 <@gmaxwell> Already cited.
20:17 < adam3us> gmaxwell: well even just at the asymmetric level.  eg say you could get timing from mac failure vs success or something.
20:17 < BlueMatt> iirc there's a section on that...
20:17 <@gmaxwell> Section 10. It's like a keyboard reflex.
20:17 < BlueMatt> heh
20:19 < adam3us> gmaxwell: u know on sci.crypt there was this annoying guy very young, school kid; some of the regulars clubbed together and sent him some crypto books, evidently he read them and eventually wrote a quite well regarded crypto library and got crypto employment if i recall.  http://libtom.org
20:20 <@gmaxwell> Yea, I read sci.crypt religiously throught the 90s.
20:21 <@gmaxwell> endless "I have made an ultimately secure cipher because none of you can break it!"
20:22 < adam3us> gmaxwell: sometimes noob status + enthusiasm leads somewhere :)  altoz tendency to /ignore forum handles not giving criticism in the way he like might not help his learning curve tho!
20:22 <@gmaxwell> yea, well, I've been responding to the guy. but ouch.
20:23 <@gmaxwell> lots of earnest enthusiasm, but also layered cluelessness. :) He seems to respect me (the fool!) so at least my conversation with him is having forward progress.
20:24 < BlueMatt> hey, I havent failed out of bitcoin yet (despite repeated efforts), so maybe he can prove useful :p
20:24 < BlueMatt> too
20:26 < adam3us> gmaxwell: the sci.crypt ones i enjoyed most were the new factoring methods :) but yes the "i challenge you to break my new cipher" were endlessly amusing also
20:30 < andytoshi> gmaxwell, adam3us: those factoring posts were still happening as of 3-4 years ago..
20:30 < andytoshi> also thx gmaxwell for posting your break, i'll check it out
20:38 < andytoshi> gmaxwell: on https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29 it says
20:38 < andytoshi> By now, CTR mode is widely accepted, and problems resulting from the input function are recognized as a weakness of the underlying block cipher instead of the CTR mode.[18]
20:39 < andytoshi> i read that to suggest that altoz was safe from attacks such as yours
20:39 <@gmaxwell> ha ha
20:39 < andytoshi> which obtain a ciphertext which can just be xor'd with the desired message
20:39 < andytoshi> (not that i would go implementing such a system based on 30 seconds of wikipeiaing)
20:40 <@gmaxwell> nah, thats just what countermode does, turns a nice pretty blockcipher into a stupid stream cipher. :P
20:40 <@gmaxwell> I am personally not a fan of CTR mode. It is widely used and respected, and you can certantly get yourself into trouble with blockcipher modes too.
20:40 < andytoshi> huh, that's what it looked like to me
20:40 < andytoshi> but "one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier" suggested i was being naive
20:40 < adam3us> gmaxwell: i reckon some of nsa $250m proto sabotage budget went into touting ctr mode... fragile & dangerous
20:40 <@gmaxwell> But this case is a nice example of how CTR mode can contribute to a cryptosystem being brittle.
20:41 < andytoshi> cool, i'll definitely work through your attack to make sure i know what's going on
20:41 < andytoshi> but my next flight is boarding, i gtg for now
20:41 <@gmaxwell> adam3us: okay, I feel better to hear you say that. I _think_ these sorts of things, but I try to not say them. :P
20:41 < adam3us> andytoshi: scroll up i did the math
20:42 < adam3us> gmaxwell: ctr mode seems like the dsa of cipher modes - inexplicably optimized for fragility
20:43 <@gmaxwell> well I know a lot of people (esp hardware people) just really would prefer stream ciphers.
20:43 < maaku> adam3us: in what way?
20:43 <@gmaxwell> GCM's popularity surprises me.
20:44 <@gmaxwell> maaku: fails totally completely to key/iv reuse and any amount of known plaintext.
20:56 < adam3us> gmaxwell: exactly any single reuse breaks it wide open; and there is no clear in-standard defined way to robustly avoid reuse so everyone does their own crappy time, counter, guid iv thing with semi public input or influencable input; similar to dsa, even the original dsa specified rng had enough bias that bleichenbaker figure out how to recover the private key in 1mil msgs
21:04 <@gmaxwell> Did a matonis or someone write some article extolling "DAC" lately, IRC seems to be getting flooded with jabber about them?
21:04 < Luke-Jr> DAC?
21:05 < jgarzik> gmaxwell, Vitalik is writing software for it as part of Dark Helmet^WWallet
21:06 < jgarzik> gmaxwell, Bitcoin Magazine did a series of articles, and Jerry Brito recently wrote http://reason.com/archives/2013/12/16/the-coming-robotic-world
21:07 < Luke-Jr> LOL @ Dark Helmet ref
21:07 < Luke-Jr> jgarzik: poke, never got a response on Fedora UNIX group for USB devices :P
21:08 < adam3us> jgarzik, gmaxwell: i think its more useful to call it a self-funding bot
21:09 < pigeons> DAC is the term protoshares/bitshares is using to mean "future app that will make our altcoin useful"
21:09 < adam3us> though i suppose they are hypothesizing about share-holder votes so there could be human owners; i think its more fun for a money making bot to go rent its own VPS with its own profit and own itself (right up until it hacked and loses its bitcoin stash:)
21:10 < Luke-Jr> wasn't it bitshares' guy who was recently proposing a license that forbids any usage of software by anyone who consents to copyright law? -.-
21:10 < adam3us> pigeons: yeah i saw DAC on invictus site, some of their rhetoric was cringe worthy
21:10 < jgarzik> DAC = Distributed Autonomous Corporation, AFAIK, which does not necessarily equal autonomous agent
21:10 < jgarzik> Some people appear to be using the term simply for an extranational / virtual corporation
21:10 < adam3us> jgarzik: this is true
21:11 < warren> Luke-Jr: to enforce that license you need to enforce copyright, rendering yourself unable to use your own software?
21:11 < Luke-Jr> warren: you don't need a license to use your own software :?
21:11 < Luke-Jr> :/
21:12 < adam3us> the alt story: step1. make useless alt; step2. make up some BS buzz about why its cool; step3 premine/postmine the heck out of it; step4 profit.
21:12 < warren> well, the point is you need copyright to enforce such a license
21:13 < adam3us> corollary to alt story: screw up just about every param choice, mining function choice that you possibly can; and yet inexplicably still profit (protoshares!)
21:13 <@gmaxwell> ::sigh:: "Another point of evidence on address reuse is the popularity of vanity addresses. Are you suggesting people spend hours, sometimes days searching for an address only to use them once? I somehow find that unlikely."
21:13 <@gmaxwell> adam3us: thats basically the story of all altcoins.
21:15 < jgarzik> sadly true
21:15 <@gmaxwell> I mean, even freicon bubbled up to 0.0005 BTC per FRC and its supposted to be inflationary and not go through these speculative bubbles! :P
21:15 < adam3us> ***adam3us wants to kill all alts
21:15 < jgarzik> I like the proof-of-$somethingelse experiments
21:16 < jgarzik> just fiddling with algo choice or params is droll
21:16 <@gmaxwell> well, I'm certantly more happy when they write more than 0 lines of code with their alt.
21:16  * Luke-Jr likewise
21:16 <@gmaxwell> I thought someone was going to do an altcoin maker?
21:16 < Luke-Jr> I especially like that Freicoin also tries to deter scammers from abusing their alt
21:16 < adam3us> ah that reminds me, i was thinking there might be a way to let people play with alts without wasting electricity
21:16 <@gmaxwell> adam3us: regtest? merged mining?
21:17 < jgarzik> lawcoin: relies on proof-of-wasted-paperwork-filed-at-city-hall
21:17 < adam3us> or at least it would be interesting if a way could be found :) eg just some central trusted server would do, like coinwarz
21:17 <@gmaxwell> jgarzik: I had a few fun ideas like that, ... but SSL doesn't have any way to sign the traffic through it.
21:17 <@gmaxwell> There is that AWS thing for SSL quasi-non-repudiation though.
21:18 <@gmaxwell> Proof-of-frivilous-litigation: You must file a nussance lawsuit against pirate40 to mine a block.
21:18 < adam3us> gmaxwell: yes so general framework for merge mining plus dont waste cpu.  pay some virtual VPS and the central server allocates you some corresponding alts, proceeds go to something useful
21:18 < jgarzik> precisely
21:19 <@gmaxwell> I realized the existing merged mining code would only take a few lines of code to turn into a proof-of-attack against the chain its merging with.
21:20 < jgarzik> I do something wonder what the world would look like, if "bitcoin1" remained at 1MB etc. forever, and "bitcoin2" was layered on top of that as a day-to-day transactional currency, used in tandem with the asset-store bitcoin1.
21:20 < jgarzik> *sometimes
21:20 < adam3us> i mean these alts are mostly just a game, and have no non-speculative transactions; so they'd just as well own up to that reality.
21:21 < adam3us> jgarzik: did u see the idea BlueMatt & gmaxwell were talking about yesterday... a 1:1 peg feature, a better way to do bitcoin-staging
21:21 < jgarzik> adam3us, interesting, though not quite what I was thinking
21:21 <@gmaxwell> jgarzik: I dunno if you saw the sub-chain discussion from here with bluematt 24 hours ago.  Sounds like we could pretty 'easily' with some changes (perhaps just softforking) have a sub-coin where you could move bitcoin to and from the subcoin.
21:21 < adam3us> jgarzik: then we could make a bitcoin2 that safely allowed coins to be move between bitcoin1 & bitcoin2.  (the protection is only coins moved into it can be moved back so there is no security risk for people not participating)
21:21 < jgarzik> I just openly wonder about keeping 1MB forever
21:22 < jgarzik> My statement has always been "it will probably change"... notably not stating "it should change" of which I'm not yet convinced
21:22 < jgarzik> and then logically extend from there
21:22 <@gmaxwell> one of the complicating issues is that some of these ideas— like the subchain stuff really only work if Bitcoin1 remains reasonable cheap to validate, because all the sub-things below it must commonly validate bitcoin1 (but not each other)
21:23 < adam3us> jgarzik: i think the 1:1 peg is he best idea i heard in quite a while in bitcoin land.  with that we could move ahead and develop the queued ideas and fixes without risking bitcoin1 funds
21:23 < adam3us> jgarzik: and yet avoiding the alt-coin trap and with no market / arbitrage cost/risk and no security risk to bitcoin1 funds
21:23 <@gmaxwell> adam3us: it's not even a new idea really, we've know for a long time that it was possible to do something like this, subject to some limitations. As I mentioned before script is _almost_ powerful enough to express it directly.
21:24 < jgarzik> hmm
21:25 < jgarzik> bah, baby bedtime, bbiah
21:25 <@gmaxwell> adam3us: the point you make about -staging is interesting though, I know you'd proposed 1way for staging, but I think one-way is not so interesting, the point that subchains would be useful for playing with new cryptocoin ideas is quite interesting.
21:27 < adam3us> gmaxwell: too much idea backlog to trace as close as i got was the 1-way peg; i was thinking a) cant change bitcoin because thats the problem the peg is trying to solve; and b) 1:1 peg while desirable requires btc change; and c) i didnt go further
21:27 <@gmaxwell> sort of interesting to consider that maybe in the future the bitcoin network goes away and its replaced with ... another bitcoin network.. and it all happens in a fully consentual way with people just migrating their coins into another system.
21:27 <@gmaxwell> adam3us: well I think we can make the one change to rule them all.
21:27 <@gmaxwell> ... the more useful things a change does the more justifyable the effort.
21:28 < adam3us> gmaxwell: yes i like it; i like that its seemingly possible with a focused change to do this, and this does seem like the one change to rule them all which is why i was interested in the staging idea - i think it solves a real-world dev problem
21:29 < adam3us> gmaxwell: forking things could be done on this network; maybe you can even move coins out, upgrade, move them back; or roll out new forking versions with the analogous coin move protocol
21:29 < adam3us> gmaxwell: all without risking bitcion n-1 funds
21:30 < adam3us> gmaxwell: and also version1.0 could reject further non-defect changes and focus on being a value store afterwards
21:31 < adam3us> gmaxwell: that could be the stable IP protocol on which payment internet is built (or other stupid / non-transferring analogies people like to make)
21:32 < adam3us> gmaxwell: (mostly they actually mean "yay were going to flood bitcoin scarce broadcast channel as if its an IP datagram network")
21:33 < adam3us> and eg people doing well considered script changes would have somewhere to do them outside of alt-space (eg like freimarket extensions)
21:35 < BlueMatt> gmaxwell: the idea of a 1:1 peg is that bitcoin1 could remain easy to verify forever since txn just happen on bitcoinN
21:36 < adam3us> BlueMatt: and reward mining could happen only on bitcoin1
21:36 < BlueMatt> yup
21:36 < BlueMatt> (eg 1MB blocks forever on bitcoin1...)
21:38 <@gmaxwell> BlueMatt: moreover, that kind of design strongly favors bitcoin1 being fairly small blocked, simply because you want bitcoin* also verifying it (so at least security in one direction was _full_, and so if a false proof shows up in the other direction the bitcoinN nodes can take action).
21:38 <@gmaxwell> this has long been one of my concerns with cranking the block size— that once it happens some scalablity solutions are harder.
21:39 <@gmaxwell> it's also more egalitarian— developers of your coin turning down your awesome automatic stolen coin recovery feature?  Okay fine, create a new altcoin, and migrate your coins into it.
21:40 <@gmaxwell> it could even go in hierarchies. Say that your "alt system" is too unblockchain like to be directly bound into bitcoin with this one-change-to-rule-them-all feature.
21:41 < BlueMatt> yup
21:41 <@gmaxwell> thats alright, you migrate your coins to bitcoin3 which has SNARK scriptpubkeys, and with those you can bind your wacky offchain system.
21:41 < BlueMatt> yup
21:44 <@gmaxwell> you could, if you wanted, even expirement with different economic formulas. You can't create bitcoin out of thin air, but you could tax inbound, store, and/or outbound coins.
21:45 <@gmaxwell> oh man, this guy won't give up.
21:45 <@gmaxwell> "'m not certain it's very much discouraged. I've been reading here and /r/bitcoin actively for the past 10 months and this is the first time I'm hearing about the importance of using addresses only once."
21:45 < BlueMatt> wtf
21:46 < BlueMatt> this is the point where you say "I'm sorry, but you're wrong, You should go ask people who actually know (ie work on bitcoin as devs) and give up reading idiots all day"
21:46 < adam3us> maybe the bitcoin fungibility thread might get the msg over (or not)
21:47 <@gmaxwell> Well, I'm not talking with him for the sake of arguing. I don't care about right and wrong, he is in my petri dish now.
21:47 < adam3us> people with that level of understanding are dangerous to be writing code others might use
21:47 < adam3us> brainwallet.org level
21:47 <@gmaxwell> He seems to be especially sour about avoiding reuse, I think because he'd been building an empire in his mind based on having identity services around static addresses.
21:48 <@gmaxwell> So I'm not sure how much is due to that vs the popularity of that misunderstanding in the population, I suspect its a bit of both.
21:48 <@gmaxwell> he was responding to me writing this:
21:49 <@gmaxwell> I hope I didn't come across as suggesting it never happens. Only that its problematic, discouraged, and not done by many (esp. those who know better, or whos livelihoods depend on using Bitcoin well).  Because of the rapid growth the overwhelming majority of people you interact with in Bitcoin space are very new to Bitcoin... and pick up bad habits like using "brainwallet" which sound appealing but often burn them with subtle ...
21:49 <@gmaxwell> ... complications.
21:49 <@gmaxwell> ...
21:49 <@gmaxwell> he continued in his response: " I have friends that have been using bitcoin for years and they use the same address because it's very convenient for peer-to-peer transmission (you don't have to ask a new one all the time). Heck, I'm working on a project (not this one) right now and that's reusing addresses in certain cases.
21:49 <@gmaxwell> If this is as important as you've made it seem, this needs to be a lot more prominently communicated to the general public, explaining all the risks of not changing addresses with every outgoing transaction."
21:49 <@gmaxwell> which I think is probably fair enough.
21:50 <@gmaxwell> It's not communicated well, especially since there is some wallet software that basically forces reuse.
21:50 <@gmaxwell> (e.g. multibit)
21:50 < BlueMatt> we need a much, much, much better bitcoin intro for devs
21:50 < BlueMatt> and bitcoin wallet on android :(
21:51 <@gmaxwell> We're also failing to use the existing software as an educational tool. There really should be some warning emblem that comes up on transactions that reuse addresses.
21:52  * BlueMatt desperately wants to have a good bitcoin library that provides nice apis to encourage proper use
21:52 < BlueMatt> but, sadly, that requires lots of effort...
21:53 < adam3us> gmaxwell: i think Luke-Jr is on the right track with eligius policy there ;) just need wider adoption of his patch "why is my transaction not completing"... well did u read the doco? no address reuse
21:53 <@gmaxwell> well, there is A bitcoin library, bitcoinj but basically um.. all (?!) its users are not so good on the best practices front
21:53 < Luke-Jr> there's also libbitcoin
21:53 <@gmaxwell> I don't think you can both provide enough flexibility to really be a toolbox without making it easy to abuse.
21:54 < Luke-Jr> gmaxwell: well, bitcoinj goes very far in making abuse easy
21:54 < BlueMatt> gmaxwell: even bitcoinj fails to get it right by far
21:55 < BlueMatt> (hell, all the apps that use it reuse the hell out of addresses)
21:55 < BlueMatt> gmaxwell: easy to abuse != easy to use right and possible to abuse
21:55 <@gmaxwell> okay, thats a point.
21:55 < BlueMatt> Luke-Jr: does libbitcoin do an actually good job here?
21:56 < Luke-Jr> BlueMatt: not sure
21:56 < BlueMatt> oh, well if we're just listing bitcoin libraries...there's millions
21:56 < Luke-Jr> there are?
21:56 < BlueMatt> theres the one in go, theres ones (multiple) in python
21:56 < BlueMatt> theres another one in java
21:56 <@gmaxwell> well if you limit them to c-callable...
21:57 < BlueMatt> theres bitcoin js theres bitcoin-ruby.....
21:57 < BlueMatt> gmaxwell: meh, you can call pretty much all of those from c with the right wrappers
21:57 < adam3us> i kind of like the public public derivation method (sender multiply Q by r and encrypt r for recipient, plus some bloom filter hint to reduce that below full node trial decrpt all payments) for this reason - safe to reuse because the uncompressed address is randomized during payment
22:26 < adam3us> jgarzik: proof of $somethingelse... doesnt proof of stake give a reward bias to those with lots of btc?
22:29 < adam3us> jgarzik: interesting result for efficiency, and self-interest to not damage the network, but side-effect an ongoing mining advantage to large btc holders
23:06 < Luke-Jr> adam3us: only if subsidy is on those blocks..
23:06 < Luke-Jr> proof-of-stake without subsidy might be interesting
--- Log closed Thu Dec 19 00:00:08 2013