| 02:58:29 | home_jg: | home_jg is now known as jgarzik |
| 04:26:01 | phantomcircuit: | gmaxwell, blargh |
| 04:26:03 | phantomcircuit: | man fuck the people who made this pdu |
| 04:26:05 | phantomcircuit: | circuit 1/2/3 != phase a/b/c |
| 04:26:13 | phantomcircuit: | to balance the load you have to plugin to specific outlets |
| 04:26:15 | phantomcircuit: | what the fuck |
| 04:59:51 | tacotime_: | tacotime_ is now known as tt_away |
| 07:38:06 | firepacket: | firepacket is now known as Guest26356 |
| 12:34:24 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 13:33:02 | mike4: | mike4 is now known as c--O-O |
| 18:07:16 | qwertyoruiop: | qwertyoruiop is now known as BigBIitz |
| 18:07:24 | BigBIitz: | BigBIitz is now known as qwertyoruiop |
| 18:16:49 | diesel_: | diesel_ is now known as flotsamuel |
| 19:07:32 | andytoshi: | gmaxwell: on https://bitcointalk.org/index.php?topic=440572.0 (oleganza's first blindsig) attempt you pointed out that the signer can simply recognize r after the fact to see what he had signed |
| 19:07:50 | andytoshi: | this breaks oleganza's "oblivious escrow" usecase, but does it matter for normal blindsig applications? |
| 19:08:29 | oleganza: | andytoshi: usually r is unique to message |
| 19:08:30 | andytoshi: | even in the blind schnorr scheme http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html , the signer can find out after-the-fact what parameters he used to sign the original message |
| 19:09:23 | andytoshi: | oleganza: yeah, but you can't obtain a message from r until after the signature is published |
| 19:09:35 | andytoshi: | and by that point, it's too late for the sender to do any censorship or to have any liability |
| 19:09:45 | oleganza: | if signature is not published, then what's the use? |
| 19:09:57 | oleganza: | can you clarify the use case |
| 19:10:32 | oleganza: | to prevent censorship i can simply send my hash to the signer. It'll hide my message sufficiently. |
| 19:11:16 | andytoshi: | not necessarily, if the message has low entropy |
| 19:11:37 | oleganza: | * oleganza current mood: watching storm of Kiev's euromaidan http://www.youtube.com/watch?v=Y_LFrMcoEm4 |
| 19:11:42 | oleganza: | andytoshi: it gets too abstract too quickly :-) |
| 19:15:34 | andytoshi: | oleganza: see http://cryptography.wikia.com/wiki/Blind_signature for some applications |
| 19:15:46 | andytoshi: | say, if you are voting for one of four people then the hash does not protect you at all |
| 19:16:30 | andytoshi: | i think my above claim that matt green's blind signatures can be linked back to the signing session is a serious break actually |
| 19:16:38 | oleganza: | andytoshi: i see. But I started with ECDSA-compatible scheme to have something useful for Bitcoin |
| 19:18:13 | andytoshi: | oleganza: right, and there are definitely useful applications to bitcoin along the same lines as what's in that wikia article (using a trusted signer without making him liable) |
| 19:22:52 | andytoshi: | so, in the typical RSA blindsig example, what gets published is a valid signature H(m)^d, and obviously the signer can't determine any context from that. but both schnorr and ecdsa signatures have this extra nonce and it seems hard to actually blind the nonce so that the holder of the private key can't figure out how it was made |
| 19:23:19 | andytoshi: | your initial "don't even blind r" proposal fails this, the complicated protocol I emailed you fails this, the schnorr sig scheme on matt green's blog fails this... |
| 19:26:43 | andytoshi: | oleganza: so when i get some i'll help you clean up your original proposal, since i'm pretty sure that works exactly as intended. for any extensions like this i'd like one of the crypto guys here to clarify the above concerns for me |
| 19:26:56 | andytoshi: | s/extensions/variations/ ;) |
| 19:27:42 | oleganza: | andytoshi: thanks :) |
| 19:33:22 | maaku: | andytoshi: wait, are you saying that with matt green's protocol a coinjoin facilitator would be able to figure out after the fact which blind-signed output is which? |
| 19:35:58 | andytoshi: | maaku: yes, if he kept track of the parameters used every time he blindsigned |
| 19:36:20 | andytoshi: | he'd have to loop through every parameter-set and check each one for a match, it is not an efficient way to identify signatures.. |
| 19:38:40 | maaku: | andytoshi: well the facilitator isn't a signing oracle |
| 19:38:52 | maaku: | for N mixed outputs, he only makes N signatures |
| 19:39:19 | maaku: | that is a serious break, and pretty much defeats the point of blind signing cj outputs |
| 19:39:25 | andytoshi: | yeah, wow |
| 19:39:43 | andytoshi: | maaku: the algo on that site has two secret parameters a,b that only the output owner should know. but a is the difference between the blinded and unblinded signatures, while b is the difference between the message hash and the 'fake message hash' given to the signer |
| 19:39:59 | maaku: | is oleganza's new/old protocol immune to this? |
| 19:40:08 | gmaxwell: | andytoshi: hm? in blind schnorr you rerandomize r too. |
| 19:40:24 | andytoshi: | gmaxwell: you 'rerandomize' it as r' = r*(g^a)*(y^b) mod p |
| 19:40:29 | oleganza: | what's the point of blind singing coinjoin txs? |
| 19:40:56 | gmaxwell: | andytoshi: oh so the signer could recover the randomization parameters if he sees the signature. |
| 19:41:06 | gmaxwell: | yea, thats a break of blind singing in general. |
| 19:41:12 | maaku: | oleganza: so no one, not even the signing oracle / facilitator can determine which inputs match to which outputs |
| 19:41:13 | andytoshi: | maaku: yeah, i believe oleganza's new protocol is what we want. and it even works with ecdsa :) |
| 19:41:31 | gmaxwell: | The original purpose of blind signing is to mask the signed object from even the signer (chaum cash!) |
| 19:43:26 | maaku: | well, it might work for chaum cash because you only reveal the signature when you redeem the token, right? |
| 19:43:48 | maaku: | but it wouldn't work for cj-like protocols, or brands credentials |
| 19:43:53 | gmaxwell: | maaku: but the bank needs to be unable to link the signature to their prior signing incident. |
| 19:44:00 | maaku: | ah yeah |
| 19:44:13 | andytoshi: | well, the bank could in principle determine the first and last owners, but nobody in between.. |
| 19:44:23 | gmaxwell: | if you just want to mask what is being signed you don't need blind signing, you just need a nonce in your message. |
| 19:44:33 | gmaxwell: | andytoshi: ... |
| 19:44:52 | gmaxwell: | andytoshi: the whole idea in chaum cash is that every trade goes via the bank to prevent double spending. |
| 19:44:58 | andytoshi: | oh :} |
| 19:45:08 | andytoshi: | right |
| 19:46:53 | andytoshi: | oleganza: did i explain how coinjoin blindsigning works in one of my emails to you? i don't remember.. and imo it's pretty nonobvious and you won't get it just from the conversation here |
| 19:48:12 | andytoshi: | yeah, looks like i did |
| 19:50:10 | gmaxwell: | andytoshi: it would be pretty 0_o if people have been going around with non-blind blindsinging techniques. |
| 19:51:09 | andytoshi: | gmaxwell: yeah, i'm actually a bit concerned about this. i should tell somebody about this but i don't know who |
| 19:51:12 | andytoshi: | maybe i'll email matt green.. |
| 19:51:25 | nsh: | what's the concern? |
| 19:51:27 | andytoshi: | or just leave a comment on that blog post, i'm sure someone will notice :P |
| 19:51:36 | nsh: | is there a flaw in mattgreen's blinding scheme? |
| 19:51:37 | gmaxwell: | andytoshi: you should probably try out compromising it and send a sage notebook. |
| 19:51:55 | andytoshi: | ooh, i like that. that'll be my weekend project |
| 19:52:09 | andytoshi: | nsh: i believe so, yes |
| 19:52:11 | gmaxwell: | it's really easy to sign at the prompt in sage... |
| 19:52:23 | nsh: | interesting. *reads buffer* |
| 19:52:32 | andytoshi: | oh, i didn't realize sage had those functions |
| 19:53:02 | gmaxwell: | yea... |
| 19:53:02 | gmaxwell: | sage: F = FiniteField (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F) |
| 19:53:05 | gmaxwell: | sage: C = EllipticCurve ([F (0), F (7)]) |
| 19:53:43 | nsh: | . o O ( it'd be nice if -- using Sage or something -- we could have some public scratchpads/notebooks of crypto[currency] investigations and elucidations ) |
| 19:54:17 | gmaxwell: | sage has a whole web-ui. |
| 19:54:25 | nsh: | * nsh nods |
| 19:57:10 | gmaxwell: | andytoshi: so you can just pocket calculator all this stuff. |
| 19:57:39 | maaku: | andytoshi: try it out, then write it up. this is too big to give up to a comment on a blog ;) |
| 19:58:41 | gmaxwell: | Finding weaknesses in things is the only concrete indicator that you're doing real cryptographic work in any case. Otherwise perhaps its all navel-gazing. |
| 20:01:40 | nsh: | (and if you gaze at a navel with a high enough frequency, it can't even evolve...) |
| 20:02:16 | nsh: | ((Zeno)) |
| 20:16:53 | andytoshi: | sagenb says 'public worksheets' currently disabled. can you guys give me some sage usernames so i can share this? |
| 20:18:17 | andytoshi: | sagenb says 'public worksheets currently disabled', wants sagenb usernames to share with specific people |
| 20:27:44 | andytoshi: | or i will post an uncropped screenshot for you to read http://wpsoftware.net/andrew/secrets/exploit.png |
| 20:32:11 | nsh: | are you unable to share worksheets because of... silly reasons? |
| 20:32:29 | nsh: | guess so :/ |
| 20:34:15 | andytoshi: | one sec, i'll just pastebin the code |
| 20:39:02 | andytoshi: | http://0bin.net/paste/MrGNUVUxr0DR44Nu#6tGBRjT1+FPADOfOhpuBHBFtfCMxelinPFh+0GWJuUg= |
| 21:30:17 | andytoshi: | i sent a note to matt green about it |
| 21:31:53 | nsh: | could you annotate the 0bin post with it? (or at least, to the extent that there are bits that add context/elaboration, as opposed to any private contents) |
| 21:32:10 | nsh: | (you can't annotate posts on 0bin, sorry) |
| 21:34:40 | andytoshi: | nsh: sure, i can post the whole email to 0bin, one sec |
| 21:34:59 | nsh: | ty |
| 21:36:25 | andytoshi: | http://0bin.net/paste/WSj45yA0+E1r2jls#GuwWRW/7Uw2Goakt6i0Oq55ZY/2r9/0dpdvs84/VT/w= i'm not sure that this says any more than what's been mentioned here tho |
| 21:37:44 | nsh: | right. i tend to perpetually read diagonally though so sometimes there's utility in redundancy |
| 21:43:20 | tt_away: | tt_away is now known as tacotime_ |
| 22:04:38 | andytoshi: | cool, he got back to me and said i'm wrong. |
| 22:05:00 | nsh: | interesting |
| 22:05:05 | andytoshi: | my equation that the attacker checks to see if he got the right (a, b) parameters -- it always passes |
| 22:07:39 | andytoshi: | o.O it's really simple algebra but it's still surprising, i had to read it three times |
| 22:08:39 | andytoshi: | http://0bin.net/paste/8kE0Ak3D39ubpt1U#hIGPJyFjfgtDvHupTnwHdGBJv7KSZv6XX6koL2C/hCU= |
| 22:08:59 | andytoshi: | (sadly, he did not write all that for me, somebody else came up with my attack so he just copied the response to me) |
| 22:11:39 | gmaxwell: | andytoshi: yea, I wondered if that would be the case— that you'll always get a a/b value that works for any transaction. |
| 22:11:50 | gmaxwell: | but a quite glance surprised me due to the a*gen in the equation. |
| 22:13:00 | andytoshi: | the end of his message was a plea for tor applications, which -wizards may be interested in: |
| 22:13:02 | andytoshi: | NOW, moving on to applications ---- which interests me a lot. What are you planning to do with these blind signatures? We have some ideas related to decentralized anonymous credentials and we've been dying for a Tor related application. Here's our paper. Can you think of one? |
| 22:13:03 | andytoshi: | https://eprint.iacr.org/2013/622.pdf |
| 22:13:05 | andytoshi: | We were thinking about doing node bandwidth controls at the Tor exit nodes, for example, without the need for a central server. Any thoughts you have would be terrific. Maybe we could write a paper about it together? |
| 22:13:24 | andytoshi: | gmaxwell: yeah, ditto |
| 23:09:26 | pigeons: | pigeons is now known as Guest77360 |
| 23:17:02 | K1773R_: | K1773R_ is now known as K1773R |
| 23:50:23 | licnep__: | licnep__ is now known as licnep |
| 23:53:16 | gmaxwell: | Anyone want to see an example of gox multi-payment? I think I found one: https://blockchain.info/address/1HXwfTJZV5D1kAN75L7fjbH22drBEqS2K5 |
| 23:53:54 | sipa: | ? |
| 23:54:23 | gmaxwell: | First I identified mtgox controlled keys— by taking a list of known mtgox transactions and assuming common signing means common ownership. |
| 23:54:28 | gmaxwell: | This resulted in some 580k keys. |
| 23:55:18 | gmaxwell: | I then started scanning looking for cases where coins paid to those mtgox addresses were used to the same address and value multiple times. |
| 23:55:36 | gmaxwell: | They're further identified by paying a tx fee of 0.001 which is characteristic of mtgox. |
| 23:56:08 | gmaxwell: | interestingly, I'm not finding very many of these, and not any with high value yet. |
| 23:56:52 | sipa: | what do you mean by multi-payment? |
| 23:57:09 | gmaxwell: | paying the user multiple times when it should have paid once. |
| 23:57:17 | sipa: | ah |
| 23:57:34 | sipa: | right, of course |
| 23:58:14 | nsh: | nice work gmaxwell! what are the chances anyone from gox will comment positively on the results, i wonder... |
| 23:58:23 | gmaxwell: | 1HXwfTJZV5D1kAN75L7fjbH22drBEqS2K5 is paid 0.5037 and then again in 48 hours and then again in about 8 hours. Each time paying 0.001 fee. |
| 23:58:30 | gmaxwell: | I assume they already know about all these cases. |
| 23:58:58 | nsh: | well, whether they might corroborate the results or methodology |
| 23:59:10 | nsh: | i'm sure they have their own investigation, but PR and transparency are not always aligned |