3ncr.org

3ncr.org is a standard for string encryption/decryption (algorithms + storage format). Originally it was intended for encryption tokens in configuration files. It may be used to encrypt any UTF-8 strings.

3ncr.org v1 uses AES-256-GCM for authenticated encryption and base64 for encoding binary data back to string. The envelope format is fairly simple:

header + base64(iv + aes-256-gcm(data) + tag)

Encrypted data looks like this 3ncr.org/1#I09Dwt6q05ZrH8GQ0cp+g9Jm0hD0BmCwEdylCh8

The envelope format does not prescribe how the 32-byte AES key is obtained. A key may be supplied directly, or derived from a secret using a key derivation function (KDF). See Key Derivation below.

A self-contained browser demo is available for encrypting and decrypting 3ncr.org v1 values without installing any library.

Envelope Format

A 3ncr.org v1 string consists of the literal header 3ncr.org/1# followed by the base64 encoding of the binary payload. The binary payload is the concatenation of three fixed-layout fields:

iv[12] || ciphertext[N] || tag[16]

• iv — 12 bytes (96 bits). A fresh, cryptographically random value generated per encryption. This is the IV length recommended by NIST SP 800-38D for AES-GCM.
• ciphertext — N bytes, where N equals the length in bytes of the UTF-8 encoded plaintext. AES-GCM is a stream cipher in counter mode, so the ciphertext length matches the plaintext length exactly (no padding).
• tag — 16 bytes (128 bits). The AES-GCM authentication tag. Decoders must verify the tag and reject the input if verification fails.

The AES key is always 32 bytes (AES-256). No associated data (AAD) is used.

The payload is encoded using standard base64 (RFC 4648 §4 alphabet: A–Z, a–z, 0–9, +, /) without padding: any trailing = characters produced by a padded encoder must be stripped before emission. Decoders should accept input with or without padding for robustness.

The minimum binary payload length is 12 + 0 + 16 = 28 bytes, which base64-encodes to 38 characters (no padding).

Key Derivation

The AES-256-GCM cipher takes a 32-byte key. Implementations should accept a raw 32-byte key as their primary input. When a raw key is not available, the recommended derivation depends on the entropy of the source material.

Recommended KDF for low-entropy secrets (passwords, passphrases)

Use Argon2id. For interoperability, implementations should default to these parameters so that the same secret and salt always produce the same derived key:

• memory cost m = 19456 KiB (19 MiB)
• time cost t = 2 iterations
• parallelism p = 1
• output length: 32 bytes
• salt: at least 16 random bytes, stored alongside the ciphertext or otherwise managed by the application
• no associated data and no secret key

These follow the OWASP Password Storage baseline for Argon2id and are compatible with RFC 9106. Implementations must use the raw key-derivation variant that returns 32 raw bytes, not the encoded-string "password hash" variant that embeds its own parameters.

Recommended KDF for high-entropy secrets (random keys, API tokens, etc.)

When the input already carries at least 128 bits of unique entropy — for example a random pre-shared key, a UUIDv4, or a sufficiently long random API token — a full password KDF is unnecessary. A single SHA3-256 hash over the input produces a well-distributed 32-byte AES key. No salt or iteration count is required in this tier.

Legacy KDF (PBKDF2-SHA3)

PBKDF2 with SHA3-256, parameterised by secret, salt and iterations (default 1000), was the original KDF shipped with 3ncr.org v1 and is retained for backward compatibility with existing encrypted data. It is not recommended for new deployments: the default iteration count is too low by modern standards, and PBKDF2 offers no memory-hardness against GPU/ASIC attackers. New code should use one of the recommended KDFs above, or supply the 32-byte AES key directly.

Testing a 3ncr.org implementation

Because 3ncr.org encryption is non-deterministic — a fresh random IV is generated on every call — two encryptions of the same plaintext under the same key produce different ciphertexts. There are therefore no fixed "encryption vectors" to match byte-for-byte. A conforming implementation should instead be exercised along the axes below.

Round-trip

The fundamental property: for any plaintext p and any key, decrypt(encrypt(p)) == p. Cover at minimum:

• the empty string;
• a single ASCII character;
• a short ASCII string;
• a UUID-shaped ASCII string (exercises a length that crosses the base64 / AES block boundaries awkwardly);
• a multibyte UTF-8 string (e.g. Cyrillic, CJK, or emoji) to confirm the plaintext is treated as a UTF-8 byte sequence and not as fixed-width code units.

Decryption against known ciphertexts

While encryption is non-deterministic, decryption is deterministic: given a fixed key, a given ciphertext always yields the same plaintext. The canonical v1 test vectors below use the legacy PBKDF2-SHA3 KDF with secret = "a", salt = "b", iterations = 1000. A new implementation can cross-check itself by decrypting each ciphertext and comparing against the expected plaintext. The vectors are ordered by plaintext length and deliberately cover the edge cases listed under Round-trip above: the empty string, a single ASCII character, a short ASCII string, a UUID-shaped ASCII string, a multibyte UTF-8 string, and a longer multi-sentence ASCII string that crosses several AES blocks. The same vectors are pre-loaded into the browser demo so they can be decrypted interactively.

A more thorough option is a cross-implementation interop test: encrypt with implementation A, decrypt with implementation B, for every (A, B) pair of libraries one cares about. This is the only way to catch subtle divergences (base64 alphabet, padding rules, IV length, tag placement) without relying on a single reference.

Tamper detection

AES-GCM is authenticated encryption. Implementations must reject any input whose authentication tag does not verify. A useful test is to take a valid ciphertext, flip a single bit anywhere in the base64 payload (IV, ciphertext, or tag region), and confirm that decryption fails with an error rather than returning garbage plaintext. Truncated inputs shorter than 28 bytes after base64 decoding must also be rejected.

IV uniqueness

Encrypting the same plaintext twice with the same key must produce two different ciphertexts — if they are ever equal, the IV source is broken. A simple regression test is to call encrypt twice on the same input and assert the resulting strings differ. The first 12 bytes of the decoded payload are the IV; their distribution across many encryptions should be indistinguishable from random.

Envelope shape

The decryptIf3ncr convenience function must return the original string unchanged when the input does not start with the 3ncr.org/1# header. This branch is easy to miss in tests because the happy path exercises only the encrypted form.

Official implementations:

The following libraries implement 3ncr.org version 1:

• tokencrypt (Go)
• nodencrypt (Node.js)
• tokencrypt-php (PHP)
• tokencrypt-python (Python)
• tokencrypt-rust (Rust)
• tokencrypt-java (Java)
• tokencrypt-csharp (C# / .NET)
• tokencrypt-ruby (Ruby)

To have a third-party implementation listed here, please open an issue or pull request on 3ncr/3ncr.org. To report a security vulnerability, please open a private advisory via the Security tab of the relevant 3ncr repository on GitHub.

License

All original content at 3ncr.org is distributed under MIT license:

Copyright (c) 2018-2026 3ncr.org

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.