REST API signature explaination lacking

[C0DK]

So i've read another issue regarding the same thing, but i really have no clue what is going on.
Read the following: #514

I'm trying to implement this in Python, but your sourcecode isn't that transparent (to me atleast) and doesn't seem to follow the same conventions as many other APIs in the same field, so i really have a hard time figuring out how to sign my GET request.

• What is "m/1/1 derivative"?
• What 'algorithm' is used to actual encrypt the message? It isn't using something standard it seems.

It would be great if you provided some more non-language-specific explaination in the readme file 👍

It's probably just me being stupid, but i'd love to get pointed in the right direction.

[dabura667]

1. BIP32
2. ECDSA signatures. No encryption.

[C0DK]

Sorry but this really doesn't help me at all.

[C0DK]

If you could help guide me through the signing process then i'd be glad. Maybe, as i said before, put it in the readme

[dabura667]

1. Take the NFKD normalized recovery phrase, split by space and gather the indices from the BIP39 wordlist.
2. Turn the indices into binary, divide the number of bits into 32, and take the remainder number of bits from the end. Hash what’s left using sha256 twice, and compare the first bits of the hash to the remainder bits you removed.
3. If it matches, hash the normalized recovery phrase using PBKDF2 with hash function of SHA512, iteration count of 2048, and read length of 64 bytes.
4. Take those 64 bytes, and feed them into HMAC-SHA512 with the key of “Bitcoin seed”.
5. Take the leftmost 32 bytes of the resulting 64 byte hash, treat it as a private key on the curve SECP256k1 and generate the DER compressed public key serialization. We’ll call this serpub1.
6. Take the rightmost 32 bytes of the resulting 64 byte hash from step 4 and use it as the key in a new HMAC-SHA512, the data fed into it is the concatenation of serpub1 and the 4 byte sequence 0x00000001.
7. Repeat 5 and 6 once more, you will now have a 64 byte hash representation of the m/1/1 key using BIP32 derivation.
8. The leftmost 32 bytes of the resulting hash from step 7 is your private key for request signing.
9. The request type (get, post etc) in lower case, the endpoint URL, and the JSON.stringify representation of the request body (this should be the body of the request. Be sure to add the header of application/json for content-type) should be concatenated with vertical line. “|” and signed using the private key we derived. The hash algorithm used for message digest is sha256 x 2.
10. The signature in the header should be a hex representation of strict DER encoding.

There you go, a minimalistic explanation of BIP39, BIP32, and I glossed over ECDSA since you really should not re-implement cryptographic functions if you don’t know what you’re doing.