Cryptography-Digest Digest #742, Volume #9 Mon, 21 Jun 99 00:13:02 EDT
Contents:
Re: RC4 Susectability (c a l a n d e)
Re: Cipher ([EMAIL PROTECTED])
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: CAST-256 implementation (?) ([EMAIL PROTECTED])
Re: crack the winzip files with password (Sundial Services)
Re: CAST-256 implementation (?) ([EMAIL PROTECTED])
Re: CAST-256 implementation (?) ([EMAIL PROTECTED])
Re: CAST-256 implementation (?) ([EMAIL PROTECTED])
Good book for beginning Cryptographers? (Who me?)
Re: ATTN: Bruce Schneier - Street Performer Protocol (Bruce Schneier)
Here is the cipher algorithm (infinitySquared)
Re: Hot on the heels of hushmail....(ziplip.com) (Fred)
----------------------------------------------------------------------------
From: c a l a n d e <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Sun, 20 Jun 1999 15:28:23 -0700
These comments reflect what I had believed.
That is that RCA algorithm is elegant in its
simplicity. At the same time I can imagine
using RCA in many different ways to
create a whole series of cyptosystems.
Thanks for the comments.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher
Date: Sun, 20 Jun 1999 22:07:45 GMT
In article <7kjbaa$11q0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Actually if you cipher is any good you will get few comments.
However
> if it has errors you will get pleanty of comments. Many people who
read
> post here are to lazy to bother to look at webpages where the code is
> discribed or even look at the source code you may porvide. If it is
really
> good they will dismiss it as easy to break but will never bother to
prove it.
> For a sample of something the experts claim they can't follow go to my
> site.
Actually I have gotten a few comments about some of my ideas. It just
happens people would rather comment on clear descriptive documents
instead of crappy code.
Why are you so stuck up? Your code is not good, your cipher maybe good
but you will never get any positive attention until you work for it.
You never responded to my comments on the cipher so why would anyone
else want to comment on it?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Sun, 20 Jun 1999 22:05:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> RC4, I agree, seems to be secure. The 40 bit RC4, is a joke.
>
> 40 bits is well within the reach of todays processors for reliable
brute
> force seaching.
Yeah but the max keysize is 1683.98 bits so who really cares about
small keys? Even still a home computer would take a week or two to
find a 40-bit key, so ideally the smallest key would be about 64 bits.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CAST-256 implementation (?)
Date: Sun, 20 Jun 1999 22:14:26 GMT
In article <[EMAIL PROTECTED]>,
Horst Ossifrage <[EMAIL PROTECTED]> wrote:
> > For what it's worth I am a Canadian... :)
>
> OK, a 2 day old cow pie.
I don't follow you there jim.
> No, why don't you spell it out for me, Dr. Acronym.
Fair enough. A BFN or balanced feistel network is where the maximum
avalanche is exactly 50% (which is ideal). The input is split into two
and one half is modifed by a function of the other half and the key. A
UFN is a unbalanced feistel network where one portion (unequal to the
other) is modified by a function of the other portion and the key.
UFNs generally have slower defusion (note Macguffin requires 2 rounds
to equal a BFN round). They are slower and gererally only have a max
of 25% diffusion per round (for example a 16 to 48 UFN would have a
maximum (avg.) of 8 bits hd per round. A 32 to 32 BFN would have a max
(avg.) of 16 bits per round.). The diffusion is noted as average
though. So on average a smaller part will be effected in a UFN then a
BFN.
Note that some hash functions are UFNs such as MD5 SHA1 etc... I would
look into www.counterpane.com and read their papers on feistel
networks. It really cleared things up for me.
Another problem with UFNs is that diffusion normally runs in one
direction. This means there is very little diffusion in the opposite
direction (which is normally decryption). This can be cured but
usually requires more rounds. That's why 1:1 functions are much better
such as SPNs and BFNs.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sat, 19 Jun 1999 15:23:05 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: crack the winzip files with password
JPeschel wrote:
>
> ><[EMAIL PROTECTED]> writes:
>
> >How to crack the winzip files w/ password faster? Or where can find the
> >information of zip 2.0 encryption format?
>
> Mount a known-plaintext attack. For info
> on the format see the Kocher/Biham paper,
> also Conrad's source code for the implementation.
If you know any complete member of the ZIP file you can generally
extract the password in about ten minutes' time.
At one time I pursued Conrad's work further to explore a "probable
plaintext" approach because much of the frequency-characteristics of a
ZIP-encoded file are predictable regardless of what the plaintext is.
(The file is logically composed of bits, not bytes, and portions of the
file are predictably very dense '1's.) This experiment actually did
produce a "crack," but required about 14 hours' computation, and I have
not pursued it since. Interesting, though, since I supplied the
algorithm with no actual plaintext at all...
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CAST-256 implementation (?)
Date: Mon, 21 Jun 1999 00:03:06 GMT
In article <7kjtk4$rb2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> IIRC (it's been a while since I've looked at the specs), each CAST-256
> does basically the same amount of work as a CAST-128 round (ie. the
> result formed by mixing the S-box outputs of one word is combined with
> another word). CAST-256 is not especially slow; at ~600 cycles, its
> about average for the AES candidates. You certainly can't judge an
> algorithm by how many rounds it uses.
It's not speed it's rounds. I wouldn't mind a slow eight round
cipher. Because I would know that the transformation was secure and
not just complex. For example TEA is very insecure at 8 rounds, but at
64 rounds (the suggested number) it's secure. That does not inspire a
sense of confidence.
SAFER+ has 8,12,16 rounds, each of which are clearly defined and have
nice even mixing. CAST-256 however has 48 rounds of which they are
cascaded (diffusion in one direction) for 24 and the opposite for the
other 24. I couldn't care less if it were fast or not.
Think of using a fast RSA variant with 32768 bit keys ... That would
not inspire much confidence. You could have key entropy problems,
etc...
> I believe that the term UFN (unbalanced Fiestel network) is rather
> loaded; the alternative of Generalized Fiestel Network has fewer
> negative connotations. The diffusion of a UFN is not neccesarily
> biased; I really don't feel like spelling out the details, but it
should
Well to my understanding a BFN is where the mixing is even, and UFN
where the mixing is cascaded. A BFN sounds like a better idea since
two rounds would mean the entire block is mixed, and in three rounds
the entire block is mixed in some key dependant fashion. UFNs normally
require double/quadruple this much...
> The SAFER submission is significantly slower than CAST-256, although
> it does have fewer rounds.
I don't think it is that much slower. It is however compact and has
nice known properties (well CAST does as well..).
> Just as one can design a poor SPN (not intended to suggest that SAFER
> is a flawed algorithm), one can design a good GFN. Perhaps the only
> true objection against the GFN chosen in CAST is in the rather
abstract
> sense that it would require ~40 rounds or so to achieve provable
> security under the constraints of the Luby-Rubkoff construction.
Which beckens the question why did they choose that construction? They
could have made a double word BFN (see twofish/RC6)...
> Bruce Scheiner's stated thoughts, however valid, against the CAST
> design methodology have prompted your post, have they not? In the
> future, please judge things on their own merits, and only when you are
> qualified to judge them.
Well I listen well. Maybe he was a catalyst but I just happen to
realize the need for 48 rounds... I seem to agree with him on this
matter.
To be frank when is anyone READY to judge anyone elses ciphers? Either
you can comment or you cannot. I choose to comment but not to
critically comment (note: I pointed out a potential flaw in CAST-256
but did not say it was weak because of it).
> BTW, McGuffin (sp?) is pretty much a strawman cipher and is not
> representative of the potential of GFNs. For examples, Mars, one of
the leading contenders among the AES candidates,is a GFN as well.
AFAIK MacGuffin was not designed to be a 'serious' cipher. It was a
catalyst (to quote the second page)
-=-=-=-
...As its name suggests, MacGuffin is intended primarily as a catalyst
for dicussion and analysis.
-=-=-=-
I am well aware of MARS, however it too has a large number of rounds.
I believe it has 32 rounds? 8 unkeyed forwards, 16 key-mixing, 8
unkeyed backwards. Which kinda demonstrates the high level of rounds
required.
Generally I think balanced block ciphers require fewer rounds if their
mixing function (normally called the f function) are designed
properly. Most ciphers include several mixing functions, a linear
function (is linear because it is simply data dependant) to promote
diffusion, a non-linear (non-linear because it requires a key) to
promote confusion. SQUARE is a good example where these functions are
clearly explained and seperated.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CAST-256 implementation (?)
Date: Sun, 20 Jun 1999 23:31:16 GMT
In article <7khkqp$7oc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Well at 48-rounds I seriously doubt the effectiveness of Cast-256.
IIRC (it's been a while since I've looked at the specs), each CAST-256
does basically the same amount of work as a CAST-128 round (ie. the
result formed by mixing the S-box outputs of one word is combined with
another word). CAST-256 is not especially slow; at ~600 cycles, its
about average for the AES candidates. You certainly can't judge an
algorithm by how many rounds it uses.
> While it may be a secure process I would rather not use a UFN because
> the diffusion is not balanced and therefore biased. It has the
reverse
I believe that the term UFN (unbalanced Fiestel network) is rather
loaded; the alternative of Generalized Fiestel Network has fewer
negative connotations. The diffusion of a UFN is not neccesarily
biased; I really don't feel like spelling out the details, but it should
> rules but I still would not like to use it.
>
> I personally like pure substitution (i.e SAFER) or feistel type
ciphers
> (where the block is divided). The diffusion and mixing is rather
> balanced which means there is a quick avalanche after very few rounds.
The SAFER submission is significantly slower than CAST-256, although it
does have fewer rounds.
Just as one can design a poor SPN (not intended to suggest that SAFER
is a flawed algorithm), one can design a good GFN. Perhaps the only
true objection against the GFN chosen in CAST is in the rather abstract
sense that it would require ~40 rounds or so to achieve provable
security under the constraints of the Luby-Rubkoff construction.
>
> I personally don't think CAST-256 is unsafe (what would I know
> anyways), I just like the 64-bit versions because they are not UFNs
> (and only have 8 rounds...)
Bruce Scheiner's stated thoughts, however valid, against the CAST
design methodology have prompted your post, have they not? In the
future, please judge things on their own merits, and only when you are
qualified to judge them.
BTW, McGuffin (sp?) is pretty much a strawman cipher and is not
representative of the potential of GFNs. For examples, Mars, one of the
leading contenders among the AES candidates,is a GFN as well.
>
> Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CAST-256 implementation (?)
Date: Mon, 21 Jun 1999 01:34:02 GMT
In article <7kjvfn$rr2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7kjtk4$rb2$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > IIRC (it's been a while since I've looked at the specs), each CAST-
256
> > does basically the same amount of work as a CAST-128 round (ie. the
> > result formed by mixing the S-box outputs of one word is combined
with
> > another word). CAST-256 is not especially slow; at ~600 cycles, its
> > about average for the AES candidates. You certainly can't judge an
> > algorithm by how many rounds it uses.
>
> It's not speed it's rounds. I wouldn't mind a slow eight round
> cipher. Because I would know that the transformation was secure and
> not just complex. For example TEA is very insecure at 8 rounds, but
at
> 64 rounds (the suggested number) it's secure. That does not inspire a
> sense of confidence.
>
CAST attempts to do less in each round then say, DFC. No implication
can be made about the security of the cipher as a whole, although
perhaps one could say that one round of CAST is weaker then one round
of DFC. You are correct in asserting that a strong round function can
be iterated fewer times for equivalent security as a weak round
function interated many times.
> SAFER+ has 8,12,16 rounds, each of which are clearly defined and have
> nice even mixing. CAST-256 however has 48 rounds of which they are
> cascaded (diffusion in one direction) for 24 and the opposite for the
Although the CAST designers did not state that there intention was to
defeat certain attacks (I believe their motivation was to ease
implementation in hardware) this asymmetrical cipher topology prevents
many attacks. For example, impossible differential cryptanalysis can be
applied to 20 rounds of the forward round function. If you're concerned
about the number of rounds, you could envision a meta-round consisting
of 4 rounds, reducing the meta-round count to 12.
> other 24. I couldn't care less if it were fast or not.
>
> Think of using a fast RSA variant with 32768 bit keys ... That would
> not inspire much confidence. You could have key entropy problems,
> etc...
>
> > I believe that the term UFN (unbalanced Fiestel network) is rather
> > loaded; the alternative of Generalized Fiestel Network has fewer
> > negative connotations. The diffusion of a UFN is not neccesarily
> > biased; I really don't feel like spelling out the details, but it
> should
>
> Well to my understanding a BFN is where the mixing is even, and UFN
> where the mixing is cascaded. A BFN sounds like a better idea since
I would suggest that you clarify your understanding of UFNs.
> two rounds would mean the entire block is mixed, and in three rounds
> the entire block is mixed in some key dependant fashion. UFNs
normally
> require double/quadruple this much...
>
> > The SAFER submission is significantly slower than CAST-256, although
> > it does have fewer rounds.
>
> I don't think it is that much slower. It is however compact and has
> nice known properties (well CAST does as well..).
According to Gladman's results, CAST takes 633 cycles regardless of key
length, while SAFER 1722, 2555, and 3391 cycles respectively. Certain
properties of the SPN used in SAFER are rather troubling. IIRC,
Vaudenay wrote something a few years ago on this. Try searching for the
word "multipermutations".
>
> > Just as one can design a poor SPN (not intended to suggest that
SAFER
> > is a flawed algorithm), one can design a good GFN. Perhaps the only
> > true objection against the GFN chosen in CAST is in the rather
> abstract
> > sense that it would require ~40 rounds or so to achieve provable
> > security under the constraints of the Luby-Rubkoff construction.
>
> Which beckens the question why did they choose that construction?
They
> could have made a double word BFN (see twofish/RC6)...
Have you even read the first part of my sentence?
<<snip>>
>
> > BTW, McGuffin (sp?) is pretty much a strawman cipher and is not
> > representative of the potential of GFNs. For examples, Mars, one of
> the leading contenders among the AES candidates,is a GFN as well.
>
> AFAIK MacGuffin was not designed to be a 'serious' cipher. It was a
> catalyst (to quote the second page)
>
> -=-=-=-
> ...As its name suggests, MacGuffin is intended primarily as a catalyst
> for dicussion and analysis.
> -=-=-=-
>
> I am well aware of MARS, however it too has a large number of rounds.
> I believe it has 32 rounds? 8 unkeyed forwards, 16 key-mixing, 8
> unkeyed backwards. Which kinda demonstrates the high level of rounds
> required.
Let's have a though experiment. Define a cipher A with a very complex
round function, say it takes 1000 cycles, and requiring only 8 rounds.
We have cipher B, a GFN, with a round function that takes only 25
cycles, but needs 40 rounds for security. B might require more rounds
to acheive equivalent security, but this fact alone does not make B any
weaker than A.
>
> Generally I think balanced block ciphers require fewer rounds if their
> mixing function (normally called the f function) are designed
> properly. Most ciphers include several mixing functions, a linear
> function (is linear because it is simply data dependant) to promote
Linear != data dependent
> diffusion, a non-linear (non-linear because it requires a key) to
Non-linear != key dependent
> promote confusion. SQUARE is a good example where these functions are
> clearly explained and seperated.
>
> Tom
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Who me? <"binthr"@@hotmail.com>
Subject: Good book for beginning Cryptographers?
Date: Mon, 21 Jun 1999 06:44:30 +0100
Can anyone/everyone recommend a good book for a beginner, (please not a
slow book, one that is fairly advanced but covers all areas)
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Mon, 21 Jun 1999 02:40:47 GMT
On Fri, 18 Jun 1999 16:28:13 GMT, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Bruce Schneier) wrote:
>> >And we enjoy your company (as in presence). BTW any news about
>> >blowfish? Is it still the wickedly cool algorithm I believe it is?
>> >Any variants using less memory?
>>
>> Twofish uses less memory, but it would be a stretch to call it a
>> "variant."
>
>Hmm ever try a blowfish variant with two f functions?
That's where we started when we developed Twofish.
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: infinitySquared <"binthr"@@hotmail.com>
Subject: Here is the cipher algorithm
Date: Mon, 21 Jun 1999 06:47:49 +0100
you asked for the algorithm so here it is....
Well the algorithm is simple (keep in mind it is my first one)
the passkey is read from the keyboard, the passkey chars are associated
within an array (built into the program for fun really not security).
values are then computed like such
Passkey
who
location in array of w = 30
location of h = 20
location of o = 10
ans say the text to encrypt is
simple
location in array of s = 12
i = 13
m = 14
p = 15
l = 20
e = 21
so the first char in the text to encrypt relates to the first char in
the passkey as such. the total of the passkey starting at pos 1 =
30+20+10, so the s (location 12) will be advanced 60 positions in the
array and that char will be printed out. the o is the second so the
running total is 20+10 =30, the second char in the text to encrypt is
advanced 30 pos in the array and that char is printed out..
once we pass the end of the sectet key we loop back to the first post in
the secret key?
with me i hope so?
so there you have it..
not very hard to crack i imagine? but it was trival to make ..
infinitySquared
------------------------------
From: Fred <[EMAIL PROTECTED]>
Subject: Re: Hot on the heels of hushmail....(ziplip.com)
Date: Mon, 21 Jun 1999 02:39:42 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <7ij062$9eq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Passwords are limited to 15 characters, the Web site doesn't explain
> what algorithm they use for encryption, and they display part (not
all)
> of the ciphertext when you receive encrypted email. It's in a box,
> with the password dialog on top. It can be selected and copied
> to the clipboard.
>
I just got some more mail from the folks at ziplip.com. They
still won't explain what crypto algorithm they're using, but do
say it's "a well established public crypto algorithm ". At
least they didn't roll their own.
Their comment about password length:
[quote]
We are looking at expanding a variety of features for the ZipLip
website
and among these are longer passwords. We understand the interest for
this
and will work as quickly as we can to include many of the features
that
have been requested.
[\quote]
As of 6/17, they consider the site to be in beta.
- --
f r e d e r w <atsign> p o b o x . c o m
Boycott spammers!
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>
iQA/AwUBN22lNHJQgJ+siYlMEQKuVgCffLaw8f1DaafEZlGaGj8zjQ0zNNcAn3pp
zhceLJiNrizObIuLpEtX21gY
=SwRO
=====END PGP SIGNATURE=====
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
******************************
