MIRDEK: more fun with playing cards. 
Paul Crowley 
1/15/00 12:00 AM 
The earlier discussion about playing card ciphers inspired by Schneier's "Solitaire" has motivated me to return to Mirdek and implement some of the fixes I've been thinking about. Obviously, I wanted to improve security and I think I have, but I've also been thinking a great deal about practicality. The latest version of Mirdek is now really *very* practical: I've been doing stopwatch tests on every stage, and I can get to usually twenty to thirty seconds per plaintext letter, plus about a ten minute overhead in setup, mixing, and tidying up. This puts it some way ahead of either of the other modern hand ciphers I know about. In addition, it has some nice security properties and it's fun to do. Give it a go with a real deck of cards: I can encrypt "plain text" using key "keyphrase" in just under twenty minutes, and I'm not a carddealing speed demon. http://www.hedonism.demon.co.uk/paul/crypto/mirdek/ All this is not academic: quite a few human rights people have been very interested in the possibility of a practical, secure hand cipher, and it seems at the moment that if Mirdek isn't it then we don't have one.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\ 
MIRDEK: more fun with playing cards. 
CLSV 
1/18/00 12:00 AM 
Paul Crowley wrote: > http://www.hedonism.demon.co.uk/paul/crypto/mirdek/ > > All this is not academic: quite a few human rights people have been > very interested in the possibility of a practical, secure hand cipher, > and it seems at the moment that if Mirdek isn't it then we don't have > one. I have only glanced at Mirdek, but it looks nice. One comment I have is: what is wrong with a modified version of ARCFOUR, say restricted to 52 values? Key setup would be slow but can be done in a reasonable amount of time. It could even be skipped at the expense of generating and transmitting a 52 card key using thorough shuffeling. Encryption/decryption on the other hand would be relatively fast. Regards, CLSV 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/18/00 12:00 AM 
"CLSV" < clvi...@dds.nl> wrote ... Thanks for repeating my questions. I posted those ideas 3 days ago  "Changing ARC4's StateSpace Size")  and have seen no reply. In that posting I also explain how to translate ARC4 source code into cardmanipulations. (Is it too much to ask that replies to these ideas be posted in that thread which originated them?)  r.e.s. rs...@mindspring.com

MIRDEK: more fun with playing cards. 
T_Re...@yahoo.com 
1/18/00 12:00 AM 
Actually, I like your idea, and will be trying it out in the next couple of days. As a long time user of cyphers, I have never found a stong hand cypher fast enough to be practical. Solitaire is to slow (IMHO). I cannot seem to get better than about 50 char per minute. In the first year or so after it was published, I even tried creating three of them myself, and got two to four times the speed of Solitaire  but have managed to break two out of three. The third one seems a lot like your idea, but I will actually have to try it out to see what the differences are. Rex Stewart In article "r.e.s." <rs...@mindspring.com> wrote: > : <<cut>>
> > Thanks for repeating my questions. I posted those ideas 3 days ago >  "Changing ARC4's StateSpace Size")  and have seen no reply. > In that posting I also explain how to translate ARC4 source code into > cardmanipulations. (Is it too much to ask that replies to these > ideas be posted in that thread which originated them?) > >  > r.e.s. > rs...@mindspring.com > >
Sent via Deja.com http://www.deja.com/ Before you buy.

MIRDEK: more fun with playing cards. 
CLSV 
1/18/00 12:00 AM 
"r.e.s." wrote: > "CLSV" < clvi...@dds.nl> wrote ... [...] > : One comment I have is: what is wrong with a modified > : version of ARCFOUR, say restricted to 52 values?
> Thanks for repeating my questions. I posted those ideas 3 days ago >  "Changing ARC4's StateSpace Size")  and have seen no reply. > In that posting I also explain how to translate ARC4 source code into > cardmanipulations. (Is it too much to ask that replies to these > ideas be posted in that thread which originated them?)
I must have missed your posting. Maybe you can repost it in this thread? One of the things that might be worth investigating is if it is possible to strengthen the cipher (I'll call it "ARC52") by utilizing the cards that do not correspond to a character. If you define an alphabet consisting of the characters "A".."Z", "0".."9", ".", " " you have 38 characters. Yet there are 52 cards available. I was thinking about adding useless characters at random points in the text. The problem is that it should be done at random positions else you would give information about the state space away. Regards, CLSV 
MIRDEK: more fun with playing cards. 
Paul Crowley 
1/19/00 12:00 AM 
CLSV < clvi...@dds.nl> writes: > Paul Crowley wrote: > > > http://www.hedonism.demon.co.uk/paul/crypto/mirdek/ > > > > All this is not academic: quite a few human rights people have been > > very interested in the possibility of a practical, secure hand cipher, > > and it seems at the moment that if Mirdek isn't it then we don't have > > one. > > I have only glanced at Mirdek, but it looks nice. > One comment I have is: what is wrong with a modified > version of ARCFOUR, say restricted to 52 values? Sorry I didn't see this question before; I thought I'd been following these threads quite carefully, but... First, RC4 is biased, and variants with smaller states exhibit greater bias. I don't know how large the bias would be for 52 cards. It also exhibits weak keys. Second, RC4 doesn't provide a convenient way to generate a randomiser, or IV, to ensure the same passphrase can be used multiple times; it seems sensible to use card shuffling as a source of randomness for this application. But third and most importantly, I very much doubt that encryption/decryption would be relatively fast as you say. I suggest you try it with a real deck of cards and see how fast you can go; compare to a computer implementation to see whether you're getting the right answers. You'll have to count lots of cards to index into the deck, swap cards without losing your place, and do Vigenere addition (or for decryption, subtraction, which is worse) in your head. Try feeding the output of the Unix "fortune" program into your implementation and decrypting it; I suspect you'll find it a demoralising experience, with lots of time burned on incorrect decryptions. You can see that Solitaire is strongly influenced by RC4, but the differences are there because Solitaire is a relatively practical hand cipher and RC4 turns out not to be. Mirdek is IMHO considerably more practical than Solitaire. As you'll see from the website, I've spent quite a bit of time with a stopwatch and a pack of cards, making sure I've got a cipher that can be done in reasonable time. I've successfully decrypted thirty character ciphertexts with six character keyphrases in just over twenty minutes, using only a conversion chart (which is easily drawn from memory) and a pack of cards. Once you've tried doing RC4 by hand and got bored, try doing Mirdek, and I think you'll appreciate why I felt the need to design a new cipher. Actually, I'll post some ciphertext/key pairs on the site in a few days so people can have a go with unknown plaintexts. I hope this answers your question...  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/19/00 12:00 AM 
T_Re...@yahoo.com writes: > Actually, I like your idea, and will be trying it out in > the next couple of days. As a long time user of cyphers, > I have never found a stong hand cypher fast enough to > be practical. Solitaire is to slow (IMHO). I cannot seem > to get better than about 50 char per minute. You can't mean you got that speed by hand! Check out my C implementation of Solitaire on http://www.hedonism.demon.co.uk/paul/solitaire/ I don't know quite how fast it goes, but it's rather quicker than 50 chars per minute. For that matter, I haven't tested how fast a computer implemtation of Mirdek can go. I don't think it matters; one end of the communications link will be a hand cipher, and simply can't process enough text that the processing at the machine end will take more than a blink of an eye.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
CLSV 
1/19/00 12:00 AM 
Paul Crowley wrote: [...] > Mirdek is IMHO considerably more practical than Solitaire. As you'll > see from the website, I've spent quite a bit of time with a stopwatch > and a pack of cards, making sure I've got a cipher that can be done in > reasonable time. I've successfully decrypted thirty character > ciphertexts with six character keyphrases in just over twenty minutes, > using only a conversion chart (which is easily drawn from memory) and > a pack of cards. Once you've tried doing RC4 by hand and got bored, > try doing Mirdek, and I think you'll appreciate why I felt the need to > design a new cipher. I'm going to check your cipher out when I have more time. I agree with you that it is better to design a hand cipher using operations that can be done by hand quickly than trying to patch a cipher like RC4. Regards, CLSV 
MIRDEK: more fun with playing cards. 
T_Re...@yahoo.com 
1/19/00 12:00 AM 

MIRDEK: more fun with playing cards. 
Joseph Ashwood 
1/19/00 12:00 AM 
[a great number os snips follow] > > One comment I have is: what is wrong with a modified > > version of ARCFOUR, say restricted to 52 values? > > Sorry I didn't see this question before; I thought I'd been following > these threads quite carefully, but... >
> First, RC4 is biased, [and has weak keys] > Second, RC4 doesn't provide a convenient way to generate a randomiser, or IV,
Both of those can be addressed, at least to a degree, it's going to take me quite some time to write out the idea, but it is possible to address both of these quite easily, the main disadvantage being that it slow key setup by a significant amount. > But third and most importantly, I very much doubt that > encryption/decryption would be relatively fast as you say.
This is probably the biggest problem, in order to do the swaps a computer really should be involved. I just don't see where RC4 can be effectively done exclusively by a human If anyone is interested in seeing the idea please email me personally at mailto:ash...@msn.com I have working C code to perform a 54 card (deck w/ jokers) version, unfortunately it is significantly slower than RC4 in the key setup phase (by a rather large factor, approximately O(n^2) instead of O(n)). If there's enough interest I will create a step by step key setup along with the source code. I will be performing the prior analysis on it later today to determine the degree that it suffers from the repeated value problem found in RC4. Joe 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/19/00 12:00 AM 
[ repost of my 1/15/00 "Changing ARC4's StateSpace Size" ] begin repost Lately there've been some threads on secure "hand ciphers"; e.g., those implemented with pencil & paper, or with a deck of cards, etc. (Bruce Schneier says that his Solitaire algorithm "is certainly better than any other pencilandpaper cipher I've ever seen", but I notice that Paul Crowley is working on another candidate.) ...Which leads me to wonder about ARC4. It's too much to do by hand, of course; however, the ARC4 stream generator logic extends naturally to a state vector of "arbitrary" length M, e.g. M=52, which allows for the construction of a more workable hand cipher (see below). Yes, 52! <<< 256!, but 52! is also the size of the statespace for the Solitaire algorithm. Is there any reason to believe that the ARC4 stream generator, extended to M=52, would be of worse quality than Solitaire? (Of course, both might be badly flawed.) Apparently, a lot of analysis has been done for ARC4, so I wonder if there might be results, concerning its stream generator alone, that carry over to its extension to M <> 256. (?) (One question being how the quality of the generator degrades with decreasing M.)  Extending ARC4's stream generator to a state vector of length<>256: ARC4 maintains a state vector as an evolving permutation of 256 distinct symbols (bytevalues), managed with mod 256 arithmetic. But the same logic of ARC4's stream generator can also be applied to manage an Msymbol state vector with mod M arithmetic, for "arbitrary" M. The output stream then consists of symbols from an Msymbol alphabet. So I would like to consider the following encryption method: (1) A state vector of M distinct symbols is managed by mod M pointer arithmetic, using the same logic as ARC4's stream generator. (2) Modular addition is used as the combiner, instead of ARC4's XOR. (3) The method for initializing the state vector is not specified, but is to be established by the user, as is the case with Solitaire. This could be the same method as in ARC4's keyingphase, extended to mod M, but might instead be some form of "true randomization" (e.g. shuffling the deck in a carddeck implementation, or using physical noise sources in a computer implementation with larger M.)  To get a "hand cipher", choose M as a small multiple of the size N of the plaintext alphabet, e.g. M=m*N, and use addition mod N as the combiner. For example, we can take M=52 and use addition mod 26 for the combiner, similar to Solitaire. The case M=52 is tedious but not difficult to implement either with pencil & paper, or with cards (easier than Solitaire?). The state vector S(0)..S(51) is seen as a permutation of say A..ZA'..Z', with numerical values A=0, ..., Z=25, A'=26, ..., Z'=51. In a 54card implementation, 52 cards comprise the state vector, with the jokers as pointers, x & y. It's a simple matter to translate ARC4's stream generator into card manipulations: The top lettercard (as opposed to a pointer/joker) defines position 0, and the bottom lettercard defines position 51. A pointer/joker, x or y, points to the letter card next below it, but does not itself define a position. Thus, in translating the ARC4 algorithm, "initialize x=0,y=0" means "begin with both jokers on top of the deck", "x=x+1" means "move the xjoker down by jumping it over the lettercard next below it". Similarly, "S(x)" is the value of the lettercard next below the xjoker, so "y=y+S(x)" means "move the yjoker down by jumping it over that number of lettercards". (Treat the top card as the next one "below" the bottom, etc.) For an easytotranscribe description of the ARC4 algorithm, see http://ciphersaber.gurus.com/faq.html#getrc4 (Their i and j are my x and y, respectively.) I would be interested in any feedback. end repost I'm mystified why that posting has received exactly 0 replies. (It was posted, and appeared on DejaNews, three days before this topic was raised in this thread.)
"Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ... : Sorry I didn't see this question before; I thought I'd been following
: these threads quite carefully, but... : : First, RC4 is biased, and variants with smaller states exhibit greater : bias. I don't know how large the bias would be for 52 cards. It also : exhibits weak keys. Second, RC4 doesn't provide a convenient way to : generate a randomiser, or IV, to ensure the same passphrase can be : used multiple times; it seems sensible to use card shuffling as a : source of randomness for this application.
I would like to know more about any bias in RC4. Are there references on the web? Concerning your second point, I find the method that I decribed above (using 54 cards) to be roughly comparable to Solitaire in speed. A side question is what is the state space size for Solitaire. It seems to me that, just as my carddeck implementation of ARC4 uses the jokers as pointers, so does Solitaire, although in a more complicated way. (Note that arriving at a joker in the final step of Solitaire is a "null" result, consistent with them being pointers and not part of the state vector itself.) : But third and most importantly, I very much doubt that : encryption/decryption would be relatively fast as you say. I suggest : you try it with a real deck of cards and see how fast you can go;
That's just what I did. As I mentioned, it's comparable to Solitaire in speed. : You can see that Solitaire is strongly influenced by RC4, but the : differences are there because Solitaire is a relatively practical hand : cipher and RC4 turns out not to be.
My handson experience disagrees with that last claim.  r.e.s. rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/19/00 12:00 AM 
"CLSV" < clvi...@dds.nl> wrote ... : "r.e.s." wrote: : : > [ repost of my 1/15/00 "Changing ARC4's StateSpace Size" ] : : [...] : : > So I would like to consider the following encryption method: : > : > (1) A state vector of M distinct symbols is managed by mod M pointer : > arithmetic, using the same logic as ARC4's stream generator. : > (2) Modular addition is used as the combiner, instead of ARC4's XOR. : > (3) The method for initializing the state vector is not specified,
: : Ah, I has the same idea about using RC4 as you pointed out. : : [...] : : > To get a "hand cipher", choose M as a small multiple of the size N : > of the plaintext alphabet, e.g. M=m*N, and use addition mod N as the : > combiner. For example, we can take M=52 and use addition mod 26 for : > the combiner, similar to Solitaire. : : > The case M=52 is tedious but not difficult to implement either with
: : One of the weak points of this cipher is that it is not optimized : for hand use. Maybe it could be changed by subsituting mod 52 arithmetic : with some simpler operations that could be executed with help of : the deck of cards. But otherwise I still think it is a very strong : cipher especially for small messages. : : Regards, : : CLSV Another thing I've tried, with very good success for speed, is taking M=40 instead of 52, using a deck of 40 cards (A10 in four suits) plus 2 jokers. "Digitize" the plaintext, converting from letters to decimals, say with a straddlingcheckerboard), and then use addition mod 10 (very easy by hand) to encipher the digits using the ARC4(M=40) digit stream. Of course such a reduction of state makes it more important to know ARC4's performance with decreasing M. A mitigating factor for the decimal scheme is that at least another 22 bits come from the substitution table for digitizing the plaintext, giving a total of at least 180 bits of entropy. A similar mod40/mod10 scheme can be applied to MIRDEK and Solitaire. Paul says the state space for MIRDEK is (26!)^2, as I recall, but it really looks like 52! to me. If he's right though, reducing to (20!)^2 may not be acceptable, while 40! (159 bits) might be. A mitigating factor favoring the decimal scheme is that at least another 22 bits come from digitizing the plaintext, for a total of at least 180 bits of entropy. (My handson experience with MIRDEK is that it's by far the easiest & fastest cardcipher I've tried  it's just that, like Solitaire, its cycle properties are mostly unknown. That was my main motivation for thinking about extending ARC4, which I thought was regarded as one of the most secure stream ciphers around.)  r.e.s. rs...@mindspring.com

MIRDEK: more fun with playing cards. 
CLSV 
1/20/00 12:00 AM 
Joseph Ashwood wrote: > > > One comment I have is: what is wrong with a modified > > > version of ARCFOUR, say restricted to 52 values?
[...] > the main disadvantage being that it slow key setup by a > significant amount.
Well you could skip the key setup phase completely at the expense of communicating the initial 52card state of the deck as your secret key. If you do 10 proper shuffles the order of the cards will be random enough. > > But third and most importantly, I very much doubt that > > encryption/decryption would be relatively fast as you say. > This is probably the biggest problem, in order to do the swaps a computer > really should be involved. I just don't see where RC4 can be effectively > done exclusively by a human Well, I've tried it (not for speed I must admit) and I believe calculating modulo 52 is possible for most people. The major problem is that the operations are not as userfriendly as those of MIRDEK and Solitaire might be. One thing I would like to see in MIRDEK is a richer character set. "A".."Z", "0".."9", " ", and "." would me enough. If encrypting a character takes 2030 seconds you want to minimize the number of characters in a message. Regards, CLSV 
MIRDEK: more fun with playing cards. 
CLSV 
1/20/00 12:00 AM 
"r.e.s." wrote: > [ repost of my 1/15/00 "Changing ARC4's StateSpace Size" ] [...] > So I would like to consider the following encryption method: > > (1) A state vector of M distinct symbols is managed by mod M pointer > arithmetic, using the same logic as ARC4's stream generator. > (2) Modular addition is used as the combiner, instead of ARC4's XOR. > (3) The method for initializing the state vector is not specified, Ah, I has the same idea about using RC4 as you pointed out. [...] > To get a "hand cipher", choose M as a small multiple of the size N > of the plaintext alphabet, e.g. M=m*N, and use addition mod N as the > combiner. For example, we can take M=52 and use addition mod 26 for > the combiner, similar to Solitaire. > The case M=52 is tedious but not difficult to implement either with
One of the weak points of this cipher is that it is not optimized for hand use. Maybe it could be changed by subsituting mod 52 arithmetic with some simpler operations that could be executed with help of the deck of cards. But otherwise I still think it is a very strong cipher especially for small messages.Regards, CLSV

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/20/00 12:00 AM 
"r.e.s." <rs...@mindspring.com> writes: > Yes, 52! <<< 256!, but 52! is also the size of the statespace for > the Solitaire algorithm. Is there any reason to believe that the > ARC4 stream generator, extended to M=52, would be of worse quality > than Solitaire? (Of course, both might be badly flawed.) Solitaire is certainly biased, see http://www.hedonism.demon.co.uk/paul/solitaire/ > I would like to know more about any bias in RC4. Are there references on > the web? http://www.hedonism.demon.co.uk/paul/rc4/  I recently found out that there's also a paper by Jovan Golic on bias in the least significant bits. > Concerning your second point, I find the method that I decribed above > (using 54 cards) to be roughly comparable to Solitaire in speed. OK. I'm surprised! Have you checked your results against a computer implementation of your cipher? I'll try and measure the bias in RC454 when I get time. > A side question is what is the state space size for Solitaire. It seems > to me that, just as my carddeck implementation of ARC4 uses the jokers > as pointers, so does Solitaire, although in a more complicated way. Solitaire's state space is slightly larger than that of your cipher: 54! compared to 52! * 52 * 52. That's because with your cipher jokers can't end up on the bottom, and the order of two jokers next to each other can't matter. > (Note that arriving at a joker in the final step of Solitaire is a "null" > result, consistent with them being pointers and not part of the state > vector itself.) They are part of the state vector. They just get skipped in the keystream generation stage.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/20/00 12:00 AM 
CLSV <clvi...@dds.nl> writes: > Well you could skip the key setup phase completely at the > expense of communicating the initial 52card state of > the deck as your secret key. If you do 10 proper shuffles > the order of the cards will be random enough. If you have a channel over which you can communicate such a key, why not send the message over it? Or use onetimepads? The convenient thing about Mirdek is that you and I can meet up one day and agree a nice, memorable passphrase, then much later you can go and buy a pack of cards, encrypt as many messages as you like, and I can decrypt them all. > Well, I've tried it (not for speed I must admit) and > I believe calculating modulo 52 is possible for most people. I'd be interested to hear some stopwatch results for this one. > One thing I would like to see in MIRDEK is a richer character > set. "A".."Z", "0".."9", " ", and "." would me enough. This is pretty much impossible. If you use the jokers you could create a cipher with one extra character, perhaps " "; I suggest a number encoding on the Web pages, and you can use STOP telegramlike for full stops (though of course it takes 2:30 to encode it). But then what will you map to joker in the output? No, I think I'll keep it the way it is. Mirdek depends fundamentally on having twice as many cards as characters.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
r.e.s. 
1/20/00 12:00 AM 
"Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ...
[...] : I'll try and measure the bias in RC454 when I get time. That would be interesting, I think. (But imo it would be more appropriate to call this something like ARC452, since it is an implementation of ARC4  or at least the stream generator of ARC4  with altered statevector length M=52 *and* altered combiner. It's worth emphasizing that the modular addition combiner does not produce to ARC4's XOR combiner when M=256.) : > A side question is what is the state space size for Solitaire. It seems : > to me that, just as my carddeck implementation of ARC4 uses the jokers : > as pointers, so does Solitaire, although in a more complicated way. : : Solitaire's state space is slightly larger than that of your cipher: : 54! compared to 52! * 52 * 52. That's because with your cipher jokers : can't end up on the bottom, and the order of two jokers next to each : other can't matter.
For ARC4 using 54 cards in the way I described, it's certainly 52!, because the jokers are used strictly as pointers. (ARC4's statevector of length M has M! states, and the card version is *constructed* to use the jokers in 11 correspondence with the pointers in ARC4's algorithm. Only the sequence of the 52 nonjokers constitute the statevector.) : > (Note that arriving at a joker in the final step of Solitaire is a "null" : > result, consistent with them being pointers and not part of the state : > vector itself.) : : They are part of the state vector. They just get skipped in the : keystream generation stage.
I have to agree that for Solitaire they are part of the statevector, and hence the 54!  my reasoning is that it's because the jokers are *not* skipped in all the counting routines, as they must be if they're pointers (e.g. as in ARC452).  r.e.s. rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
John Myre 
1/20/00 12:00 AM 
Paul Crowley wrote: > CLSV < clvi...@dds.nl> writes: <snip> > > One thing I would like to see in MIRDEK is a richer character > > set. "A".."Z", "0".."9", " ", and "." would me enough. > > This is pretty much impossible. If you use the jokers you could > create a cipher with one extra character, perhaps " "; I suggest a > number encoding on the Web pages, and you can use STOP telegramlike > for full stops (though of course it takes 2:30 to encode it). But > then what will you map to joker in the output? No, I think I'll keep > it the way it is. Mirdek depends fundamentally on having twice as > many cards as characters.
I was thinking a bit about using the old trick of having shift modes. It's rather ugly with 26 symbols since you have to steal a letter to do it. But with a joker, maybe it would be practical? That is, the 27'th symbol would mean "alternate character set". Of course you could invent all sorts of coding schemes; the hope is that you could invent one that is easy and fast. What if we said that joker followed by black card is one of 13 punctuation symbols; joker followed by a sequence of red cards and a terminating joker are used for numbers (10 digits plus perhaps some helpful symbols for scientific notation or money). (Then we get to decide what two consecutive jokers means, and so on). I haven't actually sat down with Mirdek to try this, of course, so I don't know if it really is practical. John M. 
MIRDEK: more fun with playing cards. 
CLSV 
1/20/00 12:00 AM 
Paul Crowley wrote: > > CLSV <clvi...@dds.nl> writes: > > Well you could skip the key setup phase completely at the > > expense of communicating the initial 52card state of > > the deck as your secret key. If you do 10 proper shuffles > > the order of the cards will be random enough. > If you have a channel over which you can communicate such a key, why > not send the message over it? Or use onetimepads? A 52card key is the equivalent of a 225 bit key I don't see the connection with a onetime pad. > The convenient thing about Mirdek is that you and I can meet up one > day and agree a nice, memorable passphrase, then much later you can go > and buy a pack of cards, encrypt as many messages as you like, and I > can decrypt them all.
You have to remember that the opponents will use computers to crack your codes. So it does pay to use a strong password. If you are not able to communicate a 52card key one time I don't believe you have any chance to communicate securely. In the context of civil rights you'll need a semisecret communication channel anyway. If someone catches you sending letters with content like "AXQZV WXYXZ OINAF ..." I think you can expect a visit of the local Gestapo pretty soon. > > Well, I've tried it (not for speed I must admit) and > > I believe calculating modulo 52 is possible for most people. > > I'd be interested to hear some stopwatch results for this one. In a few weeks I have more time on my hands for experiments, I'll try it out and post some results. Module 52 arithmetic can be made easier by splitting it into modulo 4 and modulo 13 arithmetic. > > One thing I would like to see in MIRDEK is a richer character > > set. "A".."Z", "0".."9", " ", and "." would me enough. > > This is pretty much impossible. If you use the jokers you could > create a cipher with one extra character, perhaps " "; I suggest a > number encoding on the Web pages, and you can use STOP telegramlike > for full stops (though of course it takes 2:30 to encode it). But > then what will you map to joker in the output? No, I think I'll keep > it the way it is. Mirdek depends fundamentally on having twice as > many cards as characters. Well you could use two decks of cards, say a blue deck and a red deck. There are quite a few card games using two decks so it would not look too suspicious. Regards, CLSV 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/20/00 12:00 AM 
sorry about the double post  the other one escaped prematurely ;) "Paul Rubin" <p...@netcom.com> wrote ... [re ARC4 using cards] : You'd lay out 4 rows of 13 cards face up, with a pair of coins : (not identical) to mark where the X and Y pointers are. Losing : your place swapping cards doesn't sound like a problem. Since 4 and 13 : are coprime, you'd do the arithmetic mod 4 and 13 separately, so : you'd go up 2 columns and over 5, or etc. I've gone through this : in my head and it doesn't seem too bad. I'll have to try it with : an actual deck of cards sometime when I get around to borrowing one : (I don't have one handy and don't feel like buying one just for this). : : >You can see that Solitaire is strongly influenced by RC4, but the : >differences are there because Solitaire is a relatively practical hand : >cipher and RC4 turns out not to be.
: : I think Bruce just didn't like the idea of laying out all the cards : face up (he and I discussed this stuff by email sometime before he : designed Solitaire). Laying out the cards as you say is a great idea. When done that way, I find "52card ARC4" is even faster than MIRDEK, and leaves Solitaire way behind. Using two different coins as pointers, there is no card movement at all except when swapping, which is now *very* easy. (Just leave a bit of space for the coins between rows.) The whole procedure is now practically effortless.  r.e.s. rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/20/00 12:00 AM 
Rex, I suppose you mean you have trouble adding the *swapped* cards. The pointers themselves have no value except as the cards they mark, i.e. the ones that get swapped. ("y=y+S(x)" as a source code instruction translates into "move the ypointer ahead by jumping over a number of cards equal to the value of the card pointed to by the xpointer", just as "x=x+1" means "move the xpointer ahead by jumping over 1 card".) As far as adding the two swapped cards mod 52, I use the suits to keep things straight. (I'm visuallyoriented, and see Diamonds,Spades,Hearts,Clubs as visually suggestive of 0,1,2,3 respectively  spades & clubs have "stems" with 1 and 3 globs attached; diamond and spades look "roundish" (even) with a diamond resembling a 0. Thus an X of diamonds has value X + 0*13, while an X of spades has value X + 1*13, etc with X + 2*13 and X + 3*13 for hearts & clubs, respectively.) *Note* Paul Rubin's idea of laying out all the cards in a 4x13 array, and using two different coins as pointers in the space between rows, allows *very* fast operation. You'll like it better, I'm sure. The only card movement is the swap, which is a cinch. This is now the fastest card cipher I've seen.
 r.e.s. rs...@mindspring.com <T_Re...@yahoo.com> wrote in message news:868qjo$b8e$1@nnrp1.deja.com... : Trial Results of ARC452 compared with Solitaire. : : Well, I did get around to an initial attempt at ARC452 and, at least : at first is does seem more difficult to me than Solitaire. However, : I seem to be having trouble with a different part of it than some of : you would expect. I can do addition mod 52 in my head rather easily, : but remembering i an j while counting and swapping cards seems to : befuddle me. Maybe it is just because I don't do that too often, : or maybe I am just not wired that way. ... 
MIRDEK: more fun with playing cards. 
T_Re...@yahoo.com 
1/21/00 12:00 AM 
Trial Results of ARC452 compared with Solitaire. Well, I did get around to an initial attempt at ARC452 and, at least at first is does seem more difficult to me than Solitaire. However, I seem to be having trouble with a different part of it than some of you would expect. I can do addition mod 52 in my head rather easily, but remembering i an j while counting and swapping cards seems to befuddle me. Maybe it is just because I don't do that too often, or maybe I am just not wired that way. This does bring up a point that may never be agreed upon  which operation take longer, or are more complex, for a human. The time it takes a Pentium or K6 processor to do a particular operation can be looked up in a book  and it is likely if one operation is quicker than another (addition is quicker than division) on one processor it is likely to be quicker on most of them. Humans are much more variable. I can do some math functions in my head that astonish most algebra and trig teachers  but as I stated above, trying to remember a couple of numbers while counting to 31 befuddles me. Also, while I can do some fairly descent gymnastics with my mind (admittedly not as fast as most people in this forum), manipulations done with my hands are slower than average. These individual differences are likely to mean one cypher will be faster for one person, and a different one for someone else. Rex Stewart Sent via Deja.com http://www.deja.com/ Before you buy.

MIRDEK: more fun with playing cards. 
Paul Rubin 
1/21/00 12:00 AM 
Paul Crowley < pa...@hedonism.demon.co.uk> wrote: re: [RC4 with a deck of cards] >But third and most importantly, I very much doubt that >encryption/decryption would be relatively fast as you say. I suggest >you try it with a real deck of cards and see how fast you can go; >compare to a computer implementation to see whether you're getting the >right answers. You'll have to count lots of cards to index into the >deck, swap cards without losing your place, and do Vigenere addition >(or for decryption, subtraction, which is worse) in your head. Try >feeding the output of the Unix "fortune" program into your >implementation and decrypting it; I suspect you'll find it a >demoralising experience, with lots of time burned on incorrect >decryptions. You'd lay out 4 rows of 13 cards face up, with a pair of coins (not identical) to mark where the X and Y pointers are. Losing your place swapping cards doesn't sound like a problem. Since 4 and 13 are coprime, you'd do the arithmetic mod 4 and 13 separately, so you'd go up 2 columns and over 5, or etc. I've gone through this in my head and it doesn't seem too bad. I'll have to try it with an actual deck of cards sometime when I get around to borrowing one (I don't have one handy and don't feel like buying one just for this).
>You can see that Solitaire is strongly influenced by RC4, but the >differences are there because Solitaire is a relatively practical hand >cipher and RC4 turns out not to be.
I think Bruce just didn't like the idea of laying out all the cards face up (he and I discussed this stuff by email sometime before he designed Solitaire).
>Mirdek is IMHO considerably more practical than Solitaire. As you'll >see from the website, I've spent quite a bit of time with a stopwatch >and a pack of cards, making sure I've got a cipher that can be done in >reasonable time. I've successfully decrypted thirty character >ciphertexts with six character keyphrases in just over twenty minutes, >using only a conversion chart (which is easily drawn from memory) and >a pack of cards. Once you've tried doing RC4 by hand and got bored, >try doing Mirdek, and I think you'll appreciate why I felt the need to >design a new cipher.
One character/minute sounds pretty painful. How about RC4 (even with 255 = 15*17 elements) with pencil, paper, 2 coins, and an eraser? 
MIRDEK: more fun with playing cards. 
Paul Crowley 
1/21/00 12:00 AM 
CLSV <clvi...@dds.nl> writes: > So it does pay to use a strong password. If you are not able to > communicate a 52card key one time I don't believe you have any > chance to communicate securely. When you say "one time", you mean "once per message". If you're in a position to communicate big strings of random nonsense once per message, you can use the most successful secure hand cipher in the world, the one time pad. On the other hand, six randomlychosen six digit words can be memorised readily, and searches will not reveal them. If you use Diceware to generate them, this will give you 77.5 bits of entropy in your keyphrase  enough to keep even the best funded attackers off your back for quite a while. > In the context of civil rights you'll need a semisecret > communication channel anyway. If someone catches you sending letters > with content like "AXQZV WXYXZ OINAF ..." I think you can expect a > visit of the local Gestapo pretty soon. Or at least a channel by which, if messages are intercepted, they can't be traced back to you. > Well you could use two decks of cards, say a blue deck > and a red deck. There are quite a few card games using > two decks so it would not look too suspicious. True, but I'd rather the output consisted only of the letters AZ, which fixes the input to those letters for any convenient variant of Mirdek. Unless you use some sort of input transformation which converts the input to a string of characters drawn from AZ...  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/21/00 12:00 AM 
p...@netcom.com (Paul Rubin) writes: > You'd lay out 4 rows of 13 cards face up, with a pair of coins > (not identical) to mark where the X and Y pointers are. Losing > your place swapping cards doesn't sound like a problem. Since 4 and 13 > are coprime, you'd do the arithmetic mod 4 and 13 separately, so > you'd go up 2 columns and over 5, or etc. I've gone through this > in my head and it doesn't seem too bad. ISTR this exact cipher was proposed on this very newsgroup long before Solitaire was ever published  was it you perchance? I'm not surprised to learn that it's fast, but finding enough table space to lay out all the cards is a pain, and when you do the arithmetic as you suggest you're looking at a very different cipher than RC4  possibly one far more biased. If you ever code it up, though, please let us know and I'll do some statistics on the output. In general, I recommend *everyone* write a machine implementation of their proposals, because without one it's hard to assess the accuracy you can achieve. I've been testing Mirdek by decrypting random outputs from Unix "fortune". I also think that only randomised ciphers are practical proposals, since you can't keep exchanging keyphrases! So I'd be interested to hear ideas about how to make a randomised cipher out of ARC134. > I'll have to try it with an actual deck of cards sometime when I get > around to borrowing one (I don't have one handy and don't feel like > buying one just for this). Oh go on, this is fun! I currently have three decks of cards lying about, two of which are now marked with letters because they're too old and marked to be used for card games... > One character/minute sounds pretty painful. No, it's more like two characters per minute, with a ten minute overhead. Actually it's slightly faster than two characters per minute for me at the moment. With a friend transcribing the ciphertext, I wouldn't have to stop to reach for a pen and I could probably get it done in about 20 seconds per character.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/21/00 12:00 AM 

MIRDEK: more fun with playing cards. 
r.e.s. 
1/21/00 12:00 AM 
It's simple to use a 4x13 card layout to implement the *exact* ARC4 logic with statevector length 52 (and modular addition combiner.) The only cardmovement is the swap, which takes about 1 second, and the pointer(coin)movement takes about 10 seconds for both pointers total. I can easily run off 1415 letters per minute this way, so I think this version of "52 card ARC4" is faster than any other secure card cipher. Also, as I already posted, you can shuffle the deck to initialize the state vector if you want randomization. My suggestion was to not specify the initialization method as necessarily being ARC4's, but to instead leave it up to the user. (But ARC4's keying method could easily be adapted for using passphrases with "52card ARC4.) Concerning the alleged bias in ARC4, imo it's so small as to be negligible in the context of hand ciphers.  r.e.s. rs...@mindspring.com "Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ... [...] : I'm not : surprised to learn that it's fast, but finding enough table space to : lay out all the cards is a pain, and when you do the arithmetic as you : suggest you're looking at a very different cipher than RC4  possibly : one far more biased. If you ever code it up, though, please let us : know and I'll do some statistics on the output. [...] : I also think that only randomised ciphers are practical proposals, : since you can't keep exchanging keyphrases! So I'd be interested to : hear ideas about how to make a randomised cipher out of ARC134. [...]

MIRDEK: more fun with playing cards. 
r.e.s. 
1/21/00 12:00 AM 
"Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ...
: "r.e.s." <rs...@mindspring.com> writes: : > For ARC4 using 54 cards in the way I described, it's certainly 52!, : > because the jokers are used strictly as pointers. : : The position of the pointers is part of the state of both pure ARC4 : and ARC452, thus 52! * 52 * 52. I disagree. Your two extra factors of 52 have no counterpart in any free selection of values. The pointers are required to be initialized as x=y=0, and are thereafter completely determined by the algorithm's way of managing the evolution of the 52element statevector.  r.e.s. rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
CLSV 
1/21/00 12:00 AM 
Paul Crowley wrote: > CLSV < clvi...@dds.nl> writes: > > So it does pay to use a strong password. If you are not able to > > communicate a 52card key one time I don't believe you have any > > chance to communicate securely. > When you say "one time", you mean "once per message". If you're in a No, I mean just once before encrypted communication starts. Just like the scenario in your previous posting where two persons meet and exchange a password. Why do you keep insisting that exchanging a 225 bit password is the same as exchanging a one time pad? > position to communicate big strings of random nonsense once per > message, you can use the most successful secure hand cipher in the > world, the one time pad. > On the other hand, six randomlychosen six digit words can be > memorised readily, and searches will not reveal them. If you use There are ways to communicate a 52 card password that don't draw suspicion. For example you could agree on using the last 52 unique reverse digrams from a specific article of the popular political journal "The Great Dictator". > Diceware to generate them, this will give you 77.5 bits of entropy in > your keyphrase  enough to keep even the best funded attackers off > your back for quite a while. I believe nowadays 80 bits is thought to be the bare minimum for secure communication. Regards, CLSV 
MIRDEK: more fun with playing cards. 
CLSV 
1/21/00 12:00 AM 
"r.e.s." wrote: > It's simple to use a 4x13 card layout to implement the *exact* ARC4 > logic with statevector length 52 (and modular addition combiner.) > The only cardmovement is the swap, which takes about 1 second, and > the pointer(coin)movement takes about 10 seconds for both pointers > total. I can easily run off 1415 letters per minute this way, so > I think this version of "52 card ARC4" is faster than any other > secure card cipher. Please try it out before you make such claims (as Paul Crowley remarked it *is* fun to do). I think it can be fast given enough practice but 1415 characters a minute, no way. That is 4 seconds for one encryption! On my first try I achieved a speed of about one char in 50 seconds. Regards,
CLSV 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/21/00 12:00 AM 
"CLSV" < clvi...@dds.nl> wrote ... : "r.e.s." wrote: : > It's simple to use a 4x13 card layout to implement the *exact* ARC4 : > logic with statevector length 52 (and modular addition combiner.) : > The only cardmovement is the swap, which takes about 1 second, and : > the pointer(coin)movement takes about 10 seconds for both pointers : > total. I can easily run off 1415 letters per minute this way, so : > I think this version of "52 card ARC4" is faster than any other : > secure card cipher. : : Please try it out before you make such claims : (as Paul Crowley remarked it *is* fun to do).
Please don't be so presumptuous. I was speaking from handson experience. : I think it can be fast given enough practice but : 1415 characters a minute, no way. That is 4 : seconds for one encryption! On my first try I : achieved a speed of about one char in 50 seconds.
We must be doing something differently. Here's the routine for the stream generator of "52card ARC4" with 4x13 cardlayout, placing the coins adjacent to the cards they point to: 1) start with the xcoin and ycoin at the upperleft card 2) move the xcoin to the next card 3) read the card at the xcoin and move the ycoin that many cards ahead 4) swap the cards at the x and ycoins 5) output the modulo sum of the cards just swapped 6) return to step 2 Only step 4 involves moving cards  it takes ~1 sec  and moving the coins is now *very* fast because of the mod13 significance of the rows.  r.e.s. "Mistr Typo" rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/21/00 12:00 AM 
"r.e.s." < rs...@mindspring.com> wrote ... : "CLSV" < clvi...@dds.nl> wrote ... : : "r.e.s." wrote: [...] : : > I can easily run off 1415 letters per minute this way, so : : > I think this version of "52 card ARC4" is faster than any other : : > secure card cipher. : : : : Please try it out before you make such claims : : (as Paul Crowley remarked it *is* fun to do). : : Please don't be so presumptuous. : I was speaking from handson experience.
Ouch!  I owe you an apology. My times were for letters per *3* minutes, not 1, which means I'm generating ~5 letters per minute. Still the fastest secure card cipher around?  r.e.s. rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/21/00 12:00 AM 
[typo correction] "r.e.s." <rs...@mindspring.com> wrote ... [...] : Here's the routine for the stream generator of "52card ARC4" : with 4x13 cardlayout, placing the coins adjacent to the cards : they point to: : 1) start with the xcoin and ycoin at the upperleft card : 2) move the xcoin to the next card : 3) read the card at the xcoin and move the ycoin that : many cards ahead : 4) swap the cards at the x and ycoins : 5) output the modulo sum of the cards just swapped
^^^^^^^... Of course that should be be 5) output the value of the card whose location is the mod52 sum of the cards just swapped Sorry for the typo. : 6) return to step 2 : : Only step 4 involves moving cards  it takes ~1 sec  : and moving the coins is now *very* fast because of the mod13 : significance of the rows. : :  : r.e.s. "Mistr Typo" : rs...@mindspring.com

MIRDEK: more fun with playing cards. 
Joseph Ashwood 
1/21/00 12:00 AM 
I see two major problems with the key setup. Using the original method of determining the state values for ARC4 leads to a very large number of keys that have repeated values, not a problem in a computer but it is a problem for a human with a deck of cards. Doing the math to figure out the order of the cards using the original method leads to a great number of potential problems, ie I can create a password that would be completely impossible to use. Both of these lead me to believe that if we do chose to base it on ARC4 we would need to replace the key setup. My initial thoughts on the concept turn out to be rather a long process, but I believe it yields enough ambiguity to the initial state to be usable, however I'm still trying to solve for the allowed entropy with various length passwords/phrases, and even then I'm not sure if it's useful for a human. Joe 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/21/00 12:00 AM 
"Joseph Ashwood" < ash...@email.msn.com> wrote ... : I see two major problems with the key setup. : : Using the original method of determining the state values for ARC4 leads to : a very large number of keys that have repeated values, not a problem in a : computer but it is a problem for a human with a deck of cards. : : Doing the math to figure out the order of the cards using the original : method leads to a great number of potential problems, ie I can create a : password that would be completely impossible to use.
Could you give specific examples of these two claims. I don't understand either one of them, but I seem to be in a poor "operating mode" today What do you mean by "keys that have repeated values"?
Are you speaking of problems with the "y=y+S(x)+K(x)" part of ARC4's setup phase, now involving 52 iterations? I don't see where the math problems might enter. : Both of these lead me to believe that if we do chose to base it on ARC4 we : would need to replace the key setup.
I agree, in the sense that more than 52 iterations would be advisable in the keying phase, especially if an IV is being used, as is recommended. (When I proposed using cards for ARC4's stream generator, I suggested leaving the state initialization method up to the user, so that using a shared shuffled deck as the key would be a possibility if that were deemed acceptable.) : My initial thoughts on the concept turn : out to be rather a long process, but I believe it yields enough ambiguity to : the initial state to be usable, however I'm still trying to solve for the : allowed entropy with various length passwords/phrases, and even then I'm not : sure if it's useful for a human. : Joe
 r.e.s. "Mistr Typo" rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
Joseph Ashwood 
1/21/00 12:00 AM 
"CLSV" < clvi...@dds.nl> wrote in message news:38890234.AC515A45@dds.nl... > I don't think I understand what you mean? > Personally I would communicate a random > permutation of 52 cards as a key and skip > the setup. The problem with that is that the needed resources to communicate with multiple people grows very quickly, at exactly one 52/54 card/numeric order per person, however if you have a static beginning permutation of 52 or 54 cards/numbers, and simply generate a new permutation based on the key, you have the need to store the permutation once and a relatively small key from there on. Also if one deck is compromised, there is the distinct possibility of not having the complete key compromised, very much like the ATM systems. If you're communicating with only one entity, or you have a single powerful entity in the middle (clients/server model), then it is concievable to go keyless. Joe 
MIRDEK: more fun with playing cards. 
Joseph Ashwood 
1/21/00 12:00 AM 
> Could you give specific examples of these two claims.
No problem. First: Take ARC4 and give it the passphrase of 255, 254, 253, 252, . . . .2, 1, 0 Every value in the array becomes identical, this is a very bad idea, especially since we only have one of each card. This is one of 256 in the worst cases, but there are a large number of others. Second: I can choose a password such that an arbitrary card is outside of the valid bounds, this could be partially be remedied by the use of modular division, but that introduces quite string biases for lower order values, amplifying the effect of the first. This problem can be reduced by using absurdly large values as the input to the modular division, but that's simply not workable in this situation. As a specific example: When using addition card with value 1, plus key of highest value = value outside bounds Using XOR we must use a 063 range: card value = 15, key = 48 > value = 63 Joe 
MIRDEK: more fun with playing cards. 
CLSV 
1/22/00 12:00 AM 
"r.e.s." wrote: > "CLSV" <clvi...@dds.nl> wrote ... > : "r.e.s." wrote: > : > It's simple to use a 4x13 card layout to implement the *exact* ARC4 [..] > : Please try it out before you make such claims > : (as Paul Crowley remarked it *is* fun to do). > Please don't be so presumptuous. > I was speaking from handson experience. Well my apologies if it sounded that way, it was more like my amazement sounding through. > : I think it can be fast given enough practice but > : 1415 characters a minute, no way. That is 4 > : seconds for one encryption! On my first try I > : achieved a speed of about one char in 50 seconds. > We must be doing something differently. > Here's the routine for the stream generator of "52card ARC4" > with 4x13 cardlayout, placing the coins adjacent to the cards > they point to: > 1) start with the xcoin and ycoin at the upperleft card > 2) move the xcoin to the next card > 3) read the card at the xcoin and move the ycoin that > many cards ahead > 4) swap the cards at the x and ycoins > 5) output the modulo sum of the cards just swapped > 6) return to step 2
Ah, you forget a step I believe, shouldn't it be 5) the modulo of the sum of the cards swapped gives the index to the card whose value is the output The card swapping is indeed fast but the administration in my head always slows things down. But that's probably because I'm not a fast thinker. Regards, CLSV 
MIRDEK: more fun with playing cards. 
CLSV 
1/22/00 12:00 AM 
"r.e.s." wrote: [On ARC452] > My times were for letters per *3* minutes, not 1, > which means I'm generating ~5 letters per minute. > Still the fastest secure card cipher around? Well you're still much faster than I am :) Personally I think 2 chars a minute would be *really* great. But check my remarks in another post about your procedure. Regards, CLSV 
MIRDEK: more fun with playing cards. 
CLSV 
1/22/00 12:00 AM 
Joseph Ashwood wrote: > I see two major problems with the key setup. > Using the original method of determining the state values for ARC4 leads to > a very large number of keys that have repeated values, not a problem in a > computer but it is a problem for a human with a deck of cards. I don't think I understand what you mean? Personally I would communicate a random permutation of 52 cards as a key and skip the setup.
Regards, CLSV 
MIRDEK: more fun with playing cards. 
Paul Rubin 
1/22/00 12:00 AM 
In article <3888FF92...@dds.nl>, CLSV <clvi...@dds.nl> wrote: >Ah, you forget a step I believe, shouldn't it be >5) the modulo of the sum of the cards swapped gives > the index to the card whose value is the output > >The card swapping is indeed fast but the administration >in my head always slows things down. But that's probably because >I'm not a fast thinker. Don't try to do the arithmetic mod 52. Just do it mod 13, based on (say) K=0, A=1, 2=2, ..., 10=10, J=11, Q=12 to locate the output column of the output card. To get the row of the output card, add the *suits* of the swapped cards, mod 4. I like the visual mnemonic of Diamond=0, spade=1, heart=2, club=3. Very cute. 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/22/00 12:00 AM 
"Joseph Ashwood" <ash...@email.msn.com> wrote ...
: > Could you give specific examples of these two claims. : No problem. : : First: : : Take ARC4 and give it the passphrase of : 255, 254, 253, 252, . . . .2, 1, 0 : : Every value in the array becomes identical, this is a very bad idea, : especially since we only have one of each card. This is one of 256 : in the worst cases, but there are a large number of others.
Every value in *what* array becomes identical? ARC4's statevector array is always some permutation of 256 *distinct* values 0,1,2,...,255. "ARC452", to mirror ARC4, would use an alphabet of 52 symbols (instead of 256) for both the statevector and for keydata. Maybe you were thinking that a 256symbol character set would still be used in ARC452? (The statevector will have length 52, and will always be a permutation of the 52symbol alphabet.) If you're concerned about the alphabet being 52 symbols instead of 26, this is no problem, because we could simply have keys that use, say, both upper & lower case letters to get 52 ordinary letters az,AZ with values 025,2651 respectively. : Second: : : I can choose a password such that an arbitrary card is outside of the valid : bounds, this could be partially be remedied by the use of modular division, : but that introduces quite string biases for lower order values, amplifying : the effect of the first. This problem can be reduced by using absurdly large : values as the input to the modular division, but that's simply not workable : in this situation. As a specific example: : When using addition card with value 1, plus key of highest value = value : outside bounds : Using XOR we must use a 063 range: card value = 15, key = 48 > value = 63
It looks to me like there is a misunderstanding about the size of the character set, perhaps.  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/22/00 12:00 AM 
CLSV <clvi...@dds.nl> writes: > > When you say "one time", you mean "once per message".
> No, I mean just once before encrypted communication starts. Could you be more explicit about how you then go on to encrypt more than one message? I can think of one way, which is simply to start the new message with the state where you left off the old message, but this requires that the recipient either receive all of your messages (unlikely) or at least know how long they all were (OK if your recipient is decrypting with a computer). However, the requirement that you carry this state around with you is burdensome  with Mirdek, you can throw away your (sorted) pack of cards at the border, buy a new pack in a new country, and start encrypting again, all using only a memorised passphrase. There must be ways to achieve this goal with an ARC4 variant. > Why do you keep insisting that exchanging a 225 bit password is the > same as exchanging a one time pad? Because I'm guessing that a lot of messages will be fewer than 52 characters long, so you could ship a onetimepad suitable for encrypting them just as easily as you could ship one of your keys. However if you do have a practical way to encrypt more than one message then this objection won't hold. > > Diceware to generate them, this will give you 77.5 bits of entropy > >in your keyphrase  enough to keep even the best funded attackers off > >your back for quite a while. > > I believe nowadays 80 bits is thought to be the bare minimum for > secure communication. 80 bit passphrases are kind of hard to come by. If you want the incredible convenience of passphrases, as well as freedom from the risk of the key being found by physical search, you have to put up with a little loss in key entropy. In practice raising the resources to bruteforce a 77.5bit key is still out of anyone's reach today  consider that the 64bit RC5 cracking project is still going and doesn't expect to finish for years. > There are ways to communicate a 52 card password that don't draw > suspicion. For example you could agree on using the last 52 unique > reverse digrams from a specific article of the popular political > journal "The Great Dictator". What's the key entropy under these circumstances, though? I'm guessing that many fewer than 2^80 such diagrams have ever been published. Even including transformations, you'll have a hard time getting much key entropy. (Apologies if anything I write here sounds harsh, I've just been dragged out of bed to let the TV aerial worker in. I'm enjoying this thread a lot and grateful to all participants!)  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/22/00 12:00 AM 
"r.e.s." <rs...@mindspring.com> writes: > : The position of the pointers is part of the state of both pure ARC4 > : and ARC452, thus 52! * 52 * 52. > > I disagree. Your two extra factors of 52 have no counterpart in any > free selection of values. The pointers are required to be initialized > as x=y=0, and are thereafter completely determined by the algorithm's > way of managing the evolution of the 52element statevector. I guess it depends on your terminology. I'd say 52!*52*52 is the state space, but that it can only start in a small part of that space.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/22/00 12:00 AM 

MIRDEK: more fun with playing cards. 
r.e.s. 
1/22/00 12:00 AM 
"Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ... : "r.e.s." <rs...@mindspring.com> writes:
: > : "Paul Crowley" wrote: : > : The position of the pointers is part of the state of both pure ARC4 : > : and ARC452, thus 52! * 52 * 52. : > : > I disagree. Your two extra factors of 52 have no counterpart in any : > free selection of values. The pointers are required to be initialized : > as x=y=0, and are thereafter completely determined by the algorithm's : > way of managing the evolution of the 52element statevector. : : I guess it depends on your terminology. I'd say 52!*52*52 is the : state space, but that it can only start in a small part of that space.
OK, but that seems misleading because one might be led to suppose that there are log2(52!*52*52) bits of entropy involved, when there are only log2(52!) bits. (With the usual convention that the algorithm is assumed to be known by the attacker.)  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
CLSV 
1/22/00 12:00 AM 
Paul Crowley wrote: > > CLSV <clvi...@dds.nl> writes: > > > When you say "one time", you mean "once per message". > > No, I mean just once before encrypted communication starts. > Could you be more explicit about how you then go on to encrypt more > than one message? > I can think of one way, which is simply to start the new message with > the state where you left off the old message, but this requires that > the recipient either receive all of your messages (unlikely) or at > least know how long they all were (OK if your recipient is decrypting > with a computer). That would also give problems when you are communicating with different people using the same key. I was thinking about using special start values of the pointers I and J as salt. You can send them in the clear with the encrypted message. I don't know how it affects security 'though. > However, the requirement that you carry this state around with you is > burdensome  with Mirdek, you can throw away your (sorted) pack of > cards at the border, buy a new pack in a new country, and start > encrypting again, all using only a memorised passphrase. There must > be ways to achieve this goal with an ARC4 variant. Well ARC4 is not sacred to me in this context. One of its problems is that it fails to make use of powerful operations that can be done easily by hand and inefficiently on a computer. E.g. swapping two cards by hand is as easy as swapping two packs of twenty cards. > I'm enjoying this > thread a lot and grateful to all participants!) Indeed, I think it is a useful subject and it provides some interesting food for thought. Regards, CLSV 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/22/00 12:00 AM 
"Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ...
: "r.e.s." <rs...@mindspring.com> writes: : > Concerning the alleged bias in ARC4, imo it's so small as to be : > negligible in the context of hand ciphers. : : I'm not sure why you use the word "alleged" here. Also we don't yet : know how large it would be for the variant you propose. I say "alleged" to mean that bias is being asserted, not that the assertion is without some evidence. You're right, of course that "ARC452" requires further evaluation (as does MIRDEK and Solitaire). A side issue: If you required "just under 56 trillion samples of RC4 output" to confirm a bias in ARC4, does that suggest that an adversary would need a similar volume of ciphertext in order to capitalize on that bias? It seems likely to me that there are always values of eps > 0 such that the mere *existence* of bias < eps is without practical significance for the cipher. So we want to know not only, e.g., a confidence interval for the bias with a reasonable level of confidence, but also we need to determine whether the results are of practical significance.  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
Paul Rubin 
1/23/00 12:00 AM 
In article < 8766wmw...@hedonism.demon.co.uk>, Paul Crowley <pa...@hedonism.demon.co.uk> wrote: >CLSV <clvi...@dds.nl> writes: >> > When you say "one time", you mean "once per message". >> No, I mean just once before encrypted communication starts. > >Could you be more explicit about how you then go on to encrypt more >than one message? > >I can think of one way, which is simply to start the new message with >the state where you left off the old message, but this requires that >the recipient either receive all of your messages (unlikely) or at >least know how long they all were (OK if your recipient is decrypting >with a computer).
Why not just do what CipherSaber does, which is combine the passphrase with a random salt before doing the key setup, and send the salt in the clear?

MIRDEK: more fun with playing cards. 
Rex Stewart 
1/23/00 12:00 AM 
I have been practicing Mirdek and have noticed several things. First is that, because I haven't done much with card deck cyphers in a while I am rusty, and it appears to require about 15 hours to get proficient. This is an important fact to convey to anyone planning to use these cyphers in a "real world" situation. The first several hours of this will be spent getting their mind used to seeing the letters of the alphabet on the red and black cards and learning the rules of the encryption system. You can't just agree on a system and run off to a hostile area and expect to do this cold turkey. Also, this means if they have trouble at first they should not give up too easily. At this point I do not feel proficient enough to state whether ARC452, Mirdek, or even Solitaire  and I haven't even begun to look at John Savard's (unnamed?) card deck cypher  is faster. I expect it will require several more weeks of practice before I will feel comfortable making that statement. I think it would be interesting if someone were to take the time to make a table showing all of the operations used in each cypher, how many of each operation are required in the keying and encryption routines, and how long an "average" person would take (after some practice) to execute each operation. Using a generic "timer tic" unit of time measurement would allow comparing speed on one operation to another while obscuring the comparison of the speed of one person to another. Again, I must point out, this is something may never be agreed upon: which operation take longer, or are more complex, for a human. The time it takes a Pentium or K6 processor to do a particular operation can be looked up in a book  and it is likely if one operation is quicker than another (addition is quicker than division) on one processor it is likely to be quicker on most of them. Humans are much more variable. I can do some math functions in my head that astonish most algebra and trig teachers  but as I stated above, trying to remember a couple of numbers while counting to 31 befuddles me. And I can't manipulate cards with my hands as quickly as many of my card playing friends. I would expect this nonagreement to be increased because the author of a particular cypher will likely have much more practice with his/her own cypher than with other cyphers. While reading the following, it should be noted: I am not a cryptographer. Especially every time you see the words "should" or "seems" or "appears" :) While there has been a lot of discussion about bias in the output, I have been looking at all of these cyphers from a different point of view. A bias of several percent in the output in a hand cypher is not nearly as important as insulating the factors that are known (or can be guessed) to an adversary from those that the adversary does not know. While experimenting with my own variations of card deck cyphers, I was able to create one that I am certain has very balanced output, but when I looked at a known plaintext attack, it was a disaster. It leaked over two bits of state information for every consecutive known plaintext letter. Not that the discussions on bias are completely unwarranted, but I wonder: in 60 separately keyed messages of 400 characters each, with 30 consecutive known plain text bytes  how much state information would you expect the bias to reveal? (See the disclaimer above, but in this case I don't think the bias would be significantly useful.) On output feedback cyphers based on ARC4 variants (like Solitaire) insulating the state information (and therefore the key) from the output seems fairly straightforward, and in fact Solitaire seems to have two layers of such insulation. The downside of course is the requirement to use a new key for each message. In cyphers which incorporate the cyphertext or plaintext into the state entropy, this can be much more difficult. Terry Ritter posted a message a few years back about this problem with his Dynamic Substitution. An explanation of the problem can probably be found on his website. I was first bothered by the open transmission of the IV in the message, but on closer observation, swapping the decks between keying and mixing seems to effectively hide this information by reordering the IV based on the key. This cypher adds entropy to the state information in much the same way as Terry Ritter's Dynamic Substitution, and that could be a problem, although the simultaneous adding of entropy from the right hand deck should provide enough confusion (it adds 3.5 bits entropy each round, the plain text adds 1.3 bits) to preclude recovery of significant state information in the case of a known plaintext attack (I am not so sure about a chosen plaintext attack). The 26 mixing steps themselves seemed at first to be aimed at insulating the key from the state information, but because the IV is sent in the clear this is not the case and in fact Paul Crowley, the author, clearly warns it is not the case. These steps appear aimed at using the key information to hide the IV. As such it seems excessive, since every card in the IV should be effected by key at least most of the key information (I have not done a full statistical analysis of this) in the first seven mixings, and should be effected twice after only ten mixings. In fact, in all of these card deck cyphers, it seems the keying phase is the biggest single chunk of overhead  and it seems in all of them the keying is somewhat excessive. OTOH, I don't have a degree in statistics and am not prepared to present a universally acceptable alternative.  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A Sent via Deja.com http://www.deja.com/ Before you buy.

MIRDEK: more fun with playing cards. 
CLSV 
1/23/00 12:00 AM 
Paul Rubin wrote: > In article <8766wmw...@hedonism.demon.co.uk>, > Paul Crowley <pa...@hedonism.demon.co.uk> wrote: > >I can think of one way, which is simply to start the new message with > >the state where you left off the old message, but this requires that > >the recipient either receive all of your messages (unlikely) or at > >least know how long they all were (OK if your recipient is decrypting > >with a computer). > Why not just do what CipherSaber does, which is combine the > passphrase with a random salt before doing the key setup, and > send the salt in the clear? The problem is that you want to skip key setup because it is very labor intensive. But I posted an alternative like initializing I and J with other values than 0. Regards, CLSV 
MIRDEK: more fun with playing cards. 
Paul Rubin 
1/23/00 12:00 AM 
In article <388B32C5...@dds.nl>, CLSV <clvi...@dds.nl> wrote: >> Why not just do what CipherSaber does, which is combine the >> passphrase with a random salt before doing the key setup, and >> send the salt in the clear? > >The problem is that you want to skip key setup because >it is very labor intensive. But I posted an alternative >like initializing I and J with other values than 0. I thought that the "coins" method might make key setup tolerably fast. Reusing keys with different initial I and J sounds very dangerous. Collecting a few such messages reveals too much of the state vector. 
MIRDEK: more fun with playing cards. 
CLSV 
1/23/00 12:00 AM 
Paul Rubin wrote: > > In article <388B32C5...@dds.nl>, CLSV <clvi...@dds.nl> wrote: > >> Why not just do what CipherSaber does, which is combine the > >> passphrase with a random salt before doing the key setup, and > >> send the salt in the clear? > > > >The problem is that you want to skip key setup because > >it is very labor intensive. But I posted an alternative > >like initializing I and J with other values than 0. > > I thought that the "coins" method might make key setup > tolerably fast. Reusing keys with different initial I and J Hmm, if we use the ARC4 setup that means creating 52 output values that we throw away. Say 30 secs per character that means 25 minutes shuffling cards at top speed before encryption starts. > sounds very dangerous. Collecting a few such messages > reveals too much of the state vector. Ah, you got me there. Patching a cipher is never a good idea. At least not without proper analysis. Regards, CLSV 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/23/00 12:00 AM 
"Rex Stewart" < T_Re...@yahoo.com> wrote ... [...] : On output feedback cyphers based on ARC4 variants (like : Solitaire) insulating the state information (and therefore the key) : from the output seems fairly straightforward, and in fact Solitaire : seems to have two layers of such insulation. The downside of : course is the requirement to use a new key for each message.
[...] But it's a "downside" required for any stream cipher, and hence applies to all of the card ciphers mentioned in this thread. IMO, I don't think it's accurate to describe Solitaire as an "ARC4 variant", although it may have been influenced by ARC4. (As I posted before, I'm actually interested in the whole class of what we might call ARC4M variants  where M is the length of the state vector  whether implemented by cards or computer. The lack of response to those earlier postings suggests that this may be an unexplored area.)  r.e.s. rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/23/00 12:00 AM 
"CLSV" < clvi...@dds.nl> wrote ... [...] : Hmm, if we use the ARC4 setup that means creating : 52 output values that we throw away.
Depending on how wellrandomized the passphrase letters are, it could be quite a bit worse than that if we want say 128 bits of entropy in the passphrase  and this applies to all the card ciphers discussed in this thread. (If a cipher's key is determined by a passphrase, and we want the overall system to be secure in the sense of requiring any adversary to do bruteforce searches in a space of, say, at least 128 bits, then it's inescapable that the passphrase itself must incorporate at least that much entropy.) Since the entropy per letter in a passphrase from a 26letter alphabet is in the range ~1.34.7 bits, depending on how randomized the selection is, 128 bits of entropy would require about ~2899 letters. But the passphrase alphabet can consist of the *52* letters azAZ, as I suggested before, which changes the 4.7 bits/letter to 5.7 bits/letter, in the truly randomized best case. That corresponds to roughly an 18% reduction in the number of letters needed, e.g. roughly ~2381 letters for 128 bits, if my arithmetic is OK. The bottom line is that someone wanting 128bits of entropy and using a 10letter IV (essential with stream cipher "passphrase" keys) may very well be stuck with ~90 letters to key in before enciphering a single letter of plaintext. (This is not an unrealistic rough estimate, I think, because most people can't remember very much random text, and a "Diceware" wordlist may not be handy ;) (As I recall, Bruce Schneier has recommended >=80 letters in passphrases for Solitaire, but that doesn't include an IV and doesn't capitalize on a 52letter passphrasealphabet.)  r.e.s. rs...@mindspring.com 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/23/00 12:00 AM 
"Paul Rubin" < p...@netcom.com> wrote ... : CLSV < clvi...@dds.nl> wrote: [...] : >The card swapping is indeed fast but the administration : >in my head always slows things down.
: : Don't try to do the arithmetic mod 52. Just do it mod 13, based : on (say) K=0, A=1, 2=2, ..., 10=10, J=11, Q=12 to locate the : output column of the output card. To get the row of the output : card, add the *suits* of the swapped cards, mod 4. I like the : visual mnemonic of Diamond=0, spade=1, heart=2, club=3. Very cute.
The above paragraph really says it all, but some visuals may be useful  until some fatal flaw is found in the ARC452 algorithm itself ;( (The following is for stream generation, but it should be clear how to use for key setup as well.) The "card table" looks like this: K A 2 ... J Q 0 1 2 ... 11 12  Diamonds 0 0 1 2 ... 11 12 Spades 1 13 14 15 ... 24 25 Hearts 2 26 27 28 ... 37 38 Clubs 3 39 40 41 ... 50 51 Take the "value" of a card as a *pair* of numbers (suit, facevalue), i.e. the (row,col) coordinates in the above table, and leave it at that while navigating the card layout. Don't waste time finding the values 051! Also, I'd like to repeat the associations in the mnemonic for suits, because that's what makes it work for me: Red suits are even, with Diamond=0 and Heart=2 because they're "roundish" and a diamond most resembles a 0. Black suits are odd, with Spade=1 and Club=3, because they have 1 and 3 leaves on a stem. So, when reading the card at the xmarker, just read it as (suit,facevalue), and see it as an instruction to move the ymarker ahead "suit" number of rows and then "facevalue" number of cards further in that row (continuing to the next row if needed. Of course the order is row0>row1>row2>row3>row0) The real savings come in the final steps: While swapping the two cards, separately add up their "rows" & "cols". "rows" is the mod 4 sum of their suits, and "cols" is the facevalue sum (if it exceeds 012, increase the row sum by 1, and take "cols" = facevalue  13). For the final step, put your finger at the (0,0) position in the cardlayout and move it the number of rows and columns indicated by the (rows,cols) just obtained. You'll then be pointing at the output card.  r.e.s. "Mistr Typo" < excuses, excuses rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/23/00 12:00 AM 
"Paul Rubin" <p...@netcom.com> wrote ...
[...] : R.e.s. said he was getting around 5 chars/minute, apparently without : much practice. Key setup wasn't discussed thoughthe procedure : is a bit different. Anyway, 30 secs/char may be way too conservative : an estimate. At 10 secs/char, the setup time starts approaching : tolerable. I don't know what's possible with practice. With a few hundred trials, I've found that I can't sustain 4+ chars/min without burning out rather quickly. If fresh, alert, & undistracted, 3.5+ chars/min is sustainable  but I can't say for how long. I think 3 chars/min would be sustainable even if moderately fatigued, and 2 chars/min if deadtired & drunk ;) (Those rates are for stream generation only, and they don't include the final encipherment/decipherment step of adding the stream to the plaintext/ciphertext. They should, however, be comparable to rates for key setup.) I can't imagine a secure cardcipher operating at your wishedfor rate of 10 secs/char even if I did once thoughtlessly claim ~4 secs/char ;)  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/23/00 12:00 AM 
"Rex Stewart" <T_Re...@yahoo.com> wrote ...
: It is a downside for any OFB stream cypher, but for cyphers that add : either the plaintext or the cyphertext to the state entropy, simply : starting the message with a few randomly chosen letters is sufficient. The need for an IV or message key seems to apply to any stream cipher, OFB or otherwise. It's actually part of what I had in mind, and has the "downside" of increasing the message length. http://www.io.com/~ritter/GLOSSARY.HTM#StreamCipher has a brief discussion: "In general, all stream cipher designs must use a message key to assure that the cipher is keyed with a random value for every new ciphering." An IV (message key) seems especially important if passphrases are used with any of the cardciphers mentioned in this thread, for just that reason. : In a cypher like Mirdek, the users could aggree on an arrangement for : both the right and left decks ahead of time, and simply encrypt each : new message with a few random characters. As long as they never begin : with the same series, and as long as the series was truely random this : would be a safe plan. And in fact, they would not have to send those : characters in the clear. Each message would simply decrypt with a few : letters of garbage at the beginning. An IV that accompanies the ciphertext must actually be used to produce a new *key* each time, so the procedure you describe would not be secure. Just putting some junk at the start of the plaintext won't do. Have I misread your meaning here?  r.e.s. rs...@mindspring.com :  : Rex Stewart : PGP Print 9526288F3D0C292D 783D3AB640C2416A
: : In article <86g63d$72l$ 1...@nntp9.atl.mindspring.net>, : "r.e.s." < rs...@mindspring.com> wrote: : > "Rex Stewart" < T_Re...@yahoo.com> wrote ... : > [...] : > : On output feedback cyphers based on ARC4 variants (like : > : Solitaire) insulating the state information (and therefore the key) : > : from the output seems fairly straightforward, and in fact Solitaire : > : seems to have two layers of such insulation. The downside of : > : course is the requirement to use a new key for each message. : > [...] : > : > But it's a "downside" required for any stream cipher, and hence : > applies to all of the card ciphers mentioned in this thread.
: [...]

MIRDEK: more fun with playing cards. 
Joseph Ashwood 
1/23/00 12:00 AM 
I stand corrected I had misremembered/misread the key setup portion of the algorithm. On another note, I still see absolutely no reason to restrict ourselves to a 52 card deck, when the majority of decks (at least that I've seen/bought) have also contained Jokers which are themselves delineated, making a 54 card deck, regardless of the other possibilities 54 potential numbers is IMHO superior to 52, given appropraite constraints. > "ARC452", to mirror ARC4, would use an alphabet of 52 > symbols (instead of 256) for both the statevector and > for keydata. Maybe you were thinking that a 256symbol > character set would still be used in ARC452? No I was not, I was considering the potential problems associated with actually utilizing a key of any potential value up to 52 (or 26, or 27, or 54), and attempting to generate a permutation of cards based on that. I think it can be dealt with, but I also see where if it is ignored it gives rise to a small bias in the beginning state, a problem that could turn out to be more severe than we currently believe. > > (The statevector will have length 52, and will always be > a permutation of the 52symbol alphabet.) > > If you're concerned about the alphabet being 52 symbols > instead of 26, this is no problem, because we could simply > have keys that use, say, both upper & lower case letters > to get 52 ordinary letters az,AZ with values 025,2651 > respectively. I am not at all worried about 52/26 symbols except because of the biases inherent in communication. I personally think it would be more useful to use the extra space to balance the potential inputs, for example q and z should probably be left out of the upper space in favor of space and period. > > : Second: > It looks to me like there is a misunderstanding about > the size of the character set, perhaps.
I understand the size of the character set, it is instead the balance of the math that I am concerned about, if we intend to make a strong cipher it is certainly not to our advantage to cripple it from the outset. Joe 
MIRDEK: more fun with playing cards. 
Joseph Ashwood 
1/23/00 12:00 AM 
> E.g. swapping two cards by hand is as easy > as swapping two packs of twenty cards.
Actually something like this is something I had failed to consider as a possibility, and something that may be useful if one were to use several decks (not overly difficult beyond the key setup phase). 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/23/00 12:00 AM 
"Paul Rubin" <p...@netcom.com> wrote ...
: r.e.s. < rs...@mindspring.com> wrote: : > K A 2 ... J Q : > 0 1 2 ... 11 12 : >  : >Diamonds 0 0 1 2 ... 11 12 : >Spades 1 13 14 15 ... 24 25 : >Hearts 2 26 27 28 ... 37 38 : >Clubs 3 39 40 41 ... 50 51 : > : >Take the "value" of a card as a *pair* of numbers (suit, facevalue), : >i.e. the (row,col) coordinates in the above table, and leave it at : >that while navigating the card layout. Don't waste time finding the : >values 051!
: : Actually it doesn't much matter what order the "card table" is : in, if you have a convenient way to do the arithmetic. So try : it like this: : : 0 40 28 16 4 44 32 20 8 48 36 24 : 13 1 41 29 17 5 45 33 21 9 49 37 : 26 14 2 42 30 18 6 46 34 22 10 50 : 39 27 15 3 43 31 19 7 47 35 23 11 : : instead of in 0,1,2... order. Notice that with this layout, : table[row, col] % 13 = col, and : table[row, col] % 4 = row. : : You don't have to write down the above array or pay any attention : to it at all; I just included it to help explain the principle here. The table I gave is intended to be a visual indicator of several things at once: the axes (absent in your table) are to remind what the suit and facevalueassociations are, while its interior is to indicate the directions in which one navigates through it. Pedestrian, I know, but some people really benefit from visuals like that. : >The real savings come in the final steps: : > : >While swapping the two cards, separately add up their "rows" & "cols". : >"rows" is the mod 4 sum of their suits, and "cols" is the facevalue : >sum (if it exceeds 012, increase the row sum by 1, and take : >"cols" = facevalue  13).
: : Now just take the facevalue and suit sums mod 13 and 4 respectively, : independently of each other. If the facevalue sum exceeds 13 just : subtract 13. You don't have to adjust the row sum. This saves you : a step. The Chinese Remainder Theorem in action ;). I don't think that's correct. Consider DiamondNine+SpadeNine: That's (0,9)+(1,9)=(1,18)=(2,5), not (1,5). Or the long way, (0*13+9)+(1*13+9)=31 =/= 1*13+5. Have I misunderstood your meaning? : >For the final step, put your finger at the (0,0) position in the : >cardlayout and move it the number of rows and columns indicated : >by the (rows,cols) just obtained. You'll then be pointing at the : >output card.
: : Is this the scheme you were getting 34 characters/minute with? : Or is it faster now? Yup, that's been my method. Despite my early report of ~5 chars/min, such a rate hasn't proved sustainable  too much prolonged effort is required  and 3.54 chars/min, while sustainable, would be demanding. 3+ chars/min is definitely sustainable for long periods. : One final speedup: use all 52 values codebook style: : 0=a, 1=b, ..., 26=z : 27 = "escape" (like in ascii) : 28 = unescape : escaped, 09 = digits 09 : 12327123452867 would be read abc12345fg I believe only one "escape toggle" is needed, and was thinking about something like azAZ, with UCletter=LCletter+26, and with X or Z reserved as the "alphanumeric toggle". E.g. "3384900749124451" would read "Hi007bye." : Now use other codes for frequently used phrases in your traffic. : So if you're organizing a chocolate heist, you might use : : 29 = "president", 30 = "terrorist", 31 = "duct tape", 32 = "helicopter", : plus escape codes: : escape15 = "roadblock" escape16 = "chocolate" etc. If you did that, you'd probably want yet another "numbermode" toggle, this one to distinguish between numbers meant as codes instead of numbers meant as numbers. (The first one was for numbers meant as numbers instead of numbers meant as ciphertext.) : This cuts down the number of characters you need to send. : It does mean your agents now have to memorize the codebook, or : carry a printed copy (use edible paper like in the movies, or : print on silk like in "Between Silk & Cyanide"). 
MIRDEK: more fun with playing cards. 
Paul Rubin 
1/24/00 12:00 AM 
In article <388B790D...@dds.nl>, CLSV <clvi...@dds.nl> wrote: >Hmm, if we use the ARC4 setup that means creating >52 output values that we throw away. Say 30 secs >per character that means 25 minutes shuffling cards >at top speed before encryption starts. R.e.s. said he was getting around 5 chars/minute, apparently without much practice. Key setup wasn't discussed thoughthe procedure is a bit different. Anyway, 30 secs/char may be way too conservative an estimate. At 10 secs/char, the setup time starts approaching tolerable. I don't know what's possible with practice.

MIRDEK: more fun with playing cards. 
Paul Rubin 
1/24/00 12:00 AM 
In article <86fbdm$pri$ 1...@nnrp1.deja.com>, Rex Stewart <T_Re...@yahoo.com> wrote: >I have been practicing Mirdek and have noticed several things. > >First is that, because I haven't done much with card deck cyphers >in a while I am rusty, and it appears to require about 15 hours >to get proficient. This is an important fact to convey to anyone >planning to use these cyphers in a "real world" situation.
That's about how long it takes to get any good at sending and receiving morse code with a telegraph, as many spies in the movies have had to learn how to do, so it doesn't seem completely out of line. 
MIRDEK: more fun with playing cards. 
Rex Stewart 
1/24/00 12:00 AM 
As a variation on the idea of changing the values of i and j for each message, and yet capitolizing on the idea of a permanent passphraze and an initialisation vector, keeping a spare deck in a particular order and then using a short passphraze (changed with each message) to key the deck for each message could make the setup tolerable  with the problem of having a partially keyed deck that could fall into hostile hands.  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com http://www.deja.com/ Before you buy. 
MIRDEK: more fun with playing cards. 
Rex Stewart 
1/24/00 12:00 AM 
It is a downside for any OFB stream cypher, but for cyphers that add either the plaintext or the cyphertext to the state entropy, simply starting the message with a few randomly chosen letters is sufficient. In a cypher like Mirdek, the users could aggree on an arrangement for both the right and left decks ahead of time, and simply encrypt each new message with a few random characters. As long as they never begin with the same series, and as long as the series was truely random this would be a safe plan. And in fact, they would not have to send those characters in the clear. Each message would simply decrypt with a few letters of garbage at the beginning.
 Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <86g63d$72l$1...@nntp9.atl.mindspring.net>, Sent via Deja.com http://www.deja.com/ Before you buy. 
MIRDEK: more fun with playing cards. 
Paul Rubin 
1/24/00 12:00 AM 
r.e.s. <rs...@mindspring.com> wrote: > K A 2 ... J Q > 0 1 2 ... 11 12 >  >Diamonds 0 0 1 2 ... 11 12 >Spades 1 13 14 15 ... 24 25 >Hearts 2 26 27 28 ... 37 38 >Clubs 3 39 40 41 ... 50 51 > >Take the "value" of a card as a *pair* of numbers (suit, facevalue), >i.e. the (row,col) coordinates in the above table, and leave it at >that while navigating the card layout. Don't waste time finding the >values 051! Actually it doesn't much matter what order the "card table" is
in, if you have a convenient way to do the arithmetic. So try it like this: 0 40 28 16 4 44 32 20 8 48 36 24 13 1 41 29 17 5 45 33 21 9 49 37 26 14 2 42 30 18 6 46 34 22 10 50 39 27 15 3 43 31 19 7 47 35 23 11 instead of in 0,1,2... order. Notice that with this layout, table[row, col] % 13 = col, and table[row, col] % 4 = row. You don't have to write down the above array or pay any attention to it at all; I just included it to help explain the principle here. >The real savings come in the final steps: > >While swapping the two cards, separately add up their "rows" & "cols". >"rows" is the mod 4 sum of their suits, and "cols" is the facevalue >sum (if it exceeds 012, increase the row sum by 1, and take >"cols" = facevalue  13).
Now just take the facevalue and suit sums mod 13 and 4 respectively, independently of each other. If the facevalue sum exceeds 13 just subtract 13. You don't have to adjust the row sum. This saves you a step. The Chinese Remainder Theorem in action ;).
>For the final step, put your finger at the (0,0) position in the >cardlayout and move it the number of rows and columns indicated >by the (rows,cols) just obtained. You'll then be pointing at the >output card.
Is this the scheme you were getting 34 characters/minute with? Or is it faster now?
One final speedup: use all 52 values codebook style: 0=a, 1=b, ..., 26=z 27 = "escape" (like in ascii) 28 = unescape escaped, 09 = digits 09 12327123452867 would be read abc12345fg
Now use other codes for frequently used phrases in your traffic. So if you're organizing a chocolate heist, you might use
29 = "president", 30 = "terrorist", 31 = "duct tape", 32 = "helicopter", plus escape codes: escape15 = "roadblock" escape16 = "chocolate" etc. This cuts down the number of characters you need to send. It does mean your agents now have to memorize the codebook, or carry a printed copy (use edible paper like in the movies, or print on silk like in "Between Silk & Cyanide").

MIRDEK: more fun with playing cards. 
Paul Rubin 
1/24/00 12:00 AM 
In article <86grr6$n3n$ 1...@nntp6.atl.mindspring.net>, >in, if you have a convenient way to do the arithmetic. So try >it like this: > > 0 40 28 16 4 44 32 20 8 48 36 24 > 13 1 41 29 17 5 45 33 21 9 49 37 > 26 14 2 42 30 18 6 46 34 22 10 50 > 39 27 15 3 43 31 19 7 47 35 23 11
To stop you from asking, I dropped a column by accident. It should have said 0 40 28 16 4 44 32 20 8 48 36 24 12 13 1 41 29 17 5 45 33 21 9 49 37 25 26 14 2 42 30 18 6 46 34 22 10 50 38 39 27 15 3 43 31 19 7 47 35 23 11 51 Paul who has typos of his own. 
MIRDEK: more fun with playing cards. 
Paul Rubin 
1/24/00 12:00 AM 
r.e.s. <rs...@mindspring.com> wrote: >: Actually it doesn't much matter what order the "card table" is >: in, if you have a convenient way to do the arithmetic. So try >: it like this: >: >: 0 40 28 16 4 44 32 20 8 48 36 24 >: 13 1 41 29 17 5 45 33 21 9 49 37 >: 26 14 2 42 30 18 6 46 34 22 10 50 >: 39 27 15 3 43 31 19 7 47 35 23 11 >:
>: Now just take the facevalue and suit sums mod 13 and 4 respectively, >: independently of each other. If the facevalue sum exceeds 13 just >: subtract 13. You don't have to adjust the row sum. This saves you >: a step. The Chinese Remainder Theorem in action ;). > >I don't think that's correct. Consider DiamondNine+SpadeNine: >That's (0,9)+(1,9)=(1,18)=(2,5), not (1,5). >Or the long way, (0*13+9)+(1*13+9)=31 =/= 1*13+5. >Have I misunderstood your meaning? (0,9) + (1,9) = (1, 5) is correct. The long way: (0, 9) = 48 (found at location 0,9 in the grid) (1,9) = 9 (found at location 1,9) 48 + 9 (mod 52) = 5 which as expected is found at location 1,5 in the grid. You can think of this as permuting the input letters so you no longer have A=1, B=2, etc. but since you're using OFB mode, you don't have to pay attention to this permutation. >: Is this the scheme you were getting 34 characters/minute with? >: Or is it faster now? > >Yup, that's been my method. Despite my early report of ~5 chars/min, >such a rate hasn't proved sustainable  too much prolonged effort >is required  and 3.54 chars/min, while sustainable, would be >demanding. 3+ chars/min is definitely sustainable for long periods. Hmmm, I'd hoped you could get it going faster. With some practice, you can probably pound it out like a Las Vegas blackjack dealer :). I'll try to get a deck of cards and see how it goes. 
MIRDEK: more fun with playing cards. 
Rex Stewart 
1/24/00 12:00 AM 
I think you may misunderstand the operation of MirDek. I am guessing  I don't know how much time you spent looking at its spec, which changed somewhat in the middle of this month. I had to actually work through a few dozen cycles to get everything straight in my head. Yes I know Mr. Ritter's definitions, and "in general" (his own words) they are correct. An OFB stream cypher produces a keystream completely independent of the plaintext being encyphered, and most CFB stream cyphers have a specific quantity of cyphertext used in their transformation function. If a single bit is changed in the plaintext of a OFB stream cypher, a single bit is changed in the cypher text (or a small amount, depending on the design of the mixing function). In most CFB steam cyphers a single bit change will change a specific amount of cypher text in general equal to the amount of cyphertext used in their transformation function. MirDek is somewhat different. Its internal state depends on not only the key and IV, but on ALL previous encyphered text. Hence a one bit change in the input stream will change all future outputs. This means it can be used to encypher different texts with the same key  as long as the opponent cannot mount a known plaintext attack from the first encyphered bytes. The downside to this cypher design is usually a vulnerability to a chosen plaintext attack. In this case, I could see how an adaptive chosen plaintext attack could be mounted against it *in theory*  forcing the output to reveal the count cuts driven by the right deck, which would in turn would become the left deck and continuing the process until that deck is compromised as well. This would require tricking the user into encrypting repeatedly with the same key and IV and as such I don't see how it could be mounted in real life. I believe the original version of Sapphire by Michael P Johnson fell victim to such an attack, and indeed this cypher is a distant cousin of Sapphire. As to your previous comments, BTW, I concede. Calling Solitaire an "ARC4 variant" was incorrect. Another note, I intend to try ARC4m again, because I think it would be advantageous to have both card deck ciphers and Cipher Sabre working from a common root design.  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A In article <86grsv$asl$1...@nntp9.atl.mindspring.net>, Sent via Deja.com http://www.deja.com/ Before you buy. 
MIRDEK: more fun with playing cards. 
Paul Crowley 
1/24/00 12:00 AM 
"r.e.s." <rs...@mindspring.com> writes: > "Rex Stewart" <T_Re...@yahoo.com> wrote ... > [...] > : On output feedback cyphers based on ARC4 variants (like > : Solitaire) insulating the state information (and therefore the key) > : from the output seems fairly straightforward, and in fact Solitaire > : seems to have two layers of such insulation. The downside of > : course is the requirement to use a new key for each message. > [...] > > But it's a "downside" required for any stream cipher, and hence > applies to all of the card ciphers mentioned in this thread. It's not a downside that necessarily applies to randomised stream ciphers where the randomiser is sent along with the message; this is true of Mirdek, and we've heard some ideas about how that could be done for ARC452 and ARC4Rubin (the CRTbased variant). > IMO, I don't think it's accurate to describe Solitaire as an > "ARC4 variant", although it may have been influenced by ARC4. Well, perhaps "ARC4 inspired" would be fairer. > (As I posted before, I'm actually interested in the whole class > of what we might call ARC4M variants  where M is the length > of the state vector  whether implemented by cards or computer. > The lack of response to those earlier postings suggests that > this may be an unexplored area.) I know of two academic papers covering RC4  Bob Jenkins's and Jovan Golic's  and both discuss such variants where M is a power of two.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/24/00 12:00 AM 
"r.e.s." <rs...@mindspring.com> writes: > An IV that accompanies the ciphertext must actually be used to produce > a new *key* each time, so the procedure you describe would not be secure. > Just putting some junk at the start of the plaintext won't do. Have I > misread your meaning here? I think he's talking about Mirdek, which uses plaintext feedback so the state depends on what the plaintext was. Incidentally this is entirely for speed and convenience reasons  I'd prefer to design a pure OFB cipher which is easier to analyse  but it does have its advantages.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/24/00 12:00 AM 
Ouch! Halfway through responding this, I found a fatal flaw in Mirdek's resistance to a chosen plaintext attack. Back to the drawing board... Rex Stewart <T_Re...@yahoo.com> writes: > First is that, because I haven't done much with card deck cyphers > in a while I am rusty, and it appears to require about 15 hours > to get proficient. This is an important fact to convey to anyone > planning to use these cyphers in a "real world" situation. The > first several hours of this will be spent getting their mind used to > seeing the letters of the alphabet on the red and black cards and > learning the rules of the encryption system. You can't just agree > on a system and run off to a hostile area and expect to do this > cold turkey. Also, this means if they have trouble at first they > should not give up too easily. My flatmates have learned it, so it doesn't seem to require too much obsessiveness, but getting good enough to encrypt a message accurately seems to be difficult. I have seriously contemplated the possibility of programs that try and guess various mistakes you might have made in an effort to generate readable plaintext from ciphertext badly generated. > I was first bothered by the open transmission of the IV in > the message, but on closer observation, swapping the > decks between keying and mixing seems to effectively > hide this information by reordering the IV based on the > key. This cypher adds entropy to the state information in > much the same way as Terry Ritter's Dynamic Substitution, > and that could be a problem, although the simultaneous > adding of entropy from the right hand deck should provide > enough confusion (it adds 3.5 bits entropy each round, the > plain text adds 1.3 bits) to preclude recovery of significant > state information in the case of a known plaintext attack I'm not sure what your entropy calculations mean. The point about the count cut is that if you know nothing about the right pile, then you know nothing about what count cut is coming up and so even if you know the next plaintext character every ciphertext character is equally probable. If you knew the state of the left pile and the plaintext, you'd be able to infer each right hand character as it came up, and so you'd have more information about each subsequent character until the last one was determined with certainty as the one that hadn't come up yet. > (I am not so sure about a chosen plaintext attack). I strongly suspect that a chosen plaintext attack would choose the plaintext "AAAAA...." since that makes least use of the state of the left deck. Oh bugger. If you guess where this letter appears in the left pile, then you can infer the state of the right deck within 25 characters, and thus get the state of both decks in 50. If you're using Mirdek  don't encrypt the sequence "A" x 50 :) Redesign time, I think. > The 26 mixing steps themselves seemed at first to be > aimed at insulating the key from the state information, > but because the IV is sent in the clear this is not the case > and in fact Paul Crowley, the author, clearly warns it is not > the case. These steps appear aimed at using the key > information to hide the IV. These steps are meant to ensure that both decks depend strongly on the key, if that's what you mean.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Rex Stewart 
1/24/00 12:00 AM 
Reply to Paul Crowley: As for your flatmates, how long did it take them to learn it? When I said 15 hour, I meant to become reliable enough to get through a short message with only a mistake or two. The computer program able to guess at mistakes would be a great idea, as one end of the channel would almost always have access to a computer. Of course it would take a fair amount of effort to code up ALL of the possible places a mistake could have been made  and a fair amount of processing power to recover if there were two or three mistakes in short order. >> adding of entropy from the right hand deck should provide >> enough confusion (it adds 3.5 bits entropy each round, the >> plain text adds 1.3 bits) to preclude recovery of significant >> state information in the case of a known plaintext attack What this means is each time a count cut is performed, it could have one of 26 possible outcomes. This is entropy (it should have read 4.6 bits though since 25 is 2 raised to the 4.6 power). Each time a normal plaintext character is encoded, it could have one of several outcomes. Text is much more predictable than the random IV however, and I have been told on average it amounts to one out of two or three possibilities. > even if you know the next plaintext character > every ciphertext character is equally probable.
This is what I meant by resistant to known plaintext attack. > If you knew the state of the left pile and the plaintext, > you'd be able to infer each right hand character as it > came up, and so you'd have more information about > each subsequent character until the last one was > determined with certainty as the one that hadn't > come up yet. The key here is you have to know BOTH the state of the left pile and the plaintext. >> (I am not so sure about a chosen plaintext attack).
> I strongly suspect that a chosen plaintext attack would choose the > plaintext "AAAAA...." since that makes least use of the state of the > left deck.
> Oh bugger. If you guess where this letter appears in the left pile, > then you can infer the state of the right deck within 25 characters, > and thus get the state of both decks in 50. If you're using Mirdek  > don't encrypt the sequence "A" x 50 :) I don't think this is the case  as you say IF you guess where this letter appears in the left pile. And do it 25 straight times. > Redesign time, I think. I don't think so. Prove the flaw exists first  it may not. As I said in another post, the only way I can see to crack this is to recover the state of the RIGHT deck by encrypting 25 separate texts differing by only a single letter always occuring in the same position  and then 25 more with the positions incremented. And encrypting those 25 separate texts with the same key and the same IV. And then repeating the ENTIRE process again at a different point in the text to recover the other deck after the switch. I can see no way to recover the left deck directly. While you would develope a substitution table for the left deck I do not think that is the same. You would only be able to tell something about the rotations induced on the left deck by the right deck. >> The 26 mixing steps themselves seemed at first to be >> aimed at insulating the key from the state information, >> but because the IV is sent in the clear this is not the case >> and in fact Paul Crowley, the author, clearly warns it is not >> the case. These steps appear aimed at using the key >> information to hide the IV. > These steps are meant to ensure that both decks depend > strongly on the key, if that's what you mean.
Well it is more complicated than that. During the keying operation the first deck becomes dependent on both the key and the IV. But the second deck is left unchanged. Then you switch decks and mix the IV 26 times with the first deck. Awsome. The IV is permutated 26 times by the first deck. If the IV were also secret, you could not work backwards through this, but that is not the point  you did exactly what you set out to do (although I still think 26 times is overkill). I think I have reached the point where I am beginning to ramble.  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com http://www.deja.com/ Before you buy. 
MIRDEK: more fun with playing cards. 
Paul Rubin 
1/24/00 12:00 AM 
In article < 87k8kz9...@hedonism.demon.co.uk>, Paul Crowley <pa...@hedonism.demon.co.uk> wrote: >It's not a downside that necessarily applies to randomised stream >ciphers where the randomiser is sent along with the message; this is >true of Mirdek, and we've heard some ideas about how that could be >done for ARC452 and ARC4Rubin (the CRTbased variant).
Um, I don't think there's such a thing as "ARC4Rubin". The CRT thing is just a different way of physically/mentally manipulating the cards that's supposed to be a little easier. The cipher itself is supposed to be exactly the same, for cryptanalysis purposes. You could think of it as being like changing the initial and final permutations in DES. They don't have any effect at all on the strength of the cipher. 
MIRDEK: more fun with playing cards. 
r.e.s. 
1/24/00 12:00 AM 
"Paul Rubin" <p...@netcom.com> wrote ...
: r.e.s. <rs...@mindspring.com> wrote: : >: Actually it doesn't much matter what order the "card table" is : >: in, if you have a convenient way to do the arithmetic. So try : >: it like this: : >: : >: 0 40 28 16 4 44 32 20 8 48 36 24 : >: 13 1 41 29 17 5 45 33 21 9 49 37 : >: 26 14 2 42 30 18 6 46 34 22 10 50 : >: 39 27 15 3 43 31 19 7 47 35 23 11 : >: : >: Now just take the facevalue and suit sums mod 13 and 4 respectively, : >: independently of each other. If the facevalue sum exceeds 13 just : >: subtract 13. You don't have to adjust the row sum. This saves you : >: a step. The Chinese Remainder Theorem in action ;). : > : >I don't think that's correct. Consider DiamondNine+SpadeNine: : >That's (0,9)+(1,9)=(1,18)=(2,5), not (1,5). : >Or the long way, (0*13+9)+(1*13+9)=31 =/= 1*13+5. : >Have I misunderstood your meaning? : : (0,9) + (1,9) = (1, 5) is correct. : The long way: (0, 9) = 48 (found at location 0,9 in the grid) Ah, there is some notational confusion, but I see what you mean. (viz., (1,5) as a value 1*13+5=18, and not as a pointer to the value at location (1,5). My notation uses the latter meaning.) So if I understand correctly, adding the (row,col) cordinates separately for the swapped cards, and doing this (mod 4, mod 13), gives a result (r,c) that directly gives the output value as 13*r+c. (Excuse me for trying to put your suggestion in my own words.)  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/24/00 12:00 AM 
"Rex Stewart" <T_Re...@yahoo.com> wrote ...
: I think you may misunderstand the operation of MirDek. I am guessing  : I don't know how much time you spent looking at its spec, which changed : somewhat in the middle of this month.
[...] I'm sure that's it, because I actually cranked through MIRDEK quite a few times as it was descibed originally. He did give fair warning, as I recall, that it was a work in progress. I'll take a fresh look soon. : Another note, I intend to try ARC4m again, because I think it would be : advantageous to have both card deck ciphers and Cipher Sabre working : from a common root design.
Note that Paul Rubin recently posted yet another timesaver for ARC452, this one about how best to add the swapped cards to get the output value.  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/24/00 12:00 AM 
"Paul Rubin" <p...@netcom.com> wrote ...
: In article < 87k8kz9...@hedonism.demon.co.uk>, My intentions were similar with what people are calling ARC452. (But it's worth repeating that the XOR combiner is replaced with mod 52 addition.) These names like AR4whatever get very confusing, esp. because there's good reason, I think, to take ARC4's stream generator and see if it can be better used with alternative modes of keying. Then it's what, ARC452SK1, etc? ;)  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/24/00 12:00 AM 
"Paul Crowley" < pa...@hedonism.demon.co.uk> wrote ... : "r.e.s." < rs...@mindspring.com> writes: [...] : It's not a downside that necessarily applies to randomised stream : ciphers where the randomiser is sent along with the message; this is : true of Mirdek, and we've heard some ideas about how that could be : done for ARC452 and ARC4Rubin (the CRTbased variant).
It seems I've not visited your site recently enough to know of the changes it's undergone. Noticing your postings today, I see it's still a "work in progress", as you did warn. [...] : : I know of two academic papers covering RC4  Bob Jenkins's and Jovan : Golic's  and both discuss such variants where M is a power of two.
Thanks, I'll try to find them.  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
r.e.s. 
1/24/00 12:00 AM 
"Paul Rubin" <p...@netcom.com> wrote ...
[...] : ARC452 describes the cryptographic algorithm and is a good designation : (distintinguishes it from the traditional ARC4256). The xor combiner : should be irrelevant to the cryptography. It's not part of the cipher. Hmm... that's news to me. All the descriptions I've seen of ARC4, including its original posting to this NG, show the XOR combiner as part of ARC4. (I too would prefer to consider the combiner as separate from "ARC4", but I would wager that if you produced "ARC4" ciphertext using a mod 256 additive combiner, most people would say that you didn't use ARC4; i.e, any substantive change, and it's a different algorithm.) For that reason I would like to have a good designation for just the stream generator portion of ARC4, which for which I want to consider various statevector lengths. Both key setup and combiner then become separate modules.  r.e.s. "Mistr Typo" rs...@mindspring.com

MIRDEK: more fun with playing cards. 
Rex Stewart 
1/25/00 12:00 AM 
In the last few hours I realised I posted an obvious error in the paragraph below. Yes knowing the substitution table AT A SINGLE POINT in time IS THE SAME as knowing the right hand deck. I was still thinking in the mode of trying to hit a moving target. Knowing 26 points on the table, each one related to a different point in time is pretty much worthless, but I made the cardinal mistake of posting something I had not completely thought through  and in the middle of it I made a leap from logical to ludicrous. My appology if this sent anyone up a blind alley. I should have realised when I wrote that last line, it was too late in my day to post :) In article <86i1oc$mrj$1...@nnrp1.deja.com>, Rex Stewart <T_Re...@yahoo.com> wrote: > Reply to Paul Crowley: > > Redesign time, I think. > I don't think so. Prove the flaw exists first  it may not. > As I said in another post, the only way I can see to crack this is to > recover the state of the RIGHT deck by encrypting 25 separate texts > differing by only a single letter always occuring in the same position >  and then 25 more with the positions incremented. And encrypting > those 25 separate texts with the same key and the same IV. And then > repeating the ENTIRE process again at a different point in the text to > recover the other deck after the switch. I can see no way to recover > the left deck directly. While you would develope a substitution table > for the left deck I do not think that is the same. You would only be > able to tell something about the rotations induced on the left deck by > the right deck. > >
> I think I have reached the point where I am beginning to ramble. >  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A Sent via Deja.com http://www.deja.com/ Before you buy.

MIRDEK: more fun with playing cards. 
Paul Rubin 
1/25/00 12:00 AM 
r.e.s. <rs...@mindspring.com> wrote: >"Paul Rubin" <p...@netcom.com> wrote ...
>: Um, I don't think there's such a thing as "ARC4Rubin". The CRT thing >: is just a different way of physically/mentally manipulating the cards >: that's supposed to be a little easier. The cipher itself is supposed >: to be exactly the same, for cryptanalysis purposes. You could think >: of it as being like changing the initial and final permutations in >: DES. They don't have any effect at all on the strength of the cipher. > >My intentions were similar with what people are calling ARC452. >(But it's worth repeating that the XOR combiner is replaced with >mod 52 addition.) ARC452 describes the cryptographic algorithm and is a good designation (distintinguishes it from the traditional ARC4256). The xor combiner should be irrelevant to the cryptography. It's not part of the cipher.
>These names like AR4whatever get very confusing, esp. because >there's good reason, I think, to take ARC4's stream generator >and see if it can be better used with alternative modes of keying. >Then it's what, ARC452SK1, etc? ;)
That doesn't sound unreasonable. We already often run SSL/TLS with ciphersuites like EDHSHADES3CBCPKCS5. ARC452xx isn't so bad. 
MIRDEK: more fun with playing cards. 
Paul Crowley 
1/25/00 12:00 AM 
Rex Stewart <T_Re...@yahoo.com> writes: > > I strongly suspect that a chosen plaintext attack would choose the > > plaintext "AAAAA...." since that makes least use of the state of the > > left deck. > > > Oh bugger. If you guess where this letter appears in the left pile, > > then you can infer the state of the right deck within 25 characters, > > and thus get the state of both decks in 50. If you're using Mirdek  > > don't encrypt the sequence "A" x 50 :) > > I don't think this is the case  as you say IF you guess where this > letter appears in the left pile. And do it 25 straight times. It's even worse than I'm imagining. If you know the plaintext is a stream of 'A's, then each ciphertext letter tells you where the A card was immediately before the letter search. After the letter search, of course, the A will be as far from the bottom as it was from the top. So you know where the A is before and after the count cut, from which inferring the discarded card is trivial. After 51 ciphertext letters you have the state of the entire deck. No need to guess anything. What I'd like to do to fix this is to replace the count cut with a different kind of letter search, but I can't think of a search with the right properties: * dependent on the position of the searchedfor letter, not the letter searched for * reversible, given the searchedfor letter * for each card in the old state of the left deck, every new position is equiprobable * ideally it would do some mixing too Actually, I can think of one but it's unwieldy: just cut cards from the top to the bottom until the searchedfor card is as far from the bottom as it was from the top (ie one card if it's on the top, three if it's second, 5 if third etc). Better suggestions would be very welcome!  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Paul Crowley 
1/25/00 12:00 AM 
p...@netcom.com (Paul Rubin) writes: > In article <87k8kz9...@hedonism.demon.co.uk>, > Paul Crowley <pa...@hedonism.demon.co.uk> wrote: > >It's not a downside that necessarily applies to randomised stream > >ciphers where the randomiser is sent along with the message; this is > >true of Mirdek, and we've heard some ideas about how that could be > >done for ARC452 and ARC4Rubin (the CRTbased variant). > > Um, I don't think there's such a thing as "ARC4Rubin". The CRT thing > is just a different way of physically/mentally manipulating the cards > that's supposed to be a little easier. This is so only if you use the correct conversion from card to number in the final output step, which could be tricky to do in your head unless I'm missing a trick.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\

MIRDEK: more fun with playing cards. 
Johnny Bravo 
1/25/00 12:00 AM 
On 21 Jan 2000 08:28:16 0000, Paul Crowley < pa...@hedonism.demon.co.uk> wrote: >When you say "one time", you mean "once per message". If you're in a >position to communicate big strings of random nonsense once per >message, you can use the most successful secure hand cipher in the >world, the one time pad. One reason for a card cipher is that you might not be shot for carrying a deck of cards. You would have a hard time explaining to the secret police why you are carrying around a one time pad. :) >Mirdek. Unless you use some sort of input transformation which >converts the input to a string of characters drawn from AZ... Nothing wrong with using just letters. It would be simple to set up codes in advance to represent changes in the set if they are needed. Like ZZ switches to numbers (when a bunch of numbers are needed), a=1, b=2 ect, X = decimal. ZZ switches back to letters. Otherwise just spell everything out. Keep it simple as possible and it will remain flexible as well. Best Wishes, Johnny Bravo 
MIRDEK: more fun with playing cards. 
Johnny Bravo 
1/25/00 12:00 AM 
On 22 Jan 2000 10:15:44 0000, Paul Crowley < pa...@hedonism.demon.co.uk> wrote: >80 bit passphrases are kind of hard to come by. It wouldn't be hard to arrange to get the words for the passphrase from a shared source, like a national newspaper. While your opponents will also have the paper, it is like the diceware list. Having all the words isn't much of a help in picking which words to use. Best Wishes, Johnny Bravo

MIRDEK: more fun with playing cards. 
Rex Stewart 
1/25/00 12:00 AM 
I think I see your point. I didn't see it yesterday, but a string of the same letter would be a problem  assuming the adversary knows you are encrypting a repeating letter. While this in itself would not be a disaster (any agent who falls to this is not much of an agent), it may be an indicater of another  more useful attack :(  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A In article <87ln5et...@hedonism.demon.co.uk>, Sent via Deja.com http://www.deja.com/ Before you buy. 
MIRDEK: more fun with playing cards. 
Rex Stewart 
1/26/00 12:00 AM 
I have an idea that seems to meet 3 of the four properties. I can't tell if it meets the reversibility property (it takes me a while to work through that concept). The problem with the previouse search function is it provieded concrete information about the state AFTER the substitution. If, instead of counting letters, you simply used the previous card the information would not be revealed. In other words, you want to encrypt "C" you search for "C" "JOIELC" finding it, you substitute "L" this is simply the card on the other pile. Decription uses the next card. Search until you find "L" and one more card makes "C" After the decks are put back together, the only thing certain is L is lower in the deck than C  and this is only true until after the count cut. I haven't tried it yet to see if the information it DOES reveal  the proximity of the two letters PRIOR to the search  is of any value to an adversary. In going over the possibilities in my head, I haven't yet found any way to use this information.  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A In article <87ln5et...@hedonism.demon.co.uk>, Paul Crowley <pa...@hedonism.demon.co.uk> wrote: a search with > the right properties: > > * dependent on the position of the searchedfor letter, not the letter > searched for > > * reversible, given the searchedfor letter > > * for each card in the old state of the left deck, every new position > is equiprobable > > * ideally it would do some mixing too > > Actually, I can think of one but it's unwieldy: just cut cards from > the top to the bottom until the searchedfor card is as far from the > bottom as it was from the top (ie one card if it's on the top, three > if it's second, 5 if third etc). Better suggestions would be very > welcome! >  > __ > \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / > /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\ > Sent via Deja.com http://www.deja.com/ Before you buy. 
MIRDEK: more fun with playing cards. 
Rex Stewart 
1/26/00 12:00 AM 
While reviewing this post, I noticed something all too obvious. If the card searched for is the fist one dealt, there is no previous card. While this is not a show stopper, it could lead one to believe there are several possible solutions  however, most of them will lead to problems or bias. I propose, when the first card up is the searched for card, deal all remaining cards and use the last one out (which will be in the opposite pile, since there are an even number of cards). The reason I mention the card will be in the opposite pile is because upon decryption you need to deal cards until you find the searched for card (the cypher text letter) and use the next one. If it is the last card you note which pile it is dealt into, pick up the opposite pile and look at the bottom card (which is obviously the first card you dealt). Doing it this way will insure only one interpretation, will insure mixing if the card is the first one out, and is only a slight slowdown. Let me know what you think.  Rex Stewart PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <86lujh$j3p$1...@nnrp1.deja.com>, 
MIRDEK: more fun with playing cards. 
Paul Crowley 
1/26/00 12:00 AM 
Johnny Bravo <bravo...@usa.net> writes: > It wouldn't be hard to arrange to get the words for the passphrase from > a shared source, like a national newspaper. While your opponents will > also have the paper, it is like the diceware list. Having all the words > isn't much of a help in picking which words to use. No, the entropy is much smaller.  __ \/ o\ pa...@hedonism.demon.co.uk Got a Linux strategy? \ / /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
