Cryptography-Digest Digest #605, Volume #12 Sun, 3 Sep 00 22:13:01 EDT
Contents:
Re: PGP Bug: A note from Ralf Senderek (Bj�rn Persson)
Re: PGP 6.5.8 test: That's NOT enough !!! (Bj�rn Persson)
Re: Vic Cipher must have been a plant (John Savard)
R: R: R: R: R: Test on pseudorandom number generator. ("Cristiano")
R: R: R: R: R: R: Test on pseudorandom number generator. ("Cristiano")
Validating problems ("Miki Watts")
Re: more on that neat prime generator (David A Molnar)
Re: e-cash protocol concept, comments wanted ("Lyalc")
Re: Validating problems (Marlin Okey)
Re: more on that neat prime generator (Mark Wooding)
Is there any free encryption scripts in perl and VBScript
([EMAIL PROTECTED])
Re: e-cash protocol concept, comments wanted ("Tor Rustad")
Re: QKD and The Space Shuttle ("Justin Wigg")
Re: QKD and The Space Shuttle ("Justin Wigg")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bj�rn Persson)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: A note from Ralf Senderek
Date: Sun, 03 Sep 2000 21:56:27 GMT
"Michel Bouissou" <[EMAIL PROTECTED]> wrote:
>I (and not Ralf) was using PGP 6.5.8 that I was evaluating, and that
>is why Ralf's public key, which I extracted from my own public
>keyring, shows a 6.5.8 version stamp. This comes from me, not from
>Ralf.
Hey! What's the point in including a version note in a "public key
block" if it doesn't tell which version of PGP created the key or which
version the key's owner is using? Here we have yet another example of
sloppy design in the user interface.
Let's hope version 7 will have a more consistent and thought-through
design
Bj�rn Persson
------------------------------
From: [EMAIL PROTECTED] (Bj�rn Persson)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: Sun, 03 Sep 2000 21:56:35 GMT
Olaf =?ISO-8859-1?Q?Schl=FCter?= <[EMAIL PROTECTED]>
wrote:
>Reading the Senderek report got me stunned. I was very amazed about the
>existance of a data part in a public key information record unprotected
>by a signature. Is there anything that should go into the non-hashed part
>of a public-key block ? From what I see so far the part not protected by
>a signature should remain empty and a warning should be issued if
>anything is in there. Why is there even such a thing as the non-hashed
>part ?
That's a question that I too would very much like to get answered.
Bj�rn Persson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Vic Cipher must have been a plant
Date: Sun, 03 Sep 2000 22:37:05 GMT
On 03 Sep 2000 18:01:11 GMT, [EMAIL PROTECTED] (UBCHI2) wrote, in
part:
>The Vic Cipher sounds like a plot by the Soviets to waste US code breaking
>time. Why would you require an agent to memorize a code of such complexity
>that errors are extremely likely. The issuance of one time pads would have
>greatly simplified the creation and accuracy of messages.
No, I don't think that this is clear at all.
An agent is at more risk when he picks something up at a drop site
than when he leaves something at one.
As an illegal, Hayhanen would mostly have gotten paid in his Moscow
bank account, so using a cipher would reduce the number of pickups he
would make.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: R: R: R: R: Test on pseudorandom number generator.
Date: Mon, 4 Sep 2000 01:13:54 +0200
> >It seems to be the best for this: I can seed it with 25 32 bits numbers,
it
> >pass always the several tests and the p-values of Diehard is far flat
(many
> >thanks to Tim Tyler for DiehardC).
> >
> >This is what I mean for "far flat":
> >
> >Class center p-values found
> > 0,05 19 ===================
> > 0,15 19 ===================
> > 0,25 22 ======================
> > 0,35 24 ========================
> > 0,45 24 ========================
> > 0,55 28 ============================
> > 0,65 26 ==========================
> > 0,75 16 ================
> > 0,85 21 =====================
> > 0,95 35 ===================================
> > 1,05 0
> >
> >total p-values= 234
> >Mean= 0,53492095603436
> >Min= 0,00165856156182101
> >Max= 0,998935636154854
> >std. dev.= 0,284750179144904
> >std. dev./mean= 53,2321973803197%
> >
> >KOLMOROGOV-SMIRNOV test of p-values= 0,924584850949655
> >
> >The shape of this distribution is good?
>
> I would now look at the weak parts again with additional tests.
> Depending upon application, we might want to investigate the mean by
> sampling 100 times as many values, to verify that it tightens up
> toward 0.50.
Done. This is the summary of 50 Diehard tests (100 require too much time:
about 2 hours); each test examine I generate 2124800 32 bits numbers. The 50
KS p-value vary from 0,00882 to 0,9904 (mean= 0,559, std. dev.=0,2698).
KS p-value on 11700 (234 p-value x 50 times) p-values = 0,9985 (very bad!)
Class center p-values found
0,05 1149
0,15 1180
0,25 1146
0,35 1171
0,45 1089
0,55 1123
0,65 1191
0,75 1148
0,85 1207
0,95 1296
1,05 0 (here fall only p-values=1)
If a good generator must give a uniform distribution of p-values, reporting
these p-values in a graphical form we must see a triangle. To see how much
the reals p-values differ from theoretical straight line, I have interpolate
(with the least square method) the p-values with this line:
y(x)=0,000715003224985495+8,6552152065671E-5�x
from that I have computed the error given by
SUM_i[(y(i)-pvalue_i)^2]=0,1414,
and coeff. determ.= 0,99986.
also, I have computed the same error but compared with the line beginning
from 0 and ending to 1 so that for i=0, y=0 and for i=11699, y=1; in this
case the error is 0,8834.
These two errors seems better than those we get with KS (0,9985). In other
words the p-values seems to be a good approximation of a triangle.
My next step will be to compare some generators with this new method. But if
the KS test will be always bad, I am at one's wit's ends!
> I assume the K-S result is a p-value,...
Yes; from DiehardC documentation: "After all the tests are performed, you'll
see a summary of the 160 or p-values [?], and a KSTEST of all of them." (I
think there is a mistake because the p-values are 234).
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: R: R: R: R: R: Test on pseudorandom number generator.
Date: Mon, 4 Sep 2000 01:13:58 +0200
> >> >For my purpose I generate many 1024 bits numbers (with BBS), I collect
> >only
> >> >few lsb from these numbers, I apply SHA-1 every 160 bits collected and
I
> >> >take only differents bit pairs (00 and 11 are discarded, while 01=0
and
> >> >10=1).
> >> >If I test this sequence with a bit test (including Maurer), it's ok?
> >>
> >> The Maurer test article specifically disclaims use of the test on
> >> pseudorandom sequences. And, in my experience, the test itself is
> >> much less sensitive than runs.
> >
> >Do you mean that Maurer's test is good only for random sequences?
>
> I mean that he says in his article that the test is only for really
> random sequences and not pseudorandom sequences. Shall we use his
> test and then ignore what he says about its use?
I have the article. An explicit disclaim to utilize Maurer's test for
pseudorandom sequence seems not present in this article (perhaps except for
some words at the beginning of the abstract section).
> >I like this test because it's output is only a chi-square value (not 234
> >p-values),
>
> Something sounds wrong about that: Your earlier message described a
> test with 234 values; that is *not* 234 p-values, or at least it
> should not be. Those values into one test produce a statistic which
> has a p-value -- that is, one p-value -- not 234.
>
> The output of even something very simple like the frequency test is a
> statistic which has one p-value, not 234 p-values.
>From DiehardC 1.01 documentation:
"DiehardC will perform 15 tests, each of which will produce a p-value.
A p-value is normalized and if your random numbers really are random,
it should be between 0.001 and 0.999 (Bad random numbers generators
will usually produce p-values of 0.00000 or 1.00000) After all the
tests are performed, you'll see a summary of the 160 or p-values,
and a KSTEST of all of them."
Observing the program, the p-values are 234. After sorting these p-values a
KS test is performed given a p-values of 234 p-values.
You say is this wrong?
> If you have had some success finding problems using the Maurer test, I
> would like to hear about it. In my experience, it is very insensitive
> at realistic testing sizes, and if we have much more data, the other
> tests can use that and improve their results as well.
I have these tests: frequency (monobit test), Serial (two-bit test), Poker,
Runs, Autocorrelation, Maurer and Diehard (the latter only 1 week).
I found Maurer's test very sensitive. When I tested URAND, autocorrelation
test found a high chi-square at 32 (about 5) and 96 (about 4) bits distance.
Maurer's test give a very bad chi-square (about 23) with L=8 and bad (about
4) with L=9; with L=16 it give a chi-square of 1500 (!). The size of testing
sequence is 1010*2^L*L bits (as in documentation).
Normally autocorrelation test check distance up to 8-16 bits (now I check up
to
100 bits), without Maurer's test URAND can pass any test because the other
test but Diehard don't detect this weak point.
> >and then because it is able to detect any "tampering" in the
> >generator (like an arbitrary change of just few bits every hundreds).
>
> Really? What makes you think so?
>
> The Maurer test typically works on bytes, on which runs-up / runs-down
> becomes useful. In my experience runs is more sensitive, so I would
> expect it to better detect tampering. If that expectation is wrong, I
> would like to hear about it.
Only the facts!
When I try to make a PRNG by myself, it is strongly possible that my
generator don't
pass some test. My first BBS generator don't pass the runs test for L=6. So
with some "trick" I try to modify only few bits every 100-200. Now all test
are good (not Diehard) but Maurer fail with a chi-square very high.
So I'll toss Maurer's test only for strong valid reasons proven by facts.
> >For runs test do you mean the one in the above book?
>
> I started implementing statistical tests and testing RNG's a decade
> ago, way before HAC, and I have used many different references. One
> good reference is Knuth's "The Art of Computer Programming," Vol. 2.
> Now that I look at the test descriptions in HAC, they seem pretty
> sparse to me, and rather obscure as well.
>
> I do not use the HAC statistic for runs; it seems to me that runs
> should have a combinatoric (probably binomial) distribution, and
> knowing that, we can collect a distribution of run-length counts, then
> compare the sample distribution to the expectation using chi-square.
> To me, that would seem to be much more straightforward, more likely to
> be programmed correctly, and more useful if it finds a problem. In my
> experience, comparing distributions in this way can pick up a
> surprisingly wide variety of problems.
What you say seems to be what is in HAC.
> >> >For my curiosity, I test such a sequence with Diehard (ok it's bad!).
> >> >If I collect more than 4 bits at each step (x=x*x % n) Diehard fail
big.
> >> >If I collect less than 5 bits at each step Diehard is far good. Maurer
is
> >> >almost always good.
> >> >It seems that some information is given also by Diehard. It is
possible?
> >>
> >> Sure. But if your sequence fails when you test more than a few bits
> >> of RNG internal state, your RNG's are "bad" and you need to fix them
> >> before going on. "Good" RNG's generally pass statistical tests even
> >> when the tests are performed properly on all of the RNG state.
> >> (Sometimes, specific tests which correspond to RNG structure will
> >> detect that structure and fail, and we can't do much about that.)
> >
> >I do only what is in literature. A BBS generator is a BBS generator!
>
> Perhaps. But a BB&S generator with small N is insecure.
(?) Do you think that a modulus of 1024 bits it is small?
> And a BB&S
> generator with an error in implementation is not really BB&S at all.
> Is a BB&S generator which does not function as one might expect also a
> BB&S generator?
Sure, but its implementation is very simple!
> >After many attempts to get a "random" sequence, I seen that in most cases
by
> >appling SHA-1 and de-skewing the result is far good.
>
> But you should not have to do that if the underlying generator is
> working right. The need to "de-skew" should tell you that something
> is wrong! Maybe a BB&S generator is *not* a BB&S generator! Finding
> and resolving this sort of result is exactly why we test!
The de-skew in not needed. I only found that the sequences are a little
better by de-skewing it, that is the tests give a better result (not
always). Probably in my final version I'll use "standard" BBS (without any
"trick").
> >For a BBS generator is provable secure to get only lg lg n least
significant
> >bits, but by using SHA-1 I can take more bits.
>
> Really? Who says?
>
> If you take more bits, you violate the strength theory of BB&S; if you
> are willing to do that, why not use the whole BB&S state in SHA-1?
An ashing function is said to be not invertible. So if I hash some bits is
very hard to correlate the result of hash with its input.
If the bits to hash are 2, 10 or 20 bits of a BBS output I think this is not
a big problem.
If I take more bit I violate the strength of BBS if somebody can examine the
output of BBS. But if I hash its output nobody can learn about BBS.
I don't use the whole BBS state because the result is very bad.
------------------------------
From: "Miki Watts" <[EMAIL PROTECTED]>
Subject: Validating problems
Date: Mon, 4 Sep 2000 02:25:52 +0200
Hi!
I don't know if this is the right place, but i couldn't find anything
better.
Here's my problem/question:
How can i authenticate that Bob is Bob, by replying to e-mail, and not
Mallory who is tapping the line for incoming mail ?
In other words, is there some sort of authentication scheme that works over
e-mail?
TIA
Miki Watts
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: more on that neat prime generator
Date: 3 Sep 2000 23:35:48 GMT
[EMAIL PROTECTED] wrote:
[Bob Silverman writes :]
>> Might I suggest you do a literature search? Look up "Maurer"
>> and "Shawe-Taylor".
> And you talk to us about useless junk posts? What a hypocrit.
> I am sorry I am not fully aware of every book written 150 years before
> my time.
Hi Tom,
I think I mentioned these references in passing in a previous
thread, in the context of "good idea, check out these other people
who had similar ideas." Here they are with URLs:
Ueli Maurer
Fast Generation of Prime Numbers and Secure Public-Key Cryptographic
Parameters
Journal of Cryptology, vol. 8, no. 3, pp. 123-155, 1995.
ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/wwwisc/Maurer95a.ps
http://www.inf.ethz.ch/cgi-bin/cgiwrap/webisc/ShowAbstract.pl?label=Maurer95a
P.Mihailescu. "Fast Generation of Provable Primes using Search in
Arithmetic Progressions", Proceedings CRYPTO 94, Lecture Notes in Computer
Science vol 939, Springer 1994
a short version w/o proofs at
http://www.inf.ethz.ch/~mihailes/papers/primgen.ps
I wasn't aware of Shawe-Taylor, but a search for "Shawe-Taylor prime
generation" brought up the citeseer.nj.nec.com entry for Maurer's paper,
which has this as a reference :
J. Shawe-Taylor, Generating strong primes, Electronics Letters, Vol. 22,
No. 16, pp. 875-877, 1986.
BTW, the first time I saw the observation which you made about how
the existence of a generator implies the number is prime was in
Vaughan R. Pratt. Every prime has a succinct certificate. SIAM Journal on
Computing, 4(3):214-220, September 1975
This says nothing one way or the other about how to find these papers
starting from the method alone, or whether you "should" have know about
them.
But now you do, and maybe they will make interesting reading.
Thanks,
-David
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Mon, 4 Sep 2000 11:37:28 +1000
Julian Morrison wrote in message <[EMAIL PROTECTED]>...
>Tor Rustad wrote:
>
snip
>> No trace!
>
>This is deliberate. Nobody should know about the movement of coins between
when
>they're obtained, and when they're paid back into an account. Hiding the
movement
>of money from any snooper - including banks - is a design goal.
>
>> Totally unacceptable for most banks.
Hiding the money flow from the bank means they don't know to which account
to credit the value. That's pretty dumb isn't it?
"Hi, you don't know me, but can I have the $2000 that I have deposited in
your bank under a no-name account?"
snip
>The function of current ecash is more "e-debit-card" - this is unacceptable
for a
>currency system deliberatey designed to thwart audits and traces, and to
bring
>electronic transactions out of the control of any law except earned-trust.
Earned trust only says something about the past. Ongoing trust means being
able to back up any future claims with proof of correctness (or lack
thereof)
Auditable, higih integrity records are the only means to achieve ongoing and
future trust in our present 'western' society.
Lyal
------------------------------
From: [EMAIL PROTECTED] (Marlin Okey)
Subject: Re: Validating problems
Date: Mon, 04 Sep 2000 01:01:36 GMT
"Miki Watts" <[EMAIL PROTECTED]> wrote:
>I don't know if this is the right place, but i couldn't find anything
>better.
>Here's my problem/question:
>How can i authenticate that Bob is Bob, by replying to e-mail, and not
>Mallory who is tapping the line for incoming mail ?
>In other words, is there some sort of authentication scheme that works over
>e-mail?
How about PGP signed messages?
--
"Marlin Okey" is actually 0478 519362 <[EMAIL PROTECTED]>.
012345 6789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: more on that neat prime generator
Date: 3 Sep 2000 23:24:48 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I am sorry I am not fully aware of every book written 150 years before
> my time.
You can at least be expected to have read about Maurer's prime
generation algorithm, which is described in HAC 4.4.4. And perhaps to
do a little research before claiming to have `invented' things.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Is there any free encryption scripts in perl and VBScript
Reply-To: [EMAIL PROTECTED]
Date: Mon, 04 Sep 2000 01:11:02 GMT
Can someone here tell if there are any free scripts with an algorithm
for encryption (like pgp or something else with private and public
keys) which has been implemented in both perlscript and VBScript ???
I want them to be easy to use, just two simple functions or methods
(encrypt and decrypt) like this:
sEcnryptedString = encrypt(sOriginalString , sPublicKey , sPrivateKey)
sOriginalString = decrypt(sEcnryptedString , sPublicKey ,
sPrivateKey)
I want it to be SCRIPTS only, and NOT stuff like COM components for
ASP, or perl modules. (The reason is that I don't have the right
permissions for installing these kind of things on the web servers.)
The reason for wanting an encryption script implemented in both perl
and VBScript is that I would like to be able to encrypt text at a
web-site with CGI/perl and be able to decrypt the same text from
another site with ASP (with VBScript only, and ASP-perl is NOT
installed on that server, so I can't use the same perl script...
// Tomas
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Mon, 4 Sep 2000 03:20:54 +0200
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
> Tor Rustad wrote:
>
> > I have the same comment that signed coins is not useful or practical, your
purse
> > has a electronic value in a currency (or multiple currencies), the bank only
> > need to sign this value.
>
> Hiding this value from the bank is a design goal.
That isn't practical, since it will be very expensive, think about the expence
at the bank host systems.
> > 1,2) Loading the purse with electronic value.
> > Your description is not detailed on this, it does not look to me that the
> > security issues of this critical point, is _not_ addressed at all. Sorry.
>
> Once signed, the coins stand alone as chunks of data. You could put them in
> anything, transport them any way. You could even paste them into a text field
in a
> browser as a way of paying with them.
Banks do not give out electronic value without security. You don't describe the
security mechanisms involved here (this is complicated in the real life).
> > 3) Coin storage.
> > No security!
>
> Coins are like offline cash - they're anonymous and not explicitly tied to an
> owner, except by the way they're stored. A simple PGP'd zipfile would do as a
> "safe", and for transport, SSH or SSL.
These days its quite easy to steel such coins, and this system must be the dream
for a trojan horse writer (with a little bit of Visual Basic training).
Untracable and easy mony to steel.
SSH or SSL does not tell me much about the security, there is a (not small)
topic on key-management.
> > No trace!
>
> This is deliberate. Nobody should know about the movement of coins between
when
> they're obtained, and when they're paid back into an account. Hiding the
movement
> of money from any snooper - including banks - is a design goal.
If there has been a security problem, then there is no way to track it down.
Banks don't monitor people, but one of the basics is to be able to correct and
adress security and other problems with transactions.
> > Totally unacceptable for most banks.
>
> Once the coins are in the user's hands, the bank is safe. It needn't care who
> redeems the coins, and it actually gains (in terms of investable unclaimed
money)
> if the user loses it.
You lost me on this.
> > 4) Spending e-cash.
> > Totally flawed...
> >
> > Which bank will give 'transaction reciept' (whatever that is)
>
> (It's a signed use-count. The term is a holdover from an earlier design
iteration
> where there were many reciepts per coin.)
>
> > on the basis of
> > hashes?
>
> The originator for each coin. They hold the unclaimed money, the hash of the
coin,
> and a transaction count - which can be used to check anonymously when someone
> verifies the coin, or can be incremented at the request of the (anonymous) new
> owner of that coin.
If somebody has seen this coin, anybody can generate a valid hash.
> > 5) Settlement.
> > Where is the security?
>
> The security is the guarantee of the originator. Coins in this are basically
> bankers' checks made out "pay to bearer". Of course, recieving banks are free
to
> surcharge if they don't trust the bank that signed each coin - or simply check
and
> reject any bad coins. The risk here is borne largely by pure-coin transactors,
who
> have to take accound of the trustability of each originating bank. This is
very
> similar to trusting or not a normal physical coin based on the economic
policies of
> its guarantor government.
False merchants comes to mind, and that is a nightmare if it happends in the
real world.
I don't think purse to purse transactions will survive in the future, when the
national banks discover the risk involved, they will close it down. If one purse
is broken, the hole system fall apart. In your model, there is no
counter-measures for this.
No electronic payment system is totally secure, hence if there is a problem, you
need counter-measures.
> > Designing a new electronic payment protocol is very complicated, first of
all
> > its not a one-man job. Flawed protocols on this, sooner or later gets
broken,
> > and when that happends there is a great risk of major losses for the banks.
The
> > national banks also want to have a word about the security on e-cash, in the
> > future a national economy may collapse if a big e-cash system is broken!
>
> This is a simpler protocol because it does a simpler job - it's not trying to
> anonymize/authorize an interbank transfer, it's merely moving blobs of
RSA-signed
> data around.
I think you simplify what you are trying to do here, I just point out the risk
involved and that other people are doing a very good job on this.
> > There exists today real life systems on e-cash (i.e. Proton), which are well
> > designed from a bank and security point of view. There is also on-gong
> > standardization efforts to produce international e-cash protocol, with
multiple
> > contributing experts. This work is backed by major players in finance
community.
> >
> > Sorry for my negative response.
>
> The function of current ecash is more "e-debit-card" - this is unacceptable
for a
> currency system deliberatey designed to thwart audits and traces, and to bring
> electronic transactions out of the control of any law except earned-trust.
Well, I can't see how such a system can be made secure. Audit and traces are
fundamental to security in electronic payments. Your design goals are in
conflict with these basic security priciples. The card companies take huge
losses on internet fraud to day, this can't simply go on and will be closed down
with more security, not less.
--
Tor
------------------------------
From: "Justin Wigg" <[EMAIL PROTECTED]>
Subject: Re: QKD and The Space Shuttle
Date: Mon, 4 Sep 2000 12:39:26 +1000
"Guy Macon" <[EMAIL PROTECTED]> wrote in message
news:8os4fq$[EMAIL PROTECTED]...
> And you can still buy a Pint of beer in England and a Half Liter of
> Cola in the US...
Not to mention a quarter-pounder which can be bought in just about every
country on the planet...
--
He who laughs last... | Justin Wigg - Hobart, AUSTRALIA
...thinks slowest. | Reply: [EMAIL PROTECTED]
------------------------------
From: "Justin Wigg" <[EMAIL PROTECTED]>
Crossposted-To: sci.space.shuttle,talk.politics.crypto
Subject: Re: QKD and The Space Shuttle
Date: Mon, 4 Sep 2000 12:42:21 +1000
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Oh, yes:
> <upturned nose>
> STS stands for Space Transportation System, the *official* name of
> that which is _colloquially_ known as the "Space Shuttle".
> </upturned nose>
Actually the STS and NSTS (National Space Transportation System) program
names were dropped in the mid-late 1990s. The official program name is now
the "Space Shuttle Program". How about that? Of course the missions still
carry the "STS-xx" mission designations for continuity...
--
He who laughs last... | Justin Wigg - Hobart, AUSTRALIA
...thinks slowest. | Reply: [EMAIL PROTECTED]
------------------------------
** 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
******************************
