Cryptography-Digest Digest #573, Volume #14 Sat, 9 Jun 01 09:13:01 EDT
Contents:
Re: Shannon's definition of perfect secrecy (Tim Tyler)
Re: Anyone Heard of "Churning" (Tim Tyler)
Re: Algorithms ("Vance Gloster")
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Alice and Bob Speak MooJoo ([EMAIL PROTECTED])
Hex notation ("Adam O'Brien")
Re: Alice and Bob Speak MooJoo (Quisquater)
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: Uniciyt distance and compression for AES (Andreas Gunnarsson)
Re: Hex notation (Nicol So)
Differential cryptanalysis ("Adam O'Brien")
Re: Uniciyt distance and compression for AES ("Tom St Denis")
Re: Differential cryptanalysis ("Tom St Denis")
Re: Uniciyt distance and compression for AES ("Tom St Denis")
Re: cubing modulo 2^w - 1 as a design primitive? (Mark Wooding)
Re: Hex notation (Mathew Hendry)
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: practical birthday paradox issues (Johnny Bravo)
Mantin-Shamir's RC4 distinguisher paper and RC4 *student* paper ("Michael Lee")
Re: cubing modulo 2^w - 1 as a design primitive? ("Tom St Denis")
Re: Mantin-Shamir's RC4 distinguisher paper and RC4 *student* paper ("Scott Fluhrer")
Re: Hex notation (Tim Tyler)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Shannon's definition of perfect secrecy
Reply-To: [EMAIL PROTECTED]
Date: Sat, 9 Jun 2001 09:00:04 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> My main concern is with the definition and usage of the term
:> "perfect secrecy" - I'd like to see what Shannon wrote,
:> whether his proof relates to what he wrote, and whether others
:> have followed his usage properly.
: This is from the scanned copy of "Communication Theory of Secrecy Systems"
: at <http://www3.edgenet.net/dcowley/docs.html>
Thanks for that URL - and for the text. I didn't know this was available
online.
: Several things are clear from this: [...]
: - Nowhere does the paper say that the key length and message length of
: a perfect system are the same [...]
They don't need to be.
: - The footnote about traffic analysis suggests sending "blank" messages,
: which obviously requires the ciphertext distribution for blank messages
: to be the same as for normal messages [...]
Yes - if perfect secrecy is to be maintained ;-)
:> ...but [Shannon] is also supposed to have proved that the (conventional?)
:> OTP has [perfect secrecy], which it does not. I'll resolve the apparent
:> friction between these ideas by reading his actual words and proof.
: He only mentions the Vernam cipher (i.e. OTP) for the case of potentially
: infinite length streams, and for a definition of perfect secrecy adapted
: to that case. [...]
Yes - he doesn't deal with the conventional OTP on finite files in the
passage you quote.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Anyone Heard of "Churning"
Reply-To: [EMAIL PROTECTED]
Date: Sat, 9 Jun 2001 09:34:55 GMT
Stephen Thomas <[EMAIL PROTECTED]> wrote:
: [This didn't get a response in sci.crypt.research, so I thought I'd try here.]
: Apparently, ATM Passive Optical Networks (APONs) have standardized on
: an "encryption" algorithm refered to as "churning." Does anyone know
: anything about this? Especially details on the algorithm. (FWIW, PONs
: are shared media networks like cable modems.)
: The only references I can find are:
: APON uses a 24-bit key churning mechanism
: Churning is a memoryless transformation of one byte to a
: different byte
A superficial search suggests that the "churning" of keys is somtimes used
as a generic term for the passing of a key through a one-way hash
function, or similar.
That doesn't square with "Churning is a memoryless transformation of one
byte to a different byte" - but that apparently comes from a marketing
document.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Vance Gloster" <[EMAIL PROTECTED]>
Subject: Re: Algorithms
Date: Sat, 9 Jun 2001 03:17:22 -0700
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> Well if you want the algorithms for Digital Signatures, there are 3 of
them
> in FIPS 186-2, those are a good beginning, you can them compare these to
NSS
> (from NTRU www.ntru.com), various PKCS1 versions, ACE Sign, ESIGN, FLASH,
> QUARTZ, SFLASH (all 5 available from
If you are researching digital signatures, you need to take a look at the
X.509 standard.
Vance Gloster One should never listen. To listen is a sign of
[EMAIL PROTECTED] indifference to one's hearers. -Oscar Wilde
http://www.vancesoft.com/vmghome
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 09 Jun 2001 01:36:49 -0800
Tim Tyler wrote:
>
> [EMAIL PROTECTED] wrote:
> : "SCOTT19U.ZIP_GUY" wrote:
>
> :> Uncity distance is a concept found by Shannon that is valid even
> :> today. It has to do with the amount of cipher text needed to be
> :> looked at in a ciphertext only attack to determine the key and
> :> the rest of a secret message.
> : [snip]
>
> : Unicity distance can be interpreted as the smallest number of
> : of ciphertext letters which must be intercepted in order to
> : expect a unique, *meaningful* decipherment. It
> : is a function of both keyspace entropy and the redundancy of the
> : "language". Language redundancy arises from the fact that not
> : all possible messages are meaningful.
>
> : I don't see how compression makes a difference. Compression reduces
> : the redundancy (a message in a language that contains no redundancy
> : cannot be compressed), but since the redundancy is a property
> : of the *language* then not all decompressions will be meaningful.
>
> : I don't think you can get around this. It seems to me that all you're
> : doing is adding another step, i.e. decrypt and then decompress to
> : determine
> : whether or not the message is meaningful, rather than just decrypting as
> : the case would be if no compression were used.
>
> : Simply put, redundancy is a feature of the language. You can't change
> : the redundancy without changing the language. Without changing the
> : redundancy you can't change the unicity distance (assuming no
> : change in the entropy of the keyspace).
>
> : Am I overlooking something?
>
> Yes you are. Unicity distance is a function of the redundancy of the
> inputs to the encryption algorithm, not that of the original message.
This definition is convenient for your argument but is it of any
practical value since the compressed decryption must be decompressed
before it can be used?
The only way a compressor could *effectively* increase the unicity
distance is by having some mechanism for rejecting meaningless messages
in the original language as inputs.
If the compressor doesn't reject meaningless messages in the original
language, then meaningless messages will be compressed and decompression
can be used to distinguish between compressed decryptions that are
meaningful and compressed decryption that are not meaningful.
If the compressor doesn't reject meaningless message inputs, then
the redundancy hasn't effectively been reduced, since decompression
will recover it, so the unicity distance hasn't been effectively
increased.
> If the redundancy in the input the the encryption algorithm is
> decreased (e.g. via compression), then the unicity distance
> increases - a computationally unbounded adversary needs more
> cyphertext before he can uniquely determine a plaintext.
The important question is, "has the redundancy been *effectively*
reduced
or is it trivially recovered by decompression?" If you have a
compression algorithm with sufficient intelligence to compress
only those messages which have meaning in the original language,
then yes, compression has reduced redundancy and increased
unicity distance. If the compression algo doesn't reject
meaningless messages in the original language, then your
definition of redundancy (at the input to the encryption
algo) is worthless in a practical sense.
I'm not even sure that a compressor with the ability to
reject "meaningless" message inputs is practical. If it
is designed to reject all non-ASCII inputs, for example,
then it puts limits on the usefulness of the compressor.
> Note that there may be no upper bound on the degree by which
> compression can increase the unicity distance. It can transform
> a system with a unicity distance of 128 bytes to one where
> the unicity distance is effectively infinite.
Theoretically it isn't bounded. Practically it is bounded by
the ability of the compressor to reduce redundancy. Naturally, if the
compressor manages to effectively eliminate redundancy, the
unicity distance is infinite.
=====BEGIN PGP MESSAGE=====
Version: PGP 6.5.8
owEBUACv/4kAPwMFADr8zeJeh8Vpi2BPfBECIdMAnj2JL4t7ldNTP6AdJpgPZfcJ
CyCJAJwOZpDqGOriihtsout3jjUnUCSpN6wMYgZwZ3BzaWcVAAAA
=dADa
=====END PGP MESSAGE=====
------------------------------
Subject: Re: Alice and Bob Speak MooJoo
From: [EMAIL PROTECTED]
Date: 09 Jun 2001 07:18:25 -0400
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
> But I never heard that a Navajo was captured.
Sgt. Joe Kieyoomia was captured in the Philippines in 1942, and survived
the Bataan death march. He was a Navajo, but not a code talker. At first
the Japanese tortured him because they thought he was a Japanese American
due to his Asiatic appearance. They refused to believe otherwise, since
he was neither Caucasian nor Black. Finally they did believe him, and
even made the connection between the code talkers and the Navajo language.
> But I got the impression the code was not complex.
That's right. It was a simple alphabet code, except that the words were
translated into Navajo for transmission. The Japanese should have broken
the code very quickly after capturing Sgt. Kieyoomia, but they didn't,
for a very simple reason: when he said the messages were nonsense--and
gave English translations--they assumed he was lying and beat him like
a dog. If they had put him at the disposal of the cryptographers, the
code might have been broken fairly quickly.
> Actaully I have been around Navajos to my hear it sounds like
> spanish. But then so does Italian.
Part of the advantage to Navajo was that it's completely unlike any other
language (except perhaps some other Native American languages). So there
was nobody who even had an ear for the sounds. Just as many Asians confuse
'l' and 'r', so it would be extremely difficult to even begin a crack.
If it resembled some well-known language--as Italian does Spanish--then
the problem might have reduced to composing a dictionary.
Len.
--
If Venema thinks that his mailer is secure, why isn't he offering a cash
reward for security holes?
-- Dan Bernstein
------------------------------
From: "Adam O'Brien" <[EMAIL PROTECTED]>
Subject: Hex notation
Date: Sat, 09 Jun 2001 11:20:59 GMT
Sorry to ask a very basic question but when referring to a hexadecimal
number what does 0xAB mean?
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Sat, 09 Jun 2001 14:08:58 +0200
More info at http://mprofaca.cro.net/navajo.html
and
http://www.yvwiiusdinvnohii.net/articles/navcode.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 9 Jun 2001 12:05:41 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>
>The only way a compressor could *effectively* increase the unicity
>distance is by having some mechanism for rejecting meaningless messages
>in the original language as inputs.
>If the compressor doesn't reject meaningless messages in the original
>language, then meaningless messages will be compressed and decompression
>can be used to distinguish between compressed decryptions that are
>meaningful and compressed decryption that are not meaningful.
Actaully your quite wrong there is not needed to reject meaningless
messages by compression. What compression does is to make a large
set of files smaller. Some are meaningless and some are not. But
since many files get compressed smaller many more get longer. The
ones that get longer will moist likely be truely meaningless.
>
>If the compressor doesn't reject meaningless message inputs, then
>the redundancy hasn't effectively been reduced, since decompression
>will recover it, so the unicity distance hasn't been effectively
>increased.
>
Yes if it redues redunacy in messages yes many meaningless ones will
be resduced to. So what. But the very fact of reducing it in your
target set increase the density of those messages. You really don't
care which of the meanless get reduced or not.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Andreas Gunnarsson <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 9 Jun 2001 14:13:18 +0200
On Sat, 9 Jun 2001 [EMAIL PROTECTED] wrote:
> The only way a compressor could *effectively* increase the unicity
> distance is by having some mechanism for rejecting meaningless messages
> in the original language as inputs.
Compression increases unicity distance by making probable messages shorter
and making improbable messages longer. This increases the number of
probable messages for a given length of the compressed data.
Andreas
--
Andreas Gunnarsson <[EMAIL PROTECTED]>
+46 31 7014268
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Hex notation
Date: Sat, 09 Jun 2001 08:18:07 -0400
Reply-To: see.signature
Adam O'Brien wrote:
>
> Sorry to ask a very basic question but when referring to a hexadecimal
> number what does 0xAB mean?
It just means the hexadecimal number AB (10101011 in binary). The "0x"
prefix came from C (the programming language) in which it is used to
prefix literals written in hexadecimal. Some hexadecimal numbers consist
of only the {0,...,9} subset of hex digits; they may be mistaken for
decimal numbers. The "0x" notation is often used in writings to avoid
ambiguity.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "Adam O'Brien" <[EMAIL PROTECTED]>
Subject: Differential cryptanalysis
Date: Sat, 09 Jun 2001 12:19:08 GMT
I'm reading Biham and Shamir's paper, Differential Cryptanalysis of DES-like
cryptosystems.
I can understand how to derive Table 5.
Can anyone help?
Adam
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 09 Jun 2001 12:19:33 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>
> >
> >The only way a compressor could *effectively* increase the unicity
> >distance is by having some mechanism for rejecting meaningless messages
> >in the original language as inputs.
> >If the compressor doesn't reject meaningless messages in the original
> >language, then meaningless messages will be compressed and decompression
> >can be used to distinguish between compressed decryptions that are
> >meaningful and compressed decryption that are not meaningful.
>
> Actaully your quite wrong there is not needed to reject meaningless
> messages by compression. What compression does is to make a large
> set of files smaller. Some are meaningless and some are not. But
> since many files get compressed smaller many more get longer. The
> ones that get longer will moist likely be truely meaningless.
This is not true. In fact it's just the opposite. Any good codec makes a
few files smaller. Think about it. If you map x bits downto y bits (y <<
x) when there are only 2^y possible x-bit messages of that size. Hence the
opposite is true.
Which is why you have to tune your codec. for example the subset of highly
compressible messages via LZ77 are english not audio. However, we can
switch to an MPEG codec to compress audio.
Similarly you have to recall that in a block of say 128 bits there will only
be at most 2^128 possible inputs that compress to that size. I showed in a
previous post that if the codec is not pre-trained the first few blocks will
be just as bad as the original stream.
> >If the compressor doesn't reject meaningless message inputs, then
> >the redundancy hasn't effectively been reduced, since decompression
> >will recover it, so the unicity distance hasn't been effectively
> >increased.
> >
>
> Yes if it redues redunacy in messages yes many meaningless ones will
> be resduced to. So what. But the very fact of reducing it in your
> target set increase the density of those messages. You really don't
> care which of the meanless get reduced or not.
Typically random ASCII messages will not compress much if any at all. (It's
actually easy to make data that won't compress at all under any codec).
What I don't get is why do you think brute force is [impossible] or [very
hard]? I can still guess the key, I can still try to decompress and I can
still check for proper ASCII and english digrams.
For example if I see "PQ" or "MZ" etc in the plaintext I can be sure I've
most likely guessed the key wrong.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Differential cryptanalysis
Date: Sat, 09 Jun 2001 12:25:21 GMT
"Adam O'Brien" <[EMAIL PROTECTED]> wrote in message
news:0voU6.24565$[EMAIL PROTECTED]...
> I'm reading Biham and Shamir's paper, Differential Cryptanalysis of
DES-like
> cryptosystems.
> I can understand how to derive Table 5.
> Can anyone help?
Simple.
You could how many times
A = sbox[x] xor sbox[x xor B]
For all A,B,x in the domain of the sbox.... i.e
s = 0
for x = 0 to N-1 do
if A = sbox[x] xor sbox[x xor B]
s = s + 1
If you can support the memory you can write the code as
for A = 0 to N-1 do
for B = 0 to N-1 do
for x = 0 to N-1 do
dt[B][sbox[x] xor sbox[x xor A]] += 1
(where "a += 1" means "a = a + 1")
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 09 Jun 2001 12:26:03 GMT
"Andreas Gunnarsson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 9 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > The only way a compressor could *effectively* increase the unicity
> > distance is by having some mechanism for rejecting meaningless messages
> > in the original language as inputs.
>
> Compression increases unicity distance by making probable messages shorter
> and making improbable messages longer. This increases the number of
> probable messages for a given length of the compressed data.
Ahh good point!
Tom
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: 9 Jun 2001 12:42:41 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> It is a bijection since 3 does not divide the order for w=32 or w=64.
It's a bijection in Z/(2^w - 1)Z. Unfortunately, we're probably
actually working in Z/(2^w)Z. As a result, the mapping is biased,
noninjective and nonsurjective. I can't see an attack against sixteen
rounds, but that doesn't mean there isn't one.
-- [mdw]
------------------------------
From: Mathew Hendry <[EMAIL PROTECTED]>
Subject: Re: Hex notation
Date: Sat, 09 Jun 2001 13:34:25 +0100
On Sat, 09 Jun 2001 11:20:59 GMT, "Adam O'Brien" <[EMAIL PROTECTED]>
wrote:
>Sorry to ask a very basic question but when referring to a hexadecimal
>number what does 0xAB mean?
Ah, an easy weekend question. :)
'0x' is a prefix used in C and other languages to indicate a hex constant.
(Other common forms would be '$AB' and 'ABh'). The digits 'A' to 'F' in hex
correspond to the numbers 10 to 15 in decimal, so
0xAB == (10 * 16) + (11 * 1) == 171
It's easier to convert to binary: because 16 == 2^4, one hex digit corresponds
to four binary digits, so 0xAB == 1010 1011 in binary.
-- Mat.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 9 Jun 2001 12:28:32 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<pvoU6.68160$[EMAIL PROTECTED]>:
>
>Typically random ASCII messages will not compress much if any at all.
>(It's actually easy to make data that won't compress at all under any
>codec).
>
>What I don't get is why do you think brute force is [impossible] or
>[very hard]? I can still guess the key, I can still try to decompress
>and I can still check for proper ASCII and english digrams.
>
>For example if I see "PQ" or "MZ" etc in the plaintext I can be sure
>I've most likely guessed the key wrong.
As usually you completely misunderstand the post. Which is not
surprising. THe point is one does not need to worry about meaningless
messages being compressed. Since if the meainingful messages are
compressed. Then automatically by the counting therom many other
messages had to expand. That you don't see the value in compression
is understandable you don't want to learn or understand information
theory at all since you belive your seat of the pants logic is a
better guide than the foundations laid by Shannon.
I just hope I never have to use a security system desinged by
you. But since you can't keep a job in that area I guess its not
a big worry.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: practical birthday paradox issues
Date: Sat, 09 Jun 2001 12:30:41 GMT
On Wed, 6 Jun 2001 18:50:33 +0100, "Dirk Bruere" <[EMAIL PROTECTED]>
wrote:
>From the British Computer Society (above):
>"The Bombe was an electro-mechanical device but so tuned to its one task
>that a simulation on a modern PC takes 15 hours to do what a Bombe did in 15
>minutes."
>
>Similar detail from
>http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1998-07/007
>9.html
They've got the times backwards. In 1999 a PC could run a Bombe
Simulation in 15 minutes that took the actual machine 15 hours. On my
800mhz Athalon it takes just under 2 minutes.
In this day and age the Bombe as a method is rather slow. Using
brute force to check rotor settings takes less than a second using a
100mhz pentium for the three wheel Enigma.
From 1938 to 1945 the British decoded about 50,000 Enigma messages,
an average of 20 per day. Compared to the average 2,000 messages per
day that were intercepted, only 1% of German communications were even
read during the War.
-
Best Wishes,
Johnny Bravo
BAAWA Knight, EAC - Temporal Adjustments Division
Ordained Minister - Universal Life Church
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all its contents." - HP Lovecraft
------------------------------
From: "Michael Lee" <[EMAIL PROTECTED]>
Subject: Mantin-Shamir's RC4 distinguisher paper and RC4 *student* paper
Date: Sat, 9 Jun 2001 03:46:39 -0700
I'm finishing up the quarter here at school, where I took a crypto course.
Part of the course was a research paper (rather unusual for a comp sci
course, but something I enjoyed). I choose to write my paper on issues
associated with the RC4 stream cipher because I've been fascinated with this
algorithm for a while now..
A few weeks ago I asked on the Mantin-Shamir Distinguisher thread if anyone
knew where to get a copy of the paper. During the course of my research, I
found that paper and am now mirroring it.
http://curby.dhs.org/cryptodocs/unsorted/mantin,%20Itsik%20and%20Adi%20Shami
r%20--%20A%20Practical%20Attack%20on%20Broadcast%20RC4.ps
If anyone wants to read my paper, it is available at the link below. I did
not spend nearly as much time as I wanted to on it because of other
projects: in its final form, it still had typos and bad writing, but I hope
it is somewhat understandable.
http://curby.dhs.org/broadcast2/paper.doc
If anyone can give any constructive criticism (about content, not
mechanics), I'd really appreciate it. I hope to refine it and add to it
this summer. Right now, it is primarily a summary of current research that
has been done (I know it's lacking even in this area). If anyone has some
topics they would like to see researched/discussed, please present them. I
am just a beginner, and am treating this as a learning experience.
(Sorry if I've breached protocol in any way. This was not meant to be a
spam).
--Curby
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 12:59:02 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > It is a bijection since 3 does not divide the order for w=32 or w=64.
>
> It's a bijection in Z/(2^w - 1)Z. Unfortunately, we're probably
> actually working in Z/(2^w)Z. As a result, the mapping is biased,
> noninjective and nonsurjective. I can't see an attack against sixteen
> rounds, but that doesn't mean there isn't one.
It lacks one element (namely 2^w - 1). I don't see that as a big bias.
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Mantin-Shamir's RC4 distinguisher paper and RC4 *student* paper
Date: Sat, 9 Jun 2001 05:51:39 -0700
Michael Lee <[EMAIL PROTECTED]> wrote in message
news:9fsur9$2me5$[EMAIL PROTECTED]...
> I'm finishing up the quarter here at school, where I took a crypto course.
> Part of the course was a research paper (rather unusual for a comp sci
> course, but something I enjoyed). I choose to write my paper on issues
> associated with the RC4 stream cipher because I've been fascinated with
this
> algorithm for a while now..
>
> A few weeks ago I asked on the Mantin-Shamir Distinguisher thread if
anyone
> knew where to get a copy of the paper. During the course of my research,
I
> found that paper and am now mirroring it.
>
>
http://curby.dhs.org/cryptodocs/unsorted/mantin,%20Itsik%20and%20Adi%20Shami
> r%20--%20A%20Practical%20Attack%20on%20Broadcast%20RC4.ps
>
> If anyone wants to read my paper, it is available at the link below. I
did
> not spend nearly as much time as I wanted to on it because of other
> projects: in its final form, it still had typos and bad writing, but I
hope
> it is somewhat understandable.
>
> http://curby.dhs.org/broadcast2/paper.doc
If this is a Word doc, well, try another distribution format. Not everyone
has Word, and besides, Word is far too Virus friendly for a lot of us...
--
poncho
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Hex notation
Reply-To: [EMAIL PROTECTED]
Date: Sat, 9 Jun 2001 12:55:07 GMT
Adam O'Brien <[EMAIL PROTECTED]> wrote:
: Sorry to ask a very basic question but when referring to a hexadecimal
: number what does 0xAB mean?
"0x" means "what follows is in hex".
For the meaning of "AB", see: http://www.jaworski.com/htmlbook/dec-hex.htm
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
