In this second lab, you'll get acquainted with AES and learn how to cryptographically shuffle a deck of cards.
Due date: Monday, October 6th, 8:25AM.
Write here the name of the collaborators (just in case):
We will use the implementation of AES provided by the PyCrypto library.
The message space used by this library (as is quite often the case) is the set of strings of valid 8-bit ASCII characters. In other terms, every character in such a string represents a byte. This explains the parameter lengths reported by the library:
The other widely used convention for the message space would be to write everything as hexadecimal integers; we can easily convert from one view to the other.
Just keep in mind that most 8-bit characters just won't display nicely...
To convert whole strings, a convenient way is the following:
Notice that the ciphertext really is just as long as the original message (96 byte-characters, which make up 6 full AES blocks).
A note on padding: the simple scheme used here (add as many # as needed) is not fully reversible (can you see why?). Some standard solutions are described here.
The first two 16-byte blocks are identical in the ciphertext (just like they are in the plaintext).
This breaks semantic security, since the attacker should not be allowed to know that the message has repeating blocks.
To do: Encrypt the same message using AES in randomized counter (CTR) mode "by hand" (i.e., don't use the PyCrypto API except to encrypt single blocks). Verify that Bob is able to decrypt the received ciphertext knowing only the shared secret key .
A utility function that XORs two byte strings together.
The only difference between encryption and decryption in CTR mode is in the way the value of is obtained, so I chose to write a single function with a flag that specifies if encryption or decryption is to be performed.
No recognizable pattern is present this time even though the plaintext has repeating blocks. Note the conveniently permissive attitude towards input strings whose length are not a multiple of the AES block length (we have effectively turned the block cipher into a stream cipher). We get the plaintext back by performing decryption:
A good way to verify our implementation of AES-CTR would be to test it against the PyCrypto implementation for compatibility. I personally don't like very much the flexibility it leaves to the developper of managing the counter themselves (a good opportunity to introduce a cryptographic weakness by reusing initial values), but here it is nonetheless, wrapped inside a similar-looking function.
Let's turn to a seemingly unrelated problem: that of a casino wanting to "impredictably" (from the point of view of the players) shuffle a deck of digital playing cards with a 128-bit shuffle key (probably generated from a master key using a CSPRNG). There are different ways to shuffle a deck of cards, so the whole description of a shuffle couldn't possibly fit in the shuffle key: it has to be securely derived from it.
The first, "easiest" way to do it would be to:
Hence obtaining a shuffled list of the original cards.
To do: Do it! What is the first poker hand (first 5 cards) dealt from your shuffled card deck?
Here's a nice deck of 52 cards:
We encrypt the card values (padded to a full block with spaces for easy removal) with some shuffle key:
We sort these encrypted values to shuffle the deck.
Here's your hand under the given shuffle key :
The above method works well, but rapidly becomes incovenient when the number of objects to permute gets large. Suppose for example that we want to shuffle not 52, but 52000 cards: with the above method, getting the top 5 would require 52000 single AES evaluations. A more efficient solution (look up "Format-preserving encryption" for more information) is the following:
To do: What are the 5 first cards we get out of this 52000-card deck? How many AES evaluations did this take?
Here's a small function that gives to card value from its number:
Elementary byte shuffle function:
And the main shuffling function:
Here are the top 5 cards:
Are you able to tell where card no. 12345 lands in this shuffle? (You should! Using the fact that the Feistel network is easy to invert for somebody who knows the key...)
The inverse permutation (notice the similarity...)