--- Day changed Wed May 11 2016 04:08 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer] 05:15 -!- jtimon [~quassel@65.28.134.37.dynamic.jazztel.es] has joined #secp256k1 08:54 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #secp256k1 10:36 < mdavid613> hey all, quick question (and it may be completely stupid) about the use of libsecp256k1 ecdh. I notice that secp256k1_fe_is_odd() checks the first uint64/32. I'm wondering how this works for creating a shared secret between 64-bit and 32-bit machines using the 5x52 and 10x26 data layouts? I would think that perhaps the secp256k1_fe_is_odd() call in the 10x26 impl might &1 a->n[1] to match up? 10:41 < andytoshi> mdavid613: the pubkeys sholud be shared between the machines in an encoded form 10:41 < andytoshi> data structures that don't appear in secp256k1.h shouldn't ever be crossing architectures 10:48 < mdavid613> ok, sounds good. also, the pubkeys are shared in DER-encoded form 10:49 < sipa> pubkeys are not encoded in DER 10:49 < sipa> only signatures are 10:49 < sipa> if you call the specific function to convert them to der 10:49 < mdavid613> I mean in my use-case 10:49 < mdavid613> right now I'm using the library using python bindings 10:50 < mdavid613> as a test client 10:50 < sipa> do you mean actually DER, or the {02/03} + point.x format? 10:51 < mdavid613> pubkeys are shared in DER format specifically, then I deserialize from DER and use the 0x04 + x + y points to create the pubkey to use for ECDH within the library 10:52 < sipa> i see 10:52 < mdavid613> I'm trying to use the library because I'd like to standardize around the implementation of a well known library for ECDH 10:53 < sipa> if the real question you have is whether the output of secp256k1_ecdh is portable across platform, the answer is yes :) 10:53 < mdavid613> then that's perfect 10:53 < sipa> internal data structures use platform specific representations, but they're never exposed 10:53 < mdavid613> as an aside, do you have an idea when ecdh will move out of the experimental phase? 10:58 < andytoshi> i have no idea :). at the very least we're still waffling on https://github.com/bitcoin-core/secp256k1/issues/352 i believe 10:58 < mdavid613> got it, looks like a fun read ;) 11:00 < mdavid613> though I definitely understand the point as there really is no standard way of doing ECDH. I wanted to use the library's ECDH specifically because I'd like to move towards a standard. 11:00 < mdavid613> andytoshi: thanks much :) 11:00 < mdavid613> and sipa: thanks again! 13:31 -!- jtimon [~quassel@65.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 14:20 -!- jtimon [~quassel@65.28.134.37.dynamic.jazztel.es] has joined #secp256k1 15:19 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] 15:32 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has joined #secp256k1 15:42 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has quit [Quit: Leaving.] 17:15 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has joined #secp256k1 17:46 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has quit [Quit: Leaving.] 18:04 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has joined #secp256k1 18:10 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has quit [Quit: Leaving.] 19:09 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has joined #secp256k1 21:16 -!- mdavid613 [~Adium@cpe-172-251-161-231.socal.res.rr.com] has quit [Quit: Leaving.] 23:47 -!- jtimon [~quassel@65.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]