--- Log opened Fri Nov 09 00:00:16 2018
00:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
00:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
01:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
01:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
01:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
01:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
01:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
01:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
01:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
01:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
02:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds]
02:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
02:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
02:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
02:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
02:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
03:48 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
03:49 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1
04:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
04:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
04:24 -!- ken2812221 [~ken281222@110.50.135.219] has joined #secp256k1
04:34 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
04:34 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
10:28 < andytoshi> what do you guys think about rejecting 0 messages in ecdsa_verify?
10:28 < andytoshi> i guess this would go against the ECDSA spec .. but otoh these signatures are trivially forgeable and if you find yourself validating one your system is probably broken
10:37 < gmaxwell> I think I've suggested that idea before, or at least thought it.
10:37 < sipa> in theory it would be a non-observable difference, as that value is supposed to be a hash in true ECDSA
10:38 < gmaxwell> An alternative would be to change the interface so that it takes a hasher callback, to force you to hash the message.
10:38 < sipa> but in bitcoin we're already not strictly followed ECDSA, due to the sighash_single bug
10:39 < gmaxwell> if someone can compute a preimage of zero it would make for an observable difference.
10:39 < sipa> i guess my "theory" implies modeling SHA256 as a RO :)
10:41 < gmaxwell> In any case, I'm vaguely in support. We also reject high-S...
10:42 < sipa> it's a bit scary... if it ever matters, i'm not sure that a chain fork is better than theft
10:42 < gmaxwell> Bcash recently tried to add a vulnerablity related to this. (their CHECKSIGFROMSTACK opcode originally didn't hash)
10:43 < sipa> and we could bypass it in bitcoin core using a wrapper, but then what benefit is there
10:43 < nsh> how could a chain fork result? (sorry if stupid q)
10:44 < sipa> nsh: only if there is a bug and somehow a signature on the message 0 is verified
10:44 < sipa> which, as best as we know, isn't possible
10:45 < nsh> because of the preimage of 0 msg being comp. difficult to find?
10:45 < gmaxwell> nsh: if someone manages to make a transaction with a message hash of 0, e.g. by finding a sha2^2 preimage for the 0 hash, if the verify rejects these hashes, then the network would fork.
10:45 < gmaxwell> nsh: right
10:45  * nsh nods
10:45 < nsh> ty
10:46 < sipa> nsh: well, or because there is a bug in the code (like the sighash_single "bug" which results in the message 1 being verified)
10:46 < nsh> why should that be rejected?
10:46 < gmaxwell> sipa: if the message hash is 0 the valid signature is r = pubkey, right?  it would be easy enough to make a wrapper function to admit 0-hash signatures if you want them.
10:47 < gmaxwell> nsh: why should what be rejected?
10:47 < nsh> the message 1
10:47 < nsh> because of ec arithmetic?
10:48 < gmaxwell> nsh: it shouldn't be.
10:48 < gmaxwell> nsh: sipa is giving an example of how the input to ecdsa_verify might end up not being a hash.
10:48 < sipa> ECDSA doesn't care about the message being 1 (it can't be 0 though)
10:48 < nsh> oh, i read that the sighash_single 'bug' is the non-rejection of a signed message 1
10:48 < nsh> ah okay, pardon
10:49 < sipa> no, it is the (presumbly) unintentional message 1 being verified when in fact it should probably just reject spending
10:49 -!- ken2812221 [~ken281222@110.50.135.219] has quit [Read error: Connection reset by peer]
10:49 < gmaxwell> so in any case, as I said-- we could change the interface to take the message,length and a hasher callback.  If you want to pass in prehashed data, you replace the hasher callback with a no-op function.
10:51 -!- deusexbeer [~deusexbee@080-250-077-031-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds]
10:53 -!- deusexbeer [~deusexbee@079-170-138-074-dynamic-pool-adsl.wbt.ru] has joined #secp256k1
10:55 < sipa> seems like a lot of complication for little gain
10:59 < gmaxwell> sipa: The existing interface is demonstratively unsafe, we've seen vulnerable code written multiple times on account of it-- including in Bitcoin itself.
11:01 < gmaxwell> another option would be to make the standard interface a 0-rejecting wrapper on a I-promise-I-hashed-the-message rename of the current interface.
11:01 < sipa> gmaxwell: well, it's not the interface, but the scheme it implements that is unsafe
11:02 < gmaxwell> So new users would get funnled into the 0 rejecting one, but we could continue with the 0-accepting in bitcoin.
11:02 < sipa> bitcoin (and all cryptocurrency usage, as far as i know) use ecdsa-without-hashing-as-part-of-the-scheme, not actually ecdsa
11:02 < sipa> ah yes, rejecting 0 for new uses seems much more reasonable than forcing hashing
11:03 < sipa> (in a from scratch implementation, the sha256 would simply be implemented inside the library, but it's too late for that)
11:03 < gmaxwell> I doubt any cryptocurrency not derrived from bitcoin can manage to run without a hash, as that was a freaky bug.
11:04 < gmaxwell> well the callback thing I was suggesting would be essentially putting the sha256 inside the library, with an option to override.
11:04 < gmaxwell> Another option would be to remap a message hash of 0 to some other non-zero value.
16:36 < andytoshi> so, the reason i bring this up is that in rust-bitcoin we have a MessageHash type which wraps a 32-byte array, and we're considering rejecting an attempt to create one from the all-zeroes array. which currently would make the bindings "less capable" in some sense than the underlying library, but IIRC matt and I decided that was fine, in general we try to use the rust type system to force safe usage
16:36 < andytoshi> of the library
16:36 < andytoshi> but in this case, maybe it would make sense to do it upstream as well
16:41 < gmaxwell> I think it would be pretty trivial to replace the verify function with a wrapper that checks for zero and rejects the signature.  In Bitcoin we could even tie validation with the old functions vs new to some softfork, for an extra-paranoia-safe-change.
16:42 < gmaxwell> and in rust you could just wrap the checking version.
19:37 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 268 seconds]
20:34 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1
20:36 -!- ken2812221 [~ken281222@110.50.135.219] has joined #secp256k1
21:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
21:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
21:38 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
21:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds]
21:43 -!- lukedashjr is now known as luke-jr
--- Log closed Sat Nov 10 00:00:17 2018