understanding the block bits for DES 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.
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.