Cryptography-Digest Digest #963, Volume #10 Mon, 24 Jan 00 02:13:01 EST
Contents:
Re: New Crypto Rules (wtshaw)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
The Code Book Challenge ("G. R. Bricker")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Card Ciphers ("Joseph Ashwood")
Re: Challenge. ("Douglas A. Gwyn")
Re: Combination of stream and block encryption techniques ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New Crypto Rules
Date: Mon, 24 Jan 2000 00:44:26 -0600
In article <[EMAIL PROTECTED]>, "John E. Kuslich"
<[EMAIL PROTECTED]> wrote:
> The "rules" will be determined after you have made your case to the
> "authorities" not before.
>
> If the "authorities" specify that there is a one time review and then do
> not specify whet they are reviewing, then this is the only conclusion
> that may be drawn.
>
> I think those who have bought the hype that the reules have benn relaxed
> are in for a terrible surprise.
>
The idea is to get you to be relaxed so you don't fight injustice.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Ed Stone) wrote:
> It's clear that the new regs aren't clear.
>
> Source: Cindy Cohn, lead Bernstein counsel in Bernstein v. Dept. of
> Justice, et. al.
>
--
As an issue in the campaigns, crypto may be forgotten unless we
ask questions whenever we can to bring it up. Report responses.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 06:35:18 GMT
r.e.s. <[EMAIL PROTECTED]> 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.
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").
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sun, 23 Jan 2000 22:36:15 -0800
"Rex Stewart" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]
: --
: Rex Stewart
: PGP Print 9526288F3D0C292D 783D3AB640C2416A
:
: In article <86g63d$72l$[EMAIL PROTECTED]>,
: "r.e.s." <[EMAIL PROTECTED]> wrote:
: > "Rex Stewart" <[EMAIL PROTECTED]> 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.
:
[...]
------------------------------
From: "G. R. Bricker" <[EMAIL PROTECTED]>
Subject: The Code Book Challenge
Date: Mon, 24 Jan 2000 06:37:20 GMT
Has anyone typed these examples, especially the later ones? I could solve
the first few examples with a whiskey in one hand and a pen in the other.
However, when I started looking ahead to the later examples, I began to
despair. If anyone has already sweated on a keyboard and typed these out,
or, better yet, scanned and ocr'ed them, I would GREATLY appreciate having
the examples posted. Perhaps a web site has already done this.
Also, I have begun to toy with programming some simple frequency analysis
programs. For instance, a program to scan a message and generate a list of
the characters used in decreasing order. Ditto for words. Ditto for common
pairings of characters. As I began tinkering with writing the program, I
realized that certainly somebody else has already done this. Why reinvent
the wheel? Anyone know where I can find such elementary tools?
Thanx, George
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Mon, 24 Jan 2000 06:35:53 GMT
> > > Not in practice. The security of the key generally depends
> > > only on the size of the key.
> >
> > So what you are saying is... Is that what you are saying?
>
> May I suggest you read a bit more carefully? Where did I say
> that it can not be broken no matter how you construct the key?
All you need to do is answer my request for clarification by saying,
"No, that is not what I am trying to say."
> I said that ** IN PRACTICE ** the security of the key only
> depends on its size. This is because primaility tests will
> (even probabilistic ones) screen out deliberately constructed
> p,q which have a large number of prime factors.
Then in practice it does not depend on the size of the resulting
number, but the size of the primes that make up the number?
Is that what you are implying? (does the word imply help?)
> No. For RSA (e.g.) they keysize is fixed. For EC the
> private keysize is a random variable (with an exponential
> distribution with mean 1 bit less than the field size)
Why not just set the MSB with an ECC private key? Would that help?
> > The strength of ECC is in the key space being too large to
> > search and too complex to readily determine the factor,
> What "factor"?
Fine- private key. (Did you read Dr Rosing's book that likened the
key generation to "point multiplication"?)
> Existsing STANDARDS permit the use of a private key selected at
> random. Note also that if indeed you implement your suggested scheme,
> then you have reduced the time to break the key by 1/sqrt(2).
Then the standard needs to sit the MSB. And what is the difference
between nuclear_strength and nuclear_strength/sqrt(2)? It is
still nuclear_strength- still strong enough to hide the launch codes
with. Now if you said sqrt(original_key_size), then I would be
concerned. Besides, if it secures the key space, it can only
strengthen the cryptography overall, not weaken it.
> > > Further, if it can be guessed that the private key lies in
> > > a restricted range,...
> > ...then there is something wrong,
> Why? Cryptographers worry all the time about partial key revelation.
But that has nothing to do with the cipher, but with key leakage,
and entirely different aspect of security. Sure it can be used
against ECC far more than RSA, but it has nothing to do with either.
> > but what ever it is that is wrong has nothing to do with ECC...
> WRONG. With ECC this information is very useful in attacking the key.
> With RSA is is not (unless you reveal TOO MUCH)
No, I am right. Key leakage is only a problem "with" ECC if the
ECC public key can give hints away about portions of the private key.
Otherwise, key leakage is only a problem "FOR" ECC for the reasons
you state above. To date, I have not heard anything of the former.
Have you? I agree with the latter, however. But again, it is
symptomatic of a problem unrelated to ECC being deployed.
> > Given an elliptic curve of 500 bits and an RSA key of 500 bits,
> > if you expose half the bits, which key is likely to be cracked in
> > our life time?
>
> May I suggest that
> you go read the literature on this subject? Especially in terms
> of what can be done and what has been done?
500 to 500 was a bit odd, but I thought you were heading along
that line with 20 bits exposed from RSA with 20 bits exposed from
ECC. I thought you ment to compare 4 oz apple to 4 oz orange.
And, pray tell, how will I know I have reached enough knowledge
to begin posting here again? Will you tell me? Of course not.
> 512 bit RSA is breakable in a month even with no bits revealed.
>
> And 500 bit ECDL is so far beyond what is needed that noone is
> suggesting to use keys this large.
NIST does. They have a "recommended" curve over a field of
571 bits. Would you not consider this nuclear strength if you
also consider beyond what is needed? And I use it on my
cryptosystem for one reason and one reason only (because as
you say, there is no real reason to date for its deployment):
IF a sub exponential attack were to be found against ECC in general,
then 571 field size would not necessarily be a weak curve, but will
likely remain formidable. In other words, the information encrypted
with such a field size today will have the best chance of surviving
such a discovery tomorrow. You see, I don't rule out anything. I
surround my data with the strongest possible encryption with today's
knowledge. The only size of RSA that has the same type of strength
is around 20kbits. And I am not interested in implementing
anything that size.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 06:49:44 GMT
In article <86grr6$n3n$[EMAIL PROTECTED]>,
>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.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sun, 23 Jan 2000 22:20:30 -0800
> 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).
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sun, 23 Jan 2000 22:37:17 -0800
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
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Card Ciphers
Date: Sun, 23 Jan 2000 22:54:41 -0800
My current line of thought regarding this is that we have experts, in many
different methods all trying to single-handedly work out a solution, and we
have in fact discussed back and forth a number of possibilities. This is not
my attempt at a cipher, but instead my attempt at breaking a cipher of the
accepted style up into the parts needed.
Initial State:
Generating the initial state, in such a way that it is fast for a human,
simple for a human to remember, and requires nothing beyond a deck of cards.
The two lines of thought on this are 1) We can start with any initial vector
of cards, 2)We should only start with the cards in a given order so that we
can throw away and purchase decks without difficulty.
Both of these can be used, I suspect that I would side with the second due
to the fact that given any of the designs that I have seen they could be
easily used with a different known original order of cards. I personally see
the initial order of cards as IV, useful for many reasons, but not
absolutely required for most situations.
Conversion of plaintext to encipherable text:
While this has not been discussed in great detail, I feel that in order to
make a truly strong cardcipher we will need to adjust the encoding of
symbols in the language (this would obviously have to be only a suggestion,
and should be changed to suit the needs of the entities communicating)
Encipherment, and alteration of card states associated with it:
This part of the cipher hasn't really been discussed but it could certainly
be a useful portion of the mechanism.
While I see where this may be a difficult task, I think that having a record
of the thoughts of the group could be useful in order to give newbies
(realistically, myself included) some idea of the thoughts of more
experienced analysts.
Joe
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Challenge.
Date: Mon, 24 Jan 2000 06:59:02 GMT
Paul Schlyter wrote:
> In article <86em8o$ckq$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>, Roy Longton <[EMAIL PROTECTED]>
>wrote:
> >> Second that. For all I know, he could've used OTP.
> > Yeah, but I didn't.
> So you claim -- but can you prove your claim? <g>
Actually, it's pretty obvious.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Mon, 24 Jan 2000 07:04:38 GMT
Mok-Kong Shen wrote:
> Douglas A. Gwyn wrote:
> > The existence of shades of grey does not obviate the difference
> > between black and white.
> Ah, I see you are apparently arguing for a THIRD category, i.e.
> for stuffs that don't clearly fall into either (of the existing two)
> categories, don't you? (Would you like to suggest a name for that?)
> Isn't the mere existence of the fact that there are examples that
> don't clearly fall into either categories an indication of deficiency
> of the current classification system and therefore gives additional
> support for removing the boundary between the two categories?
You didn't understand my point.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
