tools / des
des/
DES symmetric encryption and decryption, for working with legacy systems that still use DES. Mode, padding, key and IV formats and charset are all configurable, results match Java and CryptoJS, and your key never leaves the browser.
Plaintext
Ciphertext
History
Each successful encryption or decryption is saved automatically. The latest 20 are kept, only in this device's browser. Keys are never saved, but IVs and decrypted plaintext are, so clear the history when you are done on a shared computer.
AES, DES and RSA: what they are and how they differ
AES and DES are symmetric ciphers: the same key encrypts and decrypts, like one key that both locks and unlocks a door. They are fast and suit large amounts of data; the hard part is getting that key to the other side safely.
DES is an old standard from the 1970s with an effective key of only 56 bits, which dedicated hardware or computer clusters can now brute-force, so it is only for talking to legacy systems that still use it. AES replaced DES as the standard. It uses 128, 192 or 256-bit keys, has no practical attack today, and is the default choice for encrypting data.
RSA is asymmetric: there is a key pair. The public key can be given to anyone and is used to encrypt; the private key stays with you and is used to decrypt, like a mailbox anyone can drop letters into but only you can open. No shared key has to be agreed in advance, but RSA is slow and can only encrypt a few hundred bytes at a time. Real systems often combine the two: RSA encrypts a randomly generated AES key for the other side, and AES encrypts the actual data.
What is a cipher mode, and which one to use?
DES encrypts 8 bytes at a time; the mode decides how longer data is split into blocks and how the blocks are linked. ECB encrypts each block on its own, so identical content gives identical ciphertext and leaks patterns; avoid it. CBC mixes each block with the previous ciphertext block before encrypting, and the first block with the IV; it is the most common choice. CFB, OFB and CTR turn DES into a keystream that is XORed with the data byte by byte, so no padding is needed.
Key, IV and padding
A DES key is 8 bytes, but the lowest bit of each byte is a parity bit that is not used, so the effective key is only 56 bits. If the key is longer than 8 bytes only the first 8 are used, as with Java's DESKeySpec and CryptoJS; shorter keys are rejected. Every mode except ECB needs an 8-byte IV. It does not need to be secret, but never reuse one with the same key.
ECB and CBC need the data length to be a multiple of 8 bytes, so short data is filled up according to the padding. PKCS5Padding and PKCS7Padding are identical for DES and the most common. ZeroPadding fills with zeros and strips every trailing zero byte on decryption, so plaintext that itself ends in zero bytes loses them. NoPadding adds nothing, so you must get the length right yourself.
Mapping to Java and CryptoJS
Java's Cipher.getInstance("DES/CBC/PKCS5Padding") means CBC with PKCS5Padding; plain "DES" defaults to ECB with PKCS5Padding. In Java, CTR only works with NoPadding. CryptoJS.DES.encrypt modes and paddings match by name, and CryptoJS.pad.Pkcs7 is PKCS7Padding. For new systems, use AES instead.
FAQ
Can it encrypt and decrypt 3DES (DESede, TripleDES)?
No, only single DES is implemented here. A 3DES key is 16 or 24 bytes; pasting one here uses only the first 8 bytes, so the output differs from 3DES, and the Key field also shows "only the first 8 bytes are used". For 3DES, use a tool that supports DESede.
What should I do about "The key is N bytes; a DES key needs at least 8 bytes"?
Fewer than 8 bytes gives an error, and nothing is padded with zeros for you, so pad it to 8 bytes yourself. A likelier slip is the wrong format: if a 16-character hex key is entered with the key format set to string, it is treated as 16 bytes of text and only the first 8 characters are used. There is no error, only a note "only the first 8 bytes are used" beside the Key field and below the result, and the output will not match. In string format the count follows the selected charset, so one Chinese character takes 3 bytes in UTF-8.
What should I do about "this mode needs an IV of exactly 8 bytes"?
A DES IV must be exactly 8 bytes, not the 16 bytes of AES, in every mode except ECB. A key longer than 8 bytes is cut to its first 8, but the IV is not, so too long or too short is an error, and a 16-byte IV taken from AES settings has to be changed to 8 bytes. Check the format as well: 16 hex characters make 8 bytes, while the same 16 characters in string format are 16 bytes. ECB needs no IV and hides the IV row.
What should I do about "invalid padding" or "not a multiple of 8" when decrypting?
A ciphertext length that is not a multiple of 8 usually means an incomplete copy or hex and base64 swapped. Invalid padding usually means one of the key, IV, mode or padding differs from what was used to encrypt. ZeroPadding and NoPadding do not check the padding, so they never raise this error, but the result is garbage if the parameters are wrong.
The start of the decrypted text is garbled, or it says the result is not valid UTF-8 text
Check the IV first. When the ciphertext is longer than one block, a wrong IV in CBC and CFB mode ruins only the first 8-byte block, the rest comes out fine and no padding error appears, so you see garbage at the start and correct text after it. If the message says the result is not valid text, the charset may differ from the one used to encrypt, for example the other side used GBK. Setting the output format to hex lets you check the decrypted bytes themselves first.
My result does not match Java or CryptoJS. How do I troubleshoot?
Check these in order: mode and padding, the format and byte count of the key and IV, the charset, and the input and output formats. Plaintext in string format is not trimmed, so one extra trailing newline makes it different data. CTR, CFB and OFB also pad to the selected padding here, so with PKCS5Padding the ciphertext is longer than the plaintext; if the backend uses NoPadding, choose NoPadding here too. CFB here is the 64-bit full-block variant, so it will not match a backend that uses CFB8.
CryptoJS.DES.encrypt output starts with U2FsdGVkX1. Can it be decrypted here?
No. When you pass a plain string as the key to CryptoJS.DES.encrypt(message, string), CryptoJS treats it as a passphrase: it adds a random salt and derives the key and IV the way OpenSSL does, and the result starts with U2FsdGVkX1. That format is not supported here. To match this tool, convert the key to bytes in CryptoJS with CryptoJS.enc.Utf8.parse and pass it in, and set iv, mode and padding explicitly.
What does the history store, and is it uploaded?
It lives only in the localStorage of this device's browser and is never uploaded; the page code makes no network requests. One entry is added after each successful encryption or decryption, up to 20 are kept, and anything whose input or result is over 20,000 characters is not recorded. An entry holds the parameters, IV, input and result, plus an 8-character fingerprint derived from the first 8 bytes of the key (the characters after the # in each entry, used to tell whether it is the same key), but never the key itself, so after clicking "Load" you need to enter the key again. Each entry can be deleted on its own, and on a shared computer click "Clear history" when you are done.