In this lesson we will talk about cryptography in the digital world. As a part of this, we'll look at some real-world cryptographic tools. Before we do anything, however, we need to recall the similarities and differences between our basic cryptographic tools [technically we call them cryptographic primitives]: Symmetric / Secret-Key Encryption, Asymmetric / Publi-Key Encryption, and Hashing.
Cryptography in the digital world
In cyberspace, our messages are not text-only. A message can be any piece of digital data. However, we know that fundamentally any digital data is just a squence of bytes. So instead of encrypting or hashing sequences of characters, we encrypt or hash sequences of bytes. Ceasar shift, Vigenere Cipher, Rubic's Cube Hash ... all of these could be modified to work on bytes 00000000 to 11111111 instead of letters A to Z. However, there are much better symmetric encryption algorithms and hash algorithms available to us, so we'll move on to look at them — though, obviously, we won't be able to understand them to the same depth.A hash value in the digital world has to be represented by bytes just like the data you're hashing is represented by bytes. So we just view a hash technique as a function that maps the bytes of the input into bytes representing a number, which is the hash value. The number of bytes in the hash value is usually fixed, regardless of how many bytes are in the input. We invariably write down hash values as sequences of hex digits that spell out the values of the bytes within the hash. So, for example, a 128-bit [16 byte] hash function would give us this picture:
.-------------.
N-byte input --> |HASH FUNCTION| --> 16-byte hash value
'-------------'
The idea is just the same as with the Rubic's cube, though. The hash function should be relatively easy to compute. Working backwards from a hash value to generate a string should be infeasibly difficult. Strings that are even the smallest bit different should have wildly different hash values. Encryption in the digital world is more complex. Recall how we were able to break the Vigenere Cipher. Because the Vigenere Cipher maps individual letters to individual letters, letter frequencies in the cyphertext could ultimately be related back to letter frequencies in the plaintext. This allowed us to break the cipher. Even though we encrypt bytes not letters in the digital world, frequency analysis still works — it would just be the frequencies of the 256 possible bytes rather than the 26 letters. So what we do is encrypt a block of bytes at a time [16 bytes in the symmetric encryption algorithm we'll look at]. So instead of replacing each byte of plaintext with a corresponding byte of cyphertext, we replace a block of bytes in the plaintext with a block of bytes in the cyphertext. If the plain-text input doesn't come out to an even number of blocks, some padding [extra bits] needs to be added. We could tabulate frequency counts for the 256 bit patterns possible within a single byte, but we cannot tabulate frequency counts for the 340,282,366,920,938,463,463,374,607,431,768,211,456 bit patterns possible within a 16-byte block. The next issue is the key: the key is also digital data, so the key is ultimately a sequence of bytes. Once again, we usually write down a key by the hex representation of the sequence of bytes. A given encryption method must specify the block size and the key size — both are usually specified as a number of bits. So, with 128-bit [16 byte] key and block size we have a picture like this [N is the number of bytes in the plaintext, B is the number of blocks after padding]:
.-----------------------------------.
| |
| .---------. |
N-byte plaintext ---|-> pad to 16*B bytes ->| | |
| | Encrypt |-|--> 16*B byte ciphertext [B blocks]
16 byte key---------|---------------------->| | |
| `---------' |
| |
`-----------------------------------'
.-----------------------------------.
| |
| .---------. |
| | |