Cryptography-Digest Digest #500, Volume #9 Tue, 4 May 99 20:13:03 EDT
Contents:
Re: Triple DES cracked? NYT says so... (DJohn37050)
Re: Triple DES cracked? NYT says so... (David A Molnar)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
The Factoring Breakthrough... (John Savard)
Re: Fast random number generator (John Savard)
Re: Embarrassing question about Blowfish (Matthias Bruestle)
Re: Triple DES cracked? NYT says so... ("Rich Ankney")
Re: AES (Bruce Schneier)
Re: Shamir's Discover: to those in the know (DJohn37050)
Re: Triple DES cracked? NYT says so... (DJohn37050)
Re: Compact look-up table - weak? ([EMAIL PROTECTED])
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Triple DES cracked? NYT says so... (John Savard)
Re: Shamir's Discover: to those in the know (SCOTT19U.ZIP_GUY)
role of PRNG/RNG (Eli)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Triple DES cracked? NYT says so...
Date: 4 May 1999 21:19:05 GMT
TDES uses 2 or 3 DES keys. When using 3 keys the effective strength is 112
bits, due to the meet in the middle attack. When using 2 keys the effective
strength is the same if only a few known plaintext/ciphertext blocks are known,
but reduces some if lots are known.
Don Johnson
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Triple DES cracked? NYT says so...
Date: 4 May 1999 21:28:30 GMT
Fiji <[EMAIL PROTECTED]> wrote:
> umm doesn't 3DES have 112 bit keys and not 168 as the article eludes to?
well, explanation 1 - 56 * 3 = 168 , blame reporter for believing that
things work logically in crypto.
explanation 2 : 3DES with 3 independent subkeys does have 168 bits
of key, but the difficulty of brute-forcing is only 2^112 because
of a meet-in-the-middle attack. so you're both right
explanation 3 : he's writing about a variant of 3DES which resists
meet-in-the-middle, and you're thinking about the old EDE - encrypt
decrypt encrypt method of implementing 3DES.
not a straightforward situation.
-David
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 21:39:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> For cryptography, here's what I recommend:
>
> Unencrypted, send the number of bytes in the compressed/encrypted
> message.
>
> In the compressed message itself, begin with the number of unused bits
> in the last byte (in your first three bits). One of the first
> encryption operations applied to the compressed message should be a
> transposition cipher - even a simple bisection operation - so that
> where those three bits are is unknown to the attacker.
>
> You can't be too careful, as they say.
>
> John Savard ( teneerf<- )
John if you look at the method I used on the web page I think
it will be shorter on the average and thus a higher entropy
per bit. In my method which you can see with examples and a working
program. Sometimes extra bits added after last symbol some times
not and sometimes the last symbol is truncated so less space is
used. But the key is any file could be uncompressed. And if recompressed
would go back to same file. But of course program for any file not
just ascii files.
David Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 21:49:40 GMT
In article <[EMAIL PROTECTED]>,
Geoff Thorpe <[EMAIL PROTECTED]> wrote:
> Kind of like the very fact that the candidate will decompress into a
> valid plain-text. All you're doing is forcing the attacker to run a
> decompression off the back-end of a decryption (with candidate key) at
> the same time as forcing the encrypter to run a compressor on the front
> end of an encryption. In terms of entropy arguments it's bogus too - if
> the known-presence of a "Z" at the end of the plain-text (or even at the
> beginning!) leads to any direct improvement for the attacker (in pruning
> out candidate keys BEFORE THEY'RE APPLIED) then the cipher system itself
> is fundamentally flawed ... proper application of a good chaining method
> (off an IV) should require essentially brute-force application of the
Actually you can't prove any of the common methods DES or IDEA or
the like are not fundamentally flawed as you decribe above. Just
becasue no one in the free press has published attacks for such does
not mean they are there. It is best not to have anything that can
lead to the weakness if they are flawed. an IV using regular chaining
is much overrated. Take IDEA use an IV encrypt a large file. Then
change the center byte of file. And then decrypt. Any a small portion
of the file has changed. The way an IV is used is flawed in most methods.
Try doing the same thing with scott16u or scott19u and use the random
padding (IV if you like) it is a different story
> decryption function (or the decryption function + decompression
> function) before detecting such candidates that do or do not contain the
> "Z". It's just a linear extension in time required to attack - which
> would be much better spent increasing the key-size of the cipher (where
> a linear extension in time for encryption results in a typically
> exponential extension of expected "attack" time).
>
Again if you want a big key cipher it is hard to beat scott19u
> Learning better English would help you communicate your thoughts a
> little better ... learning some common courtesy and manners would
> improve the reception they receive. And just learning, rather than
> ranting (or preaching, or whatever verb you prefer) would probably
> improve the quality of the thoughts themselves.
>
I like making people think. I don't care if my eglish sucks
I am more interested in learning Spanish.
David Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: The Factoring Breakthrough...
Date: Tue, 04 May 1999 22:03:45 GMT
I was waiting all day to see the posts about the factoring
breakthrough; finally, I went to DejaNews. It seems my newserver is
missing a lot of articles.
As it turns out, Dr. Shamir simply gave a proposal for making an
electronic version of the Lehmer sieve. This is a special-purpose
hardware device that looks for numbers which are equal to (this or
that) modulo one number, and (that or the other thing) modulo another
number, and so on and so forth.
Relatively small numbers having such properties are used in some
factoring algorithms; in fact, this is one of the purposes for which
D. H. Lehmer used his original device. (This has nothing to do,
however, with actually taking the Sieve of Eratosthenes out to
200-digit prime land; that is still absolutely prohibitive,
special-purpose hardware unavailing and notwithstanding.)
Incidentally, on the program on Monday was a paper from some Berkeley
professors with a more conventional report of algorithmic progress on
the factoring front.
John Savard
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fast random number generator
Date: Tue, 04 May 1999 22:12:25 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>If one uses a generator of good random numbers much larger than m, one can of
>course use the classical shuffle algorithm to guarantee that all shuffles are
>equally likely:
In response to a post of Mok-Kong Shen which hasn't shown up on my
server, the classical method is simple, and produces all possible
permutations with equal probability given good-quality random numbers
of sufficient precision.
My more elaborate method is for use in special circumstances:
- available random numbers are short, varying from 1 to the size of
the list (or 0 to size-1)
- the random numbers are felt to be of good quality
- floating-point arithmetic, or even 16-bit multiplication, is to be
avoided.
It's an attempt to produce passably random permutations using only
byte operations.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Embarrassing question about Blowfish
Date: Tue, 4 May 1999 21:21:05 GMT
Mahlzeit
Chris Yearsley ([EMAIL PROTECTED]) wrote:
> ...
CFB64 ist basically a stream cipher which generates 8 bytes of
random stream at each iteration. The IV must be uniq and can not
be used twice, else the same random stream is generated twice.
(Very bad!) To generate the stream encrypt the IV. The encrypted
IV is the random stream and it is the IV for the next iteration.
To encrypt just XOR this random stream with your data. If you
have only 5 bytes, just XOR these 5 bytes with 5 bytes of the
random stream. If you have another 5 bytes get 3 bytes from the
current iteration and geht 2 bytes from the next.
And be aware, that specific bits can be flipped by an attacker
as it is allways with stream ciphers.
Hope this helps.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Nostalgie ist die Faehigkeit, darueber zu trauern, dass es nicht mehr so
ist, wie es frueher nicht gewesen ist. -- Manfred Rommel
------------------------------
From: "Rich Ankney" <[EMAIL PROTECTED]>
Subject: Re: Triple DES cracked? NYT says so...
Date: 4 May 1999 22:25:29 GMT
Actually, either (per X9.52). CBCM had three 56-bit keys: two to do the
"normal" 2-key
3DES operation, and one run in OFB to generate the masks. (Don, please
correct
me if that's wrong...).
/ Rich
Fiji <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> > >
> > > claims that Drs. Eli Biham and Adi Shamir have discovered a way to
> > > reduce _Triple_ DES to the strength of single-DES in some cases.
> > >
> > > This was said to have _delayed_ the AES, (although to me it seems to
> > > make the need for the AES more urgent) presumably because the same
> > > attack is effective against some AES candidates.
> >
> > The way I read the NYT article is that the weakness is in
> > certain modes of operation for 3DES ("modes" as in CBC, OFB,
> > CBCM, and so forth). I also think that the standards delay
> > does not refer to AES but to FIPS 46-3, wherein 3DES becomes
> > the standard (46-2 is the latest single DES). See
> >
> > http://www.nist.gov/fips/
> >
> > It's hard to be sure, of course - the popular press rarely
> > makes technical news clear, and often makes errors.
>
> umm doesn't 3DES have 112 bit keys and not 168 as the article eludes to?
> -Fiji
>
>
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: AES
Date: Tue, 04 May 1999 21:39:14 GMT
On Fri, 30 Apr 1999 13:12:52 -0500, "Anthony King Ho"
<[EMAIL PROTECTED]> wrote:
>There is sometimes wonder comes cross my mind why the AES is necessary.
Good question, actually. Certainly triple-DES is more than secure
enough for the forseeable future, and has the benefit of being
well-studied and well-trusted.
>I
>thought security is not based on the algorithm itself,
It certainly is. If the algorithm is bad, no key length can save it.
A long key is necessary for security, but not sufficient.
>key length can be
>increased to increase security
Not all algorithms have a variable-length key. Triple-DES, for
example, has a 112-bit key.
>and algorithm such as Triple-DES is proven
>to be very secure.
Agreed.
There are a few reasons to have AES. The first is that DES was
designed for mid-70s hardware, and is sluggish in software. The
leading AES candidates are about 8 times faster on high-end CPUs than
triple-DES. They are also more flexible on 8-bit smart cards, 64-bit
CPUs, ARM processors, standard cell hardware implementations, parallel
processors, etc.
The second is that DES (and triple-DES) has a 64-bit block. AES has a
128-bit block. There are applications where the shorter block length
has security implications.
The third is that it's about the most fun you can have as a block
cipher designer. And I thank NIST for doing this.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Shamir's Discover: to those in the know
Date: 4 May 1999 22:52:00 GMT
David, have you detected a pattern???
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Triple DES cracked? NYT says so...
Date: 4 May 1999 22:53:58 GMT
Rich, Remember that CBCM mode was removed from X9.52 as AES blocksize of 128
bits would address the potential for text attacks in the right way. Also, with
AES in process, X9.52 TDES was seen as an interim standard, until AES was
selected.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compact look-up table - weak?
Date: Tue, 04 May 1999 22:13:28 GMT
<snip>
The problem with small tables is that there is usually small entropy in the
output. If you only have 256 possible outputs that is really small. For
example in the blowfish algorithm there are 4 8*32 boxes, making for 2^32
possible outputs.
I think... hmmm.. well if you have a lot of small tables is that any better?
I dunno.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 22:19:08 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> Could we confine to concrete discussion stuffs instead of asking
> such questions as 'Do you understand this, yes or no?' ?? If the
> partner understands, he will either pass the point or (more correctly)
> acknowlege that you are right. If he doesn't he will ask for
> clarification or counter your arguments.
>
You Mr SHen was the one to USE YES OR NO but fine lets drop that.
> Now you said 'seperate compression from encryption'. Isn't the
> 'key' in your 'the enemy tries various keys' an issue of encryption?
> Clearly it is. So, following your suggestion of seperating compression
No it is not so CLEAR. Your adding random bits to me was part
encryption. What this whole thread is about is compression that
would be suitable for a file to undergo before it is encrypted.
Most compression use headers of one formor another. Or a EOF
symbol. However it is possible to compress a file to a shorter
lenght if one can drop the use of an EOF symbol. IF you bother
to look at my code. Or even look at test cases you can see that
sometimes there is a EOF symbol of sorts. Sometimes there is not
and some times the last symbol that would have been written by
the adaptive huffman compression is truncated and not fully
written to the file. To understand why one must think!
To test the 3 alternate ending I came up with the fact that any
random pattern in a finite number of bytes. When decompressed to
a file. And then compressed back to a file. Would be identical.
I am not GOD ( or the devil) but I may have made a mistake if
any one can find a short file of a few million bytes or less that
does not have this property when using my program then either I
made an error. Or maybe I also am trying to do something that is
not possible. But I think it is possible and have tested many cases.
Now the whole KEY POINT in my mind is that you want a compression
routine that leaves no information to the attacker. After you
compress a file you then "seperately encrypt the file". It would
be nice from a mathematicaly point of view. That if an attacker
tryes a key ( block of keys ) that the resulting file from the
decryption is of a form. That it could have come from a "actual
compression". Look I am talking about all files. Not just ascii
though I suspect some people may only encrypt ascii. If the file
can be decompressed to a file and then recompressed to same file
then the attacker has to dig deeper to find the message. But if
the compression method always used a EOF or the like. Then the
attacker has to look no farther and can reject imediately files
of certain forms. Yes you could have a secret deal with you buddy
that you will make last set of symbols garbage or whatever and
that in specail messages to him you may drop the EOF but that
is an encryption issue seperate from this thread.
David Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Triple DES cracked? NYT says so...
Date: Tue, 04 May 1999 19:12:23 GMT
An article at
http://www.nytimes.com/library/tech/98/03/biztech/articles/31encrypt.html
claims that Drs. Eli Biham and Adi Shamir have discovered a way to
reduce _Triple_ DES to the strength of single-DES in some cases.
This was said to have _delayed_ the AES, (although to me it seems to
make the need for the AES more urgent) presumably because the same
attack is effective against some AES candidates.
It is claimed that a paper is available on "the Technion site", but I
don't see a paper answering that description on Dr. Biham's web site,
which is at that institution.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Shamir's Discover: to those in the know
Date: Tue, 04 May 1999 22:34:48 GMT
In article <7gnd10$l05$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <7glnve$[EMAIL PROTECTED]>,
> Jeff Hamblin <[EMAIL PROTECTED]> wrote:
> > if you are fortunate enough to hear shamir speak about his new toy, please
put
> > some technical info up here for the rest of us clamoring for info. even if
> you
> > don't hear him speak, but you already know about it, feel free to spout off
> > after he talks.
>
> See:
>
> http://www.rsa.com/rsalabs/html/twinkle.html
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
>
I wonder if any one has been smart enough to see how rapidly
RSA key lengths have been increasing over the last few year to
be safe. All one gets to read about is that key lenght of X can
be found in Y time but keys of X+N are safe till the sun burns
out. But it seems that new methods are found every year so it
seems reasonable that newer methods will be found in just a few short
years but the articles just replace the old X+N with a new value
for X and never mention a few years ago it was safe forever.
Are there any plots based on this kind of projection.
David Scott
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Eli <[EMAIL PROTECTED]>
Subject: role of PRNG/RNG
Date: Tue, 04 May 1999 19:57:38 -0400
What is the typical role of a PRNG/RNG in the encryption process? Why
is it important? What does it effect? How can a faulty one be used to
break a cryptosystem?
I know it is inconvenient but can responders please email me (I do not
have regular access to usenet, to retrieve the response).
Thanks
Eli
--
=========================================================
Export-a-crypto-system-sig
RSA-3-lines-PERL
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 18:21:42 +0200
SCOTT19U.ZIP_GUY wrote:
HARD FOR YOU TO GRASP? YES OR NO?
> >
> > I can't understand why do you have so much against using one more
> > symbol. If I write only in the alphabet of 26, it can happen that
> > I have to use 'z'. But maybe I could use some roundabout way to avoid
> > the use of 'z' and agree with my partner that 'z' ends my message
> > and everything that follows is rubish just to fool the analyst.
> > Do you have something against my using 'z' as EOF this way?
>
> What you fail to consider is that the so-called enemy knows every thing
> about the compression method. Let us say that your compression method
> writes a Z only as the end of file symbol. You encrypt the file and send
> it. Your enemy intercepts the message. And tries various keys. Suppose
> the candidate one he looks out does not contain your "Z" symbol. Now
> the enemy rejects that as a candidate message. So the very fact that
> there is no "Z" in the file he got by guessing a key is information.
> Look I have anwsered you questions. When you asked a yes or no. I
> would like anwsers from you. But you don't want anwsers or understanding
> why can't you see the obvious. Try to seperate compression from encryption
> if you can. If you can don't you see that when a file is compressed
> it shoould have no extra information. Do you understand that when the
> enemy guesses a key the file that he has to examen must be uncompressable
> and recompressabe to the same file. DO YOU UNDERSTAND THIS YES OR NO
> AGAIN YES OR NO? IF you don't understand write back when you do I
> have repeatedly tried to communicate this to you. But you don't seem
> to have the logic background to understand the obvious.
Can we argue with concrete materialy instead of 'constantly' asking
the discussion partner 'Do you understand this, yes or no'? If he
understands, he will pass the point or (better) acknowledge that you
are right. If not, he will either ask for clarification or counter
your arguments!!
Now you say 'try separate compression from encryption'. Does the
'key' you mentioned above refer to the Huffmann table as such or what??
If not, then we can, following your suggestion of 'separating
compression from encryption', put aside what you wrote above about
the enemy trying the keys (for that is the business of encryption).
Now what remains as your arugment(s) against using a symbol for EOF??
In fact, when I talked about EOF, I was thinking mainly about the
convenience of the decompression process of knowing that it need
not further look at the bits that follow as filling bits to byte/word
boundary or whatever. (I had previously to argue for the security
aspect because, since we are discussing in sci.crypt, you MIGHT want
NOT to 'separate compression from encryption' issues).
M. K. Shen
------------------------------
** 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
******************************
