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 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]
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).
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.
Use Argon2id. For interoperability, implementations should default to these parameters so that the same secret and salt always produce the same derived 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.
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.
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.
The following libraries implement 3ncr.org version 1:
Send email to 3ncr at andrian dot io if you want your implementation to be referenced here.
All original content at 3ncr.org is distributed under MIT license:
Copyright (c) 2018 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.