Authenticated ECDH Derivation Path

A Python prototype demonstrating authenticated session establishment with:

• secp256k1 elliptic-curve Diffie-Hellman (ECDH)
• deterministic key derivation from a BIP39 mnemonic
• BIP32 extended public keys (xpubs)
• ECDSA signatures for authenticating ephemeral session keys
• AES-256-CBC encryption for an application message

This repository is intended for experimentation and protocol review. It is not production-ready cryptographic software.

Protocol overview

The example in server-client.py follows this flow:

1. Derive separate server and client keys from deterministic derivation paths.
2. Derive an xpub that the client can use to verify server keys.
3. Generate an ephemeral secp256k1 key pair for each side.
4. Sign each ephemeral public key with the corresponding derived identity key.
5. Verify the signatures using the derived or stored public keys.
6. Derive a shared AES key with ECDH and a session identifier from the combined public keys.
7. Encrypt a message on the client and decrypt it on the server.

Requirements

• Python 3.9 or newer
• pip

Install the Python dependencies:

python -m pip install cryptography bip-utils bip32 ecdsa

Run the examples

From the repository directory, run the end-to-end demonstration:

python server-client.py

Generate and print a secp256k1 private/public key pair:

python test.py

The output from server-client.py should show successful validation of both session public keys and the original message after decryption.

Project files

File	Purpose
server-client.py	End-to-end authenticated ECDH and encrypted-message demonstration
secp256k1.py	secp256k1 curve and point arithmetic
bip.py	BIP39/BIP32 key derivation, xpub handling, and ECDSA helpers
aes.py	AES-CBC encryption and decryption helpers
coords.py	Coordinate-related elliptic-curve utilities
a-ecdh.py	Additional ECDH experiment
test.py	Basic key-generation exercise

Security notes

• The mnemonic embedded in server-client.py is public and must never be used for real credentials, devices, or funds.
• The implementation is educational and has not been audited.
• AES-CBC does not provide message authentication. A production protocol should use an authenticated encryption mode such as AES-GCM or ChaCha20-Poly1305.
• Ephemeral randomness, key storage, key rotation, public-key validation, error handling, and replay protection require additional production design.

License

This project is distributed under the GNU General Public License v3.0. See LICENSE.