Please see latest draft and conversation in the bips repository PR #1378
Forked from jonasschnelli/BIPoverhaul.mediawiki
Last active
February 28, 2023 19:50
-
-
Save dhruv/5b1275751bc98f3b64bcafce7876b489 to your computer and use it in GitHub Desktop.
I've created a repo for now to get the large outstanding questions under discussion. Once we are in reasonable shape, I will update again here or make that repo public.
Pushed revision 92 removing the BIP 61 REJECT p2p message which is no longer used.
On rekey, it may help strengthen entropy to feed the last 32 bytes of keystream into the HKDF:
... The IV is initialized to 0 and incremented on every re-key event.
k0 = key
iv = 0
k0 = HKDF_EXPAND(prk=k0, hash=SHA256, info="BitcoinK_Rekey", L=32)
ks0, k1 = ChaCha20DRBG(k0, iv)[0:4064], ChaCha20DRBG(k0, iv)[4064:4096]
iv = iv + 1
k1 = HKDF_EXPAND(prk=k1, hash=SHA256, info="BitcoinK_Rekey", L=32)
ks1, k2 = ChaCha20DRBG(k1, iv)[0:4064], ChaCha20DRBG(k1, iv)[4064:4096]
iv = iv + 1
k2 = HKDF_EXPAND(prk=k2, hash=SHA256, info="BitcoinK_Rekey", L=32)
ChaCha20Forward4064DRBG(key) = ks0 || ks1 || ks2 || ...
We now have a bips repo PR and will continue community engagement there.
Is there any reference code (or other library?) for your x-only ECDH secret derivation? There are several places with Gordian Envelope, in particular for pairing between a coordinator or watchtower and holders of bitcoin keys where we'd like to encrypt the PSBTs. This would enhance the security of our current UR PSBT approach that a dozen wallet vendors support that can optionally be transported with animated QRs.
Yes, see
- bitcoin-core/secp256k1#1129
- https://github.com/bitcoin/bips/blob/master/bip-0324/reference.py#L393
https://bip324.com/sections/code-review/ may also be helpful to navigate the jungle of the PRs.
Be aware that our key exchange encodes the EC points contributed from both sides using Elligator Swift.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I agree with creating a repository, so separate aspects can be discussed separately.
FWIW, I've discussed the idea of a generic extension/feature negotiation mechanism after the ECDH step, and before starting the application level protocol with @dhruv. It's probably easiest to work on that as part of a repository too.
I have some thoughts on @real-or-random's discussion points, but I'll keep them for discussing them as issues if we go that route, to avoid spreading everything out.