vault/notes.md

Steps in the auth scheme

1. sever issues a packet with an PoW challenge
2. client breaks the challenge, and send the data encrypted by its RSA private key
3. server checks against all public keys on file till the right matching one is found
4. server sends ephemeral public key | possible second layer security
5. client sends ephemeral public key | possible second layer security
6. shared secret is computed by both sides
7. hfkd is used by both sides to generate an AES key
8. target commpunication begins

full spec

Enhanced Authentication Scheme Analysis

Your proposed authentication flow is on the right track, but there are a few optimizations I'd suggest:

Revised Authentication Scheme

1. Server Issues Challenge with PoW

   • Server sends: Random nonce + PoW difficulty parameter
   • This prevents DoS attacks against the server

2. Client Solves Challenge & Identifies Itself

   • Client solves the PoW challenge
   • Client sends: Client ID + PoW solution + Digital signature (nonce signed with client's RSA private key)
   • Including the client ID avoids having the server check against all public keys (more efficient)

3. Server Verifies Client

   • Server looks up the client's public key using the provided ID
   • Verifies the PoW solution meets the difficulty requirement
   • Verifies the signature using the client's public key
   • This confirms the client's identity

4. Ephemeral Key Exchange

   • Server generates X25519 ephemeral keypair
   • Server sends ephemeral public key to client
   • Client generates its own X25519 ephemeral keypair
   • Client sends its ephemeral public key to server
   • These temporary keys provide forward secrecy

5. Shared Secret Computation

   • Both sides independently compute the shared secret via Diffie-Hellman
   • Client: client_ephemeral_private × server_ephemeral_public
   • Server: server_ephemeral_private × client_ephemeral_public
   • Both calculations produce identical results

6. AES Key Derivation

   • Both sides derive the session AES key using HKDF
   • Input: shared secret, nonce from challenge, connection context
   • Output: 256-bit AES key unique to this connection

7. Secure Communication

   • All further communication encrypted using AES-GCM with the derived key
   • Each message includes a counter/nonce to prevent replay attacks

Security Benefits

• Efficiency: Server doesn't need to check against all public keys
• Forward Secrecy: Even if long-term keys are compromised, past sessions remain secure
• Anti-Replay: Unique elements in each session prevent replay attacks
• Identity Verification: Strong cryptographic proof of client identity
• Session Uniqueness: Each connection has a unique, ephemeral encryption key

This approach gives you extremely high security while maintaining reasonable performance characteristics, especially with the optimization of having the client identify itself rather than the server trying all possible public keys.

docs

x25519_dalek

rsa

aes-gcm

hkdf

zeroize

sha2