SimpleumSafe 3 Security – Technical White Paper

SimpleumSafe separates encrypted file contents, encrypted metadata, and the keys required to open them. The Safe password protects the key file; it is not used as the file-encryption key itself.

This white paper explains the current SimpleumSafe 3 architecture for technical reviewers and interested users. It focuses on data at rest, key management, the macOS working-copy boundary, backups, and synchronization.

Published by: Simpleum Media GmbH Last technically reviewed: 21 Aug 2026 Document version: 3.2

At a glance

• File contents are stored as individually encrypted files with non-meaningful UUID-based names.
• File names, folder relationships, dates, tags, comments, and other metadata are stored in encrypted SQLCipher databases.
• SimpleumSafe generates random encryption keys. The Safe password protects the key file that contains those keys.
• The normal synchronization target contains encrypted Safe data, but not the separate Safe key file.
• Previewing, editing, sharing, and exporting require a usable copy. The protection boundary changes for that authorized copy.
• Simpleum Media cannot recover a forgotten Safe password or recreate missing Safe key material.

Scope and security boundaries

SimpleumSafe adds an application-level encryption layer to the protections already provided by macOS, iOS, and iPadOS. It is designed to protect the data stored inside a closed or locked Safe and the encrypted data transferred by SimpleumSafe synchronization.

For a broader product-level explanation of these protection layers, see Security of SimpleumSafe.

Encryption does not remove every risk. Protection also depends on:

• a strong, unique Safe password;
• the security and update status of the device;
• keeping key and recovery material separate from untrusted copies of the Safe;
• locking the Safe when it is not in use;
• maintaining and testing independent backups; and
• handling exported, shared, or externally edited copies appropriately.

Design principles

Usable security

SimpleumSafe is intended to make encrypted file storage practical without requiring users to configure cryptographic algorithms. Its interface combines encryption with everyday archive functions such as folders, tags, favorites, comments, import, export, preview, and editing.

Established cryptographic components

The architecture uses established formats and libraries rather than proprietary encryption algorithms:

• AES-256 for file and database encryption;
• the RNCryptor Version 3 data format for encrypted key files and encrypted file payloads; and
• SQLCipher for encrypted SQLite databases.

For a shorter explanation of the algorithms and their roles, see Which encryption method does SimpleumSafe use?.

Data minimization between software layers

Encryption and key-management operations are concentrated in the Simpleum®Cryptor component. Other parts of the application request operations from this component instead of reading encryption keys directly. This reduces the amount of code that handles key material, but it does not replace normal secure-development practices, testing, or platform protections.

Encrypted by default inside the Safe

SimpleumSafe keeps stored file contents and metadata encrypted. Decryption happens when an authorized operation needs the information, for example to display a file name, render a preview, edit a file, share it, or export it.

Storage model

Every imported file is represented by two protected parts:

1. Encrypted file data: the binary contents of the file.
2. Encrypted attributes: the original file name, folder relationship, dates, tags, comments, and other management data.

Separating these parts avoids rewriting a large encrypted file when only a small attribute changes. It also supports transactional updates, backups, and synchronization.

1 Original file

2 Encrypted on import

3 Stored separately in the Safe

Import

An import is processed transactionally. SimpleumSafe records the file attributes in the encrypted database and writes the file contents as an encrypted binary file. Long-running imports can be paused and resumed.

The encrypted data filename is based on a UUID and does not contain the original file name or other imported attributes.

Export, share, preview, and edit

An export reconstructs the file name, folder hierarchy, dates, and file contents at the chosen destination. That exported copy is no longer protected by the Safe.

Previewing and editing also require a usable copy. On macOS, SimpleumSafe places that copy in encrypted temporary storage as described below. An external editing application can read the working copy while it is open.

Backup

SimpleumSafe’s Safe Backup copies encrypted file data and stores the information required to reconstruct the archive in an encrypted, restore-oriented format. A backup is separate from synchronization: synchronization propagates changes and deletions, while a backup is intended to preserve a recoverable state.

Backups remain dependent on their associated key material. A backup process should therefore include both the Safe backup and a tested recovery plan, with recovery credentials stored separately.

The practical backup strategy is explained in Why backups are part of digital security.

Key hierarchy and opening a Safe

Creating a Safe

When a Safe is created, SimpleumSafe generates random keys for file data and encrypted databases. These keys are written to the Safe key file (k.crypt).

The user chooses a Safe password. RNCryptor derives separate encryption and authentication keys from that password and random salts. Those derived keys protect the Safe key file. Neither the Safe password nor the derived keys are stored.

This distinction is important:

• the Safe password unlocks the Safe key file;
• the Safe key file contains randomly generated encryption keys; and
• those random keys protect file data and databases.

Changing the Safe password therefore re-protects the key file; it does not require every stored file to be encrypted again.

Opening a Safe

When a user enters the Safe password, SimpleumSafe attempts to authenticate and decrypt the Safe key file. In the RNCryptor Version 3 format, an authentication failure does not reveal whether the password is incorrect or the encrypted data is damaged. SimpleumSafe therefore treats both cases as a failed open operation.

If the key file opens successfully, the Simpleum®Cryptor retains the required key material for the authorized Safe session. Simpleum Media does not receive the Safe password or a service-side copy of the key file and cannot reconstruct access if both the password and recovery material are unavailable.

Safe package structure

A Safe uses a package structure containing key material, encrypted databases, and encrypted file payloads. Figure 2 shows the core storage relationship. It is intentionally simplified: feature-specific key files, configuration, settings, transaction, synchronization-bookkeeping, and operating-system support files may also be present.

k.crypt Safe key fileRequired to open the Safe

r.crypt Recovery key fileOptional; store separately

*.crypt Encrypted databasesAttributes, settings, and transactions

files/ Encrypted file dataUUID-named encrypted payloads

Safe key file

The Safe key file contains the random keys used for file data and encrypted databases. Its outer encryption uses the RNCryptor Version 3 format with password-based key derivation.

New and migrated SimpleumSafe 3 key files use 1,000,000 PBKDF2-HMAC-SHA-1 iterations. Older key files that used 10,000 iterations remain readable as a compatibility path and are rewritten with the current setting after a successful open.

For each password-protected RNCryptor message, SimpleumSafe uses:

1. an 8-byte random encryption salt;
2. PBKDF2-HMAC-SHA-1 to derive a 32-byte encryption key;
3. a separate 8-byte random HMAC salt;
4. PBKDF2-HMAC-SHA-1 to derive a separate 32-byte HMAC key;
5. a 16-byte random initialization vector;
6. AES-256 in CBC mode for encryption; and
7. HMAC-SHA-256 over the header and ciphertext for authentication.

PBKDF2-HMAC-SHA-1 is the key-derivation construction defined by the RNCryptor Version 3 format. SHA-1 is used here as the pseudorandom function inside PBKDF2; HMAC-SHA-256 authenticates the resulting RNCryptor message.

Optional recovery key file

The recovery key file (r.crypt) contains the same type of Safe key material as the main key file, but it is protected by a separate, randomly generated recovery password. Creating it requires authorization with the current Safe password.

The recovery password is shown to the user for separate storage. It can restore access if the normal Safe password is forgotten. Anyone who obtains both the recovery key file and its recovery password may be able to access the Safe, so they should not be stored together.

Encrypted databases

File names, dates, folder relationships, tags, comments, and other Safe metadata are stored in encrypted SQLite databases. SimpleumSafe uses SQLCipher with a randomly generated database key stored in the Safe key file.

SQLCipher encrypts database pages with AES-256 and authenticates them. Database access remains transactional while the on-disk database contents are encrypted.

Encrypted file data

The files directory stores encrypted file payloads. Each payload uses a UUID-based name ending in .data.crypt. Subdirectories are derived from the first two UUID characters to limit the number of entries in one directory.

File payloads use the RNCryptor Version 3 container with AES-256-CBC encryption and HMAC-SHA-256 authentication. The file-encryption and authentication keys are random keys from the Safe key file, not keys derived directly from the file name or Safe password.

RNCryptor Version 3 byte layout

The following table describes the password-based RNCryptor Version 3 container used for the Safe key file. The iteration count is an application setting and is not encoded in the container.

Swipe or scroll horizontally to see all columns.

All multi-byte values are in network order. The RNCryptor format version is separate from the SimpleumSafe key-file schema version and the SimpleumSafe application version.

Read the RNCryptor Version 3 specification

Secure temporary storage on macOS

Some macOS workflows require a file-system copy, for example when Quick Look or an external application opens a file. SimpleumSafe creates a new encrypted temporary workspace when the app starts.

For an authorized preview or edit operation, SimpleumSafe:

1. places the file in the encrypted temporary workspace;
2. opens the preview or editing application with that working copy;
3. observes save events and imports changes back into the Safe; and
4. removes the working copy after the external application closes.

When the temporary workspace is retired, SimpleumSafe changes its password to a new random value that is not stored and does not reuse that workspace. This avoids relying on secure erasure of individual blocks on an SSD.

Authorization controls

Security-relevant changes, such as changing the Safe password or selected automatic-lock settings, require renewed authorization with the current Safe password.

After an incorrect password attempt, the interface delays the next attempt. The delay grows exponentially: 2 seconds, then 4, 8, 16, 32 seconds, and so on for repeated attempts in that session. This slows interface-based guessing; it does not replace a strong password or the cost added by PBKDF2 for offline attempts.

When a new password is chosen, SimpleumSafe uses the zxcvbn password-strength estimator to provide feedback. Such estimates are guidance, not a guarantee of the time an attacker would need.

Encrypted synchronization

SimpleumSafe supports three synchronization paths:

• iCloud synchronization via CloudKit for Apple devices;
• direct device-to-device synchronization using Apple’s Multipeer Connectivity technologies; and
• folder synchronization between Macs through a shared folder, for example on a NAS or removable drive.

Simpleum Media does not operate a separate synchronization server for these methods.

Synchronization model

Each device records Safe changes in encrypted transaction data. During synchronization, devices exchange and integrate new transactions and transfer the corresponding encrypted file payloads. Metadata can arrive before a large file payload; the interface may therefore show an entry before its file content has finished transferring.

Synchronization data remains encrypted at the source device, on the synchronization target, and on the receiving device until an authorized Safe session uses it.

Synchronization configuration

A synchronization configuration identifies the Safe and the selected synchronization method and contains the key material needed by the receiving device. It is encrypted with the Safe password and transferred directly as a file or through device-to-device nearby networking.

The synchronization configuration is distinct from the normal synchronization target. It should be handled as sensitive key material and not left with an untrusted copy of the synchronization data.

No Safe key file in the synchronization target

The normal CloudKit, shared-folder, or device-to-device synchronization dataset does not contain the separate Safe key file. Therefore, a copied synchronization dataset plus knowledge of the Safe password is not sufficient by itself to decrypt the synchronized Safe data.

This boundary no longer holds if an attacker also obtains a synchronization configuration, Safe key file, recovery material, an unlocked endpoint, or control of a configured device.

Synchronization is not a backup. Deletions and unwanted changes can propagate to other devices, so an independent, tested backup remains necessary.

Software development controls

SimpleumSafe development uses issue tracking and version control to make requirements and code changes traceable. Security-relevant components and user flows are covered by automated unit and user-interface tests. These controls reduce risk but do not prove that software is free of defects.

Glossary

Explore further

• How SimpleumSafe worksA less technical overview of the product architecture and everyday workflow.
• Security of SimpleumSafeProtection layers, practical safeguards, and the Security Center.
• Encryption methodsA concise explanation of AES-256 and the protected components.
• Support and FAQsAnswers, tutorials, release notes, and ways to contact support.

References

• NIST FIPS 197: Advanced Encryption Standard
• RNCryptor Version 3 specification
• SQLCipher security design
• Apple CloudKit documentation

Version history