1 2016-11-13 15:37:25 <venzen> hi all, experimenting with BIP151 (encrypted sessions). Anyone able to point me at a utility for calculating the 2nd ECC point from a compressed pubkey in Python?
 2 2016-11-13 15:37:31 <takashi> test message
 3 2016-11-13 15:40:20 <jonasschnelli> venzen: what are you trying to do?
 4 2016-11-13 15:40:43 <jonasschnelli> Second key for the AEAD
 5 2016-11-13 15:40:46 <jonasschnelli> ?
 6 2016-11-13 15:43:03 <venzen> hi jonasschnelli
 7 2016-11-13 15:44:07 <venzen> yes, working with comp keys is giving me some headaches when trying to calc the ECDH secret, because the utility i have expects a point on the curve...
 8 2016-11-13 15:44:53 <venzen> i can calculate that and pass it along but i'm not sure how to determine the points from the compressed privkey
 9 2016-11-13 15:45:31 <venzen> i understand its a single point with a sign prefix for the corresponding point...
10 2016-11-13 15:45:49 <jonasschnelli> ECDH always take a private and a pub-key as input to calculate a shared secret
11 2016-11-13 15:46:01 <venzen> ehe
12 2016-11-13 15:46:31 <jonasschnelli> Example: ECDH(PubKey-Alice, PrivateKey-Bob) == ECDH(PrivateKey-Alice, PubKey-Bob)
13 2016-11-13 15:46:51 <venzen> thanks and great
14 2016-11-13 15:47:30 <venzen> and it expects two points for the privkey, how do you handle that?
15 2016-11-13 15:48:53 <venzen> rather, let me ask, if we generate two points, then which of the two do we use in the EncInit/EncAck messages?
16 2016-11-13 15:48:59 <jonasschnelli> Not sure what library you are using,... but I guess it should take a 32-byte scalar containing a valid private-key and a valid public-key
17 2016-11-13 15:51:27 <jonasschnelli> venzen: I guess if you gave two points, you have an uncompressed pubkey,... you need to compress it first
18 2016-11-13 15:51:27 <venzen> my lib is generating a compressed privkey, I then decompress it, split that in two (after removing the prefix) and feeding those two points to ECDH... but that's clumsy and I'm not left wondering which of the points to use for the Encryption messages because they want a compressed privkey (33 bytes)
19 2016-11-13 15:52:11 <jonasschnelli> http://crypto.stackexchange.com/questions/8914/ecdsa-compressed-public-key-point-back-to-uncompressed-public-key-point
20 2016-11-13 15:52:26 <jonasschnelli> there is no such thing like a compress private key
21 2016-11-13 15:52:31 <jonasschnelli> only compressed public-keys
22 2016-11-13 15:52:58 <venzen> is there a ECDH lib you can recommend that accepts  a compressed pubkey?
23 2016-11-13 15:53:12 <jonasschnelli> libsecp256k1
24 2016-11-13 15:53:25 <venzen> indeed, my error, i meant to say compressed pubkey
25 2016-11-13 15:53:26 <jonasschnelli> not sure if it has python bindings
26 2016-11-13 15:54:24 <venzen> thanks, i'll look at that and see if i find python bindings or smething else suitable
27 2016-11-13 15:54:26 <jonasschnelli> If you are using python, maybe check https://github.com/petertodd/python-bitcoinlib
28 2016-11-13 15:54:49 <jonasschnelli> They certainly have signing,... though not sure through what library
29 2016-11-13 15:55:07 <venzen> have checked it and use it in part...
30 2016-11-13 15:56:18 <venzen> so far so good, I have the message types (EncInit, EncAck) as well as the Auth handshake working. Now focussing on getting the Encryption to spec
31 2016-11-13 15:57:36 <venzen> will feedback once I make progress. Do you have test implementation I can try against?
32 2016-11-13 15:59:40 <jonasschnelli> No. We are also working on the implementation..
33 2016-11-13 15:59:49 <jonasschnelli> but there is a java script implementation of 150/151
34 2016-11-13 15:59:53 <jonasschnelli> bcoin
35 2016-11-13 16:00:04 <jonasschnelli> Though, not sure if its correctly after the specs.
36 2016-11-13 16:00:09 <jonasschnelli> But looks good.
37 2016-11-13 16:00:35 <jonasschnelli> When implementing the AEAD (chacha20poly1305), make sure you are implementing the openssh version of the AEAD
38 2016-11-13 16:01:01 <venzen> i read about it and will try it locally or speak with one of their devs for cross-implementation auth
39 2016-11-13 16:01:27 <venzen> oh yes, i read its ref today from your BIP link
40 2016-11-13 16:01:40 <jonasschnelli> Shouldn't be very hard...
41 2016-11-13 16:02:06 <jonasschnelli> I started implementing (rip-out of openssh) the AEAD in C99: https://github.com/jonasschnelli/chacha20poly1305
42 2016-11-13 16:02:13 <jonasschnelli> Very rough currently
43 2016-11-13 16:02:45 <venzen> shouldn't - only to find a suitable python binding - i think libsodium along with pysodium has the encrypt/decrypt functions
44 2016-11-13 16:03:27 <venzen> i mean shouldn't be hard to implement, thanks for the link - i'll look at your code
45 2016-11-13 16:11:51 <AndChat> 30900|test
46 2016-11-13 16:15:17 <venzen> jonasschnelli: just to check - for your implementation of the Enc session - are you generating both a compressed pukey (for use in the two way exchange messages), as well as an uncompressed pubkey in order to pass the EC point to ECHD?
47 2016-11-13 16:16:07 <venzen> ECDH
48 2016-11-13 16:16:26 <jonasschnelli> No. Only a single ephemeral key = one compressed pubkey
49 2016-11-13 16:17:19 <venzen> and your ECHD util accept the compressed pubkey and returns two scalars for the shared secret?
50 2016-11-13 16:17:52 <jonasschnelli> No.. only one.
51 2016-11-13 16:18:01 <jonasschnelli> The two AEAD key will be deriven by HKDF
52 2016-11-13 16:18:21 <jonasschnelli> PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinecdh", ikm=ecdh_secret|cipher-type)
53 2016-11-13 16:18:25 <jonasschnelli> K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32)
54 2016-11-13 16:18:31 <jonasschnelli> K_2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK2", L=32)
55 2016-11-13 16:18:44 <jonasschnelli> K_1 will be used to encrypt the length of the package
56 2016-11-13 16:19:20 <venzen> yes
57 2016-11-13 16:19:54 <venzen> and we use the left 32 bytes and right 32 bytes of the shared secret for k_1 and K_2
58 2016-11-13 16:19:57 <venzen> yes
59 2016-11-13 16:20:37 <jonasschnelli> left and right?
60 2016-11-13 16:20:37 <venzen> ah, ok, my util is not suitable, it takes the privkey and a point and returns a tuple of two shared secrets... i need to find something else, as mentioned before
61 2016-11-13 16:21:53 <venzen> says so in the BIP (151) under Symmetric Encryption Cipher Keys...
62 2016-11-13 16:22:19 <jonasschnelli> I guess ECDH(priv, pub) should always result in the same (single) 32byte shared secret (for the secp256k1 curvparams)
63 2016-11-13 16:23:10 <jonasschnelli> venzen: do you have the newest version of BIP151? https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki
64 2016-11-13 16:23:16 <jonasschnelli> There was an update some month ago with the HKDF change
65 2016-11-13 16:24:43 <venzen> no, i was looking at an older draft :) thanks
66 2016-11-13 16:27:04 <venzen> ok, i need to find an appropriate ECDH utility for python, could code it I guess, or hopefully find a binding for libsecp256k1
67 2016-11-13 16:33:58 <jonasschnelli> venzen: what are you implementing?
68 2016-11-13 16:37:40 <venzen> jonasschnelli: i have a python node. I initially implemented the message types for Auth and Enc, and got these working between my nodes using zero values for all keys
69 2016-11-13 16:38:32 <venzen> I've now got the Auth  working (as per spec) after a dummy Enc handshake
70 2016-11-13 16:38:40 <jonasschnelli> You could try implementing bip151 for the python-bitcoinlib
71 2016-11-13 16:38:55 <venzen> can do, yes
72 2016-11-13 16:40:19 <venzen> i'll look at Peter's lib and see what's there for kegen and the ECDH shared secret calc
73 2016-11-13 16:40:29 <venzen> *keygen
74 2016-11-13 16:41:06 <venzen> implementing the Encripted message type could be more difficult, but again I can see what he's got already
75 2016-11-13 16:53:25 <venzen> jonasschnelli: i just looked through python-bitcoinlib, and i'll begin with a pullrequest to add the message types there
76 2016-11-13 16:54:02 <jonasschnelli> I guess the message types only make sense with the according protocol implementation? not?
77 2016-11-13 16:55:27 <venzen> the ECDH functions there may be useful - i'll have a look and see what can be ported from my existing code - and what Peter likes, of course
78 2016-11-13 16:55:50 <jonasschnelli> Bip151 would make sense as a first step (without BIP150).
79 2016-11-13 17:01:32 <venzen> i think you're right... if python-bitcoinlib can produce the correct format keys and calculate the shared secret, and two instances of the lib can negotiate through BIP151 that would be a first step. I'll give it a try
80 2016-11-13 17:10:19 <jonasschnelli> Yes. That would be good.
81 2016-11-13 20:55:28 <btcdrak> p2pool PR for segwit https://github.com/p2pool/p2pool/pull/327