Cryptography-Digest Digest #547, Volume #11      Fri, 14 Apr 00 13:13:01 EDT

Contents:
  I was told that Markku had penetrated to two main technological universities in 
Finland and dumped his intelligence notes to their servers for training .. 
([EMAIL PROTECTED])
  Re: Regulation of Investigatory Powers Bill (Spiked)
  Re: One way hashing function (Runu Knips)
  Re: The use of Three DES (John Savard)
  Re: SHA2 (Runu Knips)
  ? Backdoor in Microsoft web server ? (Francois Grieu)
  Re: AND on encrypted data (John Savard)
  Re: The use of Three DES (Runu Knips)
  Re: The use of Three DES (Runu Knips)
  Re: SHA2 (John Savard)
  Re: One way hashing function (John Myre)
  Re: ? Backdoor in Microsoft web server ? (JPeschel)
  ANN: Better optimized version of Serpent. (Gisle Sælensminde)
  Re: ? Backdoor in Microsoft web server ? (Francois Grieu)
  Re: ? Backdoor in Microsoft web server ? (Tim Tyler)
  Re: Q: Entropy (James Felling)
  Re: BlowWire ([EMAIL PROTECTED])
  Re: Regulation of Investigatory Powers Bill (Mikey B)
  Re: GSM A5/1 Encryption (Paul Koning)
  Re: Is AES necessary? (Paul Koning)
  Re: ___SPEED of HARDWARE Crypto Processors (Paul Koning)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: I was told that Markku had penetrated to two main technological universities 
in Finland and dumped his intelligence notes to their servers for training ..
Date: Fri, 14 Apr 2000 14:54:24 GMT



I was told that Markku (Markku J. Saarelainen (at this time living in
Miami, FL) had penetrated to two main technological universities in
Finland and dumped his intelligence notes to their servers for
training. One of these universities was Technological University of
Helsinki, Finland's main university. They tell me that he had provided
the great number of his notebook entries for their cryptography and
encryption students and class. This had prompted both universities to
change their internal security arrangements. It is likely that his
actions had benefited these universities both to improve their internal
neural network, computer network security and their course materials
and training.

There are also some reports that he may have communicated the large
number of Finland's elite (the highest level) business and
technological researchers, educational faculty members and other people
and informed about specific intelligence and encryption matters. They
tell that these people included the highest level of Finland's
university, government and media structures - most likely the major
portion of the Finland's communication and media infrastructure.

One person emailed me and told that Markku J. Saarelainen had had some
communications with Finland's Minister for Trade, Industry and
Commerce, Kimmo Sassi, (or something) in 1999 and his secondary contact
persons. It seems that it is no wonder why the U.S. Intelligence
Community went after him. It may have been Markku's own ploy and the
game to take the whole U.S. Intelligence Community (those who were
after him) down while he knew all the time what he was doing and wanted
to die. Well, this is just my estimation and analysis.

What do you think?

BRIVET,

VLADIMIR


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Spiked <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Fri, 14 Apr 2000 14:57:00 GMT

even if there is not itteligent life out there it is most likely not
random (read some A. Church) random means that there is NO algorithm
that could generate the string. chaotic is NOT equal to random

Peace
Spiked

Scotty schrieb:
> 
> Jill wrote in message <[EMAIL PROTECTED]>...
> >Further to my previous posting I believe that suitable, genuinely random
> >data can be obtained, free of charge, from the SETI screensaver
> >project!!!
> 
> It's not random if there's intelligent life out there :)

-- 
New URL and NEW contents:
http://spikedvodka.cjb.net/
Check The site for my latest Geek code block please.
PGP Public code availible from servers, or on request.
OR from the website!!

------------------------------

Date: Fri, 14 Apr 2000 17:01:11 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: One way hashing function

[EMAIL PROTECTED] schrieb:
> 
> Dear all,
> 
>   Would you mind telling me where can I find any one-way hashing
> algorithm? TIA.
> 
> Thanks,
>   Simon
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Many places. For example, www.openssl.org, www.gnupg.org,
Tom St Denis' Cryptobag ....

Just search for SHA-1 and RIPE MD160, they are the best
ones at the moment.

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The use of Three DES
Date: Fri, 14 Apr 2000 15:06:42 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>lordcow77 wrote:

>> What exactly is this "Fermat factoring method?"

>Factoring via Difference of squares.  It's in Knuth and I believe HAC.

I have a book about mathematical recreations in number theory which
gives an excellent description of it.

Since (a+b)(a-b) = a^2-b^2, the product of two odd numbers that are
close together is equal to a large square number (the square of the
larger of the two numbers plus half the difference between the two
numbers) minus a small square number (the square of half the
difference between the two numbers).

If one could, by looking at how it fails for one large square, proceed
directly to a distant large square, rather than changing the square by
one each time, one would have a significantly faster factoring method.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

Date: Fri, 14 Apr 2000 17:04:07 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: SHA2

Diet NSA wrote:
> In article <[EMAIL PROTECTED]>, Runu Knips 
><[EMAIL PROTECTED]> wrote:
> >One of my professors was the inventors of lsd-trees, which
> >are used to sort twodimensional data. Unfortunately, I never
> >found out how they work ;-)
> Here is an explanation of how they work:
> http://www.vldb.org/conf/1989/
> P045.PDF

Hey thank you ! :) thats a nice paper for weekend :)

------------------------------

From: Francois Grieu <[EMAIL PROTECTED]>
Subject: ? Backdoor in Microsoft web server ?
Date: Fri, 14 Apr 2000 17:07:00 +0200

Disclaimer: I have NOT verified this story, which may be bogus.

According to <http://cbs.marketwatch.com>, citing The Wall Street 
Journal, Microsoft has acknowledged the existence of a "backdoor" in one 
of it's consumer web server software. Knowledge of a global password 
would grant [?read-all?] privileges on thousands of deployed web servers.

The backdoor is said to be in "dvwssr.dll", containing text [?related to 
the password?] "Netscape engineers are weenies!".

Anyone can confirm this story ?

   Francois Grieu



sources (these URL may be short-lived):

<http://cbs.marketwatch.com/news/current/msft.htx?source=htx/http2_mw>

<http://aolpf.marketwatch.com/source/blq/aolpf/news/current/press_briefin
g.asp>

<http://www.marketwatch.newsalert.com/bin/story?StoryId=CopAxWdicvJa2mtC&;
FQ=Microsoft&ED=04/14/2000&Title=Headlines%20for%3A%20Microsoft%0A#Hilite
>

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AND on encrypted data
Date: Fri, 14 Apr 2000 15:12:19 GMT

Claudio Di Flumeri <[EMAIL PROTECTED]> wrote, in part:

>Does anyone know if there are encryption schemes that allow logical
>operations (AND, OR, NOT) on encrypted data?

XOR by itself is allowed between an unencrypted value and data
encrypted by being XORed to some stream cipher output.

Multiple texts that are encrypted by the same bit transposition can be
XORed, ANDed, or ORed with one another.

To allow more than this, one could do the following - use a key from a
stream cipher, and do this:

plaintext    key    output
   0          0       01
   1          0       10
   0          1       10
   1          1       01

If the key is 0, the first bit is the plaintext bit, if it is 1, the
second bit is the plaintext bit.

Take the values you wish to AND, OR, or XOR to the ciphertext, and
double each bit in them; thus, 1010 becomes 11001100.

Then, decrypt by picking the bit that started out as the plaintext bit
(instead, say, of XORing to the first bit of the pair and ignoring the
second bit), and you get the plaintext after the AND, OR, and XOR
operations.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

Date: Fri, 14 Apr 2000 17:19:32 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: The use of Three DES

Tom St Denis wrote:
> Why use old technology?

Well not long ago I told someone (who was also a computer
science student) AMD has released a very good new i386
compatible cpu, the Athlon. He said he would still prefer
to buy Intel, because that is more "secure".

Or the well-known statement (of the past?) "nobody got
ever fired for buying an IBM computer".

Its always the same: people have used it for ages, now
it is "good" just because they know it so well.

------------------------------

Date: Fri, 14 Apr 2000 17:25:34 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: The use of Three DES

Paul Rubin wrote:
> IDEA is not especially faster than single DES (though it's faster than
> 3des) and like RC5, it's patented.

AFAIK DES is really slow, except if you have DES hardware. The main
problem is to split the input bits into the format needed for DES,
which can be very efficiently handled by hardware, but is a hard
job for modern computer instruction sets.

> One that you left out is CAST (e.g. the CAST-128 used in PGP 5).
> While it's patented, it's free to use.  It needs some large fixed
> tables but the key schedule is nowhere near as large as Blowfish's.
> It's a good choice for many applications.

Hmm my own Twofish implementation needs > 4 KB key schedule, too...

> Basically people use 3DES because it's tried and true.  Why take some
> experimental drug with unknown side effects to cure a headache if
> ordinary aspirin will do the job?

Because its slow ?

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SHA2
Date: Fri, 14 Apr 2000 15:20:42 GMT

[EMAIL PROTECTED] wrote, in part:

>3. Be totally incomprehensible, such as UTC. HAS - letters jumbled to
>   appease part of the standards body.

In this case, it would be Norme des Hashes avec Securite, or something
like that, but no part of NIST represents a French-speaking region,
which is the usual reason for jumbling the letters.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: One way hashing function
Date: Fri, 14 Apr 2000 09:24:42 -0600


>   Would you mind telling me where can I find any one-way hashing
> algorithm? TIA.

http://csrc.nist.gov/fips/fip180-1.txt
(or .pdf or .ps)

It even has test data.

------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: ? Backdoor in Microsoft web server ?
Date: 14 Apr 2000 15:41:04 GMT

[EMAIL PROTECTED] writes:



>Disclaimer: I have NOT verified this story, which may be bogus.
>

Why do you think it might be bogus?.

>According to <http://cbs.marketwatch.com>, citing The Wall Street 
>Journal, Microsoft has acknowledged the existence of a "backdoor" in one 
>of it's consumer web server software. Knowledge of a global password 
>would grant [?read-all?] privileges on thousands of deployed web servers.
>
>The backdoor is said to be in "dvwssr.dll", containing text [?related to 
>the password?] "Netscape engineers are weenies!".
>
>Anyone can confirm this story ?

Read the WSJ story.

Joe


__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------

From: [EMAIL PROTECTED] (Gisle Sælensminde)
Subject: ANN: Better optimized version of Serpent.
Date: 14 Apr 2000 17:48:58 +0200


A new implementation of the Serpent AES candidate cipher written
is now available. This is the currently fastest available 
implementation of Serpent, and encrypts with a speed of 32 Mbit/s
on a pentium pro 200. The formerly fastest algorithm encrypted
with a speed of 26 Mbit/s on the same computer. The implementation
is written in Ada.

The improvement is based on the optimized sbox functions of 
Dag Arne Osvik. A link to the source can be found at the Serpent
homepage. 

http://www.cl.cam.ac.uk/~rja14/serpent.html  - serpent home page
http://www.ii.uib.no/~gisle/serpent.html     - direct link

Dag Arne Osvik's paper on s-box optimization presented at AES3:

http://csrc.nist.gov/encryption/aes/round2/conf3/papers/26-daosvik.pdf

--
Gisle Sælensminde ( [EMAIL PROTECTED] )   

ln -s /dev/null ~/.netscape/cookies

------------------------------

From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Date: Fri, 14 Apr 2000 18:12:54 +0200

[EMAIL PROTECTED] (JPeschel) wrote:
> [EMAIL PROTECTED] writes:
>> Disclaimer: I have NOT verified this story, which may be bogus.
> Why do you think it might be bogus ?

No particular reason, except my only source is web press,
and I found no mention on the web site of Microsoft (allegedly
aware of the problem since yesterday) or ClientLogic
(allegedly involved in the backdoor's discovery).


> Read the WSJ story
does not appear to be online for free, and the paper
was unavailable at my (French) newspaper agent.


Who said: doubt until you have a proof, then doubt frequently ?


   Francois Grieu


An additional reference:
<http://news.cnet.com/news/0-1003-200-1696137.html>

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Apr 2000 16:01:35 GMT

Francois Grieu <[EMAIL PROTECTED]> wrote:

: According to <http://cbs.marketwatch.com>, citing The Wall Street 
: Journal, Microsoft has acknowledged the existence of a "backdoor" in one 
: of it's consumer web server software. Knowledge of a global password 
: would grant [?read-all?] privileges on thousands of deployed web servers.

: The backdoor is said to be in "dvwssr.dll", containing text [?related to 
: the password?] "Netscape engineers are weenies!".

See also:
http://news.cnet.com/news/0-1003-200-1696137.html?tag=st.ne.1002.thed.1003-200-1696137
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Be good, do good.

------------------------------

From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Fri, 14 Apr 2000 11:13:23 -0500



Mok-Kong Shen wrote:

> Bryan Olson wrote:
> >
> > > In
> > > the few texts that I happened to have glanced at I found that
> > > in the definition of the measure the string is said to be
> > > 'arbitrary' and there is no mention at all of 'infinite'. Now,
> > > according to common (non-explicit) conventions, 'arbitrary' means
> > > 'arbitrary finite' if used without explicitly adjoining 'infinite'.
> >
> > Hard to tell based on a one-word quote, but correct me if
> > I'm wrong: the meaning of 'arbitrary' in those definitions
> > is in the sense of arbitrarily large. If my interpretation
> > is correct on that, then consider the following three
> > questions:
> >
> >     Were the million-bit strings in the example arbitrarily
> >     large?  (The example from 2000-04-10 in which I claimed
> >     Kolmogorov complexity did not say which is more
> >     complex.)
> >
> >     If you have a finite set of (finite) strings, does it
> >     contain arbitrarily large strings?
>
> I personally think that it is a rather odd use of the word
> 'arbitrary' to imply 'arbitrary large' in the context of strings.
> Now, I happen to find the following:
>
>    For a Turing machine M_i, and a finite string x, the Kolmogorov
>    complexity of x with respect to M_i is defined as follows:
>
>         K_i(x) = min{ l | (ex y) |y| = l and M_i(y) = x }
>
>    K_i(x) = infinity if the above set is empty.
>
> on p.70 in O. Watanabe (Ed.) Kolmogorov Complexity and Computational
> Comlexity, Springer, 1992.
>
> Here one has only the term 'finite string', should I understand
> that the string's length has some implied (not given in the text)
> constriants, like the length must exceed certain fixed lower bound,
> etc. etc, or does it simply means ANY finite string that one chooses
> to pick out and examine? Thanks.
>
> M. K. Shen

Yes.  You will, however, note that what you are getting is "With respect to
M_i" and while this is a perfectly valid version of K-complexity, it is a
useless definition to allow entrophy comparison or other "inherent
k-complexity" comparisons between finite strings.

The reaon being that you are limited to a specific underlying model (M_i).
In the real world we will use the best available system which (probably) is
not M_i.  Certianly it does make sense to say versus this TM( or set of
TM's) this string S  has complexity X.  However, this in no way is
indicative of what the k-complexity if S is versus any other TM not within
the initially specified set.


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: BlowWire
Date: Fri, 14 Apr 2000 16:51:15 GMT

In article <3JwJ4.7089$[EMAIL PROTECTED]>,
  "Spleen Splitter" <Spleen*no spam*[EMAIL PROTECTED]> wrote:
> Greetings:
>
> I need something to crank on, so I decided to toy with something I
fancifully call
> BlowWire, which is simply a 500MHz or so fully pipelined
implementation of Blowfish
> in some modern technology, say 0.18um CMOS.

No one gets 500 Mhz without doing full-custom polygon pushing.
Damn cpu-hype clock inflation.

>Connecting two of these devices on a
> cable seems to have enough meat on it to provoke a discussion.

Think parallel, not picoseconds.


> I think I can do this in 60Kgates, with my biggest problem being all


One third of that, not including RAM and ROM.

the simultaneous
> accesses to pi during each clock (what a ROM, what wires!).

A K of 32-bit words is not too bad for a ROM.

> Given that I'm only doing Blowfish for fun, I'm fairly certain that
further enlightenment
> could be forthcoming on hardware implementations of
crypto-functions...

Its about 1200 lines of verilog not including the ROM :-)



=====
"There are no ifdefs in hardware."


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Mikey B <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,alt.computer.security
Subject: Re: Regulation of Investigatory Powers Bill
Date: Fri, 14 Apr 2000 18:05:32 +0100

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

There's little point, the first time a case comes to the courts, then
it will fall flat on it's face. If you have encrypted data on your
hard disk, and refuse to decrypt, the the law says that you can be
imprisoned. 

What this basically means is that they are removing the right of
indivduals in a criminal court to be tried as innocent until proven
guilty. This is a breach of at least the European Declaration of
human rights, and probably the Universal Declaration of Human Rights.

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Following a conversation regarding the Regulation of
> InvestigatoryPowers Bill, my colleague suggested I post the
> following proposal.Please comment:--It is possible, with a little
> co-operation, to defeat parts of theRegulation of Investigatory
> Powers Bill, 2000 (RIP, how appropriate!). Specifically the
> requirement to provide keys for encrypted files.  Allit requires is
> that a significant number of UK citizens form a protestgroup and
> place blocks of random data on their hard discs, by way ofprotest. 
> These blocks of data could have a standard ASCII header allongthe
> lines of:This file contains random data as a protest against the
> Regulation ofInvestigatory Powers Bill, 2000.  The data is not
> encrypted andtherefore no decryption key exists.There is no law
> against keeping files of random data and the protest, ofitself,
> provides the reason for having this data on your computer.  Itwould
> require the assistance of someone well versed in cryptography
> towrite a program to generate the random data so that it
> isindistinguishable from an encrypted file.  Key generator programs
> maywork, but this is by no means certain and I am not qualified to
> say oneway or the other.  Perhaps someone who is qualified could
> suggest aneasy means of doing this.  The best way of providing
> these files wouldbe to set up a web site which will email a
> ready-made block of data tothose requesting it.  There must be
> someone out there with the knowledgeand the inclination to set up
> such a site.Of course, certain dishonest individuals might use
> these protest filesto store real encrypted data, c'est la
> vie!Andrew Le Couteur Bisson 
- -- 

ø¤°`°¤ø,¸_¸,ø¤°`°¤ø,¸_¸,ø¤°
Mikey B

[EMAIL PROTECTED]
http://www.bsoft.co.uk
ø¤°`°¤ø,¸_¸,ø¤°`°¤ø,¸_¸,ø¤

=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.1i for non-commercial use <http://www.pgpi.com/>

iQA/AwUBOPYYeFw8xyeyXm3uEQKiIwCfc40CQvIhns4aBNltcvQ2JzHWTN8AoK0c
disKRKB1wQ5PZl8hbSbPTzeX
=b6mt
=====END PGP SIGNATURE=====

------------------------------

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Fri, 14 Apr 2000 12:15:35 -0400

[EMAIL PROTECTED] wrote:
> 
> In article <[EMAIL PROTECTED]>,
>   Paul Koning <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > > ...
> > > It would be true to say that a Stream Cipher is much faster for this
> > > type of application...
> >
> > Maybe true, maybe not, but irrelevant either way.  Block ciphers
> > can be done in software, never mind simple hardware, MUCH MUCH
> > faster than is needed here.
> >
> 
> It is not irrelavent..it is very relavent.. A good Stream Cipher would
> be much more cost effective in terms of silicon/speed...

Note I said "in software".  No silicon involved.

There's no need for the fastest possible cipher; the need is
for a sufficiently fast cipher.  Very different requirement.

It may be that the "stream ciphers are better" argument was
used as an excuse to avoid using a known good cipher.
 
> And I quote one of your messages from a thread below..."3 DES is very
> slow in software"....I think that answers your point...
> > And if you look at some popular crypto chips, you will probably
> > find they do DES and often 3DES faster than RC4.
> 
> No one is going to put a huge 1 inch square asic into a GSM...sorry we
> aint talking about a network crypto card here...

Fine, but again, you can do 3DES at GSM speeds in a few percent 
of DSP capacity.  Are you trying to tell me that these devices
are built so close to the limit that there isn't 2-3% idle time
in the DSP?

> > > I accept the fact that you can use a block cipher
> > > and it will be ok....that is if you have to include a second dsp
> into
> > > the phone...which is what Siemens did with their Topsec GSM
> > > phone..
> >
> > That's completely bogus.  As I said, you can do it in a spare
> > percent or two of the capacity of the one DSP you need.  Adding
> > a second one makes no sense whatsoever.
> >
> > > it uses a 128 bit symmetric cipher...the set up time is pretty
> > > lousey...20 secs...for DH etc
> >
> > Well, if you use sufficiently poor software I suppose it is
> > possible to get ridiculously poor performance.  On the other hand,
> > you can get DH setup using decent size keys (512 bits or better)
> > two orders of magnitude faster with a plain old PC.  So either those
> > people clocked their DSP at 1 MHz, or their compilers and/or
> > programmers are two orders of magnitude worse than gcc and the
> > FreeS/WAN team.
> 
> hmm...dont know...I am aware of two DH voice encryption ( 1024) which
> cloked out at least 20 seconds set up..by two different vendors...

Fine, I'll agree that it is possible for a vendor, and even
multiple vendors, to do an atrociously bad job.  On the other
hand, the various IPSEC implementation I have seen all  have
sub-second setup times.  I measured a wimpy old 166 MHz laptop
do a complete IKE exchange in about 300 ms, a year or two ago.

Another point: we weren't talking about key exchange, we were
talking about the data cipher.  The key exchange isn't affected
by whether you use a bad cipher like A5 or a good one.  That is,
unless you change it to use 256 bit DH so the key exchange is
weakened to match the data cipher...

        paul

------------------------------

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Fri, 14 Apr 2000 12:19:27 -0400

Mok-Kong Shen wrote:
> 
> Bryan Olson wrote:
> >
> 
> >
> > The way I see it, there are two advantages of staying with
> > DES.  First, it avoids incompatibility since it is what the
> > world uses now.  Second, it's already well examined, so less
> > likely to burn us.
> >
> > Variants of DES have neither of these advantages.  If we
> > plan to do all the work of analyzing and deploying an
> > updated cipher, we should go for the very best cipher we can
> > build.
> 
> Variation can take different forms/degrees. Do you think 3DES
> is a variant? If you think 3DES is o.k., would you object to
> 5DES (putting aside the speed issue)? How about using variable
> keys for different blocks? Note that all these don't 'manipulate'
> the module DES as such.

Right, and not all of those have security benefits.

For example, using different keys for different blocks -- I assume
that means using a small number of keys in rotation.  That is
a very weak way to use additional key bits.  For N keys, it
increases the work by a factor of N.  Why bother?  

        paul

------------------------------

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: ___SPEED of HARDWARE Crypto Processors
Date: Fri, 14 Apr 2000 12:27:56 -0400

Stou Sandalski wrote:
> 
> Applied Crypto 2nd ed (don't have first... can't speak of it) has a pretty
> big table with speeds of crypto procs. peep the counterpane website
> (counterpane.com) they might have something on there.

That table is VERY out of date.

Currently available chips can do over 100 Mb/s 3DES, much more for 
single DES.  Hash functions (SHA-1, MD5) are generally also included
at similar speeds.

RC5?  Haven't seen that.  RC4, occasionally; these days 3DES tends
to outperform it because it doesn't require table memory writes.

Some vendors: Hi/fn, IRE, Bluesteel, Chrysalis/ITS, VLSI.
I expect that's not a complete list.

        paul

------------------------------


** 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
******************************

Reply via email to