# RNCryptor v3 encrypt

Encrypt text or bytes into the password-based RNCryptor v3 container format, or verify and decrypt one, with base64/hex input and output.

## Run it

- **CLI:** `gizza tool rncryptor-encrypt 'operation=encrypt'`
- **Web:** https://gizza.ai/tools/rncryptor-encrypt/
- **Agents:** machine-readable descriptor (parameters JSON Schema) at https://gizza.ai/tools/rncryptor-encrypt/tool.json

## Inputs

- `operation` — Operation _(field)_
- `data` — Data _(field)_
- `password` — Password _(field)_
- `data_encoding` — Input encoding _(field)_
- `output_encoding` — Output encoding _(field)_
- `encryption_salt` — Encryption salt (optional hex) _(field)_
- `hmac_salt` — HMAC salt (optional hex) _(field)_
- `iv` — IV (optional hex) _(field)_

## Output

- RNCryptor container or plaintext (text)

## Query parameters

Open the tool pre-filled and auto-run via URL:

- `operation` — Operation
- `data` — Data
- `password` — Password
- `data_encoding` — Input encoding
- `output_encoding` — Output encoding
- `encryption_salt` — Encryption salt (optional hex)
- `hmac_salt` — HMAC salt (optional hex)
- `iv` — IV (optional hex)

Example: `https://gizza.ai/tools/rncryptor-encrypt/?operation=encrypt&data=attack%20at%20dawn&password=thepassword&data_encoding=text&output_encoding=base64&encryption_salt=0001020304050607&hmac_salt=0102030405060708&iv=02030405060708090a0b0c0d0e0f0001`

---

## About this tool

RNCryptor is a container format used by mobile and scripting libraries to wrap password-encrypted data. This tool emits the full password-based v3 blob: version `0x03`, options `0x01`, an 8-byte encryption salt, an 8-byte HMAC salt, a 16-byte AES-CBC IV, padded ciphertext, and a trailing HMAC-SHA256 tag. The result is not bare AES ciphertext; it is the interoperable container another RNCryptor implementation expects.

The cryptographic settings are fixed by the v3 password format: AES-256-CBC with PKCS#7 padding, PBKDF2-HMAC-SHA1 with 10,000 iterations for each 32-byte key, and HMAC-SHA256 over the header plus ciphertext. Leave the salt and IV fields empty for real data so the browser generates fresh random bytes. Fill them only when you need byte-for-byte reproducible output for a test vector.

Worked example: set operation to `encrypt`, data to `01`, password to `thepassword`, input encoding to `hex`, output encoding to `hex`, encryption salt to `0001020304050607`, HMAC salt to `0102030405060708`, and IV to `02030405060708090a0b0c0d0e0f0001`. The output starts with `030100010203040506070102030405060708020304...`; switching operation to `decrypt` with that container returns `01`.

Limits and edge cases: decoded inputs are capped at 4 MiB to keep browser memory bounded; only RNCryptor version 3 password containers are supported; key-based containers and legacy v1/v2 blobs are rejected; wrong passwords and tampered containers fail during HMAC verification before any plaintext is returned.

## FAQ

<details>
<summary>Why are there no controls for AES mode, key size, or PBKDF2 iterations?</summary>

Those values are part of the RNCryptor v3 password format. Changing them would create a private blob that looks encrypted but cannot be opened by standard RNCryptor libraries, so this tool keeps them pinned and exposes only byte-handling controls.

</details>

<details>
<summary>Should I fill in the salt and IV fields?</summary>

Usually no. Empty fields make the browser generate fresh random salts and a fresh IV for each encryption, which is the safe default. The hex override fields exist for deterministic tests, migrations, and spec-vector reproduction.

</details>

<details>
<summary>Can this decrypt containers from an iOS or Android app?</summary>

Yes, if they are password-based RNCryptor v3 containers. Paste the base64 or hex container, choose `decrypt`, and enter the same password. The HMAC is checked before unpadding, so a wrong password or modified blob returns an error rather than confusing plaintext.

</details>

<details>
<summary>What input encoding should I choose for binary data?</summary>

Use `hex` or `base64` so the data is decoded to raw bytes before encryption. `text` treats the input as UTF-8 text when encrypting; when decrypting, `text` auto-detects whether the pasted container looks like hex or base64.

</details>

## Related tools

- [CipherSaber-2 cipher](https://gizza.ai/tools/ciphersaber2/): Encrypt and decrypt CipherSaber-2 (RC4 with a 10-byte IV and repeated key setup) in your browser — hex or base64 output. Free, private, nothing uploaded.
- [AES cipher](https://gizza.ai/tools/aes-cipher/): Encrypt or decrypt text with AES in CBC, CTR, GCM or ECB mode and 128/192/256-bit keys, with hex/base64 I/O — in your browser. Nothing is uploaded.
- [AES-CMAC Generator](https://gizza.ai/tools/cmac-generate/): Generate an AES-CMAC (NIST SP 800-38B / RFC 4493) of any message and key in your browser — AES-128/192/256 by key length, hex or base64 output. Free and private.
- [HKDF key derivation](https://gizza.ai/tools/hkdf-derive/): Derive keys with HKDF, the HMAC-based extract-and-expand KDF from RFC 5869 — choose hash, salt, info label, length and hex/base64 output, all in your browser.
- [HMAC Generator](https://gizza.ai/tools/hmac-generate/): Generate an HMAC of any message and secret key in your browser — HMAC-SHA256, SHA-1, SHA-512, SHA-3 or MD5, hex or base64 output. Free and private.