3
$\begingroup$

I'm trying to understand cryptographic protocols, and I've started with the DES algorithm.

DES specs: it uses 64 bits for the plaintext, 56 bits for the key, with a result of the same 64 bits of ciphertext.

But encrypting on online websites I see a totally different thing. Encrypting the string "hello" with the key "key" will get me the cipher text "ar635N/LqmY=". Now, I used https://ethproductions.github.io/bytes/ to count the number of bits in a string, and seems like:

  • "hello" has 5 chars, totaling 10 UTF-16 bytes, which is 80 bits
  • "key" has 3 chars, totaling 6 UTF-16 bytes, which is 48 bits
  • "ar635N/LqmY=" has 12 chars, totaling 24 UTF-16 bytes, which is 192 bits

So, as you can see, we have here an input of 80 bits with a key of 48 bits and an output of 192 bits.

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ 1. "ar635N/LqmY=" is 8-bytes Base 64 encoded so it represents 64-bits not 192-bits. 2. Using the UTF-16 is confusing things in this case when for these characters one byte is 8 0x00 values. UTF-8 is a better choice for this question. Further some unicode characters such as emoji are more than two bytes in UTF-16, 🤪 is UTF-16 d83edd2a which is 4-bytes. $\endgroup$
    – zaph
    Aug 30 '18 at 13:33
  • $\begingroup$ Other issues: 1. DES has a block size of 8-bytes so data to be encrypted must be a multiple of 8-bytes and if not padded to that multiple. A common padding is PKCS#5 padding. 2. The key size is 8-bytes (one bit per byte is reserved for parity) so a key of "key" will not work. Some DES implementations will pad a key with null bytes some will not, it is a bad idea to supply an encryption key of an incorrect size. $\endgroup$
    – zaph
    Aug 30 '18 at 14:21
3
$\begingroup$

First of all, if you want to seriously learn cryptography, then do not use any online encryption sites. It seems most if not all are created by enthusiasts that just learned crypto and then wanted to do something interesting with it. Unfortunately that simply means that they are just propagating their very limited and often incorrect understanding of (block) ciphers and cryptography in general. Even if one of the sites was created by a good cryptographer, you would not be able to distinguish it from the rest.

One of the first things to learn before starting to learn cryptography is how - and when - to perform encoding / decoding. Basically there are two forms of encoding that convert byte- and character strings:

  • character encoding where a character is encoded to binary. Examples are ASCII, UTF-8 and UTF-16(BE/LE).
  • (binary) encoding where a octet string / byte array is encoded to a string consisting of characters. Examples are hexadecimals, base64, base64url.

For instance, ar635N/LqmY= is a base 64 string which encodes 8 bytes or 64 bits. Those bytes may not themselves represent a string, and assuming that they consist of 8 UTF-16 characters is obviously incorrect, if just because 8 UTF-16 characters take 8 * 16 = 128 bits at a minimum, not 64 bits.

The site you pointed to doesn't decode the base64, it just tries to character-encode the string to binary. For base 64 you could use e.g. this site (random one without ads). Note that humans are bad at reading bytes if they do not represent text, and ciphertext consists of pseudo-random bytes. So the site will return another encoding as well: hexadecimals. From hexadecimals it is easierto see any structure in the returned bytes.

To be able to take a "encryption" site seriously, the site should:

  • explicitly define which cipher is used (for DES, does it accept 3DES as well?)
  • show the key sizes that you can use
  • allow the key to be entered as hexadecimals
  • if it allows a password (a password is not a key), specify which Password Based Key Derivation Function is used (examples: bcrypt, scrypt, PBKDF2, Argon2)
  • allow you to input a given IV (and possibly create and display a random IV as an option)
  • specify the mode of operation that is used for the block cipher
  • specify the padding mode that is used for the mode of operation (if any)
  • indicate which configuration options are used (such as the hash of the digital signature, or the length of an authentication tag) instead of relying on unspecified defaults
  • specify the character encoding of the plaintext message (assuming the message is text instead of hex or base64)
  • specify the encoding of the ciphertext (directly displaying the random bytes doesn't make sense, some bytes do not translate directly into printable characters)

If any of these are not given it will leave you guessing on what is happening.

Furthermore, the site should:

  • indicate that the site is for testing only, actual plaintext or keys should not be entered
  • not make any simple crypto errors such as failing to distinguish between AES and Rijndael or reuse the key to generate an IV (the list is endless)
  • hopefully indicate that encryption using e.g. CBC is not secure for transport protocols
  • and finally, return correct results

These two lists will unfortunately rule out 99% if not all of the sites.

You're better off picking up the best crypto API for your favorite language / runtime and use that to explore.

As for your specific key issue: the site will probably add 00 valued bytes up to the key size. Or it could use spaces. Or it could use a cryptographic hash (and take the wrong, rightmost bytes if you're unlucky). All of which are insecure and show exactly how you should not use a block cipher.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ Your rules for a good site are spot-on and also unfortunately rule our just about every implementation site. The one thing missing on implementations sites is not providing the default values for unspecified options, a pet peeve of mine. $\endgroup$
    – zaph
    Aug 30 '18 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.