Cryptography-Digest Digest #696, Volume #9 Fri, 11 Jun 99 11:13:02 EDT
Contents:
Re: Algorithms (Doug Stell)
Re: Looking for a password encryption algorithm (Ari
=?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?=)
Re: huffman code length (Mok-Kong Shen)
Re: Does scott19u.zip make full use of it's large key size ? ([EMAIL PROTECTED])
1024 bits encryption for web based e-mail ("Phuriphat Dejsuphong")
Re: Tom St.Dennis, Scott16 & the Chosen Plaintext Attack ([EMAIL PROTECTED])
Re: cant have your cake and eat it too ([EMAIL PROTECTED])
Re: Cracking DES ([EMAIL PROTECTED])
Re: 1024 bits encryption for web based e-mail ([EMAIL PROTECTED])
DES lifetime (was: being burnt by the NSA) ([EMAIL PROTECTED])
Re: Does scott19u.zip make full use of it's large key size ? (SCOTT19U.ZIP_GUY)
Re: Tom St.Dennis, Scott16 & the Chosen Plaintext Attack (SCOTT19U.ZIP_GUY)
Re: cant have your cake and eat it too (Patrick Juola)
Re: I challenge thee :) (Patrick Juola)
Re: Cracking DES (Patrick Juola)
Re: DES lifetime (was: being burnt by the NSA) (Patrick Juola)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Algorithms
Date: Thu, 10 Jun 1999 15:26:38 GMT
On Wed, 09 Jun 1999 15:43:15 -0700, "John E. Kuslich" <[EMAIL PROTECTED]>
wrote:
>Ok, What the heck does AL Gore have to do with crypto???
>
>Let's keep this group free from annoying posts about politics. Who the
>heck cares about Al Gore isms any way
Al Gore chairs the U.S. committee on export regulations and policy
w.r.t. crypto. (I know people who represent industry on that
committee.) Al Gore is also very much apart of the Wassenaar
Agreement. Therefore, he has a lot to do with crypto, especially in
setting the U.S. Administration's policy on crypto. Everyone in the
U.S. and the commercial side of crypto cares a lot about export
regulations.
Now you know.
------------------------------
From: Ari =?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?= <[EMAIL PROTECTED]>
Subject: Re: Looking for a password encryption algorithm
Date: Fri, 11 Jun 1999 09:36:45 +0300
David P Jablon wrote:
>
> In article <[EMAIL PROTECTED]>,
> Paul Koning <[EMAIL PROTECTED]> wrote:
> >Ari Vähä-Erkkilä wrote:
> >> Simply, I'm looking for a reliable password encryption algorithm.
> >
> >Try any good crypto hash (MD5, SHA-1, etc.)
>
> Better yet, try a zero-knowledge password proof, like EKE or SPEKE.
A quick peek to SPEKE had me believe that the server needs to have a state
to store the mutual shared key that
is generated from the password.
> >> This is the situation: The passwords are to be stored in a database and
> >> the client software will access the database via server programs.
> >> Unfortunately the server programs are stateless, therefore a real
> >> key-exchange type protocol cannot be implemented.
>
> For a truly stateless server, no request/reply method would work.
> and you wouldn't be able to authorize any subsequent transactions.
> Is this really what you mean?
Unfortunately, yes. At the moment it is assumed that the replies produced
by the authetication phase produce information
that is otherwise not available. But that is the "dreamworld" the system
resides in.
Ari
--
*******************************************************
Ari Vähä-Erkkilä Consultant, Twin Systems Oy
Office: +358-(0)9-5840 4815 [EMAIL PROTECTED]
Mobile: +358-(0)40-586 6980 [EMAIL PROTECTED]
Fax : +358-(0)9-176 718
*** http://www.twin.fi/ *** http://www.iki.fi/vake/ ***
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: huffman code length
Date: Fri, 11 Jun 1999 13:15:50 +0200
Mr. X wrote:
>
>
> Some possible symbol sets for code set [0,1]
> [.1,.9] [.5,.5] [.9,.1]
>
> Some possible symbol sets for code set [0,10,11]
> [.33,.33,.33] [.34,.33,.32] [.8,.1,.1]
Maybe I misunderstood you, but what I think is preferable is a method
to compute, given a Huffman tree, the extreme frequency distributions
within whose range any valid distribution must lie.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Fri, 11 Jun 1999 10:48:16 GMT
Small changes have to be possible just as big changes otherwise what is
the point?
There should be at least one case per key where the input and output
differ slightly. Your block size is not defined so I bet I could find
one. With the propagation of errors, it has to be possible to single
bit errors to not propagate or the function is not bijective. This
means not all outputs are possible.
These facts are true for any block cipher, however most of the time a
single bit error will propagate.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Phuriphat Dejsuphong" <[EMAIL PROTECTED]>
Subject: 1024 bits encryption for web based e-mail
Date: Fri, 11 Jun 1999 18:06:51 +0700
i just saw the web based e-mail that allow me to have secure connection, w/
1024 bits encryption,
pretty kewl
http://www.hushmail.com
regard,
james
--
0110101001100001011011010110010101110011
m l o r e c u b k . q b g . p b z
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Tom St.Dennis, Scott16 & the Chosen Plaintext Attack
Date: Fri, 11 Jun 1999 10:55:07 GMT
Ok in scottu19/16 a one round attack could be mounted. If you take the
same plaintext and pass it through a two round variant you get even
more of the table. I know it's just an idea...
In mine I think one would fixed all but one of the words, and see how
the output changes. Sadly I do not know how to break my algorithm or
even come close (because of a lack of knowledge on my part..). I know
of several weaknesses such as if you take off the FP you get some
statistics about the last round inputs. If I take off the IP (final
and initial permutation) then the attacker has more control over the
inputs into the first round. A one round attack would be trivial, and
a 2 round attack possible (?).
I think that scottu would be weak with anything less then 3 rounds, and
as dave likes to point out requires 25 rounds to achieve ideal
diffusion. 25 rounds is a bit excessive most AES ciphers only have
8~20 rounds but they are way more optimized then both of ours.
My 2 cents.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: cant have your cake and eat it too
Date: Fri, 11 Jun 1999 10:57:39 GMT
<snip>
well in PGP I believe they use a BBS random number generator, so the 64
bit key that comes out is highly unpredictable (unless you have access
to the computer :) ). In PGP they still hash a passwd for access to
your public/private keys but they also remind the user at every step to
use long passwds...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking DES
Date: Fri, 11 Jun 1999 11:07:47 GMT
Terry Ritter wrote:
[...]
> So for n ciphers, we have n times the attack effort, and 1/n reward
> for any success, which makes the reward/effort ratio 1/n**2. This is
> not linear, and that should make the attack business somewhat more
> discouraging.
No. First the simple error: "n times the effort" is the
effort to attack all n ciphers; 1/n reward is for breaking
one of them (more on that below). We expect the number of
ciphers broken to increase with the number of ciphers
attacked, and thus the ratio stated is not the reward/effort
ratio.
Two other points indicate the assumptions are false. First,
the reward is proportional to the intelligence value of the
recovered plaintext and not the volume of plaintext. Five
percent of the traffic carries much more than five percent
of the value, since real traffic is redundant. Second, an
intelligent attacker would first try to determine what ciphers
his methods have a good chance of breaking, and concentrate
on those. Developing differential cryptanalysis took years;
determining whether it applies to a new cipher takes hours or
sometimes minutes.
I know Terry Ritter disagrees, but I find that as the number
of ciphers an enterprise uses increases, the attackers
reward/effort ratio goes _up_. He picks off the low hanging
fruit. I grant that the ratio goes down if the attacker needs
all the encrypted information, but gaining a significant
portion of the intelligence value gets easier.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 1024 bits encryption for web based e-mail
Date: Fri, 11 Jun 1999 12:32:46 GMT
In article <7jqqou$g09$[EMAIL PROTECTED]>,
"Phuriphat Dejsuphong" <[EMAIL PROTECTED]> wrote:
> i just saw the web based e-mail that allow me to have secure connection, w/
> 1024 bits encryption,
> pretty kewl
>
> http://www.hushmail.com
Not cool, if you were here about two weeks ago you would note that we
discussed this already. Hushmail can be broken quite easily. A server
could interrupt hushmail and pretend (i.e ghost servers) which could
send false java apps.
Basically the problem is that you have no clue wether the java app you
get is the real thing.
Use PGP or RIPEM for private email. You will save yourself the trouble.
BTW, what does '1024 bit encryption' mean? Is that the block size?
Key, number of bits in the name?
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]
Subject: DES lifetime (was: being burnt by the NSA)
Date: Fri, 11 Jun 1999 12:10:38 GMT
Douglas A. Gwyn wrote:
> DES and Skipjack both admirably met their design goals.
> DES has just recently *barely* been broken in a published attack,
> so it held up far longer than its design lifetime of ten years.
Which is the requirement: A cipher must remain unbroken for,
A) its operational life,
or
B) the intelligence life of any data it protects?
I think that's a pretty basic question. Could the the NSA
have come up with the wrong answer?
As I understand it "sensitive but not classified" information
would include raw data from the decennial census, and the law
states such data shall be sealed for 72 years. A cipher to
protect sensitive but not classified data, to be used from 1976
to 1986, must be sufficiently secure to protect data collected
for the 1980 census. Thus the cipher must remain unbroken until
at least 2052.
DES has failed. It was never adequate - not even for its
initial purpose and intended lifetime. The cipher resulting
from the combined efforts of IBM, NBS (now NIST) and NSA, falls
to an attack that the most naive crypto-newbie ciphers are
routinely able to resist.
--Bryan
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: Does scott19u.zip make full use of it's large key size ?
Date: Fri, 11 Jun 1999 13:47:28 GMT
In article <7jqphg$cl6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Small changes have to be possible just as big changes otherwise what is
>the point?
>
>There should be at least one case per key where the input and output
>differ slightly. Your block size is not defined so I bet I could find
Due to the large key space it is possible to consturct a table such
that 2 messages that differ from each other from each other by a bit
to use completely different parts of the S-table so that the many
internal passes look different but that the final output is slightly
differrent however this is a very very rare case and to try to find
one by trying various keys and inputs. Would require the time
of the sun to burn out as people in this group like to point out.
however if you write a small message it is easy to change the
S-table on the last pass to make a ouput that is very similar to
the first input.
>one. With the propagation of errors, it has to be possible to single
>bit errors to not propagate or the function is not bijective. This
>means not all outputs are possible.
For a given input message not all output messages are possible
if one varyes the key except for short messages then all outputs of
the same size are possible.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tom St.Dennis, Scott16 & the Chosen Plaintext Attack
Date: Fri, 11 Jun 1999 14:40:17 GMT
In article <7jqpu9$cpd$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Ok in scottu19/16 a one round attack could be mounted. If you take the
>same plaintext and pass it through a two round variant you get even
>more of the table. I know it's just an idea...
>
I take you mean to drop the Paul pass front and back and not use the
mode that has a random block in front. Just the reduced cipher with one
round. Go ahead and try it. I think a plain vanilla one round using total
chosen file plaintext attack could defeat one round.
..
>I think that scottu would be weak with anything less then 3 rounds, and
>as dave likes to point out requires 25 rounds to achieve ideal
I don't know how many rounds it takes for total diffusion. I know that
with one round that a change later in the file we not effect the whole
output. Two rounds I felt would not reqire an attacker to at least go though
one whole pass when guessing a key ( I know guessing a key is not the
way to go but it gives an idea of how much information is needed to break
the methhod). I felt that 6 rounds might be ideal but made it larger to error
on the side of safety and then added the Paul pass front and back to prevent
anything like a Paul Onions attack.
>diffusion. 25 rounds is a bit excessive most AES ciphers only have
>8~20 rounds but they are way more optimized then both of ours.
>
>My 2 cents.
>
>Tom
>
I don't care that the AES ciphers are from 8-20 and I am not so sure
that they are more optimized than mine.
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: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: cant have your cake and eat it too
Date: 11 Jun 1999 09:44:05 -0400
In article <[EMAIL PROTECTED]>, Greg Bartels <[EMAIL PROTECTED]> wrote:
>hey, wait a minute, I was asking why not use a different
>key for every stage of DES, and the response was
>1) its only nominally better and
>2) the size of the key is too big to generate from a pass phrase.
>
>but, given a secure algorithm, the weakest link becomes
>the size of the key. which says to me, current cracking
>capabilities require keys bigger than you can generate
>with a "human-memorizable-pass-phrase".
>
>so you cant have small keys and secure data too.
Sure you can. A 128-bit key is 'small' by the standards we're discussing,
but is still secure against brute force.
If 128-bits gives you all the security you need, why go with 2000?
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: I challenge thee :)
Date: 11 Jun 1999 09:42:36 -0400
In article <[EMAIL PROTECTED]>, smoke_em <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>
>> Most 'polyalphabetic' ciphers are broken by frequency analysis if I am
>> not mistaken. If this is true all you have to do is understand the
>> language of the plaintext and you can guess at the key.
>
>What i meant is, there is a Poly Alfabetical Substitution Cipher that
>achieves the same result. That is, it is possible to build
>key_length/wordsize look-up tables of 2^wordsize entries, such that you
>can compute C[i] by looking up table[key_index][P[i]].
>I don't recall anyone ever saying that i have to use a wordsize of 8
>bits and if i were to take a 8byte key, run it in 16bit code, you'd have
>to generate 4 tables of 64 kilobyte, making it at least a bit harder
>though not enough by far.
>This is also where my interest in you experts come in... while this sort
>of modification obviously twarts some, if not most, of the value of
>frequency analysis - well at least it becomes harder and your need more
>material - i don't know what sort of security it grants. How hard does
>it really get or how much security do i have if frequency analysis is
>practically eliminated.
You can't 'practically eliminate' frequency analysis unless your
codebook is so large that almost every message is a very few chunks
and codebook entries aren't repeated.
The problem is that I can calculate frequencies with almost arbitrary
precision *based on conditions that I know to obtain about you and your
messages.* For example, if you're encoding telephoned product orders,
I can tap your phone for a few days, learn what orders came in that day,
and then attempt to crack the message based not only on the absolute
frequencies but also on the fact that on days when you had a few large
orders, the messages looked like *THIS*, while on days where no one ordered
more than a hundred widgets, the messages looked like *THAT*, so....
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Cracking DES
Date: 11 Jun 1999 09:49:35 -0400
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>
>On Thu, 10 Jun 1999 09:44:09 -0400, in <[EMAIL PROTECTED]>,
>in sci.crypt [EMAIL PROTECTED] wrote:
>
>>[...]
>>Note that algorithmic weaknesses scale linearly. I.e. if you double the
>>number of algorithms you double the amout of work for an adversary
>>(Ritter and others have suggested that this may not be true, for this
>>topic it is true.)
>
>Well, you lost me there.
>
>There are several different effects to having multiple ciphers: One
>effect is that each cipher must be detected, acquired, attacked, and
>broken for future use (if possible). So the more ciphers there are,
>the more effort which must be expended, and this is linear.
>
>Another effect of multiple ciphers is that the universe of information
>is partitioned into multiple channels, which means that the reward for
>breaking any cipher is proportionately less. The more ciphers there
>are, the less information any one of them can expose, and this is also
>linear.
That isn't 'another effect', that's the same effect in disguise.
Think of it this way. I hire one group of cryptanalysts to analyze
one algorithm and break everything. That costs me $X -- and I have
access to everything in the universe of a single cypher.
I now hire N groups to analyze one algorithm and break everything.
This costs me <= N*$X, and I still have access to
everything in the universe.
>So for n ciphers, we have n times the attack effort, and 1/n reward
>for any success,
No, for N times the attack effort, you get complete success. For
a single attack effort, you get 1/N reward.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DES lifetime (was: being burnt by the NSA)
Date: 11 Jun 1999 09:52:55 -0400
In article <7jqubp$e0g$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn wrote:
>
>> DES and Skipjack both admirably met their design goals.
>> DES has just recently *barely* been broken in a published attack,
>> so it held up far longer than its design lifetime of ten years.
>
>Which is the requirement: A cipher must remain unbroken for,
> A) its operational life,
> or
> B) the intelligence life of any data it protects?
>
>I think that's a pretty basic question. Could the the NSA
>have come up with the wrong answer?
These are two different requirements. You have to consider
whether the intelligence life of the data protected is within
the capacity of the operational life of the cypher.
If I decide that I need to get from Pittsburgh to LA in a day, and
therefore go out and buy a bicycle, did the Schwinn company ''come
up with the wrong answer''? No -- I did in deciding that the
bicycle was suitable for my needs.
-kitten
------------------------------
** 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
******************************
