crypto: Port rdsec to Noise Protocol

[metaphorics]

암호화 계층의 정형화: Noise Protocol Framework 적용

현재 rdsec은 X25519, HKDF, ChaCha20Poly1305를 조합하여 독자적인 핸드셰이크를 구현하고 있습니다. 독자 암호화 프로토콜은 "Don't Roll Your Own Crypto" 원칙에 위배될 위험이 있습니다. 이를 정형화된 Noise Protocol로 대체하는 안입니다.

핵심 변경 사항

• Handshake 교체: cryptoops/handshaker.go의 수동 키 교환 로직을 Noise_XX_25519_ChaChaPoly_BLAKE2s 패턴으로 대체합니다.
• 표준 라이브러리: Go의 flynn/noise 같은 검증된 라이브러리를 사용합니다.
• Identity 유지: 기존 Credential(Ed25519)은 Noise의 Static Key로 그대로 활용 가능합니다.

장점

• 검증된 보안: 상호 인증(Mutual Auth), 전방 향 보안(Forward Secrecy), 재전송 방지 등이 수학적으로 증명된 모델을 따릅니다.
• 유지보수: 핸드셰이크 상태 머신을 직접 관리할 필요가 없어 portal/core/cryptoops 패키지의 복잡도가 50% 이상 감소합니다.

[metaphorics]

Mock Plan

Observations

The current rdsec implementation in file:portal/core/cryptoops/handshaker.go uses a custom handshake protocol combining X25519 ephemeral key exchange, Ed25519 identity signatures, ChaCha20Poly1305 AEAD, and HKDF-SHA256 key derivation. The system has comprehensive test coverage and is used in file:portal/client.go for both client and server handshakes. The protocol includes ALPN negotiation, timestamp-based replay protection, and identity verification through HMAC-SHA256 derived IDs. The implementation manages its own state machine with ~678 lines of handshake logic.

Approach

Migrate to Noise Protocol Framework using the Noise_XX_25519_ChaChaPoly_BLAKE2s pattern via the flynn/noise library. The XX pattern provides mutual authentication and forward secrecy, matching current security properties. A critical design decision is handling the Ed25519 identity keys: since Noise uses X25519 for static keys, maintain the existing Ed25519 credentials for identity/signatures while generating separate X25519 static keys for Noise handshakes. This dual-key approach preserves the identity derivation system while leveraging Noise's proven security. The migration will reduce handshake complexity by ~50% while maintaining backward compatibility through protocol versioning.

Implementation Steps

1. Dependency Integration

Add the flynn/noise library to the project dependencies. Since no go.mod file was found in the workspace root, locate the appropriate module file and add:

github.com/flynn/noise v1.1.0

Verify compatibility with existing dependencies (golang.org/x/crypto/chacha20poly1305, golang.org/x/crypto/curve25519).

2. Credential System Extension

Extend file:portal/core/cryptoops/sig.go to support dual-key credentials:

Modify the Credential struct to include X25519 static keys alongside existing Ed25519 keys:

• Add noiseStaticPrivate field (32 bytes, X25519 private key)
• Add noiseStaticPublic field (32 bytes, X25519 public key)

Update NewCredential() and NewCredentialFromPrivateKey():

• Generate X25519 static keypair using crypto/rand
• Store both Ed25519 (for identity/signatures) and X25519 (for Noise) keys
• Maintain existing ID derivation from Ed25519 public key (preserve identity system)

Add accessor methods:

• NoiseStaticPrivate() []byte - returns X25519 private key
• NoiseStaticPublic() []byte - returns X25519 public key

Rationale: Noise Protocol requires X25519 keys for DH operations, but the existing identity system relies on Ed25519. Maintaining both preserves identity verification while enabling Noise integration.

3. Protocol Version Update

Update file:portal/core/proto/rdsec/rdsec.proto:

Add new protocol version:

enum ProtocolVersion {
  PROTOCOL_VERSION_1 = 0;  // Existing custom handshake
  PROTOCOL_VERSION_2 = 1;  // Noise Protocol
}

Add Noise-specific message types:

message NoiseHandshakePayload {
  bytes noise_message = 1;        // Noise handshake message
  bytes identity_signature = 2;   // Ed25519 signature over noise_message
  Identity identity = 3;          // Ed25519 identity (for verification)
  string alpn = 4;                // ALPN string
  int64 timestamp = 5;            // Replay protection
}

Rationale: Noise handles key exchange, but we need to layer Ed25519 identity verification and ALPN negotiation on top. The signature proves the Noise handshake is from the claimed identity.

4. Noise Handshaker Implementation

Create file:portal/core/cryptoops/noise_handshaker.go:

Core structure:

• NoiseHandshaker struct wrapping *Credential
• Use noise.Config with pattern "Noise_XX_25519_ChaChaPoly_BLAKE2s"
• Configure cipher suite: noise.CipherChaChaPoly, noise.DH25519, noise.HashBLAKE2s

Client handshake flow (ClientHandshakeNoise(conn, alpn)):

1. Create noise.Config with initiator role, local static key from credential
2. Initialize noise.HandshakeState
3. First message: Generate Noise handshake message (-> e)
   • Wrap in NoiseHandshakePayload with identity, ALPN, timestamp
   • Sign the Noise message with Ed25519 credential
   • Send length-prefixed protobuf
4. Second message: Receive server response (<- e, ee, s, es)
   • Unmarshal NoiseHandshakePayload
   • Verify timestamp (±30s window)
   • Verify Ed25519 signature against claimed identity
   • Validate identity structure
   • Process Noise message through HandshakeState.ReadMessage()
5. Third message: Generate final Noise message (-> s, se)
   • Wrap and sign similar to step 3
   • Send to server
6. Extract transport ciphers from HandshakeState.CipherStates()
7. Return SecureConnection with Noise transport ciphers

Server handshake flow (ServerHandshakeNoise(conn, alpns)):

1. Create noise.Config with responder role, local static key
2. Initialize noise.HandshakeState
3. First message: Receive client init (<- e)
   • Unmarshal, verify timestamp, signature, identity, ALPN
   • Process Noise message
4. Second message: Generate response (-> e, ee, s, es)
   • Wrap, sign, send
5. Third message: Receive client final (-> s, se)
   • Verify and process
6. Extract transport ciphers and return SecureConnection

Key considerations:

• Reuse existing SecureConnection struct (already has encryptor/decryptor AEAD interfaces)
• Noise provides cipher.AEAD compatible ciphers
• Preserve memory wiping for sensitive data
• Silent failure on server validation errors (security best practice)

5. SecureConnection Adaptation

Modify file:portal/core/cryptoops/handshaker.go:

Update SecureConnection:

• No structural changes needed (already uses cipher.AEAD interface)
• Noise transport ciphers are compatible with existing Read/Write methods
• Keep existing fragmentation logic (32MB chunks)
• Maintain buffer management and memory wiping

Add factory method:

• createSecureConnectionFromNoise(conn, cs0, cs1, remoteID)
• Takes Noise CipherState objects, wraps as cipher.AEAD
• Reuses existing connection logic

6. Handshaker Facade Pattern

Update file:portal/core/cryptoops/handshaker.go to support both protocols:

Modify Handshaker struct:

• Add protocolVersion ProtocolVersion field
• Default to PROTOCOL_VERSION_2 (Noise) for new connections

Update ClientHandshake():

• Check protocolVersion field
• Route to ClientHandshakeNoise() for v2, existing logic for v1
• Add deprecation comment for v1

Update ServerHandshake():

• Peek at first message to detect protocol version
• Route to appropriate handler
• Support both v1 and v2 for backward compatibility

Add constructor variants:

• NewHandshakerV1(cred) - force legacy protocol
• NewHandshakerV2(cred) - force Noise protocol (default)
• NewHandshaker(cred) - defaults to v2

7. Identity Verification Layer

Create file:portal/core/cryptoops/noise_identity.go:

Implement identity binding:

• signNoiseMessage(credential, noiseMsg) - Ed25519 signature over Noise handshake bytes
• verifyNoiseIdentity(identity, noiseMsg, signature) - verify signature and identity structure
• validateNoiseHandshakePayload(payload, expectedAlpns) - comprehensive validation

Preserve existing identity functions:

• Keep ValidateIdentity() from file:portal/core/cryptoops/identity.go
• Keep DeriveID() from file:portal/core/cryptoops/sig.go
• Ensure ID derivation remains unchanged (critical for compatibility)

8. Testing Strategy

Create file:portal/core/cryptoops/noise_handshaker_test.go:

Port existing tests:

• Successful handshake (client/server)
• Encryption round-trip
• Large message fragmentation
• Concurrent operations
• Invalid signature detection
• Timestamp validation
• ALPN mismatch
• Protocol version handling

Add Noise-specific tests:

• Noise handshake state machine correctness
• Static key exchange verification
• Dual-key credential generation
• Cross-version compatibility (v1 client to v2 server should fail gracefully)
• Identity signature verification over Noise messages

Update existing tests in file:portal/core/cryptoops/handshaker_test.go:

• Add version parameter to test helpers
• Test both v1 and v2 paths
• Ensure backward compatibility

9. Integration Updates

Update file:portal/client.go:

Locate handshaker instantiation (lines ~344, ~639):

• Replace cryptoops.NewHandshaker(cred) with cryptoops.NewHandshakerV2(cred)
• Or keep NewHandshaker() if defaulting to v2

Add configuration option (optional):

• Allow protocol version selection via client config
• Enable gradual rollout (start with v1, migrate to v2)

Error handling:

• Ensure Noise-specific errors are properly logged
• Maintain existing error propagation patterns

10. Documentation Updates

Update file:portal/core/cryptoops/README.md:

Add Noise Protocol section:

• Document Noise_XX_25519_ChaChaPoly_BLAKE2s pattern
• Explain dual-key system (Ed25519 for identity, X25519 for Noise)
• Describe handshake flow with identity verification layer
• Update security properties section
• Add migration guide from v1 to v2

Update protocol flow diagrams:

• Add Mermaid sequence diagram for Noise handshake
• Show identity verification layer
• Highlight differences from v1

Document breaking changes:

• New credential format (includes X25519 keys)
• Protocol version negotiation
• Backward compatibility guarantees

11. Complexity Reduction Analysis

Lines of code reduction:

• Remove manual X25519 key exchange logic (~50 lines)
• Remove HKDF key derivation functions (~30 lines)
• Remove handshake state management (~100 lines)
• Simplify message framing (~40 lines)
• Total reduction: ~220 lines (~32% of handshaker.go)

Maintenance benefits:

• Noise library handles state machine (proven, audited)
• Automatic handling of DH operations
• Built-in replay protection via Noise nonces
• Simplified key derivation (handled by Noise)

Preserved complexity:

• Identity verification layer (necessary for Ed25519 binding)
• ALPN negotiation (application-specific)
• Timestamp validation (additional replay protection)
• SecureConnection wrapper (unchanged)

Migration Sequence Diagram

sequenceDiagram
    participant C as Client
    participant S as Server
    participant N as Noise Library
    
    Note over C,S: Noise XX Pattern with Identity Layer
    
    C->>C: Generate ephemeral key (e)
    C->>N: Create Noise message (-> e)
    C->>C: Sign Noise msg with Ed25519
    C->>S: NoiseHandshakePayload{noise_msg, signature, identity, alpn, timestamp}
    
    S->>S: Verify timestamp (±30s)
    S->>S: Verify Ed25519 signature
    S->>S: Validate identity & ALPN
    S->>N: Process Noise message
    S->>S: Generate ephemeral key (e)
    S->>N: Create Noise message (-> e, ee, s, es)
    S->>S: Sign Noise msg with Ed25519
    S->>C: NoiseHandshakePayload{noise_msg, signature, identity, alpn, timestamp}
    
    C->>C: Verify timestamp & signature
    C->>C: Validate identity
    C->>N: Process Noise message
    C->>N: Create final message (-> s, se)
    C->>C: Sign Noise msg with Ed25519
    C->>S: NoiseHandshakePayload{noise_msg, signature, identity}
    
    S->>S: Verify signature & identity
    S->>N: Process final message
    
    Note over C,S: Handshake Complete
    
    C->>N: Extract transport ciphers
    S->>N: Extract transport ciphers
    
    Note over C,S: Encrypted Communication (ChaCha20Poly1305)
    
    C->>S: Encrypted application data
    S->>C: Encrypted application data

Loading

Risk Mitigation

Risk: Ed25519 to X25519 key conversion complexity
Mitigation: Use separate X25519 keys, avoid conversion issues

Risk: Breaking existing deployments
Mitigation: Protocol versioning, maintain v1 support during transition

Risk: flynn/noise library maintenance
Mitigation: Library is stable (v1.1.0), widely used in production (libp2p, WireGuard-inspired projects)

Risk: Performance regression
Mitigation: Noise is optimized, ChaCha20Poly1305 unchanged, benchmark before/after

Risk: Identity verification bypass
Mitigation: Mandatory Ed25519 signature verification over Noise messages

[gosunuts]

Great idea! A generic cryptographic approach makes it easier to switch to a more suitable language (like javascript, rust) as requirements evolve.