00:36:53jps_:jps_ is now known as jps
00:43:42kanzure_:kanzure_ is now known as kanzure
01:26:19kazcw1:kazcw1 is now known as kazcw
01:29:58gmaxwell:* 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:45wyager:wyager has left #bitcoin-wizards
03:44:33Eliel_:is this the iphone wallet app?
04:07:17andytoshi:gmaxwell: can you even verify from the outside that the nonce was generated deterministically?
04:07:40andytoshi:(ignoring for the moment the complete inapplicability of the suggestion..)
04:09:56justanotheruser:justanotheruser is now known as justanotheruser-
04:11:35andytoshi: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:38gmaxwell:andytoshi: s/message/public-key/
06:41:36gmaxwell: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:32gmaxwell: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:55gmaxwell:Seems like the "attackers will follow the procedure I've specified" thinking to me.
06:44:39gmaxwell: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:34fanquake_:fanquake_ is now known as fanquake
12:43:10christo:distributed identity - anyone with strong thoughts?
14:04:06jgarzik:christo: Yes. Distributed identity: https://en.bitcoin.it/wiki/Identity_protocol_v1
14:37:35Aquent_:Aquent_ is now known as Aquent
15:10:16andytoshi:gmaxwell: derandomized nonces would have to be different per message, the whole point is to prevent nonce reuse no?
15:11:51andytoshi: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:30andytoshi: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:02iddo:andytoshi: derandomized nonce is basically hash(privkey,msg) so it's different per msg
15:27:45sipa:andytoshi: he is not talking about -s (mod n), but really about -s
15:28:51sipa: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:25sipa:which is nonstandard, as the numbers in a ECDSA signature should just always be nonnegative
15:31:09andytoshi:oh... weird
15:31:23andytoshi:is there no such thing as DER encoded unsigned integers?
15:42:13sipa:andytoshi: no
15:42:22sipa:there are byte arrays, though
15:58:02Eliel_: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:18Eliel_:if public key can be used there, then it becomes anyone can verify
16:11:37sipa:Eliel_: if you know the nonce, you can recover the privatekey
16:12:13sipa:that's why you cannot allow anyone to.verify you're using a deterministic scheme
16:13:39Eliel_: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:39Eliel_:which really doesn't prove much :/
18:56:47cym:cym is now known as pen
20:14:07gmaxwell:andytoshi: they have to be per-message unless you want to turn it into a one show signature.
20:14:42jps_:jps_ is now known as jps
20:14:59gmaxwell:wow that email thread was unexpectedly positive.
20:15:07gmaxwell:"Thanks g.maxwell, your explanation of *why* you can't just generate k
20:15:07gmaxwell:in a way that the verifier can duplicate is really helpful. This also
20:15:08gmaxwell:servers as a great illustration why engineers should never try to
20:15:08gmaxwell:designing their own crypto protocols! I knew enough to know not try
20:15:08gmaxwell:that at least."
20:15:50gmaxwell:of course, this is also what I was thinking— but it's not a lesson you can normally teach.
20:17:14andytoshi:wow! i humbly rescind my earlier comments about "those sorts of people" :/
20:27:07justanot1eruser:justanot1eruser is now known as justanotheruser
23:55:56opencryptoresear: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:57opencryptoresear:my apologies, it's www.opencryptoreview.com, forgot the name of my own site