Encryption Documentation
Hlam app (hlam.app) · last updated July 22, 2026 · support@hlam.app
This document describes the cryptography used by the Hlam mobile application. It is published for transparency and to support export-compliance declarations (Apple App Store export compliance, French ANSSI, and U.S. Export Administration Regulations). Hlam uses only standard, published encryption algorithms — no proprietary or non-standard cryptography.
1. Overview
Hlam encrypts users' inventory data end-to-end. Content is encrypted on the user's device before it leaves it, and the server stores only ciphertext — it cannot read the user's data. Encryption is used solely to protect the user's own data (confidentiality and integrity). Hlam is not a cryptographic product and does not provide any encryption capability to third parties.
2. Algorithms
| Purpose | Algorithm | Parameters | Standard |
|---|---|---|---|
| Data confidentiality & integrity | AES-GCM (authenticated encryption) | 256-bit key · 96-bit random nonce per message · 128-bit authentication tag | NIST FIPS 197 (AES) · NIST SP 800-38D (GCM) |
| Key derivation (recovery) | Argon2id (memory-hard KDF) | Derives a 256-bit key-encryption key (KEK) from the recovery phrase + per-user salt | RFC 9106 |
| Recovery phrase | BIP-39 mnemonic (English word list) | 12 words · 128-bit entropy + SHA-256 checksum | SHA-256: NIST FIPS 180-4 |
| Transport | TLS / HTTPS | Provided by the operating system (iOS / Android) | IETF TLS 1.2+ |
3. Key management
- Data Encryption Key (DEK): a 256-bit key generated on the device with a cryptographically secure random source. Each user account has its own DEK. All user content is encrypted under the DEK using AES-256-GCM.
- Local storage of the DEK: the DEK is held in the platform secure store — the iOS Keychain or the Android Keystore.
- Key Encryption Key (KEK): to allow the user to recover data on a new device, the DEK is wrapped (encrypted) under a 256-bit KEK. The KEK is derived on-device with Argon2id from the user's 12-word BIP-39 recovery phrase and a per-user salt. The KEK never leaves the device.
- Server-side escrow: the server stores only the wrapped DEK (as ciphertext) together with its nonce. The server never receives the recovery phrase, the KEK, or the plaintext DEK, and therefore cannot decrypt user data.
4. Implementation
The application-layer encryption (AES-256-GCM, Argon2id, BIP-39) is implemented with the open-source PointyCastle cryptography library for Dart. These are standard, publicly documented algorithms. The app does not implement any secret or proprietary cryptographic algorithm. Transport security (TLS) is provided by the underlying operating system.
5. Export classification
Because Hlam uses only standard published encryption algorithms to protect the user's own data, and provides no cryptographic functionality to third parties, it is a mass-market application under U.S. EAR Category 5, Part 2 and the equivalent French regime for standard cryptographic means. The publisher remains responsible for filing any required declarations (e.g. a self-classification report with U.S. BIS and a declaration to the French ANSSI where applicable). This page is technical documentation, not legal advice.
6. Contact
Questions about this document: support@hlam.app.