Using playing cards to store hidden data:

The implied card method for
encoding data into playing cards

Introduction

This is my method for storing messages and data in a deck of playing cards. The method encodes binary bits into the cards, usually resulting in many more bits of data being stored than there are cards. Depending on the nature of the particular bits being encoded, it can store from 52 to 1,378 bits of data. I haven't seen this idea anywhere else. The method can also be used to encode letters of the alphabet (English or otherwise) in a way that, on average, fewer than two cards are needed to represent one letter. In more straightforward methods, these would be impossible. My method also means that the data can be encrypted within the cards to the security level of a one-time pad. The concept can be used outside of the world of cards in any collection of items that has a set order, such as numbers or the letters of the alphabet.

[Note from 2016: When I first thought of the idea, I didn't really put much thought into the non-card uses of the Implied Card concept. Now, I think that that using it with plain numbers is actually the most interesting aspect. See the last section for this, here.]

Having a vague understanding of binary will help in understanding the following explanations. The basis of my ideas treat each card as a binary "bit". In this way, each card represents either a one or a zero.

How it works:

There are two related methods: the Basic Implied Card Method and the Recursive Implied Card Method. The Basic Implied Card Method is more straightforward to encode and decode with, but has a slightly lower capacity for storing data.



This method involves having a set order for a pack of cards. Each card's position in the pack represents a 1 or 0. If the card is absent from its position, then there is an implied 0; if the card is present, it represents a 1. As we know the order of the pack, we can tell if a card is absent. As an example, if the second card of a pack is absent, but the first, third and fourth are present, then the binary bits represented are 1, 0, 1, 1.

If we put the removed cards at the back of the pack as we do the encoding, then we can use those cards again when they next come around. The previously absent cards will have their own calculable order, and we can continue to know which cards are absent from their correct position all the way through the pack.

The more zeroes there are in our binary number, the fewer cards we will need to encode it. A zero bit does not reduce the number of cards available for further numbers.



If we map the 26 letters of the English alphabet, ordered by frequency, on to 5-bit binary numbers ordered by the number of ones in them, we can encode text fairly efficiently. To start with, the letter "e" will be represented by 00000 and so every "e" won't reduce the number of cards available to encode further letters. The next most common letters will use the fewest amount of cards. Paradoxically, if we use 7-bit binary numbers to encode cards, despite using longer numbers, we will end up using fewer cards and being able to store longer messages. This is because all the letters of the alphabet can be represented by binary numbers containing two or fewer ones in them. All the zeroes will be reused for later letters.



This is an extension to the Basic Method that can encode even more binary numbers. It takes advantage of the fact that it is possible to deduce which cards were used to represent ones in the first part of an encoded pack before the point where the "absent" cards were reused. We do this by examining the state of the pack after the point where the cards were reused. As we can work out the first part of the pack, we do not actually need those cards to be in the final pack for it still to be decoded correctly. Therefore, these cards can be used again to represent more binary numbers. A portion of these reused cards can, again, have their existence and position deduced from later cards, which again means that they do not need to be there, and they too can be used again. We can keep reusing cards in this way for several iterations depending on the nature of the binary numbers being encoded into the cards.



The two methods can be decoded by anyone who understands the encoding method. However, any decoding relies on knowing the original order of the pack of cards. Without knowing the original order of the cards, it would be impossible to decode them. If the cards are shuffled before the encoding starts, the encoded data will end up being encrypted to the level of a one-time pad. The only way to recover the data would be to know the original order. One way of keeping a record of the original order is to duplicate it with a second pack of cards before the encoding begins.



The methods work not only with playing cards, but also with any series of items that have an implied set order. For example: numbers, the alphabet, alphabetised words, piles of coins and so on.



- There is only a set number of possible permutations of cards in a pack (the factorial of 52). Some people have suggested that the maximum theoretical number of bits that could be encoded into a pack of cards is 225 (actually 225.581 = log2(52!)). However, the Implied methods' ability to encode data varies greatly according to the nature of the bits being encoded. Without recursion, this varies from 52 bits (resulting in the pack of cards being in its original order) all the way up to 1,378 bits (resulting in the pack being in reverse order).

- If the number we are encoding consists entirely of ones, the pack can only contain 52 bits. As there are no zeroes, no cards can be reused. We cannot use the Recursive Method either, as there is nowhere to split the pack.

- On various websites linking here, people have mentioned Bruce Schneier's "Solitaire" idea as featured in the book "Cryptonomicon" by Neal Stephenson. My and Bruce Schneier's methods are unrelated, save for the fact they both use cards and can be used for encryption. My method stores data *within* a deck of cards, whilst his uses the deck as a key to encrypt data kept elsewhere. His method is more useful if you want to encrypt a lot of data, while mine could be more useful if you want to smuggle a shorter hidden message without any possibility of detection. Although I was aware that Bruce Schneier had invented a card encryption system, I didn't really understand what it did until after I had thought this up and decided to make sure I wasn't just copying him.

- I'm only aware of two proper flaws in the basic or recursive methods:

1: If there are multiple 0 bits encoded at the very end of the pack, then these can end up being decoded as nonsense or not being decoded at all. If there are ten cards left in the encoding and we want to encode 10 consecutive 0 bits, we would pass them all to the back of the pack where they would end up in exactly the same position as before. Therefore, to avoid this, the encoding sometimes has to stop while there are still unused cards left.

2: If there are cards that remain unused at the end of the pack, they will be decoded as ones. When decoding text, it is obvious that we have reached the end of the message, but when decoding binary numbers of an uncertain length, there are situations when it might become confusing - it might not be clear if the end of the message is all ones or if we have finished the message. One way to reduce this problem is to work in 4-bit (or higher) groups rather than with individual bits. If we work with 4-bit numbers, and there are three cards left at the end of the pack, then we know for sure to ignore them. Another option, if we are using set bit length numbers, is to select a particular number to act as an escape character.

The rest of these pages give a thorough explanation of the Implied Card Method with various examples.

Next page