ITBox
Switch tool

AES / DES Crypto

Symmetric encrypt and decrypt with multiple modes and paddings.

Algorithm
Mode
Padding
Output
Key
IV

Expected key: 16 bytes (128-bit). IV: 16 bytes when needed.

Plaintext
0 chars · 1 lines
Ciphertext
0 chars · 1 lines

How to use

Purpose

Online symmetric and asymmetric encryption tool. Supports AES (128/192/256-bit; CBC/GCM/CTR modes), DES, 3DES, RC4, Rabbit symmetric algorithms, and RSA-OAEP asymmetric encryption. Includes password-to-key derivation (PBKDF2), auto-generated or user-specified IV, padding options (PKCS7 default). All encryption/decryption runs locally; ciphertext/plaintext/keys never leave the browser. Common for client-side field encryption, secure notes, API payload protection, and sensitive data storage.

Steps

  1. Pick algorithm: AES (recommended), DES, 3DES, RC4, Rabbit
  2. AES mode: CBC (most common), GCM (authenticated — most secure), CTR, ECB (not recommended)
  3. Key length: AES-128 / 192 / 256 (longer is more secure with negligible perf impact)
  4. Enter key (hex or Base64), or derive from password via PBKDF2
  5. IV (initialization vector): required for CBC/GCM/CTR — auto-generate or specify
  6. Padding: PKCS7 (default), ZeroPadding, NoPadding
  7. Click Encrypt for ciphertext output (Base64 or Hex)
  8. Reverse: paste ciphertext + key + IV, click Decrypt

FAQ

Is AES-256 actually more secure than AES-128? Why is 128 still common?
AES-128 is already secure against all known practical attacks (brute-forcing 128 bits would take all global compute hundreds of billions of years). AES-256 has more theoretical margin but adds key management complexity and modest perf overhead. NIST recommends 128 when the security level allows; 256 for special sensitivity or post-quantum readiness.
Why is ECB mode insecure?
ECB encrypts each block independently — identical plaintext blocks produce identical ciphertext blocks. An image encrypted with ECB still reveals its outline (famous "ECB Penguin" example). Never use ECB. Use CBC (most common) or GCM (authenticated, tamper-evident).
Does the IV need to be secret?
IV does not need to be secret but MUST be random and unique. CBC/CTR with reused (key, IV) leak info. GCM with reused (key, IV) is catastrophic — authentication is broken. Production code must use a fresh random IV every encryption — the tool auto-generates by default. IV is typically stored/transmitted alongside the ciphertext.
Can I just SHA-256(password) to derive a key?
No. A single SHA pass cannot resist brute force (billions of attempts per second). Use PBKDF2/scrypt/Argon2 with salt and tens of thousands of iterations. The tool's "derive from password" uses PBKDF2 + 100,000 iterations + salt.
Can RSA encrypt large files?
No. RSA encryption max length is limited by key size (RSA-2048 up to 245 bytes, RSA-4096 up to 501 bytes). In practice, RSA only encrypts the AES key; files are encrypted with AES (hybrid encryption). The tool warns when the input exceeds RSA limits.

Use cases

  • Frontend field encryption: encrypt ID numbers / credit cards in AES before transport
  • Local secure notes: encrypt sensitive notes in the browser before saving to LocalStorage
  • Config encryption: encrypt password fields in the project so git commits do not leak plaintext
  • Hybrid communication: RSA-exchange an AES key, AES-encrypt data on top of TLS
  • Security audit/testing: verify the AES parameters (mode, padding, IV) used in production code

Use cases

Client-side field encryption, local secure notes, config key encryption, hybrid communication, security audits. Backend, frontend, security engineers, ops. Production code should always use audited standard libraries (do not roll your own primitives). The tool is for debugging and learning. AES-GCM, PBKDF2 derivation, and auto-managed IVs are the differentiators.