Cryptography-Digest Digest #690, Volume #9 Thu, 10 Jun 99 18:13:03 EDT
Contents:
Re: Does scott19u.zip make full use of it's large key size ? (SCOTT19U.ZIP_GUY)
Re: 8Bit encryption code. Just try and break it. - code3.ecr (1/1)
([EMAIL PROTECTED])
Re: RSA patent question (Doug Stell)
Re: question about original RSA research (Doug Stell)
Re: ATTN: Bruce Schneier - Street Performer Protocol (Bob Silverman)
Fw: The Mathematics of Public-Key Cryptography, June 12 - June 17, 1999 ("Mike
Murray")
Re: DES (fungus)
Re: Cracking DES (fungus)
Re: Cracking DES (fungus)
Re: Cracking DES (Patrick Juola)
Re: I challenge thee :) (smoke_em)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Thu, 10 Jun 1999 20:25:33 GMT
In article <7joggb$ik5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> Horst Ossifrage <[EMAIL PROTECTED]> wrote:
>> Yes, memory is cheap. Your computer can easily handle it.
>
>Not in smartcards with less then 1KB of ram...
Then don't use scott19u in samrtcards. But I plan
on using it in my PC.
>
>
>> Only in one pass, after all 25 passes, the bricklaying of
>> words makes data dependent changes on adjacent words.
>> This avalanches with each pass so 25 adjacent words of
>> 19 bits each influence each other.
>
>However what happens if one operation cancels out and the value returns
>to what it was suppose to? Then there is no avalanche (you fail to
>mention that). In my simple cipher this is less likely as every word in
>the block affects the others using the PHT (i.e it's less likely all
>words will cancel out).
What are you talking about? Can you show any real examples
of this occurring?
>
>>
>> No , it has 25 passes each pass lets any bit change in the
>> file affect any other bit.
>
>This is not proven. It's impossible in fact to prove this.
When a single bit changes in the input file you go to get
a different slot in the S table That slot can point to anything
but itself and the what the original vaule the S-box pointed to. So in effect
you start a change there and it propagates down that pass and
then comes back to the top to change the following 24 passes.
>
>> > 3. The S-Box is incredibly large. It contains all possible
>> > 19bit words.
>>
>> yes.
>
>Very insightful.
>
>> > 4. The key for the algorithm is only used for generating
>> > the S-Box. It is not used anywhere else in the
>> > algorithm.
>>
>> Yes.
>
>Indeed my life has changed for the better.
>
>
>> Other ciphers may have some their s box entries not used.
>> It is just less likely than for Scott's.
>
>No it is not. What if the message is only 8 chars? (4 words)
Your correct you could map all 2^64 messages so that if
someone is always using the same key and messages of 8
characters in lenght then you could look up the anwser. But I think that is
all you need to do with any cipher if you limit it to 64 bits in and 64 bits
out unless you have some specail way I have not heard of. Maybe you can
enlighten us with your specail insight on this problem.
But even with this there is not much you could do if the
person wrote a 16 character message. But if the person was using
something as weak as IDEA your complete mapping of all 2^64 cases
of input ouput pairs whould allow you to get the solution. I hope you
can follow what I am saying here it is not to difficult.
>
>> If you consider only one pass for all algorithms, you can
>> find some with that property and some that have more extensive
>> round functions. The simpler round functions may be susceptible to
>> a Slide Attack, while less comprehensible roundss are not
>> susceptible to that attack. That attack can be blunted by
>> making each round different. But the large block size of Scott's
>> makes the probability of finding a collision between a plaintext
>> and a one round cipher too low for usefulness.
>
>No it is not. Consider a four word message (or any small message). You
>people cannot prove that it's immune because the block size is not
>fixed. Also it is not immune to a slide attack because the cipher has
>no round dependancies (i.e round keys). Same with my simple cipher. In
>fact I could mount a chosen plaintext attack faster on your cipher then
>my simple one.
Well tom here is your chance if you really think it is so easy try it
out. But I am surprised you have such a firm grip on the method that
you can see all its weaknesses with out even understanding how I encrypt
something. Or are you just parroting others or what? Try to solve the contest
for scott19u. I give the encrypted out put file short a few trailing bits and
the KEY that was used and the input file except a few characters where
changed in the middle of file. Can you solve it?
There are not many bits left to guess since every month I give 4 more
bits. So be quick because when it gets to 16 bits or less Bruce might
beat you to the solution.
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]
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (1/1)
Date: 10 Jun 1999 20:09:41 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
Wesley Horton wrote:
>Well, how about dangling some sort of prize to break it, say, $1,000 or
>so? I am sure that since you are so confident, you would have no
>problem putting money in an escrow account.
Interesting proposition.
>Or better yet, would you sell this system to a drug dealer knowing that
>if it were broken he would probably kill your family and then you?
Ha. Now, the argument that people will kill you to get the secret out of
you, the same thing applies to supposedly 'legitimate' ciphering, no?
Foreign powers are capable of doing the same thing, bluntly, just to get
at the truth.
>If you want someone to put forth the effort to break your system, people
>need some reason other than to say, "I broke your system!"
This is a good point.
--
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RSA patent question
Date: Thu, 10 Jun 1999 19:43:15 GMT
On Thu, 10 Jun 1999 20:32:01 +0200, "R. Joosten"
<[EMAIL PROTECTED]> wrote:
>Over lunch someone mentioned the following case.
>
>Suppose you are in Europe, and you want to access a US-based database over
>the internet. The database owner supplies you with an RSA key, and sends you
>database items that are RSA encrypted, and which you could then decrypt
>using the aforementioned key. You can then apparently be sued for patent
>(yes, patent) infringement. It was said that a case like this was brought to
>court only very recently.
>
>This seems weird to me; I would say that there is not necessarily any proof
>that RSA is actually executed, but only that an RSA key is sent and RSA
>encrypted stuff.
>
>Anybody know details?
Having been custodian of the RSA license and code and involved in
export for another major (and former) company, I have some insight
into the patent situation and RSADSI's feelings.
RSA is patented only in the U.S. To execute the algorithm in the U.S.,
you must have a license. Most often, license is obtained by purchase
of a BSAFE object library. Some companies have license to implement
RSA themselves and/or use BSAFE source code.
If RSA is implemented or executed outside the U.S. it is not covered
by the patent.
If RSA is implemented outside the U.S. and then imported into the
U.S., royalty must be paid upon import.
For the specific example you cite, I suspect that the US-based party
would have to have an RSA license or risk being sued for patent
infringement. The non-US party would not need a license and is safe.
Sending encrypted data across internaltional borders is a different
issue entirely. The U.S. doesn't preclude it, but the non-US country
might.
The U.S. Gov't might be very interested in whether the RSA
implementation used by the non-US party was illegally exported from
the US or not. They might also be interested in the length of the key
used. Also, they might be interested in whether the application used
by the non-US party was exported from the US with RSA used for data
encryption or hooks that permitted RSA to be inserted off-shore.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: question about original RSA research
Date: Thu, 10 Jun 1999 19:50:30 GMT
On 10 Jun 1999 18:42:15 GMT, [EMAIL PROTECTED] (Pete) wrote:
>what i would do in your shoes is to go to my university library and search
>all the journals for articles by len rivest, shamir and adleman (don't know
>if those spellings are correct).
I believe that the research was done in late 1976 and publication in
early 1977. Knowing the timeframe might bind your search somewhat.
The last names are correct. The first names are Ronald, Adi and
Lenard, respectively. (Adleman is misspelled about 50% of the time.)
You might also try Ron Rivest's web page at theory.lcs.mit.edu/~rivest
(I think). He tends to have lots of interesting stuff.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 17:46:08 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Anonymous wrote:
> >
> > Bruce,
> > I cannot believe you would put your name to such an outlandish
proposal! If you wanted to
<snip>
>
> You launched a bunch of very severe attacks agains Mr. Schneier,
<snip>
> That you write anonymously is perfectly o.k.
>
> M. K. Shen
>
Allow me to disagree. IMO, posting slurs and a personal attack then
hiding behing anonymity is the action of a bully and a coward.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Mike Murray" <[EMAIL PROTECTED]>
Subject: Fw: The Mathematics of Public-Key Cryptography, June 12 - June 17, 1999
Date: Thu, 10 Jun 1999 16:42:40 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hey all...
Hadn't seen any info on this posted on the newsgroup, but anyone
within driving distance of Toronto and with a few days off (thank God
I'm a student) might enjoy this conference... I know I'm going to.
Mike
- -----Original Message-----
From: Maria Foudolova <[EMAIL PROTECTED]>
To: <unlisted-recipients:; (no To-header on input)>
Date: Thursday, June 10, 1999 1:12 PM
Subject: The Mathematics of Public-Key Cryptography, June 12 - June
17, 1999
Below please find the final Schedule for the above-noted workshop.
Conference on
The Mathematics of Public Key Cryptography
The Fields Institute for
Research in the Mathematical Sciences
Toronto, Ontario
June 12 - 17, 1999
PROGRAM SCHEDULE
SATURDAY, JUNE 12 - 7:00 - 10:00 p.m.
Reception
SUNDAY, JUNE 13
8:45 Opening Remarks
Morning Session Chair: Jeff Hoffstein, Brown University
9:00 The Industry of Public-Key Cryptography
Paul Van Oorschot, Entrust Technologies
10:00 Break
10:30 Elliptic curve cryptography in the real world
Alfred Menezes, University of Waterloo
11:30 Efficient implementation of elliptic curve cryptography
Scott Vanstone, University of Waterloo
12:30 Lunch
Afternoon Session Chair: Neal Koblitz, University of Washington
2:00 A sublinear-time parallel algorithm for integer modular
exponentiation
Jon Sorenson, Butler University
2:30 A lattice-based public-key cryptosystem
Tom Cusick, SUNY Buffalo
3:00 Computing discrete logarithms in quadratic orders
Mike Jacobson, University of Waterloo
3:30 Break
4:00 Guaranteed message authentication faster than MD5
Dan Bernstein, University of Illinois, Chicago
4:30 Inversion in optimal extension fields
Dan Bailey, Worcester Polytechnic Institute
5:00 Comparison of algorithms to calculate quadratic irregularity of
prime numbers
Joshua Holden, University of Massachusetts
MONDAY, JUNE 14
Morning Session Chair: Edlyn Teske, University of Waterloo
9:00 Analysis of the Xedni-Calculus attack
Neal Koblitz, University of Washington
10:00 Break
10:30 Cryptographic constructions based on Galois actions
Gerhard Frey, University of Essen
11:30 Hyperelliptic function fields and cryptography
Andreas Stein, University of Waterloo
12:30 Lunch
Afternoon Session Chair: Herman te Riele, CWI
2:00 Catching kangaroos in function fields
Edlyn Teske, University of Waterloo
2:30 Efficient undeniable signature schemes based on ideal arithmetic
in quadratic orders
Sachar Paulus, KOBIL Computer
3:00 Algorithms for computations in the jacobian group of C_{ab}
curves and their applications
Arita Seigo, C & C Media Research Laboratories
3:30 The discrete logarithm problem in the jacobian of hyperelliptic
curves
Mark Bauer, University of Illinois
4:00 Break
4:30 Lattices and Cryptography
Jeff Hoffstein, Brown University
6:30 Number Theory Foundation Party
TUESDAY, JUNE 15
Morning Session Chair: Andrew Odlyzko, AT&T Bell Laboratories
8:30 Low degree polynomials
Don Coppersmith, IBM
9:30 Two contradictory conjectures concerning Carmichael numbers
Carl Pomerance, University of Georgia
10:30 Break
11:00 Class groups in cryptography
Johannes Buchmann, Technical University of Darmstadt
12:00 Speeding up the discrete log computation on curves with
automorphisms
Francois Morain, Ecole Polytechnique LIX
WEDNESDAY, JUNE 16
Morning Session Chair: Andreas Stein, University of Waterloo
9:00 Factorization of RSA-140 using the number field sieve
Herman te Riele, CWI
10:00 Break
10:30 Improved polynomial selection for the number field sieve
Brian Murphy, Australian National University
11:30 Recent progress on the discrete logarithm problem in finite
fields
Oliver Schirokauer, Oberlin College
12:30 Lunch
Afternoon Session Chair: Oliver Schirokauer, Oberlin College
2:00 Strategies in filtering in the number field sieve
Stefania Cavallar, CWI
2:30 Implementing the number field sieve for F_{p^2}
Damian Weber, Institut f�r Techno and Wirtschaftsmathematik
3:00 The elliptic curve discrete logarithm problem
Julia Chen, Tamkang University
3:30 Break
4:00 A method of constructing elliptic curves with nonsmooth orders
Doug Kuhlman, University of Illinois
4:30 Elliptic divisibility sequences and the discrete logarithm
problem
Nelson Stephens, University of London
5:00 Computing discrete logarithms in high-genus hyperelliptic
jacobians in provably subexponential time
Andreas Enge, University of Augsburg
7:00 Banquet at Casaloma
THURSDAY, JUNE 17
Morning Session Chair: Brian Murphy, Australian National University
8:30 Error-correcting codes and cryptography
Harald Niederreiter, Austrian Academy of Sciences
9:30 Security: definitions, assumptions, and proofs
Victor Shoup, IBM Zurich
10:30 Break
11:00 P-adic Numerical Analysis
Eric Bach, University of Wisconsin
12:00 Security in the random oracle + generic model
Claus Schnorr, University of Frankfurt
12:30 End of Conference
=====BEGIN PGP SIGNATURE=====
Version: PGP 5.5.5
iQA/AwUBN2BNcP5WqcMdbVvFEQKaBwCg4nRAsBgGWViumPNFqFD4EGvd9DYAoLA1
rdeJMZV224Fei3IP3JAPgaBF
=vyr/
=====END PGP SIGNATURE=====
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Thu, 10 Jun 1999 23:23:46 +0200
Thomas Pornin wrote:
>
> According to Paul Koning <[EMAIL PROTECTED]>:
> [initial and final permutations in DES]
> > Fortunately, there are ways to do it in software that aren't all that
> > expensive.
>
> Bitslice comes to mind. Since this is only routing of data, it is free.
> However, bitslicing is really efficient for DES only when enciphering a
> big block of data in ECB mode, or when programming a password-cracker.
>
DES was designed to be slow in software - the NSA wanted it to be used
in hardware devices only. Hardware devices can be regulated much more
than software.
Running DES in software on a '70s CPU would have been incredibly slow.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Cracking DES
Date: Thu, 10 Jun 1999 23:20:57 +0200
Greg Bartels wrote:
>
> "It ("Cracking DES") describes a computer built out of custom
> chips. A machine that 'anyone' can build; from the plans it presents
> --- a machine that can extract DES keys in days at reasonable prices,
> or hours at high prices. With the appearance of this book and the
> machine it represents, the game changes forever. It is not a question
> of whether DES keys can be extracted by exhaustive search; it is a
> question of how cheaply they can be extracted and for what purposes."
This has always been the case, this book has just put a definite
price on the machine. That price is $250,000 for the entire research
and development of a machine which cracked last years DES challenge
in 56 hours.
Now we've got the book the R&D is done so it should be even cheaper.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Cracking DES
Date: Thu, 10 Jun 1999 23:18:08 +0200
Patrick Juola wrote:
>
> Well, first, to the best of my knowledge, there have never been any
> published claims that single DES would require 'more time to crack
> than the universe is old'.
The director of the FBI said this last year at a press conference or
something (preaching to the unwashed masses).
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Cracking DES
Date: 10 Jun 1999 17:02:10 -0400
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
>
>Patrick Juola wrote:
>>
>> Well, first, to the best of my knowledge, there have never been any
>> published claims that single DES would require 'more time to crack
>> than the universe is old'.
>
>The director of the FBI said this last year at a press conference or
>something (preaching to the unwashed masses).
I doubt it. If so, that's proof positive that he doesn't know
what he's talking about.
-kitten
------------------------------
From: smoke_em <[EMAIL PROTECTED]>
Subject: Re: I challenge thee :)
Date: Thu, 10 Jun 1999 19:50:23 +0200
[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.
For a wordsize of 8 bits, the number alone speaks for itself unless the
key becomes very very long.
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.
If i extend wordsize to 32bits, i think you get the point. Admitted, at
this point it looks more like a block cipher than a substitution cipher
and the pasc dictionary begins to look like a ECB for a block cipher -
not surprising since any block cipher run in ECB mode is simple
substitution equivalent with a dictionary of 2^keysize entries.
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.
Perhaps i know far too little (in fact next to nothing) about
cryptanalysis, but i thought there might be some work involved to
decipher a ciphertext of this type, given the algorithm and some part of
the plaintext.
------------------------------
** 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
******************************
