| 00:36:53 | jps_: | jps_ is now known as jps |
| 00:43:42 | kanzure_: | kanzure_ is now known as kanzure |
| 01:26:19 | kazcw1: | kazcw1 is now known as kazcw |
| 01:29:58 | gmaxwell: | * gmaxwell is super scared to look at the "bread wallet" code after its author suggested that malleability could be addressed via RFC6979 derandomized DSA. |
| 02:45:45 | wyager: | wyager has left #bitcoin-wizards |
| 03:44:33 | Eliel_: | is this the iphone wallet app? |
| 04:07:17 | andytoshi: | gmaxwell: can you even verify from the outside that the nonce was generated deterministically? |
| 04:07:40 | andytoshi: | (ignoring for the moment the complete inapplicability of the suggestion..) |
| 04:09:56 | justanotheruser: | justanotheruser is now known as justanotheruser- |
| 04:11:35 | andytoshi: | istm if you could then you'd have only one possible signature per key per message..which is a pretty heavy hammer but would in fact prevent ECDSA mutation |
| 06:40:38 | gmaxwell: | andytoshi: s/message/public-key/ |
| 06:41:36 | gmaxwell: | and indeed, you cannot tell how the nonce was generated, save some huge hammer like running your signer in a ZK-snark (or some not-invented-yet more efficient parallel for this task). |
| 06:42:32 | gmaxwell: | which is why it doesn't help. (frighteningly there was some POS proposal (implementation?) around NXT that though it was accomplishing ungrindable signatures this way…) |
| 06:42:55 | gmaxwell: | Seems like the "attackers will follow the procedure I've specified" thinking to me. |
| 06:44:39 | gmaxwell: | there are randomness free signatures— most hash based signatures, and pairing short signatures are randomness free... but for DSA you're SOL without rocket science. |
| 08:49:34 | fanquake_: | fanquake_ is now known as fanquake |
| 12:43:10 | christo: | distributed identity - anyone with strong thoughts? |
| 14:04:06 | jgarzik: | christo: Yes. Distributed identity: https://en.bitcoin.it/wiki/Identity_protocol_v1 |
| 14:37:35 | Aquent_: | Aquent_ is now known as Aquent |
| 15:10:16 | andytoshi: | gmaxwell: derandomized nonces would have to be different per message, the whole point is to prevent nonce reuse no? |
| 15:11:51 | andytoshi: | also judging by this fellow's recent email, i wonder if one of us should send him an email explaining ECDSA (e.g. `s` is not a curve point, taking it modulo the curve order will not "positive-ify" it, why both `s` and `-s` will validate with the same `r`...) |
| 15:14:30 | andytoshi: | oh...he's founder of a shitty app company...i'm not touching this...but anyone who likes dealing with those sorts of people is welcome to send him a friendly "stop writing crypto software" note |
| 15:20:02 | iddo: | andytoshi: derandomized nonce is basically hash(privkey,msg) so it's different per msg |
| 15:27:45 | sipa: | andytoshi: he is not talking about -s (mod n), but really about -s |
| 15:28:51 | sipa: | as in: DER encoded integers are signed, and encoding a negative number will make OpenSSL interpret it as 2^256 + x, which may validate |
| 15:29:25 | sipa: | which is nonstandard, as the numbers in a ECDSA signature should just always be nonnegative |
| 15:31:09 | andytoshi: | oh... weird |
| 15:31:23 | andytoshi: | is there no such thing as DER encoded unsigned integers? |
| 15:42:13 | sipa: | andytoshi: no |
| 15:42:22 | sipa: | there are byte arrays, though |
| 15:58:02 | Eliel_: | is there a reason to hash private key with the message to create the nonce rather than public key and the message for the nonce? |
| 15:59:18 | Eliel_: | if public key can be used there, then it becomes anyone can verify |
| 16:11:37 | sipa: | Eliel_: if you know the nonce, you can recover the privatekey |
| 16:12:13 | sipa: | that's why you cannot allow anyone to.verify you're using a deterministic scheme |
| 16:13:39 | Eliel_: | ok, so at most you can verify that the same message always gets the same signature if you have a hardware device you don't fully trust. |
| 16:14:02 | sipa: | yup |
| 16:14:39 | Eliel_: | which really doesn't prove much :/ |
| 18:56:47 | cym: | cym is now known as pen |
| 20:14:07 | gmaxwell: | andytoshi: they have to be per-message unless you want to turn it into a one show signature. |
| 20:14:42 | jps_: | jps_ is now known as jps |
| 20:14:59 | gmaxwell: | wow that email thread was unexpectedly positive. |
| 20:15:07 | gmaxwell: | "Thanks g.maxwell, your explanation of *why* you can't just generate k |
| 20:15:07 | gmaxwell: | in a way that the verifier can duplicate is really helpful. This also |
| 20:15:08 | gmaxwell: | servers as a great illustration why engineers should never try to |
| 20:15:08 | gmaxwell: | designing their own crypto protocols! I knew enough to know not try |
| 20:15:08 | gmaxwell: | that at least." |
| 20:15:50 | gmaxwell: | of course, this is also what I was thinking— but it's not a lesson you can normally teach. |
| 20:17:14 | andytoshi: | wow! i humbly rescind my earlier comments about "those sorts of people" :/ |
| 20:27:07 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 23:55:56 | opencryptoresear: | hi all, please check out www.opencryptoresearch.com if you've not already and let me know what you think. thanks to those who have already contributed. |
| 23:56:57 | opencryptoresear: | my apologies, it's www.opencryptoreview.com, forgot the name of my own site |