Cryptography-Digest Digest #582, Volume #12 Thu, 31 Aug 00 17:13:01 EDT
Contents:
Re: Looking for site regarding RSA patent (Rich Wales)
Two quick practical questions (Maybe not scientific enough ;-) (Darren New)
crypto organisations & societies ("Jamie")
Re: Simple LFSR Stream Cipher (Terry Ritter)
Re: "Warn when encrypting to keys with an ADK" (Howard (using fs))
Re: crypto organisations & societies (Quisquater)
Re: more on that neat prime generator (James Felling)
Re: R: R: R: R: Test on pseudorandom number generator. (Terry Ritter)
Re: vernam cipher question (Jim Haynes)
Re: PGP 6.5.8 test: That's NOT enough !!! (Your Name)
RSA history (D. J. Bernstein)
Re: blowfish problem ("Trevor L. Jackson, III")
Re: blowfish problem ("Trevor L. Jackson, III")
Re: R: R: Test on pseudorandom number generator. (Mok-Kong Shen)
Re: R: R: R: Test on pseudorandom number generator. (Terry Ritter)
Re: Two quick practical questions (Maybe not scientific enough ;-) (Daniel Leonard)
Re: more on that neat prime generator (John Myre)
Re: QKD and The Space Shuttle (Alan Mackenzie)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Subject: Re: Looking for site regarding RSA patent
Date: 31 Aug 2000 18:00:56 -0000
Bill Unruh wrote:
> I am sure GPG will put in RSA to ensure
> compatibility with old PGP.
I'm not so sure. Pre-5.0 PGP compatibility would also require use
of IDEA, which will remain patented for at least another decade in
numerous countries (the US, most of western Europe, and Japan) --
but apparently not in Canada, so Bill needn't worry. :-}
(Reference: http://www.ascom.ch/infosec/idea/policy.html)
RSA and IDEA modules already exist for GnuPG, but the maintainer of
the program has refused to incorporate them officially because of
the GNU project's policy against using patented software.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Two quick practical questions (Maybe not scientific enough ;-)
Date: Thu, 31 Aug 2000 18:11:17 GMT
Is there a good place to get a simple implementation of SHA-1, or some other
well-known, standard, trusted hash? I'm looking for a function in C, Java,
Tcl, or something like that, just for testing out some algorithms that make
use of it. Even an executable that I can pipe something through to get the
hash would be adequate for now. This is just a proof-of-concept so far, so
easy is better than fast/flexible/etc. Hopefully a version that'll work on
Windows and UNIX both would be nice. I've seen a Java source posted here,
but all the source code I found looked like it relied on a whole bunch of
superclass frameworks and such.
Secondly, is there a easy way to build some random numbers? Basically, I
would think I'd need on the order of a few kilobytes of random bits, one
time for each installation. It would need to be unpredictable, so doing
something like hashing a counter won't work, but it's small, so doing
something like watching the mouse would work. It also doesn't have to be
especially secure for this proof-of-concept I'm doing, since I plan to use
the random bits only as *part* of a key to a conventional cypher. Is this
what /dev/random is for? Do "dd if=/dev/random of=..." would be an easy way
to get such a file in a proof-of-concept system? Or does someone have a
simple description of distilling the randomness out of mouse movements, as
in the old "wiggle the mouse around until I tell you I have enough bits"
kind of thing?
Thanks in advance for any hints!
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"No wonder it tastes funny.
I forgot to put the mint sauce on the tentacles."
------------------------------
From: "Jamie" <[EMAIL PROTECTED]>
Subject: crypto organisations & societies
Date: Thu, 31 Aug 2000 08:19:36 +0200
Hi All
Can anyone out there put me in touch with someone prominent who is on the
board of directors for an international association, organisation or society
in the field of cryptography or cryptology?
Jamie
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Simple LFSR Stream Cipher
Date: Thu, 31 Aug 2000 18:32:43 GMT
On Thu, 31 Aug 2000 16:51:43 GMT, in <8om2el$s8p$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>Here is an idea for a simple LFSR Stream Cipher.
>
>Take there LFSRs of relatively prime length.
>
>To make an output bit perform the following.
>
>1. Clock all three LFSRS, store result in (a,b,c)
>2. If (a) then output (b) else output (c)
That appears to be what we now know as Geffe (1973):
http://www.io.com/~ritter/RES/COMBCORR.HTM#Geffe73
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Howard (using fs))
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Thu, 31 Aug 2000 18:39:29 GMT
On Wed, 30 Aug 2000 09:38:03 +0100, Phil Harrison
<[EMAIL PROTECTED]> wrote:
>
>I don't know about you, but the only time I have ever seen a key with an
>ADK is on test keys created specifically to illustrate this bug.
>--
Lurking here trying to follow the problem. Ever cautious, me.
Switched on 'view ADKs'. Bless my soul! There's an ADK'd key on my
keyring! It's from NAI, key ID 0xE1F5529A. I did visit their site
sometime ago, and I think their site points to a file containing a set
of keys that can be used to verify files etc.
Interesting ..... I looked at Key properties, and it said the ADK was
unknown, so I've obviously not got the ADK itself on my key ring.
Safe;-) ..... Aren't I?
OK, so now I've got a real ADK'd key. Actually, I'm pretty confident
it's quite legit, but imagine it were not. How could I detect if it
was a tampered key? That's one of the remaining issues, isn't it?
--
Howard
Email : [remove the obvious]hcsc[at]tesco[dot]net
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: crypto organisations & societies
Date: Thu, 31 Aug 2000 21:04:28 +0200
Jamie wrote:
>
> Hi All
>
> Can anyone out there put me in touch with someone prominent who is on the
> board of directors for an international association, organisation or society
> in the field of cryptography or cryptology?
>
> Jamie
See http://www.iacr.org/bod.html
All are prominent :-)
Speaking now about the number of intelligible words/sec (mesured in
shannon) they are able to output: Diffie, Landrock and Berson (random order)
are the best ones :-)
Another one is nsa (http://www.nsa.gov) BUT there are not international and
their goal is:
input: infinite shannon and public output: null shannon :-)
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: more on that neat prime generator
Date: Thu, 31 Aug 2000 13:57:49 -0500
[EMAIL PROTECTED] wrote:
> I was thinking, you could start lower, making 128-bit primes with my
> method by picking 16 random 16-bit primes (*) then making 6 128-bit
> primes. Then you can use 3 each as factors of a 768-bit number ...
>
> (*) The neat thing is that 16-bit primes can be stored in a table since
> there are only 6521 of them. Now the problem is how many primes cannot
> be represented by this, the answer "None of them.". If we include '1'
> in the table then all primes from 2..2^128-1 can be represented. At
> least it sounds right. We note that 6521^16 ~ 2^202 which means the
> numerical range is covered at least.
>
> So to get a 384 bit prime we do this
>
> 1. Pick 16 random 16-bit primes
> 2. Find p' = N1 * N2 * N3 ...
> 3. Try to find a primitive generator modulo (2p' + 1), if one cannot
> be found in say under 10 attemps goto step 1.
>
> 4. Repeat #1-#3 three times.
> 5. Get the product of the output of #3 as p'' = p1' * p2' * p3'
> 5. Try to find a primitive generator. if not goto #4
>
> At the end 2p'' + 1 will be a provable 384-bit prime.
>
> I may try implementing this with MPI sometime this week.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
I wonder if there will not be some bias as to the primes generated in this
manner? I am not certian that this will hit every prime in the space of
available numbers -- if it does this would be really cool.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: R: R: R: R: Test on pseudorandom number generator.
Date: Thu, 31 Aug 2000 19:04:39 GMT
On Thu, 31 Aug 2000 18:26:05 +0200, in <8olvis$k32$[EMAIL PROTECTED]>,
in sci.crypt "Cristiano" <[EMAIL PROTECTED]> wrote:
>I seen your site (very interesting!).
>Following yours advices, now URAND (take as full 32 bits integer) is very
>bad. Fail any test!
>
>To test a BBS generator I use some test taken from "Handbook of Applied
>Cryptography" by A. Menezes, P. van Oorschot and S. Vanstone (including
>"Maurer's universal statistical test"). These tests seems to be rigth for
>bits. It is so?
I have the book. Please indicate specifically which tests you mean.
>But...
>
>>Concatenating the output from several RNG steps is one way we try to
>>hide what is going on in the RNG. But if we want to know about the
>>RNG, we do not want to confuse ourselves!
>
>>Compare the case of using an entire value per step as opposed to
>>collecting bits from multiple steps into a single value. Can we
>>imagine that the statistical results will be unchanged? Clearly the
>>results will differ. That being so, which result is correct?
>
>I don't know! But I think that it is important to see if a sequence looks
>like random (any triks is good).
We all want a random sequence. But the "trick" of taking 8-bit chunks
from a larger RNG state, then analyzing them as 32-bit values,
confuses statistical tests more than it would confuse an opponent. So
the information we get from the statistical tests does not contribute
to checking the RNG or making it better, and also does not correspond
to strength.
It is necessary to check statistics on your final RNG output. If you
intend to produce 32-bit values by taking 4 RNG steps, you should
check that output. But first you should check the output from 32 bits
on each step, and that should pass.
Just dumping bytes or bits into a file and expecting statistical tests
on that data to mean something is unrealistic.
>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.
>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.)
>If a cryptographically secure PRNG fail any randomness test, it's output is
>still unpredictable?
That depends upon what you mean by "fail":
A RNG should have a flat distribution of values. If the value
distribution is not flat, then it is to some extent "more predictable"
than it should be. The result, essentially, is similar to having a
reduced "keyspace" or "internal state." Normally this would not have
much effect, but it could.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: vernam cipher question
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Jim Haynes)
Date: Thu, 31 Aug 2000 19:18:56 GMT
In article <8ols73$jtt$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Now the text says, "The redudancy in the latter
>may permit cryptanalysis." Could someone explain
If the Vernam equipment is using one-time tapes and the tapes are actually
random then it is unbreakable. In practice there is the problem of supplying
enough one-time key and getting it to both stations that need to
communicate, since key is consumed at the rate of one character per message
character. Hence there are ciphers that operate on the principle of xor
a message and key character but generate the key character stream from a
mechanism that is set up by a much shorter key. This was the principle
of the Lorenz machine that the British broke. A German operator sent the
same message twice using the same key, except that the two transmissions
differed slightly. My understanding is that this allowed the British to
recover significant amounts of key stream, and from that to deduce how the
key generator worked.
------------------------------
From: [EMAIL PROTECTED] (Your Name)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: Thu, 31 Aug 2000 19:22:16 GMT
On Thu, 31 Aug 2000 08:07:43 -0400, jungle <[EMAIL PROTECTED]>
wrote:
>David Sternlight wrote:
>>
>> The dancing, fast footwork, and apologetics of PGP die-hards here is truly
>> sad. PGP has, after all the hubris of the past, acquired a fatal error. If
>> you can't detect a forged key, it's all over.
>
>but you can detect tampered key with easy, and nothing is over ...
>post here tampered key, that buggy PGP will not detect ADK on it ...
The fact that no one, so far, has been able to produce such a key
is very good news AFAIAC.
Hello David, wellcome back, you old lurker. :o)
Rich Eramian aka freeman at shore dot net
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: RSA history
Date: 31 Aug 2000 19:25:02 GMT
Thomas Pornin <[EMAIL PROTECTED]> wrote:
> e = 3 is the original exponent proposed in the paper from Rivest, Shamir
> and Adleman.
No. Rivest, Shamir, and Adleman proposed using public keys (n,e), with e
coprime to phi(n) and chosen randomly.
Rabin proposed exponent 2 in MIT LCS tech report 212, 1979. Does anyone
know a prior proposal to use a fixed exponent?
Knuth proposed exponent 3 in ACP volume 2, second edition, 1981. Does
anyone know a prior proposal to use a fixed exponent coprime to phi(n)?
---Dan
------------------------------
Date: Thu, 31 Aug 2000 15:43:44 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Kaz Kylheku wrote:
> I didn't mean to imply that the char type is completely useless---indeed it can
> be useful when compact storage for a small, non-negative integer value is
> needed. What I mean was that the type char is fairly useless, or at least
> awkward for manipulating text, because it doesn't necessarily represent all the
> values in the range 0 to UCHAR_MAX. Consider that the getc() function
> retrieves values in that range, and the <ctype.h> functions also take input
> values in this range. Converting a value from this range to type char calls for
> an an implementation-defined conversion; a conversion back to unsigned char
> might not produce the same value. Thus unsigned char is not suitable for
> portably storing the results of stream input, unless that input is known to
> only have positive values.
But in many cases we're stuck with char of indeterminate sign because the elements of
literal strings have that type. Since pointer conversion are not automatic one is
often
stuck with char * or tedious casts. Without this constraint it would be possible to
implement the standard library using a signed character type. Since software
interfaces
tend to conform to the most stubborn constraint the standard library will probably stay
based on plain char.
------------------------------
Date: Thu, 31 Aug 2000 15:45:32 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
"Douglas A. Gwyn" wrote:
> "Trevor L. Jackson, III" wrote:
> > Certainly it makes sense in the context of his assertion. The expressions '\0' and
> > '\1' are the character representations for boolean values, as opposed to 0 and 1
>which
> > are the integer representations for boolean values.
>
> No, they are not character representations. In C, '\0' means
> *exactly* the same thing as unadorned 0: an integer constant
> with type int and value 0, and similarly for '\1' and 1.
That's why I said it was a stylistic distinction.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: R: R: Test on pseudorandom number generator.
Date: Thu, 31 Aug 2000 22:07:13 +0200
Cristiano wrote:
>
> All my PRNG are modulus 2^m (2^32 in almost all cases).
> I'd like to test some PRNG with modulus different 2^m. Can you tell me where
> I can find this sort of generators?
You can find a list of them in Schneier's Applied Cryptography.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: R: R: R: Test on pseudorandom number generator.
Date: Thu, 31 Aug 2000 20:00:52 GMT
On Thu, 31 Aug 2000 18:26:12 +0200, in <8olvj5$k3b$[EMAIL PROTECTED]>,
in sci.crypt "Cristiano" <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn wrote:
>
>> I'm not happy with the way that Diehard presents its results.
>> There are methods of summarizing such results into a single
>> measure, e.g. weight of evidence against the random hypothesis
>> (or a significance level based on that using inverse chi-square),
>> that should have been used instead.
>
>If I collect p-values of Diehard in classes (as a histogram) the result
>looks like a bell shaped curve.
Something seems wrong here, or perhaps this is just a communications
problem. If we collect p-values from a statistical test on random
data, we expect to get between 0 and .5 half the time and between .5
and 1.0 also half the time. We expect about 1/4 of the results in
each quartile. We do not expect to get a bell shaped curve from p
values, although we might well get such a curve from the raw statistic
itself. If there really are many too many p-value results in the
center, repeatedly, the test has found a problem.
>If I compute the chi-square statistic for the number of expected p-values
>wich lies in each class (assuming a normal distribution) and some other
>parameter (like kurtosis and skewness) may be useful for a general
>evaluation?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Two quick practical questions (Maybe not scientific enough ;-)
Date: Thu, 31 Aug 2000 20:22:38 GMT
On Thu, 31 Aug 2000, Darren New wrote:
> Is there a good place to get a simple implementation of SHA-1, or some ot=
her
> well-known, standard, trusted hash? I'm looking for a function in C, Jav=
a,
Java
=09MessageDigest sha1 =3D MessageDigest.getInstance("SHA");
> Tcl, or something like that, just for testing out some algorithms that ma=
ke
> use of it. Even an executable that I can pipe something through to get th=
e
> hash would be adequate for now. This is just a proof-of-concept so far, s=
o
> easy is better than fast/flexible/etc. Hopefully a version that'll work =
on
> Windows and UNIX both would be nice. I've seen a Java source posted here,
> but all the source code I found looked like it relied on a whole bunch of
> superclass frameworks and such.
>=20
> Secondly, is there a easy way to build some random numbers? Basically, I
> would think I'd need on the order of a few kilobytes of random bits, one
> time for each installation. It would need to be unpredictable, so doing
> something like hashing a counter won't work, but it's small, so doing
> something like watching the mouse would work. It also doesn't have to be
> especially secure for this proof-of-concept I'm doing, since I plan to us=
e
> the random bits only as *part* of a key to a conventional cypher. Is this
> what /dev/random is for? Do "dd if=3D/dev/random of=3D..." would be an ea=
sy way
> to get such a file in a proof-of-concept system? Or does someone have a
> simple description of distilling the randomness out of mouse movements, a=
s
> in the old "wiggle the mouse around until I tell you I have enough bits"
> kind of thing?=20
both random.org and lavarand.sgi.com have megabytes of random data
>=20
> Thanks in advance for any hints!
>=20
> --=20
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> "No wonder it tastes funny.=20
> I forgot to put the mint sauce on the tentacles."
>=20
==========
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: John Myre <[EMAIL PROTECTED]>
Subject: Re: more on that neat prime generator
Date: Thu, 31 Aug 2000 14:25:49 -0600
[EMAIL PROTECTED] wrote:
>
> I was thinking, you could start lower, making 128-bit primes with my
> method by picking 16 random 16-bit primes (*) then making 6 128-bit
> primes. Then you can use 3 each as factors of a 768-bit number ...
Isn't 16 x 16 = 256, not 128? I'll assume you mean 8 16-bit primes.
Isn't it true that about half (or less) of the 16-bit primes have
their high bit set? That would mean you have about 2^-8 chance of
the product being a full 128 bits. Although actually, since you
want 2p'+1 to be 128 bits, you want p' to be 127 bits. In fact, you
would expect to be about 7(#) bits short or so, but you might be
anywhere from one bit longer than you would like to way short.
(#) Back-of-the-envelope calculation. Assume half of the 16-bit
primes (i.e., 4 of them) are actually 16 bits; assume half of the
rest (2 of them) are 15 bits; half left (one) is 14 bits, and the
last is 13 bits. Then we are missing 2x1 + 1x2 + 1x3 = 7 bits.
Crude, perhaps.
> (*) The neat thing is that 16-bit primes can be stored in a table since
> there are only 6521 of them. Now the problem is how many primes cannot
> be represented by this, the answer "None of them.".
Well, you'd certainly miss 2^19+1 and 2^31+1, or any other prime
2q+1 where q has more than 8 factors. Of course you would also
miss any where q was itself prime, or had any factors larger than
2^16.
> If we include '1'
> in the table then all primes from 2..2^128-1 can be represented. At
> least it sounds right. We note that 6521^16 ~ 2^202 which means the
> numerical range is covered at least.
Counting 6521^N different products means you are counting as
different those cases where the factors are reordered. I don't
think I'll go to the trouble of looking up how to solve this
combinatorial problem, but you can already see that some primes
aren't represented, and those that are are not equiprobable.
This might still be a neat method if the distribution is not
too skewed to give any advantage to the attacker - I'll leave
that problem for people smarter than I.
JM
------------------------------
From: Alan Mackenzie<[EMAIL PROTECTED]>
Crossposted-To: sci.space.shuttle,talk.politics.crypto
Subject: Re: QKD and The Space Shuttle
Date: Thu, 31 Aug 2000 19:58:58 +0000
Mike Dicenso <[EMAIL PROTECTED]> wrote on Thu, 31 Aug 2000
06:03:34 -0700:
> On Thu, 31 Aug 2000, John Savard wrote:
>> On Wed, 30 Aug 2000 20:53:22 +0100, "Richard Bembridge"
>> <[EMAIL PROTECTED]> wrote, in part:
>> >What kind of payloads can the Shuttle handle?
>> The Space Telescope represented the upper limit.
> Of what? Of payload capacity? Of the largest single payload? Not even.
> The shuttle can carry payloads well in excess of HST in size. In fact,
> the late Compton GRO was nearly 10,000 lbs heavier than HST, and the
> same for the Lacrosse radar spysats. The heaviest payload of the
> program was carried on STS-93 Columbia, the Chandra AXAF/IUS and the
> supporting equipment weighed in at about 53,000 lbs.
WTF do all these TLAs mean? Please, pretty please? This post is appearing
on talk.politics.crypto and sci.crypt as well as sci.space.shuttle.
For starters:
QKD: (Is this "Quantum" something?)
GRO:
HST: ("High Speed Train"?)
STS-93:
AXAF/IUS
> Just a side note, many of the ISS componets, such as the PV-6 array,
> and the US Destiny Lab module are also much larger than HST in terms of
> payload weight.
Main meal:
ISS:
PV-6:
>> >What is the typical altitude of the Shuttle when in Low Earth Orbit
>> >(LEO)?
And for dessert:
LEO: "Low Earth Orbit", perhaps? :-) Or "Lyons' Electronic Office"?
>> About 250 miles.
> About 250 statute miles, yes.
Are satellite altitudes really quoted in statute miles?
> Given that most payloads from here on out will be headed to that
> altitude for the ISS assembly flights, this would be a "typical"
> shuttle altitude.
>-Mike
--
Alan Mackenzie (Munich, Germany)
Email: [EMAIL PROTECTED]; to decode, wherever there is a repeated letter
(like "aa"), remove one of them (leaving, say, "a").
------------------------------
** 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
******************************
