Minimum macOS 15.0; native SwiftUI application.
B Safe
B Safe Technical Details
Technical reference for B Safe 2.1: vault format, cryptography, filesystem controls, licensing, updates and operational limits.
The main application opens only the active v11 vault format.
Content and hidden descriptors use authenticated encryption.
64/128/256 MiB memory, 3 iterations and parallelism 2.
Signed appcast and release artifact verification.
Runtime and application boundaries
B Safe 2.1 build 3 requires macOS 15.0 or later. It is built with SwiftUI and uses App Sandbox, hardened runtime, user-selected read/write access and app-scoped security bookmarks.
Network client access is used for license validation, device-block status, optional anonymous usage statistics and Sparkle update checks. Vault contents are not sent through normal licensing or telemetry flows.
Vault format and cryptographic structure
The active container uses the BSAR magic value and format version v11. Unsupported legacy formats are not silently opened. The header stores format, encryption flag, salt, Argon2id parameters, hidden-section descriptor and preview-catalog length.
Content is sealed with AES-256-GCM using a 32-byte encryption key. A separate integrity key produces HMAC-SHA512. Random salts and cryptographic bytes are generated through SecRandomCopyBytes.
Argon2id and keyfile parameters
Argon2id produces 96 bytes: the first 32 bytes become the encryption key and the remaining 64 bytes become the HMAC key. Standard, high and maximum modes use 64, 128 and 256 MiB memory; each uses 3 iterations and parallelism 2.
Header-supplied Argon2id values are validated before use against 32-256 MiB memory, 2-8 iterations and maximum parallelism 8. Keyfiles are SHA-512 hashed in 1 MiB chunks and appended to the password secret.
Hidden sections, header and manifest validation
The hidden-section descriptor is protected with AES-GCM using a key derived from its separate password. Reusing the main vault password for the hidden section is rejected.
Before opening a vault, the app validates header lengths, Argon2id parameters, catalog size, payload bounds and overflow conditions. Path traversal, absolute paths, Windows separators, excessive path depth and suspicious manifest entries are rejected.
Filesystem, extraction and operational limits
Extraction is limited to 10,000 files, 1 GiB per file and 8 GiB total. Preview data and preview catalog are each limited to 16 MiB; text indexing is limited to 256 KiB per file and 500 files.
Large file operations use streaming I/O. Secure deletion does not follow symlinks, removes only the path for hardlinked data and checks inode identity to reduce TOCTOU risk.
Licensing, device blocks and network validation
License responses are verified using Ed25519-signed tokens. The license server is accessed over HTTPS and the app validates configured SHA-256 certificate pins.
Device matching evaluates a persistent device UUID together with a hardware-bound SHA-256 fingerprint. Active blocks are persisted locally and cleared only after the server confirms that the device is allowed.
Update chain and release verification
The application checks updates through Sparkle 2.9.1. Appcast version, build, minimum system version, artifact length and EdDSA signature are verified with the release artifact.
A 2.1 release must be published with minimum macOS 15.0.0. Release builds should pass codesign, notarization and staple verification before the DMG is published.