Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MIRDEK: more fun with playing cards.

100 views
Skip to first unread message

Paul Crowley

unread,
Jan 15, 2000, 3:00:00 AM1/15/00
to
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
card-dealing 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/ /~\

CLSV

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
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

r.e.s.

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
"CLSV" <clvi...@dds.nl> wrote ...

Thanks for repeating my questions. I posted those ideas 3 days ago
-- "Changing ARC4's State-Space Size") -- and have seen no reply.
In that posting I also explain how to translate ARC4 source code into
card-manipulations. (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


T_Re...@yahoo.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
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 State-Space Size") -- and have seen no reply.
> In that posting I also explain how to translate ARC4 source code into
> card-manipulations. (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.

CLSV

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
"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 State-Space Size") -- and have seen no reply.
> In that posting I also explain how to translate ARC4 source code into
> card-manipulations. (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

Paul Crowley

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
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...

Paul Crowley

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
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.

CLSV

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
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

T_Re...@yahoo.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
OOPS! You are correct!
That should have been per HOUR.
I am no speed demon.
Rex Stewart

In article <874scaa...@hedonism.demon.co.uk>,

Joseph Ashwood

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
[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 e-mail 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

r.e.s.

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
[ repost of my 1/15/00 "Changing ARC4's State-Space 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 pencil-and-paper 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 state-space 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 (byte-values), managed with mod 256 arithmetic.
But the same logic of ARC4's stream generator can also be applied
to manage an M-symbol state vector with mod M arithmetic, for
"arbitrary" M. The output stream then consists of symbols from
an M-symbol 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 keying-phase, extended to
mod M, but might instead be some form of "true randomization" (e.g.
shuffling the deck in a card-deck 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 54-card
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 letter-card (as opposed
to a pointer/joker) defines position 0, and the bottom letter-card
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 x-joker down by jumping it over the letter-card next below it".
Similarly, "S(x)" is the value of the letter-card next below the
x-joker, so "y=y+S(x)" means "move the y-joker down by jumping it
over that number of letter-cards". (Treat the top card as the next
one "below" the bottom, etc.)

For an easy-to-transcribe 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 card-deck 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 hands-on experience disagrees with that last claim.

--
r.e.s.
rs...@mindspring.com

r.e.s.

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
"CLSV" <clvi...@dds.nl> wrote ...
: "r.e.s." wrote:
:
: > [ repost of my 1/15/00 "Changing ARC4's State-Space 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 (A-10 in four suits) plus
2 jokers. "Digitize" the plaintext, converting from letters to decimals,
say with a straddling-checkerboard), 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 hands-on experience with MIRDEK is that it's by far the easiest &
fastest card-cipher 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


CLSV

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
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 52-card 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 user-friendly
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
20-30 seconds you want to minimize the number of characters in
a message.


Regards,

CLSV

CLSV

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
"r.e.s." wrote:

> [ repost of my 1/15/00 "Changing ARC4's State-Space 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

Paul Crowley

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
"r.e.s." <rs...@mindspring.com> writes:
> Yes, 52! <<< 256!, but 52! is also the size of the state-space 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 RC4-54 when I get time.

> A side question is what is the state space size for Solitaire. It seems
> to me that, just as my card-deck 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.

Paul Crowley

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
CLSV <clvi...@dds.nl> writes:
> Well you could skip the key setup phase completely at the
> expense of communicating the initial 52-card 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 one-time-pads?

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 telegram-like
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.

r.e.s.

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
"Paul Crowley" <pa...@hedonism.demon.co.uk> wrote ...
[...]
: I'll try and measure the bias in RC4-54 when I get time.

That would be interesting, I think. (But imo it would be more appropriate
to call this something like ARC4-52, since it is an implementation of ARC4
-- or at least the stream generator of ARC4 -- with altered state-vector
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 card-deck 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 state-vector of length M
has M! states, and the card version is *constructed* to use the jokers in
1-1 correspondence with the pointers in ARC4's algorithm. Only the sequence
of the 52 non-jokers constitute the state-vector.)

: > (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 state-vector, 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 ARC4-52).

--
r.e.s.
rs...@mindspring.com

John Myre

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
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 telegram-like
> 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.

CLSV

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
Paul Crowley wrote:
>
> CLSV <clvi...@dds.nl> writes:
> > Well you could skip the key setup phase completely at the
> > expense of communicating the initial 52-card 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 one-time-pads?

A 52-card key is the equivalent of a 225 bit key
I don't see the connection with a one-time 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 52-card key one time I don't believe you have any
chance to communicate securely.
In the context of civil rights you'll need a semi-secret
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 telegram-like
> 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

r.e.s.

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
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 co-prime, 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 "52-card 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

r.e.s.

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
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 y-pointer ahead by
jumping over a number of cards equal to the value of the card
pointed to by the x-pointer", just as "x=x+1" means "move the
x-pointer 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 visually-oriented, 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 ARC4-52 compared with Solitaire.
:
: Well, I did get around to an initial attempt at ARC4-52 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.
...

T_Re...@yahoo.com

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
Trial Results of ARC4-52 compared with Solitaire.

Well, I did get around to an initial attempt at ARC4-52 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

Paul Rubin

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
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 co-prime, 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?

Paul Crowley

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
CLSV <clvi...@dds.nl> writes:
> So it does pay to use a strong password. If you are not able to
> communicate a 52-card 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 randomly-chosen 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 semi-secret
> 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 A-Z,
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 A-Z...

Paul Crowley

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
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 co-prime, 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 ARC-13-4.

> 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.

Paul Crowley

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
"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 ARC4-52, thus 52! * 52 * 52.

r.e.s.

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
It's simple to use a 4x13 card layout to implement the *exact* ARC4
logic with state-vector length 52 (and modular addition combiner.)
The only card-movement 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 14-15 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 "52-card 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 ARC-13-4.

[...]


r.e.s.

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
"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 ARC4-52, 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 52-element state-vector.

--
r.e.s.
rs...@mindspring.com

CLSV

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
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 52-card 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 randomly-chosen 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

CLSV

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
"r.e.s." wrote:

> It's simple to use a 4x13 card layout to implement the *exact* ARC4
> logic with state-vector length 52 (and modular addition combiner.)
> The only card-movement 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 14-15 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
14-15 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

r.e.s.

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
"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 state-vector length 52 (and modular addition combiner.)
: > The only card-movement 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 14-15 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 hands-on experience.

: I think it can be fast given enough practice but


: 14-15 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 "52-card ARC4"
with 4x13 card-layout, placing the coins adjacent to the cards
they point to:

1) start with the x-coin and y-coin at the upper-left card
2) move the x-coin to the next card
3) read the card at the x-coin and move the y-coin that
many cards ahead
4) swap the cards at the x- and y-coins
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

r.e.s.

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
"r.e.s." <rs...@mindspring.com> wrote ...
: "CLSV" <clvi...@dds.nl> wrote ...
: : "r.e.s." wrote:
[...]
: : > I can easily run off 14-15 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 hands-on 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


r.e.s.

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
[typo correction]

"r.e.s." <rs...@mindspring.com> wrote ...
[...]
: Here's the routine for the stream generator of "52-card ARC4"


: with 4x13 card-layout, placing the coins adjacent to the cards
: they point to:
: 1) start with the x-coin and y-coin at the upper-left card
: 2) move the x-coin to the next card
: 3) read the card at the x-coin and move the y-coin that
: many cards ahead
: 4) swap the cards at the x- and y-coins
: 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

Joseph Ashwood

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
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

r.e.s.

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
"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

Joseph Ashwood

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to

"CLSV" <clvi...@dds.nl> wrote in message news:38890234...@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

Joseph Ashwood

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
> 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 0-63 range: card value = 15, key = 48 -> value = 63

Joe

CLSV

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"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 hands-on 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
> : 14-15 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 "52-card ARC4"
> with 4x13 card-layout, placing the coins adjacent to the cards
> they point to:

> 1) start with the x-coin and y-coin at the upper-left card
> 2) move the x-coin to the next card
> 3) read the card at the x-coin and move the y-coin that
> many cards ahead
> 4) swap the cards at the x- and y-coins
> 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

CLSV

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"r.e.s." wrote:

[On ARC4-52]

> 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

CLSV

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
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

Paul Rubin

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
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.

r.e.s.

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"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 state-vector array is always some permutation
of 256 *distinct* values 0,1,2,...,255.

"ARC4-52", to mirror ARC4, would use an alphabet of 52
symbols (instead of 256) for both the state-vector and
for key-data. Maybe you were thinking that a 256-symbol
character set would still be used in ARC4-52?

(The state-vector will have length 52, and will always be
a permutation of the 52-symbol 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 a-z,A-Z with values 0-25,26-51
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 0-63 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.

Paul Crowley

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
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 one-time-pad 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 brute-force a 77.5-bit key is still out of anyone's reach today -
consider that the 64-bit 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!)

Paul Crowley

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"r.e.s." <rs...@mindspring.com> writes:
> : The position of the pointers is part of the state of both pure ARC4
> : and ARC4-52, 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 52-element state-vector.

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.

Paul Crowley

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"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.

r.e.s.

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"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 ARC4-52, 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 52-element state-vector.
:
: 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.)

CLSV

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
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

r.e.s.

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
"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 "ARC4-52" 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.

Paul Rubin

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
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?


Rex Stewart

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
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
ARC4-52, 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 non-agreement 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.

CLSV

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to

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

Paul Rubin

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
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. Re-using keys with different initial I and J
sounds very dangerous. Collecting a few such messages
reveals too much of the state vector.

CLSV

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
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. Re-using 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

r.e.s.

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
"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 ARC4-M 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

r.e.s.

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
"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 well-randomized 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 brute-force 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 26-letter
alphabet is in the range ~1.3-4.7 bits, depending on how
randomized the selection is, 128 bits of entropy would require
about ~28-99 letters. But the passphrase- alphabet can consist
of the *52* letters a-zA-Z, 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 ~23-81 letters for
128 bits, if my arithmetic is OK.

The bottom line is that someone wanting 128-bits of entropy and
using a 10-letter 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 52-letter passphrase-alphabet.)

--
r.e.s.
rs...@mindspring.com

r.e.s.

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
"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 ARC4-52 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 0-51!

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 x-marker, just read it as
(suit,facevalue), and see it as an instruction to move the y-marker
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 0-12, 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
card-layout 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


r.e.s.

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
"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 though-the 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 dead-tired & 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 card-cipher operating at your wished-for rate
of 10 secs/char --even if I did once thoughtlessly claim ~4 secs/char ;-)

r.e.s.

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
"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 card-ciphers 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.

:
[...]


Joseph Ashwood

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
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.

> "ARC4-52", to mirror ARC4, would use an alphabet of 52
> symbols (instead of 256) for both the state-vector and
> for key-data. Maybe you were thinking that a 256-symbol
> character set would still be used in ARC4-52?

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 state-vector will have length 52, and will always be
> a permutation of the 52-symbol 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 a-z,A-Z with values 0-25,26-51
> 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

Joseph Ashwood

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
> 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).

r.e.s.

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
"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 0-51!
:
: 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 facevalue-associations 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 0-12, 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


: >card-layout 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 3-4 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.5-4 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, 0-9 = digits 0-9
: 1-2-3-27-1-2-3-4-5-28-6-7 would be read abc12345fg

I believe only one "escape toggle" is needed, and was thinking about
something like a-zA-Z, with UCletter=LCletter+26, and with X or Z
reserved as the "alphanumeric toggle". E.g. "33-8-49-0-0-7-49-1-24-4-51"
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:
: escape-15 = "roadblock" escape-16 = "chocolate" etc.

If you did that, you'd probably want yet another "number-mode" 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").

Paul Rubin

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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

Paul Rubin

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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.

Rex Stewart

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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

Rex Stewart

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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>,


"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.
>

> 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 ARC4-M 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
>
>

Sent via Deja.com http://www.deja.com/
Before you buy.

Paul Rubin

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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 0-51!

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 0-12, 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


>card-layout 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 3-4 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, 0-9 = digits 0-9
1-2-3-27-1-2-3-4-5-28-6-7 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:
escape-15 = "roadblock" escape-16 = "chocolate" etc.

This cuts down the number of characters you need to send.

Paul Rubin

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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.

Paul Rubin

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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 3-4 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.5-4 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.

Rex Stewart

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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 ARC4-m 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>,


"r.e.s." <rs...@mindspring.com> wrote:
> "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 card-ciphers 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.

> :
> [...]

Paul Crowley

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"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 ARC4-52 and ARC4-Rubin (the CRT-based 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 ARC4-M 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.

Paul Crowley

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"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.

Paul Crowley

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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.

Rex Stewart

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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.

Paul Rubin

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
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 ARC4-52 and ARC4-Rubin (the CRT-based variant).

Um, I don't think there's such a thing as "ARC4-Rubin". 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.

r.e.s.

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"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.

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"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 ARC4-m 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 time-saver for
ARC4-52, this one about how best to add the swapped cards to get
the output value.

r.e.s.

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"Paul Rubin" <p...@netcom.com> wrote ...
: In article <87k8kz9...@hedonism.demon.co.uk>,

My intentions were similar with what people are calling ARC4-52.
(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, ARC4-52-S-K1, etc? ;-)

r.e.s.

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"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 ARC4-52 and ARC4-Rubin (the CRT-based 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.

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"Paul Rubin" <p...@netcom.com> wrote ...
[...]
: ARC4-52 describes the cryptographic algorithm and is a good designation
: (distintinguishes it from the traditional ARC4-256). 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 state-vector lengths. Both key setup and combiner
then become separate modules.

Rex Stewart

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
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.
>
>

Paul Rubin

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
r.e.s. <rs...@mindspring.com> wrote:
>"Paul Rubin" <p...@netcom.com> wrote ...
>: Um, I don't think there's such a thing as "ARC4-Rubin". 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 ARC4-52.
>(But it's worth repeating that the XOR combiner is replaced with
>mod 52 addition.)

ARC4-52 describes the cryptographic algorithm and is a good designation


(distintinguishes it from the traditional ARC4-256). 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, ARC4-52-S-K1, etc? ;-)

That doesn't sound unreasonable. We already often run SSL/TLS
with ciphersuites like EDH-SHA-DES3-CBC-PKCS5. ARC4-52-xx isn't so bad.

Paul Crowley

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
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 searched-for letter, not the letter
searched for

* reversible, given the searched-for 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 searched-for 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!

Paul Crowley

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
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 ARC4-52 and ARC4-Rubin (the CRT-based variant).
>
> Um, I don't think there's such a thing as "ARC4-Rubin". 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.

Johnny Bravo

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
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 A-Z...

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

Johnny Bravo

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
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


Rex Stewart

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
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>,

> --
> __
> \/ 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.

Rex Stewart

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to
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

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to
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>,

Paul Crowley

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to
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.

0 new messages