Encryption Architecture

Encryption Architecture

VailNote implements a sophisticated encryption architecture designed to maximize privacy and security while maintaining usability across different client environments.

Overview

VailNote's encryption system operates on the principle of zero-knowledge architecture, where the server never has access to plaintext content. The system supports two modes of operation to accommodate different client capabilities.

Architecture Diagram

The encryption flow follows this pattern:

1. Client-side encryption (JavaScript mode)
2. Secure transmission to backend
3. Server-side hashing and storage
4. Link generation with embedded keys
5. Decryption on retrieval

Encryption Modes

JavaScript Mode (Recommended)

In JavaScript mode, all encryption happens on the client side before any data leaves the user's device.

Note Creation Process

1. Key Generation

   • If password provided: SHA-256 hash of password becomes encryption key
   • If no password: Random 32-byte key generated locally
   • Random 12-byte IV (Initialization Vector) generated

2. Client-side Encryption

   • Content encrypted using AES-GCM algorithm
   • Encryption key derived from password hash or random generation
   • IV ensures unique encryption even with same content

3. Secure Transmission

   • Only encrypted content and hashed password sent to server
   • Server never sees plaintext content
   • Auth key remains on client side

4. Server Processing

   • Server generates random note ID
   • Password hash is salted and hashed again (bcrypt)
   • Encrypted content stored with salted hash

5. Link Generation

   • Client generates shareable link: vailnote.com/[noteId]?auth=[authKey]
   • Auth key embedded in URL fragment (never sent to server)

Note Retrieval Process

1. Link Opening

   • Auth key extracted from URL
   • Note ID sent to server for retrieval

2. Server Response

   • Server returns encrypted content and IV
   • No decryption happens on server

3. Client Decryption

   • Client uses auth key to decrypt content
   • Content displayed to user
   • Note destroyed from server

Non-JavaScript Mode

For compatibility with clients that don't support JavaScript, VailNote provides a fallback mode.

Security Trade-offs

• Content transmitted in plaintext over SSL/TLS
• Server performs encryption using note ID as key
• Reduced security compared to JavaScript mode
• Suitable for environments where JavaScript is unavailable

Technical Implementation

AES-GCM Encryption

// Key derivation from password
const keyBuffer = await crypto.subtle.digest(
  'SHA-256',
  new TextEncoder().encode(password)
);

// AES-GCM encryption with random IV
const encrypted = await crypto.subtle.encrypt(
  {
    name: 'AES-GCM',
    iv: randomIV
  },
  cryptoKey,
  contentBytes
);

Key Security Features

1. AES-GCM Algorithm

   • Authenticated encryption with associated data
   • Provides both confidentiality and authenticity
   • Resistant to padding oracle attacks

2. SHA-256 Key Derivation

   • Cryptographically secure hash function
   • Deterministic key generation from passwords
   • One-way function prevents password recovery

3. Random IV Generation

   • 12-byte random initialization vector
   • Ensures semantic security
   • Prevents rainbow table attacks

4. Bcrypt Password Hashing

   • Server-side password verification
   • Salted hashing prevents rainbow table attacks
   • Configurable work factor for future-proofing

Security Guarantees

Client-side Security

• Zero-knowledge: Server never sees plaintext content
• Forward secrecy: Each note uses unique encryption parameters
• Client-side key generation: Reduces attack surface
• Secure random number generation: Uses Web Crypto API

Server-side Security

• Encrypted storage: All content stored encrypted
• Salted password hashing: Prevents credential compromise
• Self-destructing notes: Automatic deletion after viewing
• No persistent keys: Encryption keys never stored on server

Transport Security

• TLS encryption: All data encrypted in transit
• Authentication: bcrypt verification prevents unauthorized access
• Rate limiting: ARC protocol prevents abuse

Attack Resistance

Threat Model

The encryption architecture is designed to resist:

1. Server compromise: Encrypted data remains secure
2. Network interception: TLS and client-side encryption
3. Database breach: All content stored encrypted
4. Credential stuffing: Salted password hashing
5. Replay attacks: Unique IVs and self-destructing notes

Known Limitations

1. Non-JavaScript mode: Content visible to server during processing
2. Link sharing: Auth keys transmitted in URLs
3. Client-side vulnerabilities: Depends on browser security
4. Metadata leakage: Note existence and access patterns visible

Best Practices

For Users

1. Use JavaScript mode for maximum security
2. Use strong passwords when password protection is enabled
3. Share links securely via encrypted channels
4. Verify HTTPS connection before creating notes

For Developers

1. Regular security audits of encryption implementation
2. Secure random number generation for all cryptographic operations
3. Constant-time comparisons for password verification
4. Proper error handling to prevent information leakage

Compliance and Standards

• FIPS 140-2: AES-GCM encryption algorithm
• RFC 5084: AES-GCM specification compliance
• OWASP: Following secure coding practices
• Web Crypto API: Browser-native cryptographic primitives

Future Enhancements

• Post-quantum cryptography: Preparation for quantum threats
• Hardware security modules: Enhanced key management
• Multi-factor authentication: Additional security layers
• Perfect forward secrecy: Enhanced key rotation

---

This documentation covers VailNote's encryption architecture as of July 2025. For the latest updates, check the GitHub repository.