An open, self-describing container for encrypted files.
The .bge format is an open container for encrypted files. It pairs RSA-4096 public-key encryption with AES-256-GCM authenticated encryption, splits content into independently sealed chunks for constant-memory streaming, and carries an encrypted metadata block so a file can describe itself without being opened.
There are no servers, no accounts, and no proprietary dependencies. A .bge file is a complete, portable cryptographic object — and this document is everything required to read or write one.
A .bge file is read front to back. The header recovers the data key; the metadata block describes the original file; the payload carries its contents as a sequence of sealed chunks.
Every operation uses a published, widely-implemented algorithm. The format defines no novel cryptography of its own.
| Purpose | Algorithm | Parameters |
|---|---|---|
| Payload & key wrapping | AES-256-GCM | 256-bit key · 96-bit random nonce per use · 128-bit tag |
| Identity mode | RSA-4096, OAEP | SHA-256 · MGF1-SHA256 · 512-byte ciphertext |
| Password mode | PBKDF2-HMAC-SHA512 | 16-byte random salt · 1,000,000 iterations (default) |
| Key ID | SHA-256 | First 8 bytes of SHA-256(SPKI DER) of the public key |
The mode byte at offset 5 selects how the Master Key is protected. Everything after the header is identical between the two modes.
The data key is wrapped with the recipient's RSA public key using OAEP. Only the holder of the matching private key can open the file. An 8-byte Key ID lets a reader pick the right key instantly, with no trial decryption.
A key-encryption key is derived from a passphrase with PBKDF2-HMAC-SHA512, then used to wrap the data key with AES-GCM. Anyone with the passphrase can open the file — no app, identity, or key exchange required.
What follows is the complete header definition. The preamble is common to every file; the next block depends on the mode; the file-info block then closes the header.
| Offset | Size | Field | Value |
|---|---|---|---|
| 0 | 4 | Magic | ASCII BGE3 — 42 47 45 33 |
| 4 | 1 | Version | 0x03 |
| 5 | 1 | Mode | 0x01 RSA Identity · 0x02 Password |
| Rel. | Size | Field | Description |
|---|---|---|---|
| +0 | 8 | Key ID | SHA-256(SPKI DER)[0:8] — identifies the private key |
| +8 | 4 | Cipher length N | uint32 — RSA ciphertext length, typically 512 |
| +12 | N | RSA ciphertext | Master Key, RSA-OAEP-SHA256 encrypted |
| Rel. | Size | Field | Description |
|---|---|---|---|
| +0 | 1 | KDF type | 0x01 — PBKDF2-HMAC-SHA512 |
| +1 | 16 | Salt | Cryptographically random |
| +17 | 4 | Iterations | uint32 — readers MUST use this stored value |
| +21 | 12 | Wrap nonce | AES-GCM IV for key wrapping |
| +33 | 4 | Wrap length | uint32 — typically 48 |
| +37 | 48 | Wrapped key | AES-256-GCM(Master Key) + 16-byte tag |
| Rel. | Size | Field | Description |
|---|---|---|---|
| +0 | 8 | Chunk size | int64 — bytes per chunk, default 67,108,864 (64 MB) |
| +8 | 8 | Original size | int64 — size of the unencrypted file |
| +16 | 4 | Chunk count | uint32 — total number of payload chunks |
| Order | Size | Field | Description |
|---|---|---|---|
| 1 | 12 | Block nonce | AES-GCM IV for the metadata block |
| 2 | 4 | JSON length L | uint32 — size of the encrypted JSON, ≤ 65,536 |
| 3 | L | Encrypted JSON | AES-GCM ciphertext, DEK key |
| 4 | 16 | Auth tag | GCM integrity tag |
| Order | Size | Field | Description |
|---|---|---|---|
| 1 | 12 | Nonce | Unique random nonce for this chunk |
| 2 | var | Ciphertext | AES-256-GCM(chunk, DEK) — last chunk may be short |
| 3 | 16 | Tag | GCM authentication tag |
The format has carried three on-disk revisions. A conforming v3 reader can identify and route all of them by inspecting only the first four bytes.
| Version | Signature | Notes |
|---|---|---|
| v3 | bytes = BGE3 | Current. RSA + Password modes, metadata block, Key ID. |
| v2 | byte 0 = 0x02 | Legacy. RSA only, chunked, .enc. |
| v1 | bytes 0–3 = RSA length (512) | Legacy. RSA only, whole-file, .enc. |
Because each version has a disjoint signature, detection never requires a decryption attempt. New revisions extend the magic number rather than overload an existing one.
The format is published so that .bge files outlive any single program. This document, together with the test vectors, is everything required to build a conforming reader or writer — independent implementations are welcome and need no permission.
| Implementation | Platform | Status |
|---|---|---|
| dotbge for iOS | iPhone & iPad | Available |
| dotbge for macOS | Menu bar app | In development |
| bge CLI | Terminal | In development |
| Third-party | Any language or platform | Welcome |
Building a .bge implementation? The format carries no licensing fee and imposes no branding requirement. If you ship one, get in touch and we will list it here.
Clients, downloads, and screenshots for the official apps live on dotbge.app.
This page summarises the format. The complete specification — the full byte-level layout, encryption and decryption flows, chunk-size recommendations, and the metadata schema — is published openly, with test vectors for verifying an implementation.
Yes. The complete byte-level specification is published and free to implement — in any language, for any purpose including commercial use, with no licensing fee. The format relies only on standard, published cryptographic algorithms.
No. A .bge file is self-contained: it carries its own encrypted key and an encrypted description of itself. Encryption and decryption happen entirely on-device, with no server, account, or network connection.
The file payload is encrypted with AES-256-GCM in independently sealed chunks. The data key is protected with RSA-4096 (OAEP-SHA256) for identity-based sharing, or with a PBKDF2-HMAC-SHA512 derived key for password mode.
Yes. The specification and its test vectors are everything required to build a conforming implementation. Independent implementations are welcome and need no permission.
dotbge.com documents the open .bge file format. dotbge.app is the official application that implements it — available for iPhone and iPad, with macOS and a command-line tool in development.