Remote comms: Cryptography review and hardening

[sirtimid]

Problem

The cryptography implementation in remote communications is explicitly marked as needing expert review before production use.

File: packages/ocap-kernel/src/remotes/kernel/remote-comms.ts:91-93

// XXX IMPORTANT: All the cryptography here is completely amateur and needs
// to be vetted and overhauled in its entirety by an actual competent
// cryptography expert before being unleashed on an unsuspecting public

Current Crypto Usage

1. Key Generation (remote-comms.ts)

• Ed25519 key pair generation from random seed
• Seed stored as hex string in kernel store
• Used for libp2p peer identity

2. OCAP URL Encryption (remote-comms.ts)

• AES-GCM encryption for object references in OCAP URLs
• Random 32-byte key generated per kernel
• Base58 encoding for URL transport

Files Involved

File	Crypto Usage
kernel/remote-comms.ts	Key generation, AES-GCM encryption/decryption
kernel/OcapURLManager.ts	OCAP URL issuance using encrypted refs
platform/connection-factory.ts	Ed25519 key pair for libp2p identity

Required Work

1. Document current crypto usage in detail
2. Engage cryptography expert for security review
3. Implement recommended changes based on review
4. Add test vectors for crypto operations
5. Consider key rotation mechanisms

Questions for Review

• Is AES-GCM appropriate for OCAP URL encryption?
• Is the key derivation approach secure?
• Are there timing attack vulnerabilities?
• Should we use a standard key derivation function (HKDF, PBKDF2)?
• How should key rotation be handled?

Acceptance Criteria

• Cryptography usage documented
• Expert review completed
• Recommended changes implemented
• Test vectors added for all crypto operations
• No known vulnerabilities in crypto implementation