Security Architecture

SamVault is designed around a zero-knowledge principle: documents are encrypted before reaching our servers, and our infrastructure stores only ciphertext. We have no technical ability to read the content of your documents.

Algorithm: AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode). GCM provides authenticated encryption — any tampering with the ciphertext is detected on decryption.

Key size: 256-bit (32 bytes) keys throughout. Initialisation vectors (IVs) are 128-bit cryptographically random values, generated freshly for each encryption operation.

Authentication tags: 128-bit GCM authentication tags are stored alongside ciphertext. Decryption fails if the tag does not match, preventing ciphertext substitution attacks.

No ECB mode: We exclusively use GCM mode. ECB mode, which reveals patterns in plaintexts, is never used.

Document storage format: Encrypted documents are stored as binary blobs with the structure: [IV (16 bytes)] + [AuthTag (16 bytes)] + [Ciphertext]. No metadata about the original file is stored unencrypted in the blob itself.

Key derivation: key derivation with SHA-512 digest, 200,000 iterations, 256-bit output. The iteration count significantly exceeds NIST SP 800-63B recommendations and is reviewed annually.

SamVault uses a three-tier key hierarchy designed so that compromise at any layer does not cascade to all documents:

Server-side secret: A server-side secret is mixed into all key derivations as an additional security layer. This means that even if database records were stolen, an attacker cannot reconstruct any user vault key without also compromising the server secret, which is stored separately.

No key escrow: We do not maintain copies of any user vault keys. If you permanently lose access to your registered account, document recovery is not possible. This is an intentional security property that ensures only you can access your vault.

When you share a document, the following process ensures the recipient can access the document without ever exposing your encryption keys:

• A cryptographically random 8-character OTP (one-time passcode) is generated using Node.js crypto.randomBytes
• A share-specific key is derived from shareId + OTP — never stored
• The document DEK is re-encrypted with the share-specific key and stored
• The OTP is hashed with SHA-256 before database storage — the plain OTP is never persisted
• The plain OTP is sent once to the recipient's email address and then discarded
• When the recipient accesses the document, they enter the OTP, which is used to re-derive the share key and decrypt the DEK

Cloud infrastructure: We use industry-leading cloud infrastructure hosted in a secure data centre.

Document storage: Private cloud object storage with public access fully blocked and server-side encryption enabled as an additional layer on top of our own encryption.

Database: MySQL 8.0 with encryption at rest. Connection strings are stored as environment variables, not in code. Database access is restricted to application servers by security group rules.

Email delivery: A trusted cloud email service for all transactional emails, configured with DKIM and SPF authentication.

Dependency management: We maintain an up-to-date dependency inventory and run automated vulnerability scans. Critical security patches are applied within 24 hours of disclosure.

Authentication: Users authenticate via email and password. Passwords are hashed with bcrypt (cost factor 12). Session tokens are signed JWTs stored in HttpOnly, Secure, SameSite=Lax cookies.

Authorisation: Every API endpoint verifies that the authenticated user owns the requested resource. Database queries include user_id = ? predicates — there is no admin bypass for document access.

Timing-safe comparisons: OTP verification uses crypto.timingSafeEqual to prevent timing oracle attacks.

Rate limiting: Authentication endpoints are rate-limited to prevent brute-force attacks. Failed login attempts are logged.

Audit logging: All significant operations (login, upload, download, share, delete) are recorded in an audit log with timestamps and IP addresses.

In the event of a security incident, our response process is:

• Detection: Automated alerting on anomalous access patterns and infrastructure metrics
• Containment: Affected systems isolated within 1 hour of confirmed incident
• Assessment: Scope and impact assessed within 4 hours
• Notification: Affected users notified without undue delay, in accordance with applicable data protection law
• Remediation: Root cause analysis and remediation within 7 days
• Post-incident review: Written post-mortem published internally within 14 days

Because documents are encrypted with user-derived keys, a storage-layer breach does not result in exposure of document contents.

We welcome responsible disclosure of security vulnerabilities. If you discover a potential security issue, please:

• Email security@samvault.com with a description of the vulnerability
• Include steps to reproduce, affected components, and potential impact
• Do not access or modify user data beyond what is necessary to demonstrate the vulnerability
• Allow us 90 days to investigate and remediate before public disclosure