Cryptography-Digest Digest #358, Volume #11 Sat, 18 Mar 00 05:13:01 EST
Contents:
Re: my toy cipher ("Michael A. Greenly")
Re: NIST, AES at RSA conference (SCOTT19U.ZIP_GUY)
Dss ("naptime")
Re: Universal Language (stanislav shalunov)
Re: Enigma encryption updated (Adam D) (Nemo psj)
Re: 64-bit Permutations (Boris Kazak)
Re: Cipher Contest ("Adam Durana")
recognizing English text (Eric Lehman)
Re: recognizing English text (James Pate Williams, Jr.)
Re: Improvement on Von Neumann compensator? (Guy Macon)
Re: SALT with RC4, where do I store the SALT? (Guy Macon)
Re: US export status of RC4? (Guy Macon)
Re: US export status of RC4? (Guy Macon)
Re: 64-bit Permutations (smuggdot)
Re: new/old encryption technique ("Douglas A. Gwyn")
Re: Cipher Contest ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: new Echelon article ("Douglas A. Gwyn")
Re: recognizing English text ("Douglas A. Gwyn")
Card shuffling (Mok-Kong Shen)
Re: Card shuffling ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Michael A. Greenly" <[EMAIL PROTECTED]>
Subject: Re: my toy cipher
Date: Fri, 17 Mar 2000 21:35:21 -0800
Thank you, this definitely gives me something to look into :)
<[EMAIL PROTECTED]> wrote in message
news:8au6ul$3h4$[EMAIL PROTECTED]...
> Mr. Greenly,
>
> I decided to have a crack at your sea64. As a goal, I wanted to find
> one serious weakness. I tried differential cryptanalysis but was foiled
> by the 64 rounds.
>
> I did find a serious related key attack however. As other's pointed out
> the key schedule is linear in nature. The downside of this is that if
> one round key is found the key schedule can be reversed. So to break the
> cipher, I will try to gain one round key.
>
> If the difference(-) of two keys,K1 and K2, is your d1 and d2, then the
> round keys will be off by 1. The first round key of K1 will equal the
> second round key of K2.
>
> The upshot of this is that the ciphertext of two such keys is partially
> equal. The right half of the K1 ciphertext will equal the left half of
> the K2 ciphertext. The XOR of the left of K1 and the right of K2 yields
> the f(CK1,K1[0],K1[1]). We can expect such a pair to occur in 1 pair of
> of 2^16 or 2^17 with chosen plaintext. Several pairs may be needed to
> weed out wrong pairs.
>
> Now given the input and output of the F function the two keys must be in
> a set of 2^32. Via the equation
>
> out = in <<<23 + a ^ b
>
> If 'b' is assumed then 'a' is the only unknown and thus can be solved
> for. Once the 64 round key is known, simple subtraction yields the
> 63,62,etc.
>
> Several pairs can be tried or the 2^32 can be bruted against a known
> plain text.
>
> Here is an example
>
> K1 = {223456789,999999 };
> K2[0] = K1-d1;
> K2[1] = K2-d2;
>
> m={0xd5eec2a,0}; // randomly try pair in order to get a collision
> n={0,0};
>
> encrypt(m,K1); // cipher text is 0xC42B23F4 0x3DFDF1F3
> encrypt(n,K2); // cipher text is 0x3DFDF1F3 0x32D4D746
> // (0xC42B23F4^0x32D4D746) = f(0x3DFDF1F3,K1[64][0],K1[64][1])
>
>
> This is an example of the related key slide attack. David Wagner wrote
> a very interesting paper about slide attack. Bruce Schneier and friends
> have written extensively about related key attacks.
>
> --Matthew
>
> In article <rkbA4.619$[EMAIL PROTECTED]>,
> "Michael A. Greenly" <[EMAIL PROTECTED]> wrote:
> > Anyone looking for a little crypto-anylysis fun is welcome to take a
> crack
> > at my little homebrew cipher. I suspect that nothing about this cipher
> is
> > secure but I had fun throwing it together and intend to have more fun
> trying
> > to take it apart.
> ...
>
> >
> > The code can be found here:
> http://www.pinenet.com/~mgreenly/sea64.cpp.html
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 18 Mar 2000 05:09:14 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Mok-Kong Shen wrote:
>> SCOTT19U.ZIP_GUY wrote:
>> > cause its citazens troulbe as it did the Japanese Americans
>> ... If the authorities could treat citizens of their
>> own countries 'categorically' like that, there appears indeed to
>> be scarcely any foundation to assume that machineries like the
>> Echelon would respect the freedom of privacy of civilians and
>> commercial firms of foreign countries (whether allied, friendly
>> or hostile ones) and refrain from intercepting and analysing
>> their communications.
>
>Different time, different culture, different circumstances,
>different individuals, different legal environment,
>different government. Your conclusion doesn't follow.
Yes it is a different time. Now is a time when even most
of the world knows we are corrupt. Our justice system is far
more corrupt know than any time in the past. We have Clinton
to thank for that. He has done more than any other president
in history to destroy the honor of the country. The sad part
is that he is to stupid to understand the long term damage he
has done to the country.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: "naptime" <[EMAIL PROTECTED]>
Subject: Dss
Date: Fri, 17 Mar 2000 22:18:24 -0000
Hi looking for fixing on the ECM dss send on 3/15/00
------------------------------
Subject: Re: Universal Language
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Sat, 18 Mar 2000 04:26:58 GMT
[EMAIL PROTECTED] writes:
> stanislav shalunov wrote:
> > In Russian vocative is defunct. There are three words that have it:
> > "Otche", "Bozhe", and "Gospodi" (all three happen to refer to God and
> > can be considered borrowings).
[Please put replies below quotes.]
> Borrowings from where?
>From Old Church Slavonic.
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Enigma encryption updated (Adam D)
Date: 18 Mar 2000 04:30:59 GMT
<<I think you may have misinterpretted what I wrote. I have
already demonstrated knowledge of your encryption to level
better than your understanding, by posting an equivalent and
vastly superior algorithm. Your description of your password
modification is extremely lacking. If you feel I am wrong,
please feel free to quote from the word document the parts
that I missed.>>
No you simply described how my key was changed somehow that doesnt fit the
entire algy. Frankly im tired of talking to you because your arogant in ways
wich i cant sustain any longer.
<<How did you key RC4? How did you use RC4? Did you ignore the
well known attack on RC4? Did you forget that using good
crypto in a poor way, gives poor security?
>>
No on all accounts..... Cept first I posted the source, and how it is used in
the algy in the word doc i suggest you stop thinking math and start thinking
plain english when you read it, then maybe youll get it.
<<As was noted last time, your entire security lies in your
random number generation.>> Wich in it self isnt a bad thing if i cant get a
method good enough so you cant reverse it.
<<you reveal the entire state on every
byte>>
If they cant figure out what letter the wheel is made from there not going
anywhere so your telling me what now?
Yes yes fine i'll re-explain the whole thing again in another more easy to read
word doc. You still fail to see how it works but no problem i'll keep trying
to explain it till you get it ;P
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 64-bit Permutations
Date: Sat, 18 Mar 2000 04:48:05 GMT
Please take a crash course in reading and comprehension.
Original author wrote:
**************************
The bits in each block are simply permuted in the same
fashion for each block. The key, then would be the bit-
mapping.
**************************
And you are now trying to approach some entirely different
problem...
> Nope. A non-repetitive sequence of all 2^64 elements in the set of 64 bit
> sequences is 64*(2^64) bits long. I am then talking of a permution of 64-bit
> _values_.
==================== Sorry and best wishes BNK
[EMAIL PROTECTED] wrote:
>
> In a previous article, <[EMAIL PROTECTED]> writes:
> [--cut--]
> >You're joking, right?
>
> Nope. A non-repetitive sequence of all 2^64 elements in the set of 64 bit
> sequences is 64*(2^64) bits long. I am then talking of a permution of 64-bit
> _values_.
>
> A permution of 64-bit _positions_ is a completely different story. I expect to
> unequivocally determine each such permution from 64 pairs of plain text
> cipher text blocks (i.e. from 2x64x8 bytes).
>
> ----- Posted via NewsOne.Net: Free Usenet News via the Web -----
> ----- http://newsone.net/ -- Discussions on every subject. -----
> NewsOne.Net prohibits users from posting spam. If this or other posts
> made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Fri, 17 Mar 2000 18:35:13 -0500
> I think it would be fair to have a open catagorey where one is allowed
> to let the block size be the size of the file to be encrypted.
This suggestion wouldn't have anything to do with the fact that you ScottXu
ciphers treat the file as one block, would it? You shouldn't be trying to
get the requirements to match a cipher you already have designed. And I
don't see why you couldn't take your cipher and change the block size to say
512 bits instead of the whole file.
- Adam
------------------------------
From: Eric Lehman <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: recognizing English text
Date: Sat, 18 Mar 2000 07:37:22 GMT
I'd like to write a program that takes a block of ASCII characters and
decides whether or not the block is a snippet of English text. For
example:
j2fk@30v0$ -> output "no"
ke to writ -> output "yes"
My program need not be perfect, of course, but I'd like it to be pretty
good. Any thoughts about how I could go about this? Is a hairy heap of
horrific heuristics unavoidable?
/Eric
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: recognizing English text
Date: Sat, 18 Mar 2000 08:13:13 GMT
On Sat, 18 Mar 2000 07:37:22 GMT, Eric Lehman <[EMAIL PROTECTED]>
wrote:
>I'd like to write a program that takes a block of ASCII characters and
>decides whether or not the block is a snippet of English text. For
>example:
>
> j2fk@30v0$ -> output "no"
> ke to writ -> output "yes"
>
>My program need not be perfect, of course, but I'd like it to be pretty
>good. Any thoughts about how I could go about this? Is a hairy heap of
>horrific heuristics unavoidable?
>
>/Eric
First you could do frequency analysis to make sure that the single
character frequencies matched the language. Second you could
parse words or word fragments and check them against entries in
a dictionary.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Improvement on Von Neumann compensator?
Date: 18 Mar 2000 03:25:13 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>Guy Macon <[EMAIL PROTECTED]> wrote:
>
>: I am thinking that making the input and the output of the hash have
>: the same number of bits would be necessary but not sufficient.
>
>No finite size is sufficient if you want to retain /all/ the entropy.
>
>If you use 160 bits of input to 160 bits of output, the resulting output
>stream is likely to have an entropy of a little under 0.995bits/bit.
>
>: I know that if I XOR a true random bitstream with any other bitstream
>: (except those derived from the true random bitstream), the result
>: will be a true random bitstream. Can this property be proven for
>: any cryptologically strong hash functions such as SHA1?
>
>It can be practically proven false - the hash of a fixed-length finite
>random bitstream is never itself random - though it can become /very/
>nearly so.
I understand. Thanks for explaining it to me.
Could I then conclude that the best algorithmic aproach to "improving"
a bitstream that comes from radioactive decay or thermal noise random
number generator (RNG) would be to make a pseudorandom bitstream using
the best pseuodorandom generator available (PRNG) seeded with a seperate
run of the RNG, then XOR the two together? Or is there some superior
method of trying to remove unknown biases caused by the electronics?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: SALT with RC4, where do I store the SALT?
Date: 18 Mar 2000 03:36:45 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Doug Stell)
wrote:
>The suggestion is that you pretend encrypt or decrypt so many bytes of
>ether, before beginning encryption or decryption of your data. The
>reason is that the RC4 algorithm has been shown to have some
>weaknesses in its key preparation routine. This action stirs up the
>key state to get past that weakness.
I am somehow missing the nuts and bolts here. Are you saying to:
[1] add a bunch of random bytes at the start of your plaintext.
[2] encrypt normally
[3] decrypt normally
[4] throw away the random bytes
..or am I completely in the weeds?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: US export status of RC4?
Date: 18 Mar 2000 03:39:58 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
>
>Guy Macon wrote:
>>
>> In article <8apn7d$ktg$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bill Unruh)
>wrote:
>>
>> >Tell us more. As I saw the regs, if you publish the source and make it
>> >freely available ( eg GPL) then you can export almost anything.
>>
>> I would be willing to export it for him - I don't think that doing
>> so is illegal in the U.S.
>
>It's either legal for both of you, or for neither of you.
>
Of course. What I am saying is that I am willing to risk any legal
consequences if I turn out to be wrong, and thus can be a test case
for someone who is more cautious. The offer stands.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: US export status of RC4?
Date: 18 Mar 2000 03:43:26 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Impervious) wrote:
>
>On Thu, 16 Mar 2000 16:33:57 -0500, Paul Koning <[EMAIL PROTECTED]>
>wrote:
>
>>Bill makes the point I was going to. Manuel, be sure to read
>>the *current* export rules carefully. There's a lot you can do
>>freely now. Do *not* rely on unofficial summaries that are
>>more than a month or two old, because they are likely to describe
>>the bad old days before 1/15/2000. Not that what we have now is
>>perfect -- but it is a whole lot better than what it was.
>
>Thanks for the input guys! From what I read, they still don't want you
>exporting anything with over a 56-bit key. Am I reading it wrong? My
>program is RC4 based and uses a 256-bit key with SHA. I am working on
>the SALT now..
Like I said, I am willing to risk it, based on my reading of the
regulations. The question is, (assuming that they come after me),
would my doing the exporting shield Paul Koning from legal action?
------------------------------
From: smuggdot <[EMAIL PROTECTED]>
Subject: Re: 64-bit Permutations
Date: Sat, 18 Mar 2000 09:04:08 GMT
Stephen Houchen wrote:
> Imagine a cipher where you took plaintext in 64-bit blocks.
> The bits in each block are simply permuted in the same
> fashion for each block. The key, then would be the bit-
> mapping.
>
> My gut feeling is that this is so simple that it's probably not
> very hard to break.
>
> So cryptanalysts, how would you break it?
>
> S
> [EMAIL PROTECTED]
One way would be to construct 64 map-tables with each possible walue the
bits could to be permutated to(1 - 64) and remove values in the map
after comparing known plaintexts with ciphertext, if the bit is set to 1
in the plaintext, you can simply remove each entry in the map-table
where the ciphertext bit is set to 0.
After doing this a couple of times you could search the remaining
keyspace easily.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: new/old encryption technique
Date: Sat, 18 Mar 2000 09:08:57 GMT
Samuel Paik wrote:
> JimD wrote:
> > Samuel Paik <[EMAIL PROTECTED]> wrote:
> > >Can we stop calling synchronous stream ciphers "one time pads" please.
> > Well, they probably are if the cryptovariables are changed before
> > they start to repeat.
> No they are not. ... [example omitted] ...
If the system is designed so that the CT is a simple addition/XOR
of the PT and a key stream that is used *directly* for the purpose,
then it is a "one-time pad" system, but not necessarily a very
good one. The reason we don't normally include systems like the
LFSR-based one of your example in the category "one-time pad" is
that the key in your example is actually used as the initial
setting of the (internal generator) cryptovariables, not added
directly to the PT stream. If instead the communicants had been
supplied with the *output* of such a key generator as their key
material, instead of settings for their own copies of the key
generator, then they would be using a one-time pad system, but
it would not be highly secure. The cryptanalyst indeed might
crack the system without ever realizing that it was being used
via an intermediate pad of key material, although with enough
material he could also crack the indicator system and come to
that realization. (This phenomenon of cracking a system via
its internal structure without reproducing the actual steps
used by the communicants, finding instead some equivalent
system, is fairly common in cryptanalysis.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Sat, 18 Mar 2000 09:18:58 GMT
Adam Durana wrote:
> > I think it would be fair to have a open catagorey where one is allowed
> > to let the block size be the size of the file to be encrypted.
> This suggestion wouldn't have anything to do with the fact that you ScottXu
> ciphers treat the file as one block, would it? You shouldn't be trying to
> get the requirements to match a cipher you already have designed. And I
> don't see why you couldn't take your cipher and change the block size to say
> 512 bits instead of the whole file.
D.Scott is right -- the proposed rules of the competition are far
too restrictive, if the goal is to explore new cryptosystems and
their exploitable weaknesses.
I personally think that the rule should be, submit *any* feasible
cryptosystem one wants, but the submitter must already be in
possession of a practical method for cryptanalyzing that system,
and that method will be published after a certain amount of time
(say, 6 months). The competition would be to see who could first
discover a method (not necessarily the one the author knows) for
breaking the system.
There is much more motivation to attack a system when one knows
in advance that it is crackable.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sat, 18 Mar 2000 09:25:23 GMT
Jerry Coffin wrote:
> > (There *are* several implementation-defined aspects of I/O, but
> > most programs don't depend on them.)
> I'm not convinced.
I realize you're not convinced, but I'm one of the people who
*write* the spec you are trying to interpret, and I'm telling
you what I told you.
Even if one were to accept your (incorrect) argument that it
is not possible to write a s.c. program that interacts in any
way with the real world, that wouldn't have any bearing on my
original point that the vast majority of one's C code can and
should be coded so that it is usable in a s.c. program.
But your attitude leads to a lack of care about such matters.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 18 Mar 2000 09:28:09 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Yes it is a different time. Now is a time when even most
> of the world knows we are corrupt. Our justice system is far
> more corrupt know than any time in the past. We have Clinton
> to thank for that. He has done more than any other president
> in history to destroy the honor of the country. The sad part
> is that he is to stupid to understand the long term damage he
> has done to the country.
That may well be true, but it is a different argument than
the extrapolation from the distant past that Mok-Kong Shen
used. I didn't say the conclusion wasn't true, just that
it didn't follow from the premises.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto
Subject: Re: new Echelon article
Date: Sat, 18 Mar 2000 09:33:08 GMT
Jos Horikx wrote:
> Another interesting echelon-article on:
> http://cryptome.org/echelon-cia2.htm
Thanks; that was a refreshing change from Duncan-Campbellism.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: recognizing English text
Date: Sat, 18 Mar 2000 09:42:14 GMT
Eric Lehman wrote:
> I'd like to write a program that takes a block of ASCII characters
> and decides whether or not the block is a snippet of English text.
> For example:
> j2fk@30v0$ -> output "no"
> ke to writ -> output "yes"
> My program need not be perfect, of course, ...
Of course -- because now "j2fk@30v0$" *does* appear in English text.
The standard approach is to develop a *statistical model* of the
natural language, and test the candidate string for its likelihood
under the model. Markov models where the letters are the basic
symbols are a good choice; they include single-character frequency,
trigram frequency, etc. By comparing the probability that the
model would generate the candidate string to the probability of
the string being generated from a random source, you can assess
the evidence in favor of one hypothesis over the other.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Card shuffling
Date: Sat, 18 Mar 2000 10:58:24 +0100
Although I have never played a card game, I do know the action of
shuffling. Evidently a veteran player shuffles (nearly) perfectly,
while a novice often does less well and a kid maybe very poorly.
Does there exist any objective means to determine (or help to
determine) the relative quality of shuffling or is one left to
rely on pure subjectivity in deciding on that issue?
If one let a card deck be processed through a number of successive
inferior quality shuffling, it seems plausible that the result
will asymptotically approach perfectness. Is it possible to
say something more than simply the fact that near perfectness
will ultimately be reached without knowing how fast the limit
is being approached?
I am aware that there is lot of fuzziness in my questions. But
perhaps we could nonetheless have some discussions. (There exist
mathematical works on card shuffling based on a certain defined
way of 'perfect shuffling'. I am interested however in shuffling
done by humans, which almost always have deviations from that.)
Thanks.
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Sat, 18 Mar 2000 10:05:29 GMT
Mok-Kong Shen wrote:
> Does there exist any objective means to determine (or help to
> determine) the relative quality of shuffling or is one left to
> rely on pure subjectivity in deciding on that issue?
> ...
> I am aware that there is lot of fuzziness in my questions. But
> perhaps we could nonetheless have some discussions. (There exist
> mathematical works on card shuffling based on a certain defined
> way of 'perfect shuffling'. I am interested however in shuffling
> done by humans, which almost always have deviations from that.)
Indeed, perfect shuffling, such as is reportedly actually performed
by Brent Morris, has been thoroughly studied (by Morris and others).
We had a discussion about that not very long ago.
In shuffling for a game of chance, one does not *want* perfect
shuffling. What is wanted is a random permutation; that is not
hard to formally describe. Any *measure* of randomness is
necessarily statistical, because a truly random process can on
occasion produce a highly ordered result.
As to how thoroughly people shuffle in practice, that can only
be determined empirically, for example by starting with a
totally ordered deck and testing the result of the shuffle
(which normally consists of numerous passes over the deck).
I think the most interesting information would come from just
looking at the position of the original top or bottom card,
since those are the cards most likely not to get shuffled
very well into the body of the deck. I'm sure somebody has
already performed the experiment.
------------------------------
** 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
******************************
