Cryptography-Digest Digest #663, Volume #12 Tue, 12 Sep 00 16:13:01 EDT
Contents:
Re: Known Plain Text Attack (Mark Wooding)
security of SKID based msg authentication. (Roger Gammans)
Need Tiger hash results for sample test data ([EMAIL PROTECTED])
Re: nice simple function (Mike Rosing)
Re: Steganography and secret sorting (Matthew Skala)
Re: Steganography and secret sorting (Matthew Skala)
Re: Scottu19 Broken (Mok-Kong Shen)
Re: sac fullfilling decorelated functions (Mike Rosing)
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: Steganography and secret sorting (Mok-Kong Shen)
Re: nice simple function (Bryan Olson)
Re: Need Tiger hash results for sample test data (John Myre)
Re: OutLook Express & SMIME ("Michael Scott")
Re: security warning -- "www.etradebank.com" (Ian Goldberg)
Dickman's function (Francois Grieu)
Re: ExCSS Source Code (Ichinin)
Re: Problem with Tiger hash algorithm and binary files (Daniel Leonard)
Re: Scottu19 Broken ("Douglas A. Gwyn")
Re: nice simple function ("Douglas A. Gwyn")
Re: Intel's 1.13 MHZ chip (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Known Plain Text Attack
Date: 12 Sep 2000 17:22:17 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> First of all, my US patents apply only in the US,
Clearly. Do you hold patents in other countries, though?
> Next, if the issue is *understanding* cryptographic techniques,
> avoiding patented concepts is an explicit choice for ignorance.
Agreed.
Terry's put together a great deal of really useful information. He also
explains clearly which techniques he's patented, which lets you avoid
them. His site is well worth a look.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: security of SKID based msg authentication.
Date: Tue, 12 Sep 2000 17:31:04 GMT
I was looking for a `simple' msg auth schema, and found the following
in a quick persual of Schneier + some of my thoughts as I coudn't find
quite what I wanted:-
So based on SKID we get:-
Alice needs message M from Bob, and be sure it came from Bob.
0) Alice & Bob have a pre-arranged long-lived secret K,
identity token B (for Bob ), and a cryptographic
hash function H().
1) Alice choses a random number (Ra) and sends it to Bob.
with a request for message M.
2) Bob choses a random number (Rb) , He then sends Alice:-
Rb,M,H(K,Ra,Rb,M,B)
3) Alice can then also compute H(K,Ra,Rb,M,B) to
verify the message came from Bob.
So are there any _really_ glaring errors in this? - Beyond of
course the security of H().
Interestingly Schneier claims[1] that SKID is not secure against
man-in-the-middle attacks , implying in the next sentence that it
doesn't have a shared-secret - but he previously cliamed it did.
Am I mis-reading the book here?
TTFN
[1] Applied Crytography 2e, p 56.
--
Roger
Think of the mess on the carpet. Sensible people do all their
demon-summoning in the garage, which you can just hose down afterwards.
-- [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Need Tiger hash results for sample test data
Date: Tue, 12 Sep 2000 17:27:36 GMT
Does anyone have hash results, using Tiger, for one or more files(binary
also)? Yes, the authors did provide a 'testtiger.c' program, but this
only performs hashes for sample strings (e.g. "abc"), not files. A hash
on a string SHOULD not be the same as hash on a file containing said
string, so I can't very well use this method to validate my routine (See
below).
I wrote a C routine to create a hash on an arbitrary file using the
Tiger hash algorith
(http://www.cs.technion.ac.il/~biham/Reports/Tiger/). I am now looking
for some test data to validate my routine against. It would be nice to
know I am computing the correct hash.
Thanks.
George
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 12:49:01 -0500
Tom St Denis wrote:
> f''(x) = f'(x ++ f(x)) where '++' represents modular integer addition.
> We now get f''(x) = f'(x ++ (a.x + b)) = c.(x ++ (a.x + b)) + d = c.x
> ++ c.(a.x + b) + d = c.x ++ (c.a.x + c.b) + d
>
> From what I can tell c.x cannot be grouped with c.a.x, which means we
> have an output that is a function of 'c' and 'a'. Also that c.b cannot
> be grouped with 'd', but since they are not a function of the input can
> we let 'b' be zero and just have f''(x) = (c.x ++ c.a.x) + d
>
> Which leads me to f''(x) = (a.x ++ b.x) + c as a new decorrelated
> function. (Assuming a, b != 0).
>
> Am I nuts or what? Please comment :-)
Plot it and see. Try 4 bits, so you have 4*4*4*4 possible pairs ( a nice
round number!) for each of a, b, c and x. What is the distribution of
f''(x) as a function of a, c and x. I'm assuming the modulus is 2^4 as
well, but you could really have fun by changing that :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Steganography and secret sorting
Date: 12 Sep 2000 10:28:17 -0700
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>I must admit that I have only superficially read your method
>and haven't understood it. How do you sort the stuff back to
>the original? Thanks.
With merge sort or quick sort or something of the kind.
The thing is, I've got some kind of database that doesn't have to be in
any particular order. So I sort it. I express my message as a
permutation of the records and apply that permutation. Then I send the
permuted database to the recipient. The recipient sorts it again, and in
so doing, is able to recover the permutation I applied, from which they
can extract the message. If the permuted database is intercepted, I may
be able to plausibly claim that it's not in any particular order.
For additional security, I could define the "sorted" order of the database
as something other than its obvious sorted order. That way even if the
adversaries suspect I'm using this scheme, they won't be able to recover
the message or prove that one exists without knowing my sorting order.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Steganography and secret sorting
Date: 12 Sep 2000 10:35:17 -0700
In article <pzrv5.3422$[EMAIL PROTECTED]>,
Ray Dillinger <[EMAIL PROTECTED]> wrote:
>The thing is, the permutation *IS* a number -- it just has very strange
>rules about what base each digit is in. Think about it this way:
That's more or less the way I was thinking of it, although I'd prefer to
implement it without using numbers the size of the messages. One can do
that with arithmetic decoding. On a high level, you give the arithmetic
decoder a stream of bits (the message) and tell it "Give me a number from
0 to k_1", "Give me a number from 0 to k_2"..., and it'll do so as
efficiently as possible while preserving all the information in the bit
stream. On the other end you use an arithmetic encoder to go back to a
bit stream.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Scottu19 Broken
Date: Tue, 12 Sep 2000 20:11:36 +0200
Johnny Bravo wrote:
>
> Just because it compiles doesn't make it clear. I offer the following example.
[snip]
Perfectly. This the raison d'etre of high-level programming
languages and comment statements in these, not to mention
object-oriented design methodologies and other software
engineering tools.
M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: sac fullfilling decorelated functions
Date: Tue, 12 Sep 2000 12:53:54 -0500
Tom St Denis wrote:
>
> Let's take F(x) = a.x + b in GF(2)^32, now we want to know for any
> multiple of 'a' in the same field what is the prob of at laest 16 bits
> being set... so I take out some new finite I learnt and plug in (32
> choose 16)/2^32 = 2^-2.837. This means about 1 in 6 will be SAC
> fullfilling functions.
>
> Over the entire multiplcation we find 32/6 ~ 5.3 which means of the 32
> multiples of 'a' only 5 are sac fullfilling. If 'a' is random there
> distribution should be random (?). Now consider the lower bits, such
> as with only four bits set. We find them with a prob of 2^-16.865 much
> less then with 16 bits.
>
> In any GF multiply the chances of any being of only four bits is about
> 2^-11 or 1 in 2048. This means that GF multiplication is a closely-sac-
> like function most of the time, and for a fraction of the time not.
>
> Can this be used to extract information from the function in those
> specific cases (extreme cases?)
F is linear. That's a much bigger problem :-)
Patience, persistence, truth,
Dr. mike
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Bytes, octets, chars, and characters
Date: Tue, 12 Sep 2000 17:18:31 GMT
Jerry Coffin wrote:
> Adding long long did NOT have to do with keeping from breaking
> programs that assumed long was 32 bits wide. Rather, it was about
> adding a type that was guaranteed to be a minimum of at least 64 bits
> wide.
An alternative (which was thoroughly debated) would have been
to raise the required minimum width of long to 64 bits. That
would have forced most platforms to undergo a change in a
basic type in order to maintain standard conformance, which
would have caused no end of trouble -- that's why a new type
was specified.
The other related issue was the somewhat common idiom
fprintf(stderr,"%lu",(unsigned long)sizeof object);
used to get a known type that hopefully is also big enough.
There were suggestions that we constrain size_t (the type of
the result of sizeof) to not exceed the width of long, but
during the deliberations we recognized that there were
problems with that approach also. The end result was that
a new type (long long, already an extension in widespread use)
was specified, the existing standard types were left as is,
accommodation was made for other (implementation-defined)
extended integer types, the various standard typedefs like
size_t can be any supported integer type, and <stdint.h>
and <inttypes.h> (already in widespread use) were specified
to provide ways for programmers to better deal with the
variety of integer types. That included a new intmax_t
typedef, guaranteed to be the widest supported integer type
in any implementation. So the above idiom is better coded as:
fprintf(stderr,"%"PRIuMAX,(uintmax_t)sizeof object);
which works for all object sizes on any implementation,
including new C99 ones where size_t might be wider than long.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Steganography and secret sorting
Date: Tue, 12 Sep 2000 20:18:27 +0200
Matthew Skala wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >I must admit that I have only superficially read your method
> >and haven't understood it. How do you sort the stuff back to
> >the original? Thanks.
>
> With merge sort or quick sort or something of the kind.
>
> The thing is, I've got some kind of database that doesn't have to be in
> any particular order. So I sort it. I express my message as a
> permutation of the records and apply that permutation. Then I send the
> permuted database to the recipient. The recipient sorts it again, and in
> so doing, is able to recover the permutation I applied, from which they
> can extract the message. If the permuted database is intercepted, I may
> be able to plausibly claim that it's not in any particular order.
>
> For additional security, I could define the "sorted" order of the database
> as something other than its obvious sorted order. That way even if the
> adversaries suspect I'm using this scheme, they won't be able to recover
> the message or prove that one exists without knowing my sorting order.
Sorry, I am not yet able to understand. Could you explain
with a database of, say, 5 or 10 entries? Do you assume
that the same database (without permutation) is available
to both partners? Thanks.
M. K. Shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 18:06:45 GMT
Tom St Denis wrote:
> My goal is to change the function so even knowledge of two
> pairs is not > sufficient, but somehow I have the feeling
> my other idea f(x) = (a.x ++ > b.x) + c, won't work well
> either... I have to think it over
Well, there is:
f(x) = a_2.x^2 + a_1.x + a_0
How many pairs of (x, f(x)) would it take to determine
(a_0, a_1, a_2) ?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Need Tiger hash results for sample test data
Date: Tue, 12 Sep 2000 12:52:55 -0600
[EMAIL PROTECTED] wrote:
<snip>
> A hash
> on a string SHOULD not be the same as hash on a file containing said
> string
<snip>
Huh? Why not?
JM
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: OutLook Express & SMIME
Date: Tue, 12 Sep 2000 20:06:46 +0100
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Michael Scott" <[EMAIL PROTECTED]> writes:
>
> > I am experimenting with SMIME and have got myself a free certificate
from
> > Thwaite. This all works fine.
> >
> > My question is this. Where is my private key stored? Presumably it is
stored
> > somewhere for OutLook Express to use to sign my emails (and decrypt any
> > encrypted emails I receive) but where? I also presume that it is stored
"in
> > the clear", as I am not asked for any passphrase.
> >
> > Mike Scott
>
> See http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt.
Yes, very useful. In fact it is a trivial matter to discover the private
key. There is no protection at all. So if someone were to gain access to
your computer for just a minute or so, you are completely compromised, and
all your "encrypted" emails revealed (past and present). Also the some-one
could masquerade as you, and sign legally binding documents on your behalf,
under new legislation that makes digital signatures legally binding. So much
for PKI! All that elaborate infrastructure and complex cryptography, all for
naught.
Here is the shortest sequence of steps that I found to do it, for Outlook
Express under Windows '98. There may be a shorter way.
1. Run Outlook Express
2. Work Offline
3. Click on Tools
4. Click on Options
5. Click the Security tab
6. Click on Digital IDs
7. Click on your certificate
8. Click on Export - this brings up the Certificate manager Export Wizard
9.Click on Next
10. Click on Next again to export the private key
11. Click on next again to Enable strong protection (ho ho)
12. Supply a password - use the letter x - and click on Next
13. Supply a filename - key - and click on Next
14. Click on Finish
15. Click on OK, and OK again
16. Visit www.openssl.org, and download and install openssl, which creates
the openssl utility
17. d:>openssl pkcs12 -in key.pfx -nodes
18. Supply your "password" x
19. Out pops the private key!
20. Use the private key to decrypt all "secure" emails, including all those
intercepted over the past year.
Mike Scott
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: security warning -- "www.etradebank.com"
Date: 12 Sep 2000 19:19:31 GMT
[The original article got expired from my news server, but I'll extrapolate
the missing info.]
In article <[EMAIL PROTECTED]>,
Anthony David <[EMAIL PROTECTED]> wrote:
>"Harvey Rook" <[EMAIL PROTECTED]> writes:
>
>> Why is 6 chars unacceptable? We are not talking about a piece of unguarded
>> data that your opponent has unlimited access to. Consider...
>>
>> -The accounts lock up after 3 wrong tries.
>
>"Black Hat" tries 3 times.
>
>> -Reactivation requires you to call in.
Ah, but a lot of people misunderstand the weakness of the above scheme.
The correct attack for "Black Hat" is *not* what adavid suggests
(pick an account, find their personal info, lock them out, reactivate it
yourself), but rather:
Pick random *account numbers* as well as random passwords. Especially
if account numbers are assigned sequentially, you will get a valid
username/password pair in exactly as long as it would take to guess
any _given_ account's password. But you *don't* set off the "lockout"
function! So you just try random account numbers, and the 6-letter
passwords from /usr/dict/words, and you're likely to stumble across
a valid pair pretty soon.
- Ian
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Crossposted-To: sci.math.num-analysis
Subject: Dickman's function
Date: Tue, 12 Sep 2000 21:31:51 +0200
I'm trying to find or devise simple C code to compute Dickman's
function. For non-negative reals a, this function gives the proportion
of integers N such that the highest prime factor of N is less that N^a.
It verifies:
/1
F[a] = 1 for a>=1 F[a] = 1 - | F[t/(1-t)]/t dt for 0<=a<=1
/a
Reference: Donald E. Knuth, The Art of Computer Programming, volume 2,
section 4.5.4, p367 (2nd ed) or p383 (3rd ed).
Online ref: <http://mathworld.wolfram.com/DickmanFunction.html>
Things I tried so far are very imperfect, but here they are. It is handy
to define the auxiliary function f[b] = F[1/b] and we get
/b
f[b] = 1 for 0<=b<=1 f[b] = f[c] - | f[t-1]/t dt for b>=c>=1
/c
In the above, c could be any real but using c = floor[b] which gives a
simple recurence. For exemple on the segment 1<=b<=2 we get
/b
f[b] = 1 - | 1/t dt thus f[b] = 1 - Log[b] for 1<=b<=2
/1
More symbolic integration does not help much: on segment 2<=b<=3 we need
the PolyLog function, and farther the expression grows madly.
Recursive numerical integration with a general method works for b up to
say 5, then gets terribly slow. A faster variant is to build sucessive
polynomial approximations at points j+1/2 for integers j>=0:
fj[x] = f[x + (j+1/2)] = sum(Aij * x^i) + O(x^n)
0<=i<n
Convergence is reasonably quick. However any rounding error or
truncation made in computing a segment affects the next ones as an
absolute error, and since the function decreases quickly to 0, we get
totaly innacurate results for b>12 when using 64 bits IEEE arithmetic.
Anyone has a method working for b up to say 40 without using arbitrary
precision arithmetic or too many magic values ?
Francois Grieu
Appendix: table of F[] computed using an arbitrary precision package
1/a F[a] | 1/a F[a] | 1/a F[a] | 1/a F[a]
| | | 1 1
1.25 7.7686e-01 | 1.5 5.9453e-01 | 1.75 4.4038e-01 | 2 3.0685e-01
2.25 2.0244e-01 | 2.5 1.3032e-01 | 2.75 8.1072e-02 | 3 4.8608e-02
3.25 2.8427e-02 | 3.5 1.6230e-02 | 3.75 9.0292e-03 | 4 4.9109e-03
4.25 2.6200e-03 | 4.5 1.3701e-03 | 4.75 7.0306e-04 | 5 3.5472e-04
5.25 1.7608e-04 | 5.5 8.6019e-05 | 5.75 4.1402e-05 | 6 1.9650e-05
6.25 9.1989e-06 | 6.5 4.2504e-06 | 6.75 1.9396e-06 | 7 8.7457e-07
7.25 3.8977e-07 | 7.5 1.7179e-07 | 7.75 7.4903e-08 | 8 3.2321e-08
8.25 1.3806e-08 | 8.5 5.8406e-09 | 8.75 2.4475e-09 | 9 1.0162e-09
9.25 4.1823e-10 | 9.5 1.7064e-10 | 9.75 6.9035e-11 | 10 2.7702e-11
10.25 1.1028e-11 | 10.5 4.3560e-12 | 10.75 1.7076e-12 | 11 6.6448e-13
11.25 2.5671e-13 | 11.5 9.8476e-14 | 11.75 3.7517e-14 | 12 1.4197e-14
12.25 5.3371e-15 | 12.5 1.9935e-15 | 12.75 7.3989e-16 | 13 2.7292e-16
13.25 1.0006e-16 | 13.5 3.6468e-17 | 13.75 1.3214e-17 | 14 4.7606e-18
14.25 1.7055e-18 | 14.5 6.0765e-19 | 14.75 2.1533e-19 | 15 7.5899e-20
15.25 2.6614e-20 | 15.5 9.2841e-21 | 15.75 3.2224e-21 | 16 1.1129e-21
16.25 3.8249e-22 | 16.5 1.3083e-22 | 16.75 4.4537e-23 | 17 1.5091e-23
17.25 5.0900e-24 | 17.5 1.7090e-24 | 17.75 5.7130e-25 | 18 1.9014e-25
18.25 6.3007e-26 | 18.5 2.0790e-26 | 18.75 6.8314e-27 | 19 2.2354e-27
19.25 7.2851e-28 | 19.5 2.3646e-28 | 19.75 7.6446e-29 | 20 2.4618e-29
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ExCSS Source Code
Date: Tue, 12 Sep 2000 10:27:39 +0200
John Savard wrote:
> We couldn't. MPEG-4, with its improved compression, only now just
> barely allows a movie to fit on a CD. Of course, there is CD-Video,
> but that offered inadequate video quality.
Yes we could, DivX produce a sufficiently viewable quality
(say rental VHS) when the INDATA is of a reasonably high
quality. However - it lacks one minor thing that makes it
useless:
AUDIO AND VIDEO SYNC!!!!!
(even with the media player update for wintel it looses sync
after a while and you cannot fast forward or reverse the
media, that's why i do not use it. Reason nr2: most people
can read the "License agreement" in the installation ;o)
When a legal , proper codec is out, i want it!
/Ichinin
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Problem with Tiger hash algorithm and binary files
Date: Tue, 12 Sep 2000 19:56:31 GMT
On Tue, 12 Sep 2000, John Myre wrote:
> Daniel Leonard wrote:
> <snip>
> > While on the subject, which reference implementation is the right one: =
the
> > one from Eli Biham site, or the one from Ross Anderson site ?
>=20
> How are they different? Do they give different answers?
Last time I checked (around April-May), the difference in the
implemetation was in the padding.
Anderson's: 0x80, 0x00, ...
Biham's : 0x01, 0x00, ...
It gives different results. In the paper, the padding is stated as follow:
the bit 1 followed by as many 0 bit as necessary to pad
(not verbatim, but close enough IIRC).
I had an acknowledgement with Mr. Anderson, but no answer since then about
this difference neither which is the coorect one (I favor Anderson's
since it was how I interpreted the paper).
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Scottu19 Broken
Date: Tue, 12 Sep 2000 19:33:22 GMT
Mok-Kong Shen wrote:
> Perfectly. This the raison d'etre of high-level programming
> languages and comment statements in these, not to mention
> object-oriented design methodologies and other software
> engineering tools.
Object-oriented design has nothing to do with fixing the
problems in the example source code. More to the point
would be Kernighan & Plauger's "The Elements of Programming
Style".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 19:31:17 GMT
Bryan Olson wrote:
> Tom St Denis wrote:
> > My goal is to change the function so even knowledge of two
> > pairs is not > sufficient, but somehow I have the feeling
> > my other idea f(x) = (a.x ++ > b.x) + c, won't work well
> > either... I have to think it over
> Well, there is:
> f(x) = a_2.x^2 + a_1.x + a_0
> How many pairs of (x, f(x)) would it take to determine
> (a_0, a_1, a_2) ?
Typically three, since when one plugs in known values a
linear relationship among the parameters results. With
the function Tom suggested, the > operator loses so much
information (inputs two numbers and outputs a single bit)
that it would take a fair amount of searching to nail down
the parameters. Of course, the down side of using such a
function is that the attacker can be rather inaccurate in
his guesses for the key parameters and still be able to
read the message, in some instances.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Tue, 12 Sep 2000 22:15:10 +0200
Jerry Coffin wrote:
>
> Seymour Cray's last machines were running at a 1 GHz clock speed
> around 10 years ago now. OTOH, the earlier comment about the
> military having used this level of technology for that long appears
> likely to be more or less erroneous -- essentially all the orders for
> these machines were cancelled, so only three were ever built and
> unless memory deceives me, none of those ever went to the military,
> NSA or anything similar. One stayed at the Cray plant here in
> Colorado Springs. One went to the University of Colorado. Offhand I
> don't remember exactly where the third went, but it seems like it was
> to a university as well. FWIW, at one time the government HAD
> ordered them, but they ended up getting so far behind schedule that
> the orders got cancelled.
Perhaps not with exactly the speed of the last ones, but
there have been quite a number of Crays all over the globe,
not all being used for civil purposes. That seems to be
quite certain.
M. K. Shen
------------------------------
** 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
******************************
