JPKCom DB

Cryptor (AES-256) — Manual

Full reference for Cryptor: AES-256-GCM, PBKDF2 with 300,000 iterations, the output format, every button, file operations, and operating limits.

Back to overview: Cryptor (AES-256) · Open the live tool: www.jpkc.com/tools/cryptor/

This manual describes Cryptor (AES-256) in full: how the interface is laid out, which crypto parameters apply exactly, what each button does, and what limits browser-based operation brings. The tool's interface is in English, so the labels appear here in their original spelling.

Interface layout

Cryptor has two columns:

  • Input (left) — a password field (Password) with a generate button, and a large text area (Message) for plaintext or ciphertext.
  • Encryption and File Operations (right) — the action buttons.

The password field is an ordinary text field, so its content is visible (not masked as dots). The hint below it — "Used for both encryption and decryption" — captures the core principle: there is just one password, used both to encrypt and to decrypt. Lose it, and the ciphertext is no longer readable.

The Message field does double duty: it holds either the plaintext you want to encrypt or the ciphertext you want to decrypt. The result of an action replaces the field's content.

Workflow

The typical workflow has three steps:

  1. Enter a password — type your own or have one generated via the key button.
  2. Enter text — plaintext (to encrypt) or ciphertext (to decrypt) in the Message field.
  3. Choose an action — Encrypt or Decrypt. The result appears in the same field and can be copied or saved.

On load, Cryptor checks whether the browser supports the Web Crypto API. If it's missing, an error appears and the Encrypt/Decrypt buttons stay disabled.

Crypto parameters in detail

Cryptor's modern encryption uses the browser's Web Crypto API (crypto.subtle). The parameters are hard-wired and follow common recommendations.

AES-256-GCM

The algorithm is AES with a 256-bit key in GCM mode (Galois/Counter Mode). GCM is an authenticated encryption (AEAD): alongside the ciphertext it produces a 128-bit authentication tag. During decryption the browser verifies this tag — if it doesn't match (wrong password, tampered or corrupted ciphertext), decryption fails instead of returning faulty plaintext.

PBKDF2 key derivation

The actual AES key is derived from your password via PBKDF2, using the hash function SHA-256 and 300,000 iterations. That iteration count follows an OWASP recommendation and is deliberately high: it slows down each individual derivation attempt and thereby makes systematic password guessing expensive.

Salt and IV

Before every encryption, Cryptor generates two random values from the browser's cryptographically secure generator (crypto.getRandomValues):

  • a salt of 16 bytes (128 bits) — it feeds into the PBKDF2 derivation, so the same password yields a different key every time;
  • an IV (initialization vector) of 12 bytes (96 bits) — the recommended length for GCM.

Because the salt and IV are newly random on every run, the same text with the same password produces a different ciphertext each time. That is intentional and a sign of correct cryptography.

Output format

The ciphertext is emitted as a single Base64 string. Before Base64 encoding, the components are concatenated in this order:

Base64( salt[16 bytes] + iv[12 bytes] + ciphertext + tag[16 bytes] )

So the salt and IV travel inside the ciphertext — they need not be secret and are required for decryption. The 128-bit authentication tag (16 bytes) is appended by the GCM mode. To decrypt, Cryptor splits the Base64 block back into salt, IV, and data, derives the key with the salt, and decrypts. If the block is too short (shorter than salt + IV + tag + at least one byte), it is rejected as invalid.

The actions in detail

Encrypt

Encrypts the Message field's content with the password. Preconditions the tool checks:

  • There must be text (otherwise "Please enter a message to encrypt.").
  • There must be a password (otherwise "Please enter a password.").
  • The password must be at least 8 characters long (otherwise "Password should be at least 8 characters.").

While computing, the button shows a loading state. Afterwards the Base64 block sits in the Message field and a notice confirms "Message encrypted with AES-256-GCM.".

Decrypt

Decrypts the Message field's content with the password. Here too, text and password must be present. Cryptor detects the format automatically:

  • If the ciphertext begins with the string U2FsdGVkX1 (that's Base64 for Salted__), the tool treats it as the legacy format and decrypts it with the bundled legacy library (see below).
  • Otherwise it is decrypted as a modern AES-256-GCM ciphertext via the Web Crypto API.

If decryption fails — say because of a wrong password or corrupted data — the message "Decryption failed. Check your password." appears and the field content stays unchanged.

Generate secure password

The key-icon button next to the password field produces a 64-character random password and fills it in. The password comes from a small server endpoint that assembles it with PHP's cryptographically secure random_int from a character set of lower- and uppercase letters, digits, and a range of special characters (, . - ; _ # + * ! § $ % & / ( ) = ?). No data of yours is transmitted — the endpoint just returns the string.

The underlying endpoint accepts a length from 1 to 64 characters (call pattern /tools/cryptor/pw/{length}/); the button in the interface always requests the maximum length of 64. It's purely a convenience for password generation, not a documented public API.

Copy

Copies the current Message field content to the clipboard. If the field is empty, the hint "Nothing to copy." appears.

Open, Save, Clear

The File Operations card bundles file handling:

  • Open opens a file dialog (accepts .txt, .enc, .aes) and loads the chosen file's text content as UTF-8 into the Message field.
  • Save stores the current field content as a text file named encrypted.txt (downloaded via the browser). If the field is empty, you get "Nothing to save.".
  • Clear wipes both the Message field and the password field. Handy for not leaving sensitive remnants behind once you're done.

Drag and drop

You can drag and drop a file directly onto the Message field; its text content is then loaded (as with Open) as UTF-8. While you drag a file over the field, it highlights visually.

Legacy format (gibberish-aes)

For compatibility, Cryptor ships a legacy library (gibberish-aes) — but for decryption only. It lets you read messages encrypted with an earlier version of the tool (in the OpenSSL-style Salted__ format). When Cryptor detects this old format during decryption, it points it out and recommends re-encrypting ("Legacy message decrypted. Re-encrypt for better security."). New encryption only ever uses the modern AES-256-GCM format — the legacy format can only be read, no longer produced.

Operating limits and privacy

  • Client-side: encryption and decryption run entirely in the browser. Plaintext, password, and ciphertext never leave it. The only optional server interaction is password generation, during which no user data is transmitted.
  • Secure context required: the Web Crypto API requires HTTPS (or localhost). Without it, Encrypt/Decrypt are disabled.
  • No history: Cryptor deliberately stores nothing between runs — no history, no local cache of content. Reloading means: empty field.
  • Password minimum length: 8 characters to encrypt (the generated password, at 64 characters, is much longer).
  • No key recovery: without the correct password there is no way back to the plaintext — that is the whole point, but also the biggest pitfall.

For the introduction and target audiences see the overview page. Concrete walkthroughs are in the examples, strategy and pitfalls in the tips & tricks. You can try everything directly in the tool.