--- Day changed Sat Apr 01 2017
02:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 240 seconds]     
02:24 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
05:05 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #secp256k1     
07:25 -!- ryan-c [~ryan@znc.rya.nc] has joined #secp256k1     
11:31 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
12:33 < ofek> for libsecp256k1, does a private key have to be 32 bytes?
12:37 < sipa> yes     
12:44 < ofek> sipa, ok ty. if not 32 bytes, creation will error?
12:45 < sipa> no     
12:45 < sipa> it means you get undefined behaviour
12:45 < sipa> the library takes a pointer to 32 bytes of data
12:45 < ofek> ah, I see
12:45 < sipa> if you pass anything else, the compiler is allowed to produce code which erases your disk
12:52 < ofek> sipa, if I confirm the secret is 32 bytes, is secp256k1_ec_seckey_verify necessary?
12:54 < gmaxwell> ofek: yes you do and the verify is completely orthorgonal.
12:55 < gmaxwell> ofek: there isn't anything for you to "confirm", the size of the data the pointer points to isn't a property of the key.
12:55 < gmaxwell> it's a property of the pointer.
12:55 < gmaxwell> Pointers do not have sizes.
13:00 < ofek> gmaxwell, does it simply check that 0 < secret <= p?
13:01 < sipa> yes     
13:01 < sipa> no     
13:01 < sipa> it checks 0 < secret < n
13:01 < sipa> (where n is the order)
13:01 < ofek> ah, ok
13:02 < sipa> p is commonly used to refer to the prime field modulus
13:02 < sipa> but p is a bit larger than n, the curve order
13:03 < ofek> ah yeah I always get p and n mixed up. I thought p was # of possible elements
13:11 < sipa> no, p is the number of possible coordinate values
13:12 < ofek> ah ok tyvm
13:12 < sipa> p is FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
13:12 < sipa> n is FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
13:12 < ofek> https://github.com/bitcoin-core/secp256k1/blob/master/src/eckey_impl.h#L21 what are 0x06/0x07? never seen those prefixes
13:13 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
13:14 -!- echonaut1 [~echonaut@46.101.192.134] has joined #secp256k1     
13:15 < sipa> ofek: hybrid pubkeys
13:15 < sipa> we need to support them, because openssl supports them
13:15 < sipa> but they've never been used in the network afaik
13:26 -!- echonaut1 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
13:26 -!- echonaut [~echonaut@46.101.192.134] has joined #secp256k1     
14:46 < ofek> is it ok to only check if secret > 0 and just always do mod n?
14:47 < sipa> in general, no
14:47 < sipa> that will result in a biased key
14:47 < sipa> as the key range between 0 and (p-n) will have higher probability of being picked
14:48 < sipa> in practice, and specifically for secp256k1, that difference is so small it does not matter
14:49 < sipa> but i still advise against it, it's bad practice
14:50 < ofek> how would that key range have a higher probability of being picked?
14:52 < sipa> values between 0 and p-n have twice the chance of being picked
14:53 < sipa> as they can result from either generating a number between 0 and n-p directly, or by generating a number between n and p
14:53 < sipa> eh     
14:53 < sipa> 2^256 instead of p
14:55 < ofek> oooh
14:55 < ofek> ok     
14:55 < ofek> tyvm
14:55 < ofek> I won't do that then
14:56 < ofek> (OpenSSL does btw)
14:56 < sipa> really?
14:56 < ofek> yes     
14:56 < sipa> link to code?
15:02 < ofek> sipa, well I was using a python binding to it and used 1 and order+1 and both returned key with value of 1
15:03 < sipa> maybe it's the python binding doing it?
15:04 < sipa> i'd be surprised if openssl did this
15:05 < ofek> sipa, afaict nope https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/backend.py#L1315
15:45 < gmaxwell> considering that openssl has many curves with order far from 256^n silently doing that kind of modular reduction can severely hurt security, and result in key compromises if used e.g. with DSA nonces.
16:17 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 268 seconds]     
16:42 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1     
18:48 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #secp256k1     
21:02 < ofek> why can secp256k1_ecdsa_sign only sign 32 bytes?
21:19 < sipa> because math
21:19 < sipa> it's a 256 bit curve, so all elements used internaply are only 256 bits
21:20 < sipa> that's enough for 128 bit security, regardless of the amount of data being signed
21:20 < sipa> in fact, ecdsa requires you to sign a hash of the data, not the data itself
21:20 < sipa> if you don't hash first there are serious security problems in some cases
21:21 -!- echonaut2 [~echonaut@46.101.192.134] has joined #secp256k1     
21:23 < ofek> hmm, I see now
21:23 < ofek> ty     
21:24 -!- madgoat [~gk.1wm.su@23.247.147.4] has joined #secp256k1     
21:25 < sipa> gmaxwell: i expect that openssl's "generate a random new key" code works correctly, but just doesn't enforce it on incoming private keys?
21:25 -!- echonaut [~echonaut@46.101.192.134] has quit [Ping timeout: 260 seconds]     
21:26 -!- madgoat [~gk.1wm.su@23.247.147.4] has left #secp256k1 []     
22:07 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]