Cryptography-Digest Digest #724, Volume #9 Tue, 15 Jun 99 15:13:03 EDT
Contents:
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (Nick Barron)
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (Nick Barron)
Re: stream ciphers ([EMAIL PROTECTED])
Re: sbox design ([EMAIL PROTECTED])
Re: Key Schedule Question ([EMAIL PROTECTED])
Re: Has this cipher been broken yet ? ([EMAIL PROTECTED])
Re: TEA vs Blowfish ([EMAIL PROTECTED])
Algorithm from easy spec please! ("Kenneth N Macpherson")
Re: Speed comparison of RSA/DES/SHA1 ("Bruce Geist")
Re: Speed comparison of RSA/DES/SHA1 ("Gernot Schuh")
Re: Export restrictions question (Jim Gillogly)
Re: TEA vs Blowfish (Paul Rubin)
Re: Algorithm from easy spec please! (Mok-Kong Shen)
Re: [Q]: Session key exchange (Paul Rubin)
[Q]: Session key exchange (Jyrki O Saarinen)
Re: Book Usefulness Question ("Anton Stiglic")
Re: [Q]: Session key exchange (Thierry Moreau)
Re: Algorithm from easy spec please! ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nick Barron)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Tue, 15 Jun 1999 13:39:42 GMT
On Mon, 14 Jun 1999 21:13:37 GMT, [EMAIL PROTECTED] wrote:
>On Mon, 14 Jun 1999 20:44:06 GMT, [EMAIL PROTECTED]
>(John Savard) wrote:
>
>
>>Not to keep criticizing you for being helpful, but I doubt the United
>>States has annexed Germany any time lately...
>You never know....
Surely NATO's maps aren't *that* bad! :)
Nick Barron
SGML/XML Systems and Applications Development Manager
Solvera Information Services Ltd
Disclaimer: The views expressed in this message are mine,
not necessarily those of my company
------------------------------
From: [EMAIL PROTECTED] (Nick Barron)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Tue, 15 Jun 1999 13:39:09 GMT
On Mon, 14 Jun 1999 14:31:52 +0200, chciago <"gabriel.
nock"@siemens.de> wrote:
>hey, i wanted to implement the IDEA-algorythm by the sources in bruce
>schneiers book....
>
>is there a fault in this codes, or am i only too silly, to copy code
>from a book, but : "it doesn't work"
>
>or where can I find sources of IDEA which are working, I only want to
>use it for myself, not in a commercial way..
>
Have a look at ftp.replay.com in pub/crypto/crypto/applied-crypto and
you'll find the full source set from the book.
Nick Barron
SGML/XML Systems and Applications Development Manager
Solvera Information Services Ltd
Disclaimer: The views expressed in this message are mine,
not necessarily those of my company
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: stream ciphers
Date: Tue, 15 Jun 1999 13:39:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote:
> From 1993 SEAL (Software-Optimized Encryption Algorithm), see
> _Handbook of Applied Cryptography_ Section 6.4.1 pages 213-216.
> If you are a citizen of the United States of America, currently
> residing in the U.S., then you can obtain a C implementation of
> Algorithm 6.68 (SEAL 2.0) from the _Handbook..._ by writing me at the
> following address requesting SEAL 2.0.
I would look for SEAL 3.0 which is avail from my website :) at
http://mypage.goplay.com/tomstdenis/block.html
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: sbox design
Date: Tue, 15 Jun 1999 13:31:59 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> Here's where Entrust has the CAST papers:
> http://www.entrust.com/downloads/whitepapers.htm
>
> A "bent" function is a nonlinear boolean function of several
> inputs and outputs. You need to get hold of Carlile's paper
> "Good S-boxes are hard to find", it describes everything you
> want to know in lots of detail. If you can't find it in your
> library, I'll snail mail a copy to you.
I would really appreciate that, if you have a copy to spare I could get
you my address in private email. I will take a look at the sight too.
(btw, my library would not have it since they don't believe in books
from this half of the millenium... :) )
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: Key Schedule Question
Date: Tue, 15 Jun 1999 13:36:04 GMT
In article <[EMAIL PROTECTED]>,
"Timothy Kordas" <[EMAIL PROTECTED]> wrote:
> I'm still working through a bunch of material about cryptanalysis;
> but most of what I've read so far concerns itself primarily with
> the encryption-function portion of a few different algorithms. Are
> there any good references out there about key scheduling ?
In general you want all subkeys to be the same size. This is obvious.
Each subkey should effect the others, which means that if a bit changes
in the master key it will propagate in the entire set of subkeys. The
subkeys should be independant as well, which means if one becomes
compromised then the others will not be (Blowfish is a good example of
this). The same techniques used in the round function should be used
subkeys (diffusion, non-linearness, etc...)
> How safe is it to use something like an LFSR (seeded with the key)
> to generate subkeys ?
Not very. If one some round keys become known then one could solve for
the master key with some linear algebra. Basically for the same reason
single LFSR stream ciphers are insecure.
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: Has this cipher been broken yet ?
Date: Tue, 15 Jun 1999 13:47:43 GMT
In article <[EMAIL PROTECTED]>,
Anonymous <[EMAIL PROTECTED]> wrote:
> Hello Tom,
> Thanks for replying.
> Atbash2
> Developed by Michael Paul Johnson approx 1995
> Use the Sapphire II stream cipher.
> Dos file name ATBASH2.ZIP
> Download from ftp.replay.com/pub/replay/pub/file
>
> Once again thanks for your interest.
I took a look. It reminds me of RC4 too much. I think you may be
better off with RC4. I don't think SAPHIRE is weak but it certainly is
more complex.
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: TEA vs Blowfish
Date: Tue, 15 Jun 1999 13:29:17 GMT
In article <[EMAIL PROTECTED]>,
Peter Gunn <[EMAIL PROTECTED]> wrote:
> Going by the recommended number of rounds... 18 for Blowfish,
> and 32 for TEA (or XTEA), Blowfish is ~twice as fast.
A fully optimized TEA/XTEA implementation should be about as fast as
Blowfish (maybe a bit slower).
> > Is there a clear cut advantage in security for one over the other?
> > If so why?
TEA is much simpler then Blowfish to code. Blowfish however has better
avalanche properties. The diffusion in TEA is rather symmetrical
(always 9 bits apart (x<<5^x>>4)) I don't know if that can be exploited
though.
> TEA apparently has some known weaknesses (broken with 2^32
> known plaintexts etc), but XTEA looks ok and is unbroken as far
> as I know (Mr Wagner might know better :-)
I think it was broken much faster, I would suggest using XTEA though
just to be sure.
Just a question have the authors thought of an ALPHA 64 version? It
probably would have to use another feedback function (maybe with some
composite odd multiplicand...).
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: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Algorithm from easy spec please!
Date: Tue, 15 Jun 1999 15:27:30 +0100
Hello,
If someone knows of a way to do this I would be grateful!
Need to take the numbers 32 to 126 inclusive and insert them into an array
randomly based on a key (of numbers).
The numbers in the key will all be in the range 32 to 126.
It is a simple lookup table.
Pseudo code would be brilliant and vb code would be fantastic!
Thanks in advance,
Cheers,
Ken
------------------------------
From: "Bruce Geist" <[EMAIL PROTECTED]>
Subject: Re: Speed comparison of RSA/DES/SHA1
Date: Tue, 15 Jun 1999 11:33:44 -0500
Note that the length of amessage will affect hashing time-- for example, if
you have a five megabyte message that needs to be signed, then SHA1 might be
SLOWER than the RSA signing operation.
As I recall, the RSA website used to have timing information for various
platforms. The timings are for their Bsafe software, a crypto tool kit they
sell. Bruce Geist
Gernot Schuh wrote in message <7k5lqj$6v1$[EMAIL PROTECTED]>...
>RSA generation is about 10,00 times slower than a hash function and RSA
>verifcation is about 100 times slower than one SHA operation. Those are
very
>fough benchmarks I found.
>
>Does anybody know where I can find some more detailed information about the
>speed of RSA, DES and SHA in comparison?
>
>Gernot
>
>
------------------------------
From: "Gernot Schuh" <[EMAIL PROTECTED]>
Subject: Re: Speed comparison of RSA/DES/SHA1
Date: Tue, 15 Jun 1999 17:45:22 +0100
===== Original Message =====
From: fungus <[EMAIL PROTECTED]>
Newsgroups: sci.crypt
Sent: Tuesday, June 15, 1999 6:03 PM
Subject: Re: Speed comparison of RSA/DES/SHA1
>
>
> Gernot Schuh wrote:
> >
> > RSA generation is about 10,00 times slower than a hash function
> > and RSA verifcation is about 100 times slower than one SHA operation.
> > Those are very fough benchmarks I found.
> >
>
> That's probably right, SHA is designed to be speedy.
>
> Unfortunately, you're comparing apples with oranges.
> RSA and SHA are do two completely different things.
> One is a public key signature, and other is a one-way
> hash.
>
I know, but when designing payment protocols, one can make tradeoffs between
using
lots of hash operation and reducing the number of public key operations ...
I am also aware that hasing depends on the input length (as does DES and
3DES) and
RSA depends on the key size.
What I am looking for is a comparison of those algorithms on the same
platform
e.g. DES: x Mbits/s, SHA y kbytes/s, and RSA 1024bit one signature
generation, one signature verification
Gernot
> The important difference is not the speed but what each
> algorithm actually does.
>
>
> --
> <\___/>
> / O O \
> \_____/ FTB.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Export restrictions question
Date: Tue, 15 Jun 1999 10:07:13 -0700
"SCOTT19U.ZIP_GUY" wrote:
>
> In article <7k4mk8$irp$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bill Unruh) wrote:
> >Of course if the Bernstein case is upheld the regulations will be
> >replaced by others just as silly and you will still need a license.
>
> Interesting I thought the Bernstien case was such that no license
> scheme would be required. Do you say this because it is the law or just
> using hisrory as a a fact that the politicians never follow what the court
> rules as one of constitutional rights.
The challenges to the ITAR controls on crypto were said to be one of the
reasons crypto was moved from ITAR (State Dept.) to EAR (Commerce Dept.).
Clinton said in a 15 Nov 1996 memo regarding the this transfer of control
that if adequate controls on encryption couldn't be maintained under this
new arrangement, control over crypto would be shifted back to the ITARs.
I leave it to you to guess whether a final Bernstein victory would lead to
what the White House would regard as adequate controls on encryption.
Think of it as a shell game. If the mark starts reaching for the one
that has the pea under it, a little sleight of hand moves it out of reach
again.
You expected them to play fair, after all this time? Ah, I remember when
I was that young and naive.
--
Jim Gillogly
Sterday, 25 Forelithe S.R. 1999, 16:59
12.19.6.5.0, 4 Ahau 8 Zotz, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: TEA vs Blowfish
Date: Tue, 15 Jun 1999 17:11:32 GMT
Dave Hazelwood <[EMAIL PROTECTED]> wrote:
>I have maybe one more option and that is RC4. It is the fastest right?
>How does it stack up to TEA and Blowfish in terms of security and
>ease of coding?
RC4's security appears to be reasonably good. However, it is not
directly comparable to TEA or Blowfish since it is a stream cipher
and not a block cipher. You have to make sure to never use the same
key twice.
All these ciphers are easy to code, by the way. RC4 is probably easiest.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Algorithm from easy spec please!
Date: Tue, 15 Jun 1999 18:25:30 +0200
Kenneth N Macpherson wrote:
>
> Need to take the numbers 32 to 126 inclusive and insert them into an array
> randomly based on a key (of numbers).
>
> The numbers in the key will all be in the range 32 to 126.
>
> It is a simple lookup table.
>
> Pseudo code would be brilliant and vb code would be fantastic!
Fill your array with the numbers 32 to 126 consecutively. Then
use a pseudo-random number generator delivering real-valued numbers
in [0,1) to perform a random permutation using the algorithm
of Dustenfeld (see Knuth's book, vol. 2).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: [Q]: Session key exchange
Date: Tue, 15 Jun 1999 17:47:15 GMT
In article <7k609m$co1$[EMAIL PROTECTED]>,
Jyrki O Saarinen <[EMAIL PROTECTED]> wrote:
>Is it feasible to implement a Diffie-Hellman key exchange
>where the other end is equipped with a 10MHz Hitachi H8/S CPU
>(2 cycles for simple operations) while the other end is a
>normal PC? How long this key exchange would take?
>
>The need for a session key would be likely something
>like few times in a minute.
I'm not familiar with the H8/S and don't know what a "simple
operation" is on it. The operation that matters is integer multiplication.
Unless the H8/S has a parallel multiplier (doubtful) or a DSP extension,
multiplication will take much more than 2 cycles.
It's doubtful to me whether you could do several key exchanges in
a minute.
>I read estimated of ~one second on a 20MHz 68030 which
>is probably ~2-3x faster than our target CPU.
I think the 68030, which is basically a 32-bit cpu, will be far
more than 2-3x faster, especially for this. More like 10x-100x.
>What other methods there are, a key distribution
>center doesn't sound too good for a dynamic environment.
If you have to use public key and one end of the connection has a fast
cpu (e. g. a Pentium or something), you could do RSA. The Pentium end
would supply an RSA public key. The H8 would generate a session key
and encrypt it with low-exponent RSA (which is much faster for
encryption than DH key exchange). The Pentium would then decrypt
and use the session key (RSA decryption is slower than encryption).
You could probably do this in a few seconds or less on the H8.
I'm skeptical that you need public key methods at all. If you
describe your application in more detail I may be able to make
other suggestions.
------------------------------
From: Jyrki O Saarinen <[EMAIL PROTECTED]>
Subject: [Q]: Session key exchange
Date: 15 Jun 1999 16:51:02 GMT
Is it feasible to implement a Diffie-Hellman key exchange
where the other end is equipped with a 10MHz Hitachi H8/S CPU
(2 cycles for simple operations) while the other end is a
normal PC? How long this key exchange would take?
The need for a session key would be likely something
like few times in a minute.
I read estimated of ~one second on a 20MHz 68030 which
is probably ~2-3x faster than our target CPU.
What other methods there are, a key distribution
center doesn't sound too good for a dynamic environment.
------------------------------
From: "Anton Stiglic" <[EMAIL PROTECTED]>
Subject: Re: Book Usefulness Question
Date: Tue, 15 Jun 1999 13:30:22 -0400
I will also say the same thing, it's a great book but not to be read
as light lecture.
Doug Stinson's book is good to learn the more theoretical aspect.
Anton
consalus wrote in message <[EMAIL PROTECTED]>...
>Alright.
>I decided I want to learn about cryptography.
>I got Applied Cryptography and read it.
>I've been reading papers on simple ciphers.
>Just recently, I found what seems to be a really
>great paper on Tom St. Denis's site on cryptoanalysis.
>Now, I'm finding myself with a sudden excess of cash, and
>so I was looking at Handbook of Applied Cryptography
>by Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone
>(ISBN: 0-8493-8523-7). I imagine somebody in here has read it
>once or twice, and so I just thought I should ask: It is worth getting?
>
>Thanks,
>
>Kyle Consalus
>
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: [Q]: Session key exchange
Date: Tue, 15 Jun 1999 14:05:52 -0400
Jyrki O Saarinen wrote:
>
> Is it feasible to implement a Diffie-Hellman key exchange
> where the other end is equipped with a 10MHz Hitachi H8/S CPU
> (2 cycles for simple operations) while the other end is a
> normal PC? How long this key exchange would take?
>
> The need for a session key would be likely something
> like few times in a minute.
>
> I read estimated of ~one second on a 20MHz 68030 which
> is probably ~2-3x faster than our target CPU.
>
> What other methods there are, a key distribution
> center doesn't sound too good for a dynamic environment.
[A] There is a reference from a serious source setting a 150 seconds
time-out (yes, two and a half minutes!) for the completion of a DH
primitive (presumably with the type of processor that you have).
[B] As Paul Rubin hinted, you should consider public key cryptography
only for initial key agreement, and then use secret key re-keying upon
e.g. loss or synchronization.
[C] The "Beller-Yacobi" protocols adresses your concerns about
performance, with authentication in both directions (a broader
requirement than your posting). The latest "Beller-Yacobi" protocol is
disclosed in US patent document 5,406,628, Beller, Michael J., Yacobi,
Yacov, Public Key Authentication and Key Agreement for Low-cost
Terminals, April 11, 1995 (application number 101,437, August 2, 1993),
assigned to Bell Communications Research, Inc.
[D] The suggestion to use RSA is a good direction. The Beller-Yacobi
protocols use the Rabin cryptosystem which is even more efficient than
RSA.
[E] You might consider PEKE (probabilistic encryption key exchange) as
an alternative to DH. PEKE is disclosed in Moreau, Thierry,
Probabilistic Encryption Key Exchange, Electronics Letters, vol. 31,
number 25, 7th December 1995, pp 2166-2168
[F] If you need on-line registration of new users where potential users
need to be billed or otherwise authorized at an administrative level,
then you might be interested in SAKEM (Secret Authentication Key
Establishment Method). SAKEM is disclosed in Moreau, Thierry, Initial
Secret Key Establishment Including Facilities for Verification of
Identity, Patent Cooperation Treaty (PCT) International application
number 9852316A1 (PCT/CA 98/ 00431), filed on May 7th, 1998, priority
date based on provisional U.S. patent application number 60/046.047,
filed on May 9th, 1997, published by the PCT International Bureau on
November 19th, 1998, CONNOTECH Experts-conseils Inc., Montreal, Canada
That's about as much free advice as I can provide! You are welcome to
contact me for further assistance.
- Thierry Moreau
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Algorithm from easy spec please!
Date: Tue, 15 Jun 1999 17:34:03 GMT
<snip>
Here is my idea.
1. Create 16 tables which are substitution tables. So they contain
each char once, and only once (it has to be invertible). Each table
will be different but keyed from the master key somehow.
2. Create an 16 element array of the numbers 0..15. This too will be
shuffled using the key.
3. Take your range 33-126 and convert it to 0-93 by subtracting 33 from
each input char.
4. Take this char and run it thru all the substituion tables use the
order as created in #2. So you take the char and use it as an index
into the tables recursively. The #2 array will determine the
substitution table order usage.
5. Swap two elements of array #2
6. Goto #3 as required.
To decrypt you will run the chars backwards and perform the same
operations.
I will leave it as an execise for you to figure out how to key the
tables. HINT #2 can be done using the RC4 shuffle.
This should provide about as much security as you said you need. With
16 tables you can encode 2^44 chars which I think is enough for your
purposes. The keysize is small but the average job blow probably will
not be able to brute force it. (If you need to enhance it use a larger
data space).
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
******************************
