Encryption Studio

The Advanced Encryption Standard (AES) is a symmetric block cipher standardizing on 128-bit blocks with key options of 128, 192, or 256 bits. AES is fast, making it ideal for disk encryption, database fields, and bulk file security, but it relies on a secret key that both sides must already share securely before any encrypted communication can happen.

Asymmetric cryptography solves that key-distribution problem using a mathematically related key pair: a public key that can be shared with anyone to encrypt data, and a private key, kept secret, that alone can decrypt it. RSA has been the standard asymmetric cipher, relying on the computational difficulty of factoring the product of two large prime numbers.

Elliptic Curve Cryptography (ECC) achieves the same asymmetric security guarantees as RSA using much smaller keys, based on the algebraic structure of elliptic curves over finite fields rather than prime factorization — this is why ECC has become the default choice for TLS and modern protocols where handshake size and speed matter.

In practice, most real systems combine both: an asymmetric handshake (RSA or ECC) establishes a shared secret between two parties who have never communicated before, and a fast symmetric cipher (AES) then encrypts the actual bulk data using that shared secret — this hybrid approach is exactly how TLS, the protocol behind HTTPS, works.

A common workflow is generating a key pair for a new service or testing environment. Use the RSA Key Pair Generator to produce a public/private key pair locally, then the Encryption Studio to encrypt a test payload with the public key and confirm only the matching private key can decrypt it back to the original.

When setting up a new cryptographic wallet or recovery mechanism that needs to deterministically regenerate the same keys from a memorable phrase, use the BIP39 Passphrase Generator — the resulting mnemonic phrase must be generated with genuine entropy and stored with the same care as a private key, since anyone with the phrase can regenerate the keys it derives.

Before committing to AES-128 versus AES-256 for a specific system, weigh the marginal security benefit against the real, if small, performance cost — see the AES-128 vs AES-256 comparison rather than defaulting to the larger key size without checking whether your threat model actually requires it.

If your system's core security question is whether token or session data can be read by whoever holds it, rather than whether data can be recovered from a compromised database, that is a signing or integrity problem, not an encryption problem — better addressed by the tools in the Authentication & Tokens Lab hub.

Mistake: using ECB (Electronic Codebook) mode for AES encryption. ECB encrypts each block independently, so identical plaintext blocks produce identical ciphertext blocks, meaning patterns in the original data remain visible in the encrypted output. Fix: use an authenticated mode like GCM, which also protects data integrity, not just confidentiality.

Mistake: reusing the same key for multiple unrelated purposes, such as encrypting different data types or both encrypting and signing. Key reuse across purposes can leak information between them and complicates rotating a compromised key without affecting everything else that used it. Fix: derive or generate separate keys per purpose.

Mistake: treating a BIP39 mnemonic phrase as less sensitive than the private key it derives, because it looks like ordinary words rather than a key. It is cryptographically equivalent to the private key — anyone with the phrase can regenerate every key derived from it.

Troubleshooting: if decryption fails with a seemingly correct key, check the encoding of the key and ciphertext first, hex versus base64 versus raw bytes, before assuming the key itself is wrong — a mismatched encoding is a far more common cause of decryption failures than an actually incorrect key.

AES is standardized by NIST FIPS 197. The Galois/Counter Mode (GCM) referenced above, recommended for authenticated encryption, is specified in NIST SP 800-38D.

RSA is described in RFC 8017 (PKCS #1), which defines both the core algorithm and padding schemes; OAEP padding, the modern recommended choice over older PKCS#1 v1.5 padding, is defined in the same document.

Elliptic curve parameters commonly used in TLS and other protocols, including the P-256 and P-384 curves, are defined by NIST SP 800-186 and, for some newer curves such as Curve25519, by RFC 7748.

BIP39, the mnemonic phrase standard, is a Bitcoin Improvement Proposal, not an IETF or NIST standard — it is maintained by the Bitcoin developer community and has become a de facto standard well beyond Bitcoin itself for deterministic key derivation.

For bulk data encryption where both sides already share a secret, use AES; for establishing that shared secret in the first place between parties with no prior relationship, use RSA or ECC. See the RSA vs ECC comparison for which asymmetric approach fits a given system's constraints.

Between AES-128 and AES-256, both are considered secure against any known practical attack today — the choice is mostly about compliance requirements and defense-in-depth margin rather than a real difference in current-day breakability. See the AES-128 vs AES-256 comparison for the specific tradeoffs.

If what you actually need is to verify data has not been tampered with, or to store a credential so it can be verified but not recovered, that is hashing, not encryption — see the Hashing & Integrity hub.