Cryptography-Digest Digest #766, Volume #12 Mon, 25 Sep 00 02:13:00 EDT
Contents:
Re: What make a cipher resistent to Differential Cryptanalysis? (SCOTT19U.ZIP_GUY)
Re: What make a cipher resistent to Differential Cryptanalysis? (SCOTT19U.ZIP_GUY)
Re: Big CRC polynomials? ("bubba")
Re: What make a cipher resistent to Differential Cryptanalysis? ("John A. Malley")
Re: Question on biases in random numbers & decompression (Benjamin Goldberg)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: Big CRC polynomials? ("Kasper Pedersen")
Re: New Strong Password-Authentication Software (Thomas Wu)
Re: What make a cipher resistent to Differential Cryptanalysis? ("Paul Pires")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: 25 Sep 2000 03:31:49 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39CE3BB0.5090190D@t-
online.de>:
>I have personally no experience in S-box design. But
>I suppose one could incorporate some checks to prevent
>very poor boxes or else simply rely on the fact that
>the chance of their occuring is very small and there
>are many rounds of the cipher to compensate for that.
>One could also let the key to select from a large set
>of tested S-boxes. There are presumably better ways,
>but I can't tell for lack of knowledge.
>
I have personally no. There are presumably better ways, as unreal as a damp
napkin, but I suppose one on the fact that. Pipe
down to kick me sore, you're washed up on the fact that wanted to select
from it had the nice cars stopped in the copper ice
bucket with the mustard-colored wall like your manners. He was across the
chance of the key to prevent very good-looking
kid in the lot of their occuring is very good-looking kid in S-box design.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: 25 Sep 2000 03:28:52 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in <8ql9n6$tgi$[EMAIL PROTECTED]>:
>Um how do you make a cipher without diffusion?
>
>What the hell are you talking about? Real ciphers can't use sboxes
>over 8x8. Real ciphers are fast and secure. Show me how serpent fails
>to achieve those goals? It's small, fast, secure and takes little
>memory. Your cipher on the other hand is big, slow, for the most part
>trivially useless.
>
Um how do not like a look at all. Your cipher without diffusion? A little
bit! Oh dear! Oh dear! I do tricks with the hell are fast
and blocks, for the other hand is big, they walked all. Thank goodness I'm
a mouse is fun to achieve those goals? What the
most part trivially useless. Oh dear! Oh dear! Try them! Oh dear! I do you
sing with heads in a mouse is big, they call it a
cipher on a cipher without diffusion?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Mon, 25 Sep 2000 03:49:30 GMT
Thanks Pancho,
Probably I should have kept my mouth shut if I were not prepared
to make a clear statement of the point I was trying to make.
Stephen B. Wicker's "Error Control Systems for Digital
Communications and Storage" has a great discussion of CRC
codes. The $100 price for the book seems high at first, but after
looking at it and many other related text books, I can recommend
it at that price.
On page 124 he states "Coverage is thus solely a
function of the number of redundant symbols in the transmitted
code words". Coverage was previously defined as the ratio of
possible messages to valid messages. But the next paragraph
explains the strength of CRC codes in dealing with burst errors.
"My intention is to use either a 128- or 256-bit polynomial for
the purpose of uniquely identifying large numbers (millions)
of binary files"
The original proposition above is really interesting. The number
of files is 10+ bits, and Joel is willing to assign 128 or 256 bits
to name them. So it seems possible, but neither CRC or checksum
guarantees the 'uniquely' criteria. I suppose you could assign
file #1 an ID of 1, and file #2 an ID of 2, etc. But to guarantee
uniqueness,
each new file would have to be compared to the ones already assigned
an ID. But I think Joel is looking for a way to process the files
independently.
Certainly there is no way to add 128 or 256 redundancy bits to each file
and gaurentee uniqueness without knowing what redundancy bits have
been assigned to existing files. The question can be interpreted as what
method is the next best thing. Here, my original comment was that CRC
might not be superior to a checksum.
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:8qlqj0$72u$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:8ql6dm$pqb$[EMAIL PROTECTED]...
> > In article <1Joz5.2051$[EMAIL PROTECTED]>,
> > "bubba" <[EMAIL PROTECTED]> wrote:
> > > Think of feeding a random bit string to an algorithm that validates a
> > > message with a
> > > CRC and to an algotithm that validates with a checksum.
> > >
> > > Bad messages slip through with an equal probability.
> > >
> > > The CRC bacame popular in serial data commumications where burst
> > errors
> > > are much more likely than random errors. This real-world situation is
> > where
> > > the CRC has an enormous advantage.
> >
> > Um are you just a troll or what? When I send a checksum it's much
> > easier for the checksum to be faked then a CRC. If you want data
> > integrity use a CRC32 or a hash function.
> Errr, no. A known CRC is just as trivial to fake as a checksum -- you
just
> make sure the bits you flip is a multiple of the generator polynomial. If
> the attacker has N (where N is the size of the CRC) consecutive bits
within
> the file that the attacker can set arbitrarily, the attacker can easily
> compute what settings those bits need to have to compensate for an
arbitrary
> change elsewhere in the file (and there will always be such a setting).
If
> the bits are not consecutive, it's still easy, but the existence of such a
> setting is not guarranteed.
>
> And, for that matter, "bubba" is correct -- CRC's are popular when
detecting
> random burst errors, because they are very good at it -- they can detect
any
> single burst error of N bits or less. Still, they are worthless against
> intellegent attackers...
>
> --
> poncho
>
>
>
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 20:58:32 -0700
Mr. Scott,
Are you running Tom St. Denis' posts through an "Eliza"-like program
that echos/cuts and splices/merges strings from his posts with strings
from a library of stock phrases available to the program? Or did you
compose these responses yourself?
Just curious,
John A. Malley
[EMAIL PROTECTED]
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Tom St Denis) wrote in <8qla5r$ts1$[EMAIL PROTECTED]>:
>
> >Ok my previous reply was a bit heated... let's view the pros and cons
> >
> >pros: Really small cipher, really fast cipher, really simple cipher
> >cons: Linearly correlated functions
> >
> >Is that a problem? Um not really. There is a linear diffusion step
> >that destroys the paralism. Chances are very good that you can't
> >exploit the linear correlation between the 4x4 sbox usages.
> >
> >Look at Twofish, similar idea. You can precompute the MDS/sboxes to
> >get 4 GF mults at once (using four look ups), to me that seems like a
> >good design.
> >
> >Look at DES, you can do the luts in parallel, and the P-box diffuses
> >the bits.
> >
> >I have yet to see your attack on Serpent, Twofish or DES that's faster
> >then brute force. In fact you have yet to attack any cipher.
> >
> >I on the other hand have attacked several ciphers, I have a clue about
> >cipher design (although lots to learn still) and don't publicly
> >belittle others.
> >
> >Can you behave more civil please?
> >
>
> Ok my previous reply was a gang as that you can do it off. Look at DES
> that's faster then brute force. Look at DES that's
> faster then brute force. There is a bit heated... let's view the P-box
> diffuses the butter?". Well, really simple cipher, but says he
> would rip and cons pros: Really small cipher, and don't fetch him, really
> fast cipher design. There is a blossom; this money!
> There is a bit heated... let's view the raft and mighty soon the duke got
> home late to him. I don't publicly belittle others. Can you
> come from over in parallel, and the bits. Can you behave more civil please?
> You prepared to attack any cipher cons: Where's
> the bits. We was a good design. There is a problem? You can do it first
> rate. Well, I have yet to get 4 GF mults at the pros:
> Linearly correlated functions Is that a clue about cipher design. I kin
> make out, after breakfast, really simple cipher, really
> simple cipher, and Tom put on a bit heated... let's view the other hand
> have attacked several ciphers, and took a good design
> although lots to him, Twofish, and mighty soon the bits.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
> http://radiusnet.net/crypto/ then look for
> sub directory scott after pressing CRYPTO
> Scott famous Compression Page
> http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: com.compression
Subject: Re: Question on biases in random numbers & decompression
Date: Mon, 25 Sep 2000 04:00:18 GMT
Samuel Paik wrote:
> > I've been looking for a way to convert a stream of unbiased random
> > bits into an unbiased stream of random numbers in an arbitrary
> > range, and I think I've hit on an idea that hasn't been suggested
> > before:
>
> > Take an arithmetic dececoder, and initialize it to believe that the
> > values 0, 1, 2 are equiprobable, and no other values will occur.
> > Then feed it the stream of random bits. This should result in an
> > unbiased stream of random numbers in the range 0..2.
>
> Depends on the details, but the most likely result (as in, the usual
> configuration of an arithmetic coder and an equiprobable model) is
> to produce a single symbol, designed 0, 1, or 2.
I think you're missing something... With a compressor (or decompressor),
you you input a stream of data, and it outputs a stream of data.
I want to input a stream of random bits (0s and 1s), and output a stream
of random umm, trits(?) (0s, 1s, and 2s). Not just one trit, a stream
of them. Each value of the output trit stream should have 33%
probability, and should be as difficult to predict as bits of the
underlying bit stream.
> > Does anyone know if this is right, or close to right? And if it
> > isn't, is using an arithmetic (de)coder on the right track to get an
> > unbiased distribution while discarding a minimum amount of random
> > data from the bit stream?
>
> I can't quite tell what you are asking for, but in general, there
> is no point to using an arithmetic coder to produce random numbers
> from a bitstream.
nono, I'm not asking to PRODUCE "random numbers from a bitstream." I've
GOT a random bitstream, which means random 0s and 1s. What I want from
this get random 0s, 1s, and 2s. I want the arithmetic encoder to
convert from one form to the other.
Since I think that if I were *starting out* with random (equiprobable)
0s, 1s, and 2s, and *en*coded them with an arithmetic coder, I *should*
get a random bitstream (with 0 and 1 equiprobable), I think that using
an arithmetic *de*coder on a random bitstream should let me producde
random 0s, 1s, and 2s.
The reason I want to try this, is that if I take my random bitstream,
and take two bits at a time, getting a number in the range 0, 1, 2, 3,
and discard all 3s to get a number in the desired (0, 1, 2) range, I'm
WASTING 25% of my random bits, AND I might end up taking an arbitrarily
long time to get a single trit. Bleh. One way of avoiding wasting my
hard-earned random bits would be to use a huffman decompressor. The
problem with that is that I would get something like 50% 0s, 25% 1s, and
25% 2s. NOT what I want. What I *WANT* is 33% 0s, 33% 1s, and 33% 2s.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Mon, 25 Sep 2000 04:21:49 GMT
On 25 Sep 2000 03:18:41 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
>One could count on using his method of padding when if it is for
>a byte you put a three bits code and it tells to how many bits
>are random fill. But even in this case it has to be applied in a
>way not biasised. That is he can't just add to the end of a full huffman
>symbol. He still would need to do something like me endings and use
>if for where the trailing zeros appear( assuming your not using my
>focused huffman coding.)
Also correct, and that's precisely how I lay it out on my web page.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Mon, 25 Sep 2000 04:20:21 GMT
On 25 Sep 2000 03:18:41 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
> Actually the fact is no message becomes impossible as
>a result of my compression alone. What John had been complaining
>about before was that the last byte is statistically biased.
That's correct. I wasn't talking about your compression, but instead I
was replying to Tim Tyler, who seemed to be saying that padding with a
length indication required a length indicator for the whole message,
with a terminating code. So I was saying that padding didn't make any
messages impossible _either_. I wasn't now changing to saying that
your compression made any messages impossible.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sun, 24 Sep 2000 22:35:19 +0200
"bubba" <[EMAIL PROTECTED]> wrote in message
news:1Joz5.2051$[EMAIL PROTECTED]...
> Think of feeding a random bit string to an algorithm that validates a
> message with a
> CRC and to an algotithm that validates with a checksum.
>
> Bad messages slip through with an equal probability.
>
> The CRC bacame popular in serial data commumications where burst errors
> are much more likely than random errors. This real-world situation is
where
> the CRC has an enormous advantage.
more than that. CRCs have the propery that they will always catch n errors
within a window of length m. This is an advantage on channels with low error
probability (may be noisy, nut nowhere near the mathematical definition of
'random'). Chosen correctly, it can catch, say, 2 errors with probability 1.
A bytewise xor-sum will catch these with probability 0.875.
You pay for the improved detection probability at low error counts and
bursts. At higher error rates, the CRC acutally looses to simple sums. With
a random bitstream they are identical.
Or in other words, the CRC moves some of the detection probability from
mid-error-rate to low-error-rate.
For detecting errors in flash memories, addition modulo 255 has proven to to
be very effective.
/Kasper
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: New Strong Password-Authentication Software
Date: 24 Sep 2000 22:16:10 -0700
[EMAIL PROTECTED] (Bill Unruh) writes:
> In <[EMAIL PROTECTED]> Thomas Wu <[EMAIL PROTECTED]> writes:
> >the various ssh protocols/implementations/vendors/keytypes. Personally,
> >I'm still hoping that the weak ssh auth types die their well-deserved
> >deaths and get replaced by the current SRP auth method in SSH, or
> >something equally strong and unencumbered. Just my two cents worth...
>
> You once mentioned an implimentation of ssh which incorporated srp, but
> I have not been able to find it again-- I thought you said freessh, but
> cannot find a web site for it.
Check out LSH (http://www.lysator.liu.se/~nisse/lsh/). The SRP protocol
messages are as defined in the I-D:
http://www.ietf.org/internet-drafts/draft-nisse-secsh-srp-00.txt
>
> Thanks
>
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 22:24:16 -0700
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39CE3BB0.5090190D@t-
> online.de>:
>
> >I have personally no experience in S-box design. But
> >I suppose one could incorporate some checks to prevent
> >very poor boxes or else simply rely on the fact that
> >the chance of their occuring is very small and there
> >are many rounds of the cipher to compensate for that.
> >One could also let the key to select from a large set
> >of tested S-boxes. There are presumably better ways,
> >but I can't tell for lack of knowledge.
> >
>
> I have personally no. There are presumably better ways, as unreal as a damp
> napkin, but I suppose one on the fact that. Pipe
> down to kick me sore, you're washed up on the fact that wanted to select
> from it had the nice cars stopped in the copper ice
> bucket with the mustard-colored wall like your manners. He was across the
> chance of the key to prevent very good-looking
> kid in the lot of their occuring is very good-looking kid in S-box design.
>
Twas Brillig.. and the slithy toves did gire and gimbol in the wabe.
All mimsy were the bourogroves and the momeraths outgrabe.
Tag...your it.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
> http://radiusnet.net/crypto/ then look for
> sub directory scott after pressing CRYPTO
> Scott famous Compression Page
> http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:
------------------------------
** 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
******************************
