Schneier on Security

Clive Robinson • July 13, 2010 8:56 AM

Hmm,

It uses two fairly simple “card shuffling” algorithms.

You could with a little patience do this with a single deck of cards split into two packs of red cards and black cards.

I’ll have a think to see how difficult it is to do the shuffeling by hand. On the face of it it is quite simple for the left deck and does not need the use of jokers or other cards etc.

Clive Robinson • July 13, 2010 10:52 AM

@ Stevec

“… looks suspiciously like a pair of Bakewell tarts to me”

I don’t think many people on this list would be that familiar with a couple of tarts from Bakewell…

Clive Robinson • July 13, 2010 1:50 PM

@ Chabuhi,

There is Perl code in the back of the paper that being said it’s quite a bit longer than I would expect from the description.

I’d need to take a proper look at it but it should not be to difficult to translate or code up from scratch.

Clive Robinson • July 14, 2010 12:45 AM

@ Sam,

One of the reasons Bruce says,

“Of course, it’s not able to stand up to compute cryptanalysis.”

Is the maximum possible number of states the system can be in.

Without doing an indepth analysis you can simply say,

I have two independent wheels of 26 charecters that store state.

You can assume an upper bound on the number of states each wheel can be in of 26! or a little under 4.033 x 10^26, which is about 89bits (if my brain is working at “Oh my Gawd” in the morning).

Now there is the question of how the two wheels interact with each other and the resulting number of states. For the sake of simplicity you can just assume that either wheel can be in any state against the other, so you get 26! x 26! ~= 1.62644 x 10^53 or 178bits as an upper bound.

In practice it will actually be a lot less than this. But for comparison a full pack of 52 cards gives you 8.06582 x 10^67 or a little over 227bits of state. And ARC4’s 256 bytes and two pointers gives the equivalent of 1700 bits.

However this is an upper bound on state only and says nothing about the usage of the state or the complexity of the state transitions.

To see why this is important imagine if you will the system was a stream cipher that had a 178bit counter the last 5bits of which where XORed with the plain text. In reality the state becomes the equivalent of a counter that rolls over to zero after thirty one. Which would be the equivalent of using a Ceaser Cipher of 32 alphabets one after each other which would be trivial to break with just a pencil and paper and a message of just a short plain text sentance. Even if you XOR’d in more bits of state for each bit of plain text the situation would only be fractionaly better because the mapping from the full state to each alphabet is highly linear and highly predictable.

To be secure not only do you need to use the full range of possible alphabets but the transition between them needs to be as near unpredictable as possible.

I’m not going to analyse the cipher in depth but if you look at the way the first wheel evolves it’s alphabet (state) it is very slow and easily testable from state to state. Effectivly take out one letter and move it down the current alphabet and then rotate the alphabet the same number of places.

The hard part is determining the actual starting or current alpabet and what the “shift” value is for moving to the next state.

As for the alphabet change, it is the equivalent of holding 26 cards in your hand (faned out) counting down to a card pulling it out counting down further and putting it in a new place then closing the hand and counting off cards from the top to the bottom of the deck and then fanning it out again (it’s like an Alberti disk where you move a letter around the alphabet on each encipherment of a plain text char).

I know from having designed a similar deck of cards system (it uses the whole deck and reverses the order of cards for a given count) that you can do this very quickly with a little practice. And with a bit more practice you can encipher a message (running key) in your head as you are doing it and write the cipher text down.

Clive Robinson • July 14, 2010 5:11 AM

@ Filias Cupio,

“How on earth would you implement this with early 20th century technology, reliably and moderately cheaply”

I can think of several ways…

But first “cheaply” would not have been a design consideration in the early part of the last century.

The forerunner of the Enigma machine cost about twice that a skilled craftsman would earn so you could be looking at about 100,000 USD in todays money.

As for reliably it was just after the Victorian era of great mechanical engineering, standardisation of components had happened and WWI had shown that industrialisation and mass production could be brought to bare on what was once a highly skilled manual job of making guns.

There are patents around some where for both a calculator and a cipher system using hydraulics rather than electricity. Remember dry cell batteries where virtualy unknown technology at the time, and lead acid cells where little more than large very glass containers that where extreamly heavy and very fragile. They where also very dangerous as they could not be sealed (they exploded on charging) and thus escape of concentrated sulfuric acid was virtualy guaranteed in all but the most controled environments.

However mechanical engineering ruled supreme of all mens endevors at the time, and toy manufacture was industrialised with pressed tin toys taking over from cast lead and wood.

One such novelty toy we still see today and that is the square of interlocking tiles that can be slid up down left and right with a picture on. even though one tile of the 9 or 16 was missing they did not fall out of the frame.

So the design of even quite a small wheel with letter tiles that could be slid in and out of it’s periphery would have been a well understood technology. A simple mechanical system to slide a tile out of the frame and move 12 tiles by rotation past it would have been fairly easy to do as would slotting the tile back into the wheel periphery.

We know since the time of Alberti (and his disk) that craftsmen could certainly make the wheels and based on some mechanical calculators we know they could have made a sliding mechanisum (and actually had for other things).

It amazes me quite frequently just how many simple mechanical skills that have become effectivly unknown since the 1980’s. Which is actually quite sad as pulling apart mechanical toys, clocks and locks, etc teaches a young mind a lot about what is possible and quite practical.

I learnt a lot of my engineering skills before I was even a teenager and getting old and broken valve radios and televisions and fixing them taught me a lot of fault finding skills before I was 13. It also provided me with a nice little income of a pound or two a week before I went on to “further education”.

Having had the oportunity to play a little with a pack of cards I can safely say you can split into two decks and do the required shuffling on both without putting them down (hint unlike the PDF description with it’s awkward lose card (P on the left wheel example) simply put it out of the way on the botom of the deck count 12 cards off into the other hand and slide the top card across from thbe new deck to the old deck and put the new deck back ontop of the old deck (and if you realy want move the lose card from the bottom of the deck back to the top).