Mixing
understanding the block bits for DES
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
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.
encryption algorithm-design des
edited Aug 30 at 15:59
psmears
1233
asked Aug 30 at 12:51
catalin
335
add a comment |Â
up vote
4
down vote
favorite
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.
encryption algorithm-design des
edited Aug 30 at 15:59
psmears
1233
asked Aug 30 at 12:51
catalin
335
2
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-16d83edd2awhich is 4-bytes.
– zaph
Aug 30 at 13:33
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.
– zaph
Aug 30 at 14:21
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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.
encryption algorithm-design des
edited Aug 30 at 15:59
psmears
1233
asked Aug 30 at 12:51
catalin
335
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.
encryption algorithm-design des
edited Aug 30 at 15:59
psmears
1233
asked Aug 30 at 12:51
catalin
335
edited Aug 30 at 15:59
psmears
1233
edited Aug 30 at 15:59
psmears
1233
edited Aug 30 at 15:59
psmears
1233
1233
asked Aug 30 at 12:51
catalin
335
asked Aug 30 at 12:51
catalin
335
asked Aug 30 at 12:51
catalin
335
335
2
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-16d83edd2awhich is 4-bytes.
– zaph
Aug 30 at 13:33
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.
– zaph
Aug 30 at 14:21
add a comment |Â
2
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-16d83edd2awhich is 4-bytes.
– zaph
Aug 30 at 13:33
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.
– zaph
Aug 30 at 14:21
2
2
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.– zaph
Aug 30 at 13:33
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.– zaph
Aug 30 at 13:33
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.
– zaph
Aug 30 at 14:21
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.
– zaph
Aug 30 at 14:21
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
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.
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
2
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.
– zaph
Aug 30 at 15:13
add a comment |Â
up vote
0
down vote
This is a tough one actually. Cryptographic primitive vs functional cipher, what is a block, padding, mode of operation etc.. The simplest bit is probably the UTF thing. It's actually so broad that it might take a great deal of widely ranging explanation.
Rather than say it's too board, have a look at the two following wiki links:-
Block cipher mode of operation
Padding (cryptography)
This link only answer should be okay as it's common knowledge to many readers. Previously deleted as it seemed a bit short.
answered Aug 30 at 13:12
Paul Uszak
5,58911231
2
As-is, this answer does not really explain anything or answer the question.This link only answer should be okay as it's common knowledge to many readersthis is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.
– Ella Rose
Aug 30 at 15:23
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
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.
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
2
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.
– zaph
Aug 30 at 15:13
add a comment |Â
up vote
4
down vote
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.
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
2
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.
– zaph
Aug 30 at 15:13
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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.
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
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.
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
edited Aug 30 at 15:33
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
answered Aug 30 at 14:22
Maarten Bodewes
47.7k566175
47.7k566175
2
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.
– zaph
Aug 30 at 15:13
add a comment |Â
2
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.
– zaph
Aug 30 at 15:13
2
2
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.
– zaph
Aug 30 at 15:13
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.
– zaph
Aug 30 at 15:13
add a comment |Â
up vote
0
down vote
This is a tough one actually. Cryptographic primitive vs functional cipher, what is a block, padding, mode of operation etc.. The simplest bit is probably the UTF thing. It's actually so broad that it might take a great deal of widely ranging explanation.
Rather than say it's too board, have a look at the two following wiki links:-
Block cipher mode of operation
Padding (cryptography)
This link only answer should be okay as it's common knowledge to many readers. Previously deleted as it seemed a bit short.
answered Aug 30 at 13:12
Paul Uszak
5,58911231
2
As-is, this answer does not really explain anything or answer the question.This link only answer should be okay as it's common knowledge to many readersthis is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.
– Ella Rose
Aug 30 at 15:23
add a comment |Â
up vote
0
down vote
This is a tough one actually. Cryptographic primitive vs functional cipher, what is a block, padding, mode of operation etc.. The simplest bit is probably the UTF thing. It's actually so broad that it might take a great deal of widely ranging explanation.
Rather than say it's too board, have a look at the two following wiki links:-
Block cipher mode of operation
Padding (cryptography)
This link only answer should be okay as it's common knowledge to many readers. Previously deleted as it seemed a bit short.
answered Aug 30 at 13:12
Paul Uszak
5,58911231
2
As-is, this answer does not really explain anything or answer the question.This link only answer should be okay as it's common knowledge to many readersthis is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.
– Ella Rose
Aug 30 at 15:23
add a comment |Â
up vote
0
down vote
up vote
0
down vote
This is a tough one actually. Cryptographic primitive vs functional cipher, what is a block, padding, mode of operation etc.. The simplest bit is probably the UTF thing. It's actually so broad that it might take a great deal of widely ranging explanation.
Rather than say it's too board, have a look at the two following wiki links:-
Block cipher mode of operation
Padding (cryptography)
This link only answer should be okay as it's common knowledge to many readers. Previously deleted as it seemed a bit short.
answered Aug 30 at 13:12
Paul Uszak
5,58911231
This is a tough one actually. Cryptographic primitive vs functional cipher, what is a block, padding, mode of operation etc.. The simplest bit is probably the UTF thing. It's actually so broad that it might take a great deal of widely ranging explanation.
Rather than say it's too board, have a look at the two following wiki links:-
Block cipher mode of operation
Padding (cryptography)
This link only answer should be okay as it's common knowledge to many readers. Previously deleted as it seemed a bit short.
answered Aug 30 at 13:12
Paul Uszak
5,58911231
edited Aug 30 at 14:43
answered Aug 30 at 13:12
Paul Uszak
5,58911231
answered Aug 30 at 13:12
Paul Uszak
5,58911231
answered Aug 30 at 13:12
Paul Uszak
5,58911231
5,58911231
2
As-is, this answer does not really explain anything or answer the question.This link only answer should be okay as it's common knowledge to many readersthis is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.
– Ella Rose
Aug 30 at 15:23
add a comment |Â
2
As-is, this answer does not really explain anything or answer the question.This link only answer should be okay as it's common knowledge to many readersthis is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.
– Ella Rose
Aug 30 at 15:23
2
2
As-is, this answer does not really explain anything or answer the question.
This link only answer should be okay as it's common knowledge to many readers this is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.– Ella Rose
Aug 30 at 15:23
As-is, this answer does not really explain anything or answer the question.
This link only answer should be okay as it's common knowledge to many readers this is a non-sequitur - link only answers are frowned upon and there is no special exception to the rule for "common knowledge to many readers". Saying "everyone already knows it anyways" (paraphrasing) doesn't help those who don't know yet, e.g. those who actually needed an answer to the question.– Ella Rose
Aug 30 at 15:23
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f61898%2funderstanding-the-block-bits-for-des%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
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
d83edd2awhich is 4-bytes.– zaph
Aug 30 at 13:33
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.
– zaph
Aug 30 at 14:21