Cryptography-Digest Digest #659, Volume #10 Wed, 1 Dec 99 15:13:01 EST
Contents:
Re: Some feedback from the USA --- my story is real .. (Mike Andrews)
Re: How safe is Mobile Phone ? (David Wagner)
Re: Simpson's Paradox and Quantum Entanglement (Medical Electronics Lab)
Re: The $10,000.00 contesta (Alex MacPherson)
Re: Generate a key pair from a user-entered key file? (Medical Electronics Lab)
Re: Quantum Computers and PGP et al. (Medical Electronics Lab)
Re: AES cyphers leak information like sieves (wtshaw)
Re: Decyption proof cellphones in Europe? [x3] (Helmut Wabnig)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: Ultimate Crypto Protection? (Tim Tyler)
Re: Peekboo Ideas? (Medical Electronics Lab)
Re: Recommendations on implementing ElGamal (Medical Electronics Lab)
Re: How safe is Mobile Phone ? (Jim Dunnett)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: Decyption proof cellphones in Europe? [x3] (Medical Electronics Lab)
Re: The $10,000.00 contesta (David Crick)
Re: The $10,000.00 contesta (David Crick)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: Encrypting short blocks (wtshaw)
Re: NSA should do a cryptoanalysis of AES (Jim Gillogly)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: Some feedback from the USA --- my story is real ..
Date: Wed, 01 Dec 1999 18:12:58 GMT
Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
[rant deleted]
nothing related to crypto.
Please don't feed the trolls.
--
Mike Andrews
[EMAIL PROTECTED]
Tired old sysadmin since 1964
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: How safe is Mobile Phone ?
Date: 1 Dec 1999 09:43:44 -0800
In article <[EMAIL PROTECTED]>,
Markus Peuhkuri <[EMAIL PROTECTED]> wrote:
> >>>>> "David" == David Wagner <[EMAIL PROTECTED]> writes:
> David> confidence in their product, so why should we believe the
> David> Sectra folks?
>
> Because "Sectra is the leading developer and manufacturer of
> information security products for the Swedish Armed Forces."
But there are two different products, one for military users and
one for non-military users. Even if we accept for the sake of
argument that the military phone has excellent security, that says
nothing about the security of the phone for non-military users...
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Wed, 01 Dec 1999 12:18:10 -0600
Brian Chase wrote:
> Hey I think you may have accidentally had your KOOKSLOCK key on when you
> typed this. Why do all the crazy people always hang out in sci.math and
> sci.physics? It's a strange phenomenon to witness really... Reading
> USENET's sci.* hierarchy is a lot like riding the city bus.
That's not funny, it's sick. In my town several people were
burned by a guy with a gas can and a match on a city bus.
Fortunately they all survived, but it was a damn close call.
Be careful with the kooks, they may be dangerous.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Alex MacPherson <[EMAIL PROTECTED]>
Subject: Re: The $10,000.00 contesta
Date: Wed, 01 Dec 1999 13:19:45 -0500
Bruce Schneier wrote:
"Observation on the Key Schedule of Twofish."
Could you please send a URL of where I could find this paper. I would be
extremely interested.
Thank you.
--
Alex MacPherson
Department of Mathematics and Computer Science
Royal Military College of Canada
email: [EMAIL PROTECTED]
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Generate a key pair from a user-entered key file?
Date: Wed, 01 Dec 1999 12:45:19 -0600
[EMAIL PROTECTED] wrote:
> Does anyone know how I could obtain a key pair from the contents of a
> user-entered text file or how I could extract a key pair from such a
> file?
If you use ECC, you can hash the file to create a secret key, and
then multiply that by the public parameters to get a public key.
That's not much good for real security, but it'll work.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: Quantum Computers and PGP et al.
Date: Wed, 01 Dec 1999 12:43:14 -0600
Greg wrote:
>
> > Quantum computers, like nuclear fusion, language
> > translation or artificial intelligence, may prove
> > more difficult than originally anticipated.
>
> I agree. But the reason I steer clear of IFP is due
> to the large amounts of effort by many different groups
> to develop a Quantum computer. No such specific threat
> exists for ECDLP. And I suspect it will remain this way
> for quite some time.
A quantum computer can be used to solve the DLP over any group.
Once we get quantum computers to work, we'll have a whole new
game to play with crypto. Nice to know the field will never
get boring eh? :-)
It will be at least 20 years before quantum computers become
useful in the laboratory. And it might be like fusion, "it'll
work in 40 years" has been the mantra for about 60 now. The
difference is that the tools needed to work on quantum computers
are much cheaper than the tools needed for fusion reactors.
In any event, there's no public key crypto system in existence
today that will be useful when quantum computers work.
Don't keep secrets :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 01 Dec 1999 13:24:37 -0600
In article <[EMAIL PROTECTED]>, Volker Hetzer
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
..
> However, there could be certain tradeoffs.
> What about storing only partial blocks and partial keys?
> Then you could store more different blocks of known plaintext.
>
> > An algorithm may be comprised of other algorithms. A complex algorithm may
> > involve a rather lengthy key. If properly done, analysis is devilishly
> > compounded.
> Yes. And, if the algos don't form a group you need to find out many keys.
That would be the case in appropriate chaining, as there are bad examples
of chaining where the most efficient key is less than the sum of the
components.
>
> > If much material need be solved for verification of a
> > message, surely the algorithm might be said to be stronger in one sense
> > than one that requires a lesser amount.
> Yes.
>
So, we look at how much is needed, reduce it to a standard value, and note
the strength of the algorthm on that basis. Considering various concepts
of strength, algorithms that place high on all measures, are superior to
those that have a flaw or two; I surely consider the thesis of this string
as indicating a definite flaw in AES, and, I have publically worried about
that from the beginning, while wanting the best result under the
circumstances.
If we are really interested in heightening the state of the art, we best
look at the total picture of what that involves, not only what composes
particular algorithm strength, but how it is implemented; it is foolish to
do otherwise, making chumps out of those play by rules that ignore any
vital concern that is essential in computer security.
My earlier concerns were real, and should continue to haunt those that are
pulling for an inferior AES, whatever their reasons and however sincere
they are. My biggest complaint is in the shallow thinking so involved,
not to dimish what has been thunk, simply that it does not pass muster as
a really great step, but a mere and timid hop into the future.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: Helmut Wabnig <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Wed, 01 Dec 1999 19:54:36 +0100
On 1 Dec 1999 17:15:44 GMT, [EMAIL PROTECTED] (Ian Goldberg) wrote:
...........snip
>You're confusing a couple of things, here. The SDA didn't _make_ the
>A5/1 and A5/2 and COMP128 algorithms; they just reverse-engineerend and
>published the source (which the GSM people have been unwilling to do).
>We at Berkeley (David Wagner and myself) then cryptanalysed the
>algorithms. They all suck. The one that sucks least is A5/1, which
>seems to have ~40-bit workfactor. (The A5/1 work wasn't done by us; see
>the links below.) A5/2 sucks surprisingly hard, with a 16-bit
>workfactor (i.e. real time break).
............snip
Even if the Algorithms are known, how much effort would it take
to decrypt a transmission "on the fly".
Think this is rather impossible, I cannot imagine a way to do it.
Say, we could work on a recorded transmission, which in fact
is also difficult to make, how long will it take to bring up a result?
GSM transmissions of a certain GSM unit cannot be easily
filtered out of all the traffic on certain base station.
Only the net providers can access individual beares,
or can disable encryption without notice.
Encryption has to be requested each time by the hand set
from the server.
Different to DECT, which is always encrypted.
Just my opinion, I think GSM is secure, if you do not
have access to the provider's personnell directly.
W.
W.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Tue, 30 Nov 1999 18:01:05 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Volker Hetzer <[EMAIL PROTECTED]> wrote:
[block size doubling ==> work required for a break doubling?]
:> : If [...] the usual attacks (like differential) will require the
:> : same number of blocks
:>
:> Some attacks will require a /much/ larger numbers of blocks, however.
:
: Such as?
Say you're compiling a dictionary of blocks, which matches blocks to
corresponding plaintexts. Say you have a target of getting 1/8 of the
blocks. This lets you take vague guesses at the contents of the message,
pretty much regardless of the block size.
With a 32-bit block, that's 2^28 blocks whose plaintexts you need to find.
With a 64-bit block, you need to find the plaintexts of 2^60 blocks.
Each block is twice as long and codes for twice as much plaintext :-|
This is *not* twice as much work - by /any/ stretch of the imagination.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Cole's law: marinated, thinly-sliced cabbage.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Tue, 30 Nov 1999 23:21:20 GMT
Kenneth Almquist <[EMAIL PROTECTED]> wrote:
: My guess is that the information from the NSA which influences the
: AES selection will be made public, because as you point out, keeping
: the information secret would be difficult.
Keeping information secret is part of the NSA's job.
: [...] if the NSA breaks one of the finalists, the fact that
: the encryption algorithm had been broken would rule it out of
: consideration.
It is not clear whether this is true. What does the number 56 mean to you?
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I'm telling you, they are EVERYWHERE!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Ultimate Crypto Protection?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 30 Nov 1999 23:26:48 GMT
amadeus wrote:
: Obviously if you can produce enough good random key, fine.
: But it doesn't have to be high quality, just unknown to the
: enemy and sufficiently random that he cannot predict what the
: next key byte is going to be.
It has to be *pretty* high quality. Deviations from complete randomness
will allow attackers to extract *some* information - even if the
entropy-per-bit of the stream is relatively high.
*Statistical* knowledge of what the next key byte is going to be might
help an attacker significantly.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Your attempts at intimidation are a joke.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Peekboo Ideas?
Date: Wed, 01 Dec 1999 12:54:05 -0600
Tom St Denis wrote:
> I could include the message+hash in a BASE64 encoded blob. It wouldn't
> be human readable, but if you think about it, you don't want to read a
> message until you verify the signature anyways... :)
Why not compress the message, then sign the compression? Send the
whole thing as a base64 which is easy to recover, not encrypted
but still won't get modified by all the stuff in between. Plus
you send less data :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Recommendations on implementing ElGamal
Date: Wed, 01 Dec 1999 12:58:38 -0600
Sven Knispel wrote:
>
> I am looking for links on documents on any kind about the implementation of
> ElGamal:
> - precautions
> - how to avoid wearnesses
> - cryptoanalysis of ElGamal
> - format of message packets
> - other
Under the heading of "other", check out the code on my web site:
http://www.terracom.net/~eresrch You'll find ElGamal implemented
in ECC form.
Patience, persistence, truth,
Dr. mike
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim Dunnett)
Subject: Re: How safe is Mobile Phone ?
Date: Wed, 01 Dec 1999 19:09:03 GMT
Reply-To: Jim Dunnett
On Tue, 30 Nov 1999 23:02:01 +0100, Patrik Norqvist <[EMAIL PROTECTED]> wrote:
>GSM cellphones with better encryption are available both for military an
>"non-military" customers, as the Tiger cellphone,
>http://www.sectra.se/indexm.html
You could always buy a pair of Nortel's Public-Keyed secure
systems and encrypt end-to-end, but of course that would require
all your correspondents to be so equipped. Expensive!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 01 Dec 1999 13:48:36 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
Bravo) wrote:
> On Wed, 1 Dec 1999 07:35:03 GMT, [EMAIL PROTECTED] (Brian Chase)
> wrote:
> The burden of proof is on the claimant. If has a point to make, it
> is up to him to prove he is right, it is not up to us to prove him
> wrong.
>
Well, you might be well liked in a class on legalities, but, science makes
no demand, merely that the evidence speaks for itself, whatever the
source. A *good* lawyer reallly knows what to reveal as well as what to
hide, regardless of what his expressed duties are, time cutting well into
full justice and legal fiction taking a precedence over reality.
A *good* scientist willing reveals everything if part of the evidense he
exposes is against him. There is no expectation regarding his feelings as
long as the data is there. Grace and courtesy are desired but not
required. Never think that working on the front lines of human endeavor
are parlor room games. The essence of what is found in all that matters
to me, and lots of others.
Some academics may have a club of dainty rules, but this is gild that they
demand because of the presumed superiority of their position. But,
authoritarianism can badly suck when it is wrong. Thankfully, many
academics are not so taken by their title that they forget their real
responsibility, to be slaves in increasing human knowledge.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 01 Dec 1999 13:54:06 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian Chase) wrote:
>
> I think it's true that there is no proof that it's easier to crack with
> the additional blocks, but it's certainly not harder with more blocks.
>
Additional blocks mean more overhead, making things more difficult for the
analyst, a precious goal. There is proof that additional blocks may be
required for solving some ciphers, as a lesser amount maybe indeterminate.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Wed, 01 Dec 1999 13:19:52 -0600
Bruce Schneier wrote:
> This sounds like an audio summary of Seymour Hersh's excellent New
> Yorker article on the same topic, which can be found at:
>
> http://cryptome.org/nsa-hersh.htm
>
> It's really interesting reading.
I'll say! It makes it sound like the NSA is a bunch of incompetent
morons. How much of that is disinformation?!?!
Patience, persistence, truth,
Dr. mike
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: The $10,000.00 contesta
Date: Wed, 01 Dec 1999 19:46:03 +0000
Alex MacPherson wrote:
>
> Bruce Schneier wrote:
> "Observation on the Key Schedule of Twofish."
>
> Could you please send a URL of where I could find this paper.
> I would be extremely interested.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/mirza.pdf
David.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| ICQ#: 46605825 PGP Public Keys: RSA 0x22D5C7A9 DH/DSS 0xBE63D7C7 |
+-------------------------------------------------------------------+
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: The $10,000.00 contesta
Date: Wed, 01 Dec 1999 19:49:33 +0000
David Crick wrote:
>
> Alex MacPherson wrote:
> >
> > Bruce Schneier wrote:
> > "Observation on the Key Schedule of Twofish."
> >
> > Could you please send a URL of where I could find this paper.
> > I would be extremely interested.
>
> http://csrc.nist.gov/encryption/aes/round1/conf2/papers/mirza.pdf
Here's the Twofish team's response if you're also interested:
http://www.counterpane.com/twofish-ks2.html
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| ICQ#: 46605825 PGP Public Keys: RSA 0x22D5C7A9 DH/DSS 0xBE63D7C7 |
+-------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 01 Dec 1999 14:06:00 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian Chase) wrote:
> So wait, what you're saying is that we shouldn't be concerned with
> something that we're not sure is a weakness because we, the disadvantaged
> public, have never seen it exploited?
>
> MY GOD! THERE IS AN NSA CONSPIRACY GOING ON HERE!!!
>
> No reasonable concern is unwarranted unless you can prove it is
> unwarranted. What kind of mathematicians are you people?!
>
Those that know no better teamed with those who have designs in keeping
things dumbed down is a popular political strategy.
The enlightened approach is to make all the data public so the best
decision can be made, something that NSA will fight when it figures it can
be easilythe most enlightened, while everyone would never *get it*, even
if cultured in intellectual snipe-hunts. The spoiler is when NSA is shown
not to have a locked-up advantage. So, they work against other
cryptographers by attempting to discourage their use of academic freedom,
as demonstrated by the grand accomplishements of the BXA, and back-room
deals to subvert operating systems.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting short blocks
Date: Wed, 01 Dec 1999 14:15:36 -0600
In article <[EMAIL PROTECTED]>, Markus Peuhkuri
<[EMAIL PROTECTED]> wrote:
> Is there an encyprion algorithm that can be used for short
> blocks (variable from ~10 to 24 bits) _and_ the result is same
> length as original data. The key may be much larger (128, 256,
> ...).
>
....
>
> Could some existing algorithm be changed to work like that?
>
Sure thing, block length and key length have little relationship aside
from what they do in an individual algorithm. When you change an
algorithm, you have a different algorithm.
> Thanks for any hints.
Pick a block length, pick a usable keylength, design a good algorithm,
case closed.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 01 Dec 1999 19:53:18 +0000
Keith A Monahan wrote:
> My concern is that if they DID break one of the algorithms and
> didn't tell us(or NIST) about it. I don't know how likely that
> is, but it is certainly a possible case.
>
> It wouldn't be _as_ bad as if the NSA broke it, told us about it,
> but didn't tell us how. That would still keep me wondering, but
> at least we'd know the cipher isn't secure. Even without telling
> us how they did it, we might be able to draw some conclusions about
> ciphers of that same nature.
If they say they broke it and demonstrate that they can break an
arbitrary challenge, then I agree that's useful information. If
they say they have an attack that reduces a 128-bit keyspace to
a 70-bit keyspace, I'd want to see the attack before making a
decision to eliminate the candidate. Sorry if this appears paranoid,
but we must always remember that NSA has two responsibilities: to
read traffic, and to protect US infrastructure (mainly military).
If you're going to accept their help uncritically, you'd better
know which side of the house is giving it to you. There's no
question that they could provide valuable insight on the candidates;
the only question is how they can convey it credibly.
Note also that even this information wouldn't tell you whether the
other four candidates each had an attack that would bring its
complexity down even lower than the hypothetically broken one.
--
Jim Gillogly
Sterday, 11 Foreyule S.R. 1999, 19:46
12.19.6.13.9, 4 Muluc 17 Ceh, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 01 Dec 1999 20:02:41 GMT
My comments inserted, prefixed with *.
>Subject: Re: Elliptic Curve Public-Key Cryptography
>From: [EMAIL PROTECTED] (Bruce Schneier)
>Date: Wed, 01 December 1999 12:11 PM EST
>Message-id: <[EMAIL PROTECTED]>
>
>On 30 Nov 1999 11:05:51 -0800, [EMAIL PROTECTED]
>(David Wagner) wrote:
>>I think we can all agree that
>>ECC has some apparent advantages over RSA (key size; signature size;
>>performance on small devices), and RSA has some apparent advantages over
>>ECC (performance of encryption & signature verification; RSA has been around
>>longer). So there are tradeoffs. Right?
>
>I don't necessarily agree. This assumes an EC setup with shared
>parameters. In other setups the key size difference can be minimal.
>I've seen small devices that are excellent for RSA, but extremely poor
>for EC; the statement on small device performance is too general.
* Here are some common scenarios.
1) Key pair generation - on a small device, with EC, given a set of domain
parameters, this is just generating a random number for the private key and
doing a scalar multiplication to create the public key. For RSA, it involves
prime creation and testing, GCD testing of e with phi(modulus) and possibly
more. This is a LOT more complicated.
2) Sig Gen with HW protected private key. Again, ECC appears to be a winner,
the reason I go to hardware is to protect my private key.
3) I need very fast sig ver. Well, this depends, I can use small RSA exponent,
or I can use EC public key multiples to speed up ECC. The difference is that
key multiples tradeoff time for space, but assuming they are correct, has no
increased risk. Using a low RSA exponent means I believe the additional info
given a bad guy will not help him.
>
>I avoid small values of e with RSA, but RSA is probably stiff faster
>than comparable EC algorithms for e's up to about 64 bits.
* Comparing vendor's speeds is problematical, as there are many factors to
consider. However, this is certainly not true for Certicom's implementations.
I know last year EC SigVer for 163 bit key (ANSI X9.62/NIST curve) was in the
same ballpark performance-wise as RSA SigVer for 1024 bit key and e = F4, which
is 17 bits with 2 bits set to 1. For ramdom 64-bit e (which some people
recommend as being conservative), it was not even close.
>
>Bruce
>**********************************************************************
>Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
>101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
> Free crypto newsletter. See: http://www.counterpane.com
Don Johnson
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Wed, 01 Dec 1999 14:33:35 -0500
> In sci.crypt Jerry P <[EMAIL PROTECTED]> wrote:
> > No market research needed.
>
> > 3DES at a 1 Gigabit/sec, like anti-gravity, free desalination,
> > non-polluting engines, and ADSL, is obviously a billion-dollar
> > winner. NSA can do 3DES at 1 Gigabit/WEEK with Cray computers.
Where have you been?
Megabit per second was off the shelf single chip technology
in the early eighties, and even a lowly 8080 could do a gigabit
per week in software back then (that's only 2kbits per second...)
Gigabit per second was done as an R&D effort at DEC Palo Alto
around 1994. Today, commercial off the shelf chips do several
hundred megabits/second of 3Des for $100 or so.
So 1 Gb/s 3Des is not exactly earth shattering, though it's
high enough to be worth some interest. But as far as I can tell
the original note doesn't describe anything real.
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
******************************
