Skip to content

Client-Side Encryption Using AES-256 GCM

Overview

Client-Side Encryption Using AES-256 GCM means UnoLock encrypts Safe data on the client before it is uploaded or stored remotely. This is the core of UnoLock's zero-knowledge storage model.

This page is about where encryption happens. It is not the same as the separate question of whether a payload is end-to-end encrypted while moving between endpoints.

In UnoLock:

  • Safe data is encrypted on the client.
  • Encryption keys used for data protection remain under client control.
  • Normal Safe access does not depend on a password-derived encryption secret.
  • WebAuthn access keys handle authentication.
  • The PIN is a separate control for access throttling, brute-force resistance, and deniability-related flows.

How It Works

  • Local encryption first: records, files, and other protected Safe data are encrypted before leaving the client.
  • AES-256 GCM: UnoLock uses authenticated encryption so ciphertext is protected for both confidentiality and integrity.
  • Client-controlled key material: key material needed to protect data stays under client control rather than being exposed as reusable server-side plaintext.
  • Encrypted storage: once uploaded, UnoLock stores ciphertext rather than plaintext user data.
  • Transport protection on top: TLS protects the transport path, but the main privacy guarantee for stored data begins with client-side encryption.

Security Implications

  • Zero-knowledge storage model: the server stores encrypted data rather than plaintext user content.
  • Reduced trust in infrastructure: client-side encryption limits what storage systems, operators, or attackers can learn from stored data.
  • Tamper detection: AES-256 GCM helps detect unauthorized modification of protected ciphertext.

Use Cases

  • Sensitive Safe records: store legal, financial, operational, or personal records without exposing plaintext to UnoLock servers.
  • Crypto key protection: seed phrases and related recovery material are encrypted before storage.
  • Shared infrastructure with private data: cloud delivery and redundancy can be used without turning the server into the plaintext trust anchor.

Why It Matters

Client-side encryption answers a basic trust question: does the provider ever receive your data in plaintext as part of normal storage? In UnoLock's design, the answer is no for normal Safe storage flows.

FAQs

What is client-side encryption?

It means data is encrypted on your device before it is sent to the cloud or stored remotely.

Is client-side encryption the same as end-to-end encryption?

No. Client-side encryption describes where encryption happens. End-to-end encryption describes how protected data stays encrypted between intended endpoints. UnoLock uses both in different parts of the system.

Can UnoLock access my encrypted data?

Not as plaintext in the normal client-side encrypted storage model. UnoLock stores encrypted Safe data, not your unencrypted content.

Does UnoLock use passwords to derive the main Safe encryption?

No. Normal Safe access relies on WebAuthn access keys, not password-derived encryption. The main password-style exception is optional Space backup files used for controlled backup and restore workflows.

Compliance & Privacy Regulations

  • GDPR & HIPAA Compliance: client-side encryption reduces plaintext exposure of personal and sensitive data and supports privacy-focused handling.

Integration with Other Features

  • FIDO2 Authentication with WebAuthn: authenticates access to the Safe without turning passwords into the main trust anchor.
  • Advanced API Security: protects application communication in addition to client-side protected storage.
  • Enhanced PIN Entry Security: adds access throttling and brute-force resistance around local access flows without replacing the underlying cryptographic model.