Hey all, I found a cool way to convert text into a specific order of a deck of playing cards. I detailed the instructions of how it works in the blog post but a brief overview would be that it uses Lehmer codes which allow you to uniquely identify each permutation of a set i.e. each of the many many ways a deck of cards can be shuffled/arranged
Someone else mentioned that the orientation of the cards (up or down) and possibly even the front-back facingness of the card (facing up, facing down) would add another 2 possible bits to the available encoding space. (Of course, at that point you'd have to also encode which side of the whole deck is the "top"...)
My own thought was to add par2 to make it robust against small errors... at the cost of some transmission space!
Despite appearing to have perfectly ordinary structured static HTML content (aside from the fact that it spams things like <span style="font-weight:bold"> instead of using some basic CSS properly), without JavaScript I only see a solid-colour background.
Anyway, this doesn't offer a whole lot of storage:
$ python -c 'print(sum(__import__("math").log2(x) for x in range(1, 53)) // 8)'
28.0
Good stuff. You could get much better bandwidth than this by tokenizing and using something like a Huffman or arithmetic code on token frequencies. As a simple example, if you set your tokens to be all English words - let's say there are between 500k and 1 million - that's about 9-10 bits per word. I am sure you could do much better than this as well
You can get much better than that by taking a well-known LLM model and encoding a series of offsets from the most likely sequence of tokens, especially if you are OK with the message being slightly different.
Pet peeve: the blog post mentions _decimal_ and _denary_ several times, but in reality, there are no decimal numbers involved in any part of the computation.
This is a common mistake made by people who haven't fully internalized the distinction between numbers (which have no intrinsic representation) and _numerals_ which are the encodings of numbers.
When you are converting a permutation to its index, you are not converting to _decimal_, you are converting it to an integer. That integer has no intrinsic base. In Python (and the linked C++ code) that integer will be internally represented in binary (or a base that is a higher power of 2) and the corresponding decimal representation is generated only when printing.
So functions like decimalToFactoradic() should really be named integerToFactoradic(), etc.
> This is a common mistake made by people who haven't fully internalized the distinction between numbers (which have no intrinsic representation) and _numerals_ which are the encodings of numbers.
> people who haven't fully internalized the distinction between numbers
Or people whose first intuition is that the space measured by 52! permutations, which are painfully obviously based on taking the suit and rank of each card which makes it unique, can be covered with even remote adequacy by considering only the card color, which only narrows down the card to one of two sets of 26.
There are other five bit character sets as well, such as the 5-bit Baudot character set and the 5-bit Zork character set. You could also use variable bits characters, or other bases of numbers.
You can also use other decks, e.g. with tarot cards you will have 78 cards rather than only 52 cards, and can make a longer message.
Other comments on here had mention doing other things such as face-up vs face-down cards.
How about just assigning a number to every sentence in every language known to man, and using the absurdly huge number of deck combinations to identify them?
A while ago I made an interactive demonstration of how encoding with factoradic works https://ilcavero.github.io/ seems like I found someone else who thought it was a fun thing to demo
Thanks for your post. It sent me to the 3 hour rabbit hole figuring out how to maximise bandwidth given those 104 card-tokens (52x2 for face up/down cards) in real life. I wanted the solution to be practical for, say, two people in prison cells. So the math should be really simple.
My best attempt so far is assigning about ~20 tokens to most popular words (the, and, you...), another ~30 to popular trigrams (ing, ion, tio...), another ~30 to digrams (th, er, on...) and the rest to single letters. The number of unique tokens to be adjusted to the occurrence frequency of corresponding words/trigrams/digrams in natural language.
If the encoder runs out of a token, she just skips it (assuming the decoder will calculate this token is already used and guessing to add it) up until the point where the words become unrecognisable by the decoder. Encoder is also free to use synonyms to avoid running of tokens fast.
Not quite strict system, but my rough assessment gives it 80-100 letters per deck. Should be enough to plan a jailbreak :)
19 comments
[ 2.9 ms ] story [ 41.9 ms ] thread(I just prefer poker to solitaire...)
Someone else mentioned that the orientation of the cards (up or down) and possibly even the front-back facingness of the card (facing up, facing down) would add another 2 possible bits to the available encoding space. (Of course, at that point you'd have to also encode which side of the whole deck is the "top"...)
My own thought was to add par2 to make it robust against small errors... at the cost of some transmission space!
https://en.wikipedia.org/wiki/Solitaire_(cipher)
Anyway, this doesn't offer a whole lot of storage:
https://en.wikipedia.org/wiki/Solitaire_(cipher)
https://arxiv.org/abs/2306.04050
https://bellard.org/ts_zip/
This is a common mistake made by people who haven't fully internalized the distinction between numbers (which have no intrinsic representation) and _numerals_ which are the encodings of numbers.
When you are converting a permutation to its index, you are not converting to _decimal_, you are converting it to an integer. That integer has no intrinsic base. In Python (and the linked C++ code) that integer will be internally represented in binary (or a base that is a higher power of 2) and the corresponding decimal representation is generated only when printing.
So functions like decimalToFactoradic() should really be named integerToFactoradic(), etc.
Counterpoint: it doesn’t matter.
Always Adore: Amazing Alliteration.
Or people whose first intuition is that the space measured by 52! permutations, which are painfully obviously based on taking the suit and rank of each card which makes it unique, can be covered with even remote adequacy by considering only the card color, which only narrows down the card to one of two sets of 26.
You can also use other decks, e.g. with tarot cards you will have 78 cards rather than only 52 cards, and can make a longer message.
Other comments on here had mention doing other things such as face-up vs face-down cards.
Impractical, but possible.
My best attempt so far is assigning about ~20 tokens to most popular words (the, and, you...), another ~30 to popular trigrams (ing, ion, tio...), another ~30 to digrams (th, er, on...) and the rest to single letters. The number of unique tokens to be adjusted to the occurrence frequency of corresponding words/trigrams/digrams in natural language.
If the encoder runs out of a token, she just skips it (assuming the decoder will calculate this token is already used and guessing to add it) up until the point where the words become unrecognisable by the decoder. Encoder is also free to use synonyms to avoid running of tokens fast.
Not quite strict system, but my rough assessment gives it 80-100 letters per deck. Should be enough to plan a jailbreak :)