Why Decryption Fails: Keys, IVs, Chunking, Separators
When encryption throws an error, the algorithm is almost never at fault. What goes wrong is how the key is interpreted, whether the IV was reused, which length the chunking used, and what separator convention the input follows.
- An AES key is read as bytes only when it is pure hex, even-length and exactly the algorithm's size; anything else is treated as UTF-8 text and padded or truncated
- Reusing the same IV under one key leaks the XOR of two plaintexts, and under GCM it breaks authentication outright
- RSA can encrypt at most the key size in bytes minus 66 per block, and chunking must follow the imported key length rather than the size picked in the interface
- International Morse uses three spaces between letters and seven between words, so pasting it into a tool that expects single spaces decodes into nonsense
- CBC has no integrity protection, so a modified ciphertext usually decrypts to garbage without any error - new projects should prefer GCM
#Rule out the algorithm first
AES and RSA run in millions of projects, so a wrong result is almost never the algorithm's fault - it is how the parameters were interpreted. Start the investigation with the parameters, not the maths.
Four causes, each with its own way to confirm:
| Symptom | Likely cause | How to verify |
|---|---|---|
| Encrypts fine, will not decrypt | Key or IV read as text | Check the key is pure hex of the right length |
| Works for one message, fails for the next | IV reused | Check every ciphertext carries its own IV |
| RSA reports a length error | Chunked at the selected bit size | Compute from the imported key length |
| Morse decodes into nonsense | Separator convention mismatch | Check single spaces versus three spaces |
#AES: how the key gets interpreted
The parsing rule decides which key you are actually using - the same characters can become two completely different keys. This is the most common reason a message encrypts fine but the other side cannot read it.
With the AES and DES tool the rule is: pure hex, even length, and exactly the size the algorithm requires means it is read as bytes. Anything else is treated as UTF-8 text and padded or truncated to the target length.
The sizes each mode requires:
- AES-128 key 16 bytes, AES-256 key 32 bytes, IV 16 bytes
- AES-GCM IV is fixed at 12 bytes
- DES key 8 bytes, IV 8 bytes
A key that looks like hex but is one character short will, if treated as text and padded, encrypt successfully - with a different key than the one you intended. Nobody can decrypt that. This is why a hex-shaped key of the wrong length now raises an error instead of converting silently.
#IV reuse: the most dangerous silent mistake
Reusing one IV under one key leaks the XOR of two plaintexts, so an attacker recovers content without breaking the algorithm at all. It is the only failure that neither errors nor fails - it is simply already insecure.
The two modes are sensitive in different ways:
- CBC has no integrity protection. A modified ciphertext usually decrypts to garbage without an error, and if the padding happens to validate, not even that
- GCM is authenticated encryption with a 16-byte tag, so a single wrong byte fails immediately. The cost is that GCM is more sensitive to IV reuse: repeating one both leaks the plaintext relationship and destroys authentication
Prefer GCM for new work. Use CBC only to interoperate with legacy systems, and make sure every message carries its own random IV stored alongside the ciphertext.
Output format can also cause a failure to decrypt: the format is detected automatically, so pure-hex ciphertext of even length is read as Hex and everything else as Base64. A Base64 string that happens to contain only the characters 0-9a-f at even length will be misread as Hex. It is rare but real - if decryption fails, try the other output format first.
#RSA: chunk size follows the key
The most RSA can encrypt in one block is the key size in bytes minus 66. That 66 is OAEP overhead: a SHA-256 digest counts as 2 × 32 bytes, plus 2 bytes of framing.
The limits for common sizes:
- 2048 bits → 190 bytes
- 3072 bits → 318 bytes
- 4096 bits → 446 bytes
Anything longer is split at that boundary and the ciphertext blocks are concatenated in order.
The trap with the RSA tool: chunking follows the key you actually imported, not the bit size selected in the interface. Paste a 2048-bit public key while chunking at 3072 and encryption fails; judge ciphertext length against 384 bytes and a perfectly valid message gets rejected.
Know the boundaries too: this tool does RSA-OAEP with SHA-256 only - public key encrypts, private key decrypts. Signing and verification are a separate operation and are not offered. It accepts SPKI public keys and PKCS#8 private keys; PKCS#1 files are rejected and need an openssl conversion first.
RSA should never encrypt bulk data directly. The standard engineering answer is hybrid encryption: wrap a temporary AES key with RSA and hand the payload to AES-GCM. That avoids chunk overhead and gains integrity protection.
#Morse code: the separator is the information
In Morse the letter and word boundaries exist only as spaces, so a mismatched convention guarantees a wrong decode - that is bad input, not a decoding bug. Before using the Morse converter, confirm which convention the source used.
Two conventions coexist:
- This tool: a single space between letters, a slash (or a vertical bar, or three or more spaces) between words
- Classic telegraphy: three spaces between letters, seven between words
Paste a three-space message into a tool expecting single spaces and every space becomes a letter boundary, leaving a string of broken groups.
A few points that come up constantly:
- SOS is one group - three dots, three dashes, three dots sent continuously - not three letters
- Chinese cannot be represented, because Morse covers Latin letters, digits and a small punctuation set
- Characters outside the set are preserved and counted in the status bar rather than silently dropped
#Which tool to use
| What you need | Tool | Key constraint |
|---|---|---|
| Encrypt text symmetrically | AES and DES tool | Key read as hex or text; length must be exact |
| Public key encrypt, private key decrypt | RSA tool | SPKI + PKCS#8 only; chunking follows the key |
| Encode or decode Morse | Morse converter | Separator convention must match the source |
| Verify file integrity | MD5 tool | Hashing is one-way, not encryption |
| Generate unique identifiers | UUID generator | v4 is random; v1 embeds time and node |
A useful decision order: need to get the content back - encrypt (AES, RSA); only need to compare - hash (MD5, SHA); only need to transport - Base64. Mixing those three up is another frequent source of bugs, since Base64 has no key at all.
#Frequently asked questions
#The same key does not decrypt on the other side. Why?
Most likely the key became different bytes. Take 32 characters: read as hex on your side that is 16 bytes, read as UTF-8 and truncated to 16 characters on theirs, and you are using two unrelated keys. Agree on the key representation - hex or text - and write it into the interface contract.
#Encryption succeeds but decryption errors. What is wrong?
Three usual causes: a key or IV of the wrong length silently padded, a ciphertext truncated or concatenated in the wrong order, and an output format misdetected because a Base64 string looked like even-length hex. Try the other format first, then compare the key byte by byte.
#Can I hard-code a fixed IV?
No. A fixed IV makes identical plaintext produce identical ciphertext, so an observer can see which messages repeat, and with GCM it breaks authentication outright. Generate a random IV per message and send it alongside the ciphertext - the IV is not secret.
#Why can RSA not encrypt long text?
Because one block holds only the key size minus padding overhead - 190 bytes at 2048 bits. Longer input has to be chunked and concatenated, which costs performance and provides confidentiality without integrity. Use hybrid encryption for anything substantial.
#Can Morse code represent Chinese?
No. Its character set is Latin letters, digits and a small punctuation set, with no Han characters. To send Chinese you would first convert to pinyin, or to Chinese telegraph code (four digits per character) and then to Morse - that extra mapping needs another tool, and this one does not include it.