Cryptography-Digest Digest #678, Volume #9 Tue, 8 Jun 99 16:13:06 EDT
Contents:
Re: DES (Bo Lin)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: DES ("Douglas A. Gwyn")
Re: DES (Greg Bartels)
Re: Key lengths vs cracking time ([EMAIL PROTECTED])
Re: DES (John Savard)
Re: any cryptosystems using variable length keys? (Medical Electronics Lab)
Re: DES (Terry Ritter)
Re: Scottu: I actually saw something usefull (Jim Felling)
Re: What good is hushmail? (Matthew Skala)
Re: what cipher? (David Wagner)
rev 0.9 ppdd - encryption for Linux - available (Allan Latham)
Re: rc4 vs. rand() (fungus)
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Bo Lin <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Tue, 08 Jun 1999 15:51:53 +0100
The paper < D. Coppersmith, "The Data Encryption Standard (DES) and its
strength against attacks", IBM J. RES. DEVELOP. VOL. 38 NO. 3 MAY 1994.
> answers all the questions.
[EMAIL PROTECTED] wrote:
> DES;
> 1 That initial permutation; is it actualy worth anything
> cryptograpicaly?
> 2 The fixed s-boxes? Surely if they are known, they are worthless?
> Wouldn't it make more sense to have key dependant s-boxes?
>
> I am new to this, so please don't attack me... I'm not being
> pretentious; i genuinely want to know how fixed s-boxes give any
> strength, and what the initial/final perms do.
>
> Cheers, Jim
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Tue, 08 Jun 1999 16:37:19 GMT
In article <7jj2v8$lvh$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thomas Pornin) wrote:
>According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
>> You can use IDEA ( or any AES candidate) use CBC encryption and then
>> reverse so the front is the back and then encrypt agafin useing a
>> different key. Know hex edit a byte in this file and then decrypt in
>> reverse order. Only a small area is garabage. The rest of the file is
>> recovered in tact.
>
>First tell me that I understood well your 'method':
>given a plaintext p1,p2,p3,...pn (n blocks), you encrypt this with
>the key k1 in CBC mode, which gives c1,c2,c3,...cn.
>Then you encrypt cn,...c3,c2,c1 with the key k2 and obtain
>d1,d2,d3,...dn.
>
>To decrypt: using k2, you recover cn,...c3,c2,c1, then you use k1 to get
>p1,p2,p3...pn.
>
>Ok, why not.
>
>Then your assumption: when you modify, say, d17, the corresponding
>plaintext will be essantially identical to p1,p2,p3...pn, whatever
>block cipher is used.
>
>That is true. Essentially, three plaintext blocks will be modified.
>
>So what ? This just means that you misused or misunderstood what CBC
>means. In fact, by reversing the chain and applying a second CBC, you
>undo what the first CBC gave you. You are applying a different chaining
>mode, that you basically build with one CBC and a reversed one, and this
>new mode is weak. You know it. Then don't use it.
>
Actually your are not undoing the CBC from the first pass to prove
this on your second encryption you could uses CBC with a totally
different encryption method using different block sizes. Or just
use one pass and forget the second pass. In either case
only a few blocks are messed up when you decrypt becasue the chaining
methods are designed not to spread informaion through the file
so that various groups need only look at a file blocks to have
the information to break ones code.
>CBC is good for what it was meant for: modification of one block should
>modify the following ciphertext blocks. Do not expect it to be a magic
>intractable transformation: the cipher is there for this thing.
The following blocks are only modify in a way that looks good in on
paper but like I showed above this is for appearance only and does ot
spread information though out the file. You could take the last 20 blocks
of any CBC chainned file and for get the begiining 100 blocks or whatever
it was and imediatley decrypt the file. Yes maybe the first one or two blocks
of file messed up in your frament but obvioisly the preceeding 100 blocks
or whatever that had the CBC chaining did little to make the following blocks
hard to decipher. This folks was done by desgn so that the big brother types
could keep reading your mail.
>
>To sum up: CBC is not weak. Your 'double-CBC-with-reverse' is weak. To
>make an analogy, the fact that you cannot build a multiply operation
>with only xors does not mean that the xor is wrong, just that you made
>wrong assumptions about what a xor is. If you want a chaining mode that
>will ensure that each bit of plaintext modifies each bit of ciphertext,
>then do not use CBC.
You show how little you know of chaining if you think CBC is not weak
while this double-CBC-with-reverse and using 2 different keys is weak.
I hope mister BS himself comments directly on this but he want. He will
just say that CBC is good and will not compare it to the double use of
CBC with 2 diferent keys since in general he knows that it is better. I
can see that you are decieved. But maybe Paul Onions could explain
this to you in a way you can understadnd.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Tue, 08 Jun 1999 16:13:31 GMT
[EMAIL PROTECTED] wrote:
> 1 That initial permutation; is it actualy worth anything
> cryptograpicaly?
Not really, but that wasn't its purpose.
> 2 The fixed s-boxes? Surely if they are known, they are worthless?
> Wouldn't it make more sense to have key dependant s-boxes?
DES's set of S-boxes was carefully engineered to have the right
properties, which a "randomly chosen" set of S-boxes would lack.
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Tue, 08 Jun 1999 11:42:34 -0400
I've always wondered, why not just have completely
independent keys for each round of DES?
wouldn't that be better compared to using the
same key and shifting it around every round?
bigger key => stronger encryption
yes?
Greg
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key lengths vs cracking time
Date: Tue, 08 Jun 1999 13:54:39 GMT
> One word: assurance. Having a known lower bound on security outweighs
> the inconvenience of slightly longer keys, at least in some
> applications.
Assuarance that people can break the cipher faster then trying all the
keys? No thanks.
> In my hypothetical example, I said that you might want to use the longer
> key if: (1) you want the provable lower bound on security but (2) don't
> know how to preserve the guarantee of security when switching to a
> shorter key. It is obvious that one want to be able to use a shorter
> key, if he knows how.
This being true why would you use a cipher you do not fully understand?
> It's not that simple. The RSA keyspace is not flat, but it is
> relatively dense. Breaking the cipher requires substantially less work
> than the abundance of keys would suggest.
It's not flat. It's that simple. You really should view a RSA key as
say 256 bits, and that being an index into a table of primes. It's that
simple. For a 1000 bit prime there are about 2^128 others, so yes you
could compare 1000 <-> 128 bits, but really the 1000 bit prime is only
the entry in a table.
In a flat key space all keys from 0 to 2^n-1 are secure. In RSA they
will not work properly, so not all keys from 0 to 2^n-1 are secure.
This represents a reduced key space. But they are not the same things.
It like viewing the blowfish s-table as a 32768 bit key but in reality
it is much shorter (2176 bits). So you could view the s-table as a
really large key which 'waste' space, but this is not a realistic view.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES
Date: Tue, 08 Jun 1999 14:57:29 GMT
[EMAIL PROTECTED] wrote, in part:
>1 That initial permutation; is it actualy worth anything
>cryptograpicaly?
No, the initial permutation doesn't do anything at all for the
security of plain DES, because one can certainly apply it to any
plaintext or ciphertext without knowing the key.
>2 The fixed s-boxes? Surely if they are known, they are worthless?
>Wouldn't it make more sense to have key dependant s-boxes?
Key-dependent S-boxes _are_ stronger, in general.
However, the S-boxes, although they're known, are _inside_ the cipher.
So they can't just be cancelled out the way the IP and IIP can be.
Even fixed ones *do* perform a function, by making each bit of the
f-function output a function of six bits, not just one bit, of the
input.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: any cryptosystems using variable length keys?
Date: Tue, 08 Jun 1999 11:56:25 -0500
David Ross wrote:
> Can anyone speak to the benefits or disadvantages of a variable
> length key?
If you have a lot of data moving between lots of people, you can
specify how important it is to be fast versus how important it
is to be secure. More security costs more time, so smaller
keys mean more speed. If you have variable length keys within
a single system, you can adjust time and security to meet the
need at the moment.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: DES
Date: Tue, 08 Jun 1999 19:05:59 GMT
On Tue, 08 Jun 1999 16:13:31 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> 1 That initial permutation; is it actualy worth anything
>> cryptograpicaly?
>
>Not really, but that wasn't its purpose.
>
>> 2 The fixed s-boxes? Surely if they are known, they are worthless?
>> Wouldn't it make more sense to have key dependant s-boxes?
>
>DES's set of S-boxes was carefully engineered to have the right
>properties, which a "randomly chosen" set of S-boxes would lack.
Right. If we want to use randomly constructed S-boxes securely, we
want much larger boxes, and we can't use those in DES.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Scottu: I actually saw something usefull
Date: Tue, 08 Jun 1999 14:22:26 -0500
Oh. I agree that his cypher is probably weak(esp. in comparison to an
equivalent number of bit keyed standard cypher.) (I haven't analyzed it in
depth, but there are definitely some things about it that make one
suspicious of its strength.
I was merely pointing out that the proposed attack was a nonworking one..
[EMAIL PROTECTED] wrote:
>
> The fact that the errors propagate in one direction only can be
> exploited. I just don't know how. In reality you would want a single
> bit to effect some 'random' half of the block. This is what they would
> call resistance to differential analysis?
I am not certain that the unidirectional propagation is a flaw. The
wrapping will effectively produce diffusion into the previous data which
will allow the earlier blocks to be affected. I agree that it does seem
cludgy.
>
>
> Let's not forget he has 25 rounds, requires 1.5MB ram and is about 3
> times slower then most block ciphers. (had to get that in), he is
> working backwords.
Nothing wrong with working backwards( nothing particularly right about it
either though).
I am aware that with enough rounds most any toy cypher can become very
secure, and a long key( utilized fully) will also thwart some forms of
attack. However, the best designs are small, fast, and secure. Scotts
cyphers fail criteria 1) and 2) and have not met sufficient analysis to
determine if it meets 3) or not.
>
>
> As a toy in the middle I wrote this
> http://people.goplay.com/tomstdenis/simple.c
>
> which requires 128kb ram (still bad) but doesn't have the
> unidirectional diffusion. It's basically a sub cipher like his only it
> works on a 128bit block in parallel. It still needs a bijective final
> permutation (keyed) to be a complete block cipher though. BTW my
> cipher is easier to understand, faster and requires less ram (had to
> get that in too). Yes I know that there are 23 other ciphers which are
> much faster and smaller, but I am just proving a point that large s-
> boxes can be used, and used efficiently (unlike his cipher).
>
Have you checked out CRAB( another huge blocksized 'toy' cypher )?
>
> Tom
>
> --
> PGP public keys. SPARE key is for daily work, WORK key is for
> published work. The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: What good is hushmail?
Date: 8 Jun 1999 11:29:29 -0700
In article <7irh2t$qf8$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>3) This implementation of blowfish has only 64 bits and thus should be
>faster to crack than DES since more combinations can be tried in less
>time [blowfish executes faster than DES]
Not for key setup. Blowfish has a very slow key setup; 64-bit Blowfish
would be much harder to brute-force than most other 64-bit algorithms.
--
Free laser networking and other crazy ideas @
http://www.islandnet.com/~mskala/netfree.html
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: what cipher?
Date: 8 Jun 1999 12:17:15 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Actually, LFSR isn't particularly secure, and the taps can be found,
> although I don't think the methodology has been published. I was
> instead referring to the further generalizations of the idea, such
> as nonlinear combinators.
Interesting.
By nonlinear combinator, I assume you mean a NLFSR (shift register with
nonlinear feedback function)?
Here is an interesting tie between stream ciphers and block ciphers.
Suppose you take a NLFSR, use the plaintext as the initial fill, step it
enough times to ensure avalanche, and output the register state as the
ciphertext. (This is a nonlinear version of the Encyclopedia Britannica
cipher.) Then this construction is equivalent to an unbalanced Feistel
cipher whose round function is given by the NLFSR's nonlinear feedback
function. Thus, I would claim that the "NLFSR" and the "unbalanced
Feistel cipher" are, in some sense, just two ways to view the same object.
One difficulty with the construction as I described it is that it has
no round-dependence (e.g. no round subkeys), so it is vulnerable to
a slide attack. This suggests that you should add some form of round
dependence to the NLFSR, be it round counters (like in Skipjack), round
subkeys, or whatever you like.
------------------------------
Date: Tue, 08 Jun 1999 21:28:51 +0200
From: Allan Latham <[EMAIL PROTECTED]>
Subject: rev 0.9 ppdd - encryption for Linux - available
=====BEGIN PGP SIGNED MESSAGE=====
PPDD is an encrypted device driver for Linux. It creates a device which
looks like a
disc partition on which you can then create an ext2 filesystem. The
underlying data
storage can be a file on a normal filesystem or a complete disc
partition. All data
written to this file or partition is encrypted using the blowfish
algorithm.
Special emphasis in the design has been placed on the fact that data on
disc has a
long lifetime and that encrypted backups may fall into the wrong hands.
The use of
master/working pass phrases and the ability to enter very long pass
phrases on two
lines adds to the security.
The driver concept also allows the root filesystem and the swap device
to be
encrypted. In effect this means that with the exception of a kernel and
a small initial
read-only ram-disc image, everything on disc is encrypted.
The latest revision is 0.9 and supports the late 2.0 series and the
early 2.2 series of
Linux kernels up to 2.2.9.
It has been designed so that anyone with reasonable Linux competence can
install
and use
it.
So far only the Intel-86 architecture is supported.
Please see: http://linux01.gwdg.de/~alatham
Direct access to the files is also available at:
http://ftp.gwdg.de/pub/linux/misc/ppdd
ftp://ftp.gwdg.de/pub/linux/misc/ppdd
Allan Latham <[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQCVAwUBN11gyuJCY/+xqTOxAQFSAwQAtCg28fGOPpVKvT5NwV0ItXTsMJC6kBti
cn1D1XDV7FR6JNeijs5QSrMpR3TFdKEIZpKqlJYiqOUcR9h/w7Rs0lgZ8Z4/MGDu
QAR7IAvolKKAJ0PbnEpWg7U0SmC6q5P+EZfb/tR1l4PDDfTi2qtD8+WiVOUgb9b7
oziVJuxOyZo=
=86t2
=====END PGP SIGNATURE=====
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: rc4 vs. rand()
Date: Tue, 08 Jun 1999 17:57:13 -0100
[EMAIL PROTECTED] wrote:
>
> > > I would investigate them before using RC4 commercially.
> > This has been done. RC4 is used for most secure Internet transactions.
>
> Really? It used to be a trade secret so who did the review?
>
Somebody with enough money to buy a license I expect.
> > Why better? More complex and slower, certainly, but "better"?
>
> RC4 = RSADSI!!! That's why. If I want to write a secure app I don't
> want to shell out money to write the program. I would rather use
> something like Blowfish in CBC (blocks) or CFB (streams) then something
> commercial.
>
Call it ARCFOUR instead of RC4 - instant free license to use it...
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Tue, 08 Jun 1999 18:47:07 GMT
Are you completely gone?
CBC mode is not weak when used with a strong cipher. It's like saying
ECB mode is weak for high entropy inputs...
CBC mode was designed to ensure integrity in the stream. You cannot
use your algorithm for stream data (communication, conferencing, etc...)
Try to actually prove CBC is weak, or actually say why you *think* it's
weak and we might endure further yacking. Just because CBC doesn't
effect all blocks does not make it weak, the cipher should be strong
because each chain in the cipher is used properly. Say 2 round des in
CBC mode is weak, but 16 round DES in CBC mode is strong... get the
point?
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
