Cryptography-Digest Digest #420, Volume #12 Fri, 11 Aug 00 17:13:01 EDT
Contents:
Re: TheArgon Site (Justin Levi Kennedy)
Re: BBS and the lack of proof ("Trevor L. Jackson, III")
Re: Explain S-boxes please (Simon Johnson)
Re: Destruction of CDs ("Trevor L. Jackson, III")
Re: Random Number Generator (James Felling)
Re: Destruction of CDs ("Trevor L. Jackson, III")
Re: OTP using BBS generator? ("Trevor L. Jackson, III")
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: OTP using BBS generator? ("Trevor L. Jackson, III")
Huge S-boxes! (Simon Johnson)
Re: Destruction of CDs (Simon Johnson)
Re: Random Number Generator ("Trevor L. Jackson, III")
Re: Random Number Generator ("Trevor L. Jackson, III")
Re: Random Number Generator ("Trevor L. Jackson, III")
Re: Random Number Generator ("Trevor L. Jackson, III")
Re: Pentium III h/w RNG ("Trevor L. Jackson, III")
Re: Destruction of CDs ("Paul Pires")
Re: 1-time pad is not secure... (Guy Macon)
Re: 1-time pad is not secure... (Derek Bell)
----------------------------------------------------------------------------
From: Justin Levi Kennedy <[EMAIL PROTECTED]>
Subject: Re: TheArgon Site
Date: 11 Aug 2000 19:20:48 GMT
James Pate Williams, Jr. <[EMAIL PROTECTED]> wrote:
: On Tue, 25 Jul 2000 17:07:44 -0400, "George Gordon"
: <[EMAIL PROTECTED]> wrote:
:>Hi group,
:>
:>Can anyone help this poor site? I think it's of some value to the community.
:>http://www.theargon.com
looks like it's too late now. "Death: July. 31st. 2000"
: What does the acronym ARGON stand for and why is this site germane to
: sci.crypt readers? From elementary chemistry we know that argon is an
: "inert" gas, a.k.a "noble" gas and is used in some lasers and other
: forms of illumination.
from the fine print at the bottom:
The American Research Guardian Online Network
as to what this site is, I don't know since it is just a front page and
nothing more.
--
Justin Kennedy
cs1312 TA
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: [EMAIL PROTECTED]
Do as I think, not as I say!
--conversations with java.exe
------------------------------
Date: Fri, 11 Aug 2000 15:34:33 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: BBS and the lack of proof
Mark Wooding wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> > Mark Wooding wrote:
> >
> > > tomstd <[EMAIL PROTECTED]> wrote:
> > >
> > > > Among many BBS is thought to be a prng that is as secure as at least
> > > > factoring the associated modulus. However... nobody really knows
> > > > anything about the generated bits or the period of them.
> > >
> > > Predicting the output of a BBS generator mod n is proven to be as
> > > difficult as deciding quadratic residuosity mod n. If the period is
> > > short enough for you to traverse a cycle, you'll be able to predict the
> > > generator's output. Hence, traversing a cycle is at least as hard as
> > > deciding quadratic residuosity. QED.
> >
> > Are you sure it is the traversal of a cycle rather than the finding of
> > a cycle to traverse that is equivalent? Can you mention a reference
> > that makes this distinction?
>
> Err... What's the distinction you think I've drawn?
>
> Wherever you start, you'll be on some sort of a cycle. This is clear,
> because the state is fiinte, and the transformation x |-> x^2 is a
> permutation over Q_n. So merely finding a cycle, in this sense, is a
> bit like finding the ground beneath your feet, and doesn't tell you
> anything very interesting.
Agreed.
>
>
> So the issue is whether you can find a cycle which is short enough to
> actually traverse. If you can do this, you can clearly predict the past
> and future of the generator, and (as proven in the paper) this allows
> you to decide quadratic residuosity.
I detect a difference between finding _a_ cycle and finding _the_ cycle (from
which a given sequence was taken).
>
>
> My feeling is that we're having a minor disagreement about terminology.
> I don't mind this: I like to give things the right names where I can, so
> if you have an improvement to offer then I'll accept that gladly. If
> this isn't terminological, could you please explain what it is in more
> detail so that I can respond to it sensible? ;-)
It may indeed be a terminology issue. Since the issue is an interesting one it
would be worth clarifying the terminology in order to eliminate terminological
artifacts of the discussion. To that end, permit me to suggest a scenario into
which you may poke holes.
For discussion purposes only I'll use simple numbers. Feel free to correct
them if they are not adequately representative.
Assume the existence of a BBS generator that has a large number of cycles
(~2^256) but (simplifying) a bimodal distribution of sequence lengths such that
the cycles are either long (>2^128 length) or short (<2^32 length). Assume
also that the long cycles far outnumber the short cycles, having a ratio of
2^224:1. Hopefully this elementary example captures the nature of BBS usage.
Now if a key is selected from the total space of possible keys it will produce
a long cycle with odds 2^224:1. Certainly those odds are good enough for any
use I can imagine. Given some samples from the sequence, the BBS proof shows
that it is not possible to predict the sequence.
However, if I happen to select one of the few short cycles then it will be
possible to predict the sequence by traversal. Thus if I select a key and do
not check it for shortness I'm vulnerable to a prediction by traversal. Thus
the opponent with not have to use a technique that requires QR decidability.
Resolved: one can conclude that the odds of selecting such a key are enormous,
but one cannot conclude that predicting a BBS sequence requires QR decidability
if the sequence to be predicted can be predicted using an alternate mechanism
(traversal).
Please point out the invalid assumption or conclusion I've made/reached.
------------------------------
Subject: Re: Explain S-boxes please
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 12:38:40 -0700
YAUS!
Well, its yeah its a subsitution..... This mean we take an input
digit and replace it with some other value, which is found in a
look up table.
The critera by which this mapping is choosen is a different
depending on what u're after. Some people, like Tom, prefer a
medium sized optomized s-box. Others, like me, prefer a random
but very large s-box. Either way it make no difference.
I can't tell you what the critera for a optimised S-box is.....
because i'm not sure.
Cheers,
Simon
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Date: Fri, 11 Aug 2000 15:45:54 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Destruction of CDs
Jerry Coffin wrote:
> In article <KWHk5.1548$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > Stack cd's.
> >
> > Duct tape into a cylinder and pipe lots of pure O2 into central cavity.
> >
> > Light.
>
> Go to:
>
> http://ghg.ecn.purdue.edu/
>
> for detailed information on something just a TINY bit more insane
> than just pure O2 (including full color pictures and even video of
> the insanity). He wasn't lighting CD's but I'm _sure_ they'd burn
> quite nicely given the same treatment...
Read the fine print where it says "don't try this at home" and "provide an
initial ignition source". Charcoal soaked in LOX is a high explosive -- it
detonates rather than just burning. This was discussed in some detail on
alt.eng.explosives a couple months ago.
Even gaseous O2 can be ugly. Most first responder courses demonstrates a
small stream of O2 (~1L/min), such as comes from a breather mask, aimed at a
cigarette. The butt goes from dull red to blue-white actinic flame in an
instant.
Burning polycarbonate (CDs) in pure O2 is a recipe for serious injury.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 14:46:24 -0500
Scott Fluhrer wrote:
> <[EMAIL PROTECTED]> wrote in message news:8mtu40$9ck$[EMAIL PROTECTED]...
> > Alex Random Number Generator
> >
> > The objective of this algorithm is to map finite
> > key/seed to an infinite sequence of random bytes.
> > The implementation has following characteristics:
> >
> > - 16 byte Key/Seed
> > - 57% Avalanche Effect
> > - 760Kbyte/sec performance
> > - 64 Kbyte generated random string shows Null ZIP
> > compression
> > - The probability to find in random sequence 0/1
> > value bits is exactly 50%
>
> I looked at the algorithm, and it's dreadful. It basicly works by having 32
> bytes of internal states, and going through these steps:
>
> - An "arithmetic operation" that replaces various bytes within the state
> with sums and products of the original values (mod 256). I suspect this may
> be weak, but it is not the source of the problem.
>
> - A "reflection operation", which throws away half the state, and replaces
> it with the complement of the other half.
>
> - A "permutation operation", which does a fixed permutation on the bits of
> the state.
>
> - At this point, you output all of the state as a 32 byte block
>
> Obvious problems:
>
> - This is not a CSRNG. Since there is no hidden state and no key dependance
> on the operation, the second 32 byte block is a publicly computable function
> of the first 32 byte block.
>
> - The reflection operation enforces that exactly 128 bits of the block is 0
> and 128 bits is 1. The permutation operation does not change this. This
> means that each 32 byte block will have exactly 128 0's and 128 1's.
> Obviously, real random sequences don't do this.
>
> - Even worse, since the permutation operation is fixed, any linear
> relationships generated by the reflection operation will appear at
> predictable places in the output. For example, immediately after the
> reflection operation, bit 0 of byte 0 is the complement of bit 0 of byte 1.
> The permutation operation moves bit 0 of byte 0 to bit 5 of byte 5, and bit
> 0 of byte 1 to bit 3 of byte 12 (decimal). And so, in each block of the
> output, bit 5 of byte 5 will always be the complement of bit 3 of byte 12 --
> know one and you immediately know the other.
>
> Other comments:
>
> - The documentation of the algorithm was hideous (in no way could you
> reconstruct the algorithm from that), and the only detailed description was
> the source, which was mostly x86 assembly. This is ridiculous.
>
> - If I wasn't worried about the above weakness, another thing I would worry
> about is that the above operation throws away a *lot* of entropy. The
> reflection operation itself throws away 128 bits each iteration, and the
> arithmetic operation may throw away a considerable amount itself.
>
> --
> poncho
Actually I am not certian it will throw away 128 bits per itteration, but it
looks like it throws out half of the entropy each time it is used -- this means
that this RNG will eventually settle down into a fixed output stream( it may
take a LOOOOOONG time -- I havent messed with it enoungh to tell, but it should
eventually do so, as there is no mechanism for keeping the pool churning.)
------------------------------
Date: Fri, 11 Aug 2000 15:48:28 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Destruction of CDs
CMan wrote:
> Just re-label them as AOL free Internet. Nobody will ever look at them
> again.
Now that what I call steganography!
You could even send them to the recipient in the original mailer.
------------------------------
Date: Fri, 11 Aug 2000 15:50:32 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
I think the other message regarding terminology is the more fruitful discussion,
so I'll let this one die.
Mark Wooding wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> > Mark Wooding wrote:
> >
> > > Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> > >
> > > > Interesting verb: "find". AFAICT the issue is not finding short
> > > > cycles by searching for them, but finding a short cycle in the "oops"
> > > > sense of having inadvertently selected one for use. The practical
> > > > impossibility of finding one on purpose is independent of the
> > > > theoretical possibility of finding one by accident.
> > >
> > > Errr... no.
> > >
> > > If finding X by trying very hard is impractically difficult, then
> > > finding X by accidentally tripping over it must be at least as
> > > difficult. Otherwise, I have the algorithm for finding X by trying very
> > > hard: pick possible values at random and hope to trip over one by
> > > accident. This must work unless X can read minds and is deliberately
> > > perverse.
> >
> > Two conterclaims:
> >
> > 1) The space of short cycles is _larger_ than the space of factors to
> > evaluate. This it is not as hard to pick a bad (short) key as it is
> > to find the factors of a long cycle. I'm interested in detailed
> > refutations of this claim if you are able to mention any.
>
> I'm confused by your terminology. What is a `bad (short) key' here?
> What are the `factors of a long cycle'?
>
> > 2) The proposed algorithm fails because "tripping over X" works by
> > finding _any_ short X rather than _the_ X selected. This appears
> > obvious. Am I being stupid?
>
> In the above, in both cases, `X' is `any element of Q_n which lies on a
> short cycle'. Who do you think is doing the selection of `_the_ X'?
>
> -- [mdw]
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Sat, 12 Aug 2000 01:58:38 -0600
Reply-To: [EMAIL PROTECTED]
Simon Johnson wrote:
> [EMAIL PROTECTED] (fvw) wrote:
> ><8mth1u$vpt$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
> >>Can you generate truely random numbers? No.
> >yes. time between radioactive decays for instance is a
> >textbook example of a perfect random generator.
> >
>
> I query this...... Radioactive decay can be described by a
> Expodential Curve, and is therefore is not strictly speaking
> random.
>
> Though the emmition of particles is truely spontaneous.
Why do you say that? What's not random about exponential curves? Or any
other distribution?
------------------------------
Date: Fri, 11 Aug 2000 16:03:52 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
lcs Mixmaster Remailer wrote:
> Terry Ritter writes:
>
> > It is *not* difficult to factor N . . . if we give a factor away. To
> > even attempt to assume that factoring is difficult *implies* that the
> > system be constructed in such a way as to not give away the secret.
> > And a proper construction happens with BB&S (as far as I know), only
> > when short cycles are excluded from use.
>
> You are mixing up two things: the difficulty of factoring, and the
> proper construction of the BBS RNG.
>
> Factoring difficulty depends only on the choice of the factors.
> Nothing you do after that will affect how hard it is to factor them.
>
> Consider two RSA creators. One chooses an RSA modulus and lets the
> attacker try to factor it. The other chooses an RSA modulus and then
> sends random large integers to the attacker, which the attacker may
> use to try to help him with factoring.
Up to this point I follow your argument, but at this point there's a gap. It
sounds to me that the "random larger integers" sent to the second attacker
are, for exampe, RSA ciphertexts produced by the second creator. Is this
correct or did you mean "random large integers" literally?
>
>
> It should be clear that the second system is not any weaker than the
> first one. It cannot leak any information about the RSA factors merely
> by sending random data. If it could, then the first system's attacker
> could achieve the same strength simply by using a source of random values
> to aid its efforts.
If the above interpretation is correct the first attack cannot send himself
ciphertexts because he lacks the private key retained by the first creator.
>
>
> In particular, there is no reason for the second system to filter or
> check the random values that it sends in any way. Since these values
> cannot aid the attacker, there is no reason to worry that one of them
> may happen to reveal a factor of the RSA modulus. If circumstances
> were such that that could happen, the attacker could find the same
> information himself by running his own RNG.
>
> The second system, without any checks, still has security equal to that
> of the first. Its security is that of factoring an RSA modulus.
>
> The second system is very similar to the BBS RNG, in that we choose an RSA
> modulus and then we choose an independent random value to be the seed.
> Terry Ritter is worried that this seed could lead to a short cycle.
> It has been proven that if this happens, the RSA modulus could be
> factored.
>
> Therefore, if checking seeds to avoid those that lead to factorization
> is necessary, as Terry Ritter argues, it follows that in the second
> system above, it is also necessary to check the random values which are
> sent in order to make sure that none of them could lead to factors.
> The information which is being revealed in each case as the same effect.
>
> Since we've already established that no such checking is necessary for the
> second RSA system, it follows that no such checking is necessary for BBS.
> BBS has all the security of the factoring problem, even when its seeds
> are not checked for any special properties. They only have to be randomly
> chosen. This is what is proven in BBS and the subsequent literature.
------------------------------
Subject: Huge S-boxes!
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 13:04:28 -0700
This is really two questions in one:
1. If we pick a random number, N, then pick a random prime, P,
such that it is less than N. We then iterate F(X) from 0 to 0.95N
where F(X) = (X^p) mod N. Can we derive the remaining 5% mapping
without doing the expodentation.
2. Can Linear and differential cryptanalysis be performed on S-
boxes which are so large that all the mappings are not know?
Simon.
PS. Suggestions for books which covere Linear and Differential
would be welcomed.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Destruction of CDs
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 13:11:44 -0700
Destroying CD's? Just burn them.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Date: Fri, 11 Aug 2000 16:26:39 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Tim Tyler wrote:
> tomstd <[EMAIL PROTECTED]> wrote:
>
> : Try a 1GB string and compress it. Also a random string
> : should compress a little over lots of data.
>
> From this it looks like you don't share Chaitin and Kolmogorov's notion
> of what randomness is.
Calling compressibility randomness does not lead to enlightenment. And the
randomness of finite strings is, ummm, less than meaningful, even if they are
a gigabyte long.
------------------------------
Date: Fri, 11 Aug 2000 16:29:08 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Between this and Szopa I'm guessing the moon is full.
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <8mtu40$9ck$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > says...
> > > Alex Random Number Generator
> > >
> > > The objective of this algorithm is to map finite
> > > key/seed to an infinite sequence of random bytes.
> >
> > This, of course, is impossible.
>
> Do you think that there is no mapping of finite sets of natural
> numbers into set of infinite sets of natural numbers?
> Please evaluate this algorithm and you will believe.
>
> >
> > > - 16 byte Key/Seed
> > > - 57% Avalanche Effect
> > > - 760Kbyte/sec performance
> > > - 64 Kbyte generated random string shows Null ZIP
> > > compression
> >
> > A 16-byte key is large enough that although the sequence must
> > eventually repeat, it shouldn't happen soon enough to care about.
> > We've already gone over (in almost ridiculous detail) how stupid it
> > is to make statements about performance without qualifying the
> > statement as to the situation in which that particular level of
> > performance was obtained. Avalanche normally applies to ciphers, not
> > PRNGs, so it's hard to even guess at what you mean by "57% avalanche
> > effect", though unless you're measuring something _really_ unusual,
> > 57% is probably a pretty BAD number to get: for most obvious things
> > you'd measure, you'd want outputs as close to either 50 or 100% as
> > possible, and only numbers within .001 or so of those would be good
> > enough to keep from rejecting the generator outright.
> >
>
> Thank you. Please let to do some more investigations.
>
> > > - The probability to find in random sequence 0/1
> > > value bits is exactly 50%
> >
> > This shows a lack of bias, but that's a long ways from being a
> > comprehensive test of a PRNG.
> >
>
> Please check it yourelf.
>
> > You PRNG fails some of the FIPS 140-2 tests fairly regularly. It
> > fails quite a few of the DieHard tests very consistently. Your PRNG
> > is clearly NOT suitable for cryptographic use.
>
> It is only your assumption. Let us proof it.
>
> Regards.
> Alex.
>
> >
> > --
> > Later,
> > Jerry.
> >
> > The Universe is a figment of its own imagination.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: Fri, 11 Aug 2000 16:34:19 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Scott Fluhrer wrote:
> <[EMAIL PROTECTED]> wrote in message news:8mtu40$9ck$[EMAIL PROTECTED]...
> > Alex Random Number Generator
> >
> > The objective of this algorithm is to map finite
> > key/seed to an infinite sequence of random bytes.
> > The implementation has following characteristics:
> >
> > - 16 byte Key/Seed
> > - 57% Avalanche Effect
> > - 760Kbyte/sec performance
> > - 64 Kbyte generated random string shows Null ZIP
> > compression
> > - The probability to find in random sequence 0/1
> > value bits is exactly 50%
>
> I looked at the algorithm, and it's dreadful. It basicly works by having 32
> bytes of internal states, and going through these steps:
>
> - An "arithmetic operation" that replaces various bytes within the state
> with sums and products of the original values (mod 256). I suspect this may
> be weak, but it is not the source of the problem.
>
> - A "reflection operation", which throws away half the state, and replaces
> it with the complement of the other half.
Iterating a sequence containing this step should produce a strange attractor
cycle. A PRNG that converges on a minimal length cycle is about as bad as I can
think of. It's worse than a degenerate one-state cycle because there's no way
to confuse the output of a degenerate source with the output of a random source.
------------------------------
Date: Fri, 11 Aug 2000 16:35:45 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> > Arithmetic operations with lose of overflow bit by addition and overflow
> > byte by multiplication implement one way function. It is impossible to
>
> This isn't clear at all. And in any case, a one way function should be
> impossible to guess the input to as well. I mean, if you lose one bit
> you've basically got a 50-50 chance of guessing what it was. ;)
>
> > Let me ask you how can man implement permutation of bits not using
> > Assembler?
>
> Frankly, _this_ is what gets most people's goat. What I completely
> fail to understand is how someone so interested in math and invested
> the time to learn x86 assembly can't manipulate bits in a higher level
> language.
Dain bramage.
------------------------------
Date: Fri, 11 Aug 2000 16:40:38 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Pentium III h/w RNG
Joseph Ashwood wrote:
> I think we all kind of gave up when it was discovered that if it wasn't
> present the motherboard gave back random garbage. Actually some analysis was
> done, but the only stuff I'm aware of was funded by Intel.
I question the use of the term "random garbage". Either the motherboard works
to spec without the chip installed or the garbage is predictable.
;-)
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Destruction of CDs
Date: Fri, 11 Aug 2000 13:38:24 -0700
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jerry Coffin wrote:
>
> > In article <KWHk5.1548$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] says...
> >
> > [ ... ]
> >
> > > Stack cd's.
> > >
> > > Duct tape into a cylinder and pipe lots of pure O2 into central
cavity.
> > >
> > > Light.
> >
> > Go to:
> >
> > http://ghg.ecn.purdue.edu/
> >
> > for detailed information on something just a TINY bit more insane
> > than just pure O2 (including full color pictures and even video of
> > the insanity). He wasn't lighting CD's but I'm _sure_ they'd burn
> > quite nicely given the same treatment...
>
> Read the fine print where it says "don't try this at home" and "provide an
> initial ignition source". Charcoal soaked in LOX is a high explosive --
it
> detonates rather than just burning. This was discussed in some detail on
> alt.eng.explosives a couple months ago.
>
> Even gaseous O2 can be ugly. Most first responder courses demonstrates a
> small stream of O2 (~1L/min), such as comes from a breather mask, aimed at
a
> cigarette. The butt goes from dull red to blue-white actinic flame in an
> instant.
>
> Burning polycarbonate (CDs) in pure O2 is a recipe for serious injury.
Oh Youbetcha.
What gave me the idea was.
There was a throttle-able solid rocket once propsed that had a cylindrical
core of butyl rubber where the thrust control was achieved by metring the
flow of LOX into the core. It's big problem was that you can not turn in
back on if it blows out. Re-introducing O2 into a hot hydrocarbon vapor is
one of those really bad things to do.
Subtle point: If you are going to pollute for convienience sake, at least
achieve entertainment or space travel, at best, skim the gene pool.
Paul
>
>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: 1-time pad is not secure...
Date: 11 Aug 2000 21:06:37 GMT
jkauffman wrote:
>> Actually, I measured this stuff all the time as a grad
>> student.
>
>and your measuring equipment was absolutely perfect,
>measured the underlying phenomenon to arbitrary precision,
>and introduced no bias to the results due to manufacturing
>imperfections whatsoever?
Hmmm. Interesting that you challenge the memories of a grad
student and not the post where I gave a valid metrological
upper limit on measurement inaccuracy.
I tell you, folks, this discussion isn't about science or
engineering. It's about the spreading of a particular meme.
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: 11 Aug 2000 22:08:31 +0100
Mickey McInnis <[EMAIL PROTECTED]> wrote:
: He can also try variants of "Give me the pad for future incoming messages.
: I'll hold you and shoot you if it doesn't work on the next message received."
Then give him the fake pad and send a few dummy messages in that to
lull him into a false sense of security.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [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
******************************
