Proposal for the use Bitcoin-Core native cryptographic primitives

[jakubtrnka]

This PR:

1. proposes to use cryptographic primitives used in Bitcoin Core
   • It deprecates using curve25519 in favor of secp256k1
   • proposes using SHA256 instead of Blake2s
   • proposes using Schnorr/secp256k1 for Signature Noise Message for server authentication
   • it implies changing CA-authority public keys for existing pools and introducing new format for CA public keys in order to avoid mistaking secp256k1 pubkeys for ed25519 pubkeys on new and old systems
   • requires mandatory support for Noise_NX_secp256k1_ChaChaPoly_SHA256 handshake and optional support for Noise_NX_secp256k1_AESGCM_SHA256
2. proposes to change message formats during handshake
   • Previously handshake messages used to be wrapped in length-delimited frames with 2-Byte length prefix. The length prefix is not necessary, because the size of messages in each handshake step is known
3. Each handshake step thoroughly described, mainly extracted from https://noiseprotocol.org/noise.html for the specific NX protocol
4. PR moves the description of noise-secure layer into a separate file

[rrybarczyk]

Maybe list 3 as 1 since this is the one we are choosing to implement.

[jakubtrnka]

I'd keep it on the 3rd position. Because it's the least obvious approach.

[ccdle12]

You might want to consider using option 1 given the secp256k1 C-lib used in core expects 64 bytes for ecdh operations. Not sure if it accepts 32 byte x-coordinate plus padding, would need to be investigated. Also the Rust secp256k1 library is an ffi wrapper that calls into the same C-lib secp256k1 and it seems like the PublicKey wrapper is also 64 bytes when calling ecdh operation:

• Rust secp256k1 - SharedSecret and call to secp256k1_ecdh
• Rust secp256k1 - PublicKey (64 bytes)
• C secp256k1 - secp256k1_ecdh()
• C secp256k1 - secp256k1_pubkey

[jakubtrnka]

This is about representation on the wire
The full public key as EC point is always reconstructed from the X coordinate assuming it has even parity.

[jakubtrnka]

Maybe we don't have to use exactly this prefix and leave it undefined. Individual users can use these bytes to make the base58 encoded public key start with string prefix of their choice.

[QunL]

In my opion, to protect privacy and lower detection possibility, the protocol could remove negotiation phrase and fix the Noise_NX_secp256k1_ChaChaPoly_SHA256.

[jakubtrnka]

@QunL You have a good point. Let me summarize:
Currently proposed handshake begins with non-standard cipher negotiation. This makes it very easy to an eavesdropper to recognize Stratum-V2 connection. It would be preferable to initiate a connection with standard Noise_NX_secp256k1_ChaChaPoly_SHA256 handshake.

Removing the negotiation step entirely, however, removes the possibility to choose suitable aead-cipher that might have better performance characteristics.

I therefore suggest following:

1. Initialize encrypted session using Noise_NX_secp256k1_ChaChaPoly_SHA256 protocol:

-> e
<- e, ee, s, es, SIGNATURE_NOISE_MESSAGE

2. Once the encrypted session is established cipher upgrade can be negotiated:

// In the first message in transport state, client provides list of their available aead-ciphers other than
// chachapoly-1305
-> AEAD_CIPHERS

// Server responds/acks with Option<CipherChoice>. Option is non-empty if server requires to switch
// to a new cipher. It provides a new symmetric key alongside its choice - it can because the connection
// has been authenticated and is encrypted. Key exchange is not necessary here
<- CIPHER_CHOICE

// Both client and server now restart an encrypted session using negotiated aead-cipher and key provided by server.

where

struct CipherChoice {
    cipher_code: u32,
    symmetric_key: [u8; 32],
}

3. Based on previous steps either continue using chacha-poly1305 or with a new algorithm

Advantages:

1. Standard canonical initialization of a noise-encrypted connection
2. We retain the ability to choose a cipher for the stratum-session
3. It is simpler than previous proposal of using pre-handshake negotiation and working with prologue

[jakubtrnka]

Update:
During post-handshake cipher negotiation server no-longer decides about the symmetric key to use:
instead keys are derived from the original transport keys.

Another update:
Authority public keys are encoded with version-prefix [1, 0]. Not with some fancy byte prefix [0x4b, 0x69].

[lorbax]

CAREFUL! It seems that initiator and responder have the same encryption key enc_k and the same decryption key dec_k. So, each party would use dec_k for decrypting a message encrypted with enc_k, a different key. I didn't look deeply at ChaCha20-Poly1305, but in a symmetric key algorithm, a message encrypted with a key k can be decrypted only with the key k. Consider switching the keys for one partcipant; for example, at line 263, for the initiator:
c1.InitializeKey(temp_k2) and c2.InitializeKey(temp_k1)

[jakubtrnka]

I don't understand what's the issue here.
If the handshake completes successfully without any active attacker, it means both Initiator and Responder have identical value of ck, therefore (temp_k1, temp_k2) would be identical.
the first is used as a symmetric key for messages sent from initiator to responder, as described above in the text, and the other for stream in the opposite direction.
So:
All messages that initiator sends are encrypted with temp_k1. All messages that responder receives are decrypted with temp_k1.
And correspondingly, all messages that initiator receives are decrypted with temp_k2 and all messages that responder sends are encrypted with temp_k2.

Initiator never decrypts with temp_k1 nor does he encrypt with temp_k2. Also Responder never decrypts with temp_k2 and never encrypts with temp_k1, but that's just technical detail. It's not worth mentioning.

[lorbax]

All messages that initiator sends are encrypted with temp_k1. All messages that responder receives are decrypted with temp_k1.
And correspondingly, all messages that initiator receives are decrypted with temp_k2 and all messages that responder sends are encrypted with temp_k2.

Ok it was specified for both initiator and responder, but I understood incorrectly, sorry.

[lorbax]

Maybe is a good idea to spend few words (like a compressed form of our chat on discord
discord) about backward compatibility for miners/pools that use curve 25519 cryptography. Consider also a new paragraph about backward compatibility

[jakubtrnka]

I wouldn't make any references to earlier stages where different primitives were used. This would make the specification unnecessarily complex. And implementing support for previous versions is not desired. We can handle it in our own software and new independent implementations doesn't need to care about our previous attempts.