Cryptography-Digest Digest #400, Volume #12 Thu, 10 Aug 00 15:13:01 EDT
Contents:
Re: Software license software with PK ???? ("Benny Nissen")
Re: 1-time pad is not secure... (AllanW)
Re: OTP using BBS generator? (lcs Mixmaster Remailer)
Re: BBS and the lack of proof (Mok-Kong Shen)
Re: PKCS#7 ("Kevin Crosbie")
Re: 1-time pad is not secure... (tomstd)
Re: Destruction of CDs (tomstd)
Re: OTP using BBS generator? (Terry Ritter)
Re: OTP using BBS generator? (Terry Ritter)
Re: Software license software with PK ???? ("Benny Nissen")
Re: BBS and the lack of proof (tomstd)
Re: 1-time pad is not secure... ("Douglas A. Gwyn")
Re: chap authentication scheme? ("Tomas Rosa")
Re: Destruction of CDs ("Joseph Ashwood")
Re: Physical RNG ("Joseph Ashwood")
Re: Destruction of CDs (Tom Anderson)
Re: 1-time pad is not secure... (Tom Anderson)
Re: 1-time pad is not secure... ("Douglas A. Gwyn")
Re: 1-time pad is not secure... (fvw)
Re: Japanese Kyudo and Quantum computation (Uncle Al)
----------------------------------------------------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Re: Software license software with PK ????
Date: Thu, 10 Aug 2000 17:57:24 GMT
I can not see why it is so that a public key algorithms may need to inflate
the size of the encrypted data. The strongness/security of the algorithm
must be based on the keys and not based on the length of the encrypted data.
Sorry this may be a stupid statement, but it seam to me that everybody look
in the same historical direction when implementing PK systems. (because I am
unable to understand why the security of the algorithm is based on the
length of the encrypted data)
Benny
"Joseph Ashwood" <[EMAIL PROTECTED]> skrev i en meddelelse
news:uar#HziAAHA.462@cpmsnbbsa08...
> I hate to be the bearer of bad news, but to the best of my knowledge,
there
> are no public key algorithms that do not inflate the size of the encrypted
> data. The closest you could get would be something like a ECC exchange
> (about 160-bits) used to encrypt a couple of blocks of a block cipher of
> your choice. Total: around 500bits (2 public keys, one for each side, and
a
> 128-bit encrypted block) and reasonably secure. You could slim it down
> various ways, by having the program generate a new ephemeral key every
time
> a certain part is run, and storing your key long-term in the program. That
> way all that needs to happen is the user sends their public key with the
> registration, and you send them the block encrypted with the
semi-ephemeral
> key, so you only send the block ciphered data,but the complete transfer is
> inflated by the clients public key.
> Joe
>
> "Benny Nissen" <[EMAIL PROTECTED]> wrote in message
> news:KBbk5.11515$[EMAIL PROTECTED]...
> > Hi All
> >
> >
> >
> > My background is the need for a good public key library implementation
to
> >
> > do software license software (will make a hackers key-generator
useless).
> I
> >
> > am unable to use RSAREF because it output the same size (crypt text) as
> >
> > the modulus size, and this make the output far too big compared to my
> >
> > needs (if I like to make it secure)
> >
> > I need a public key encryption algorithems that maintain the same size
> >
> > public encrypted as decrypted (as with most block cifers).
> >
> > The plain text document will be known, and also the public key will be
> >
> > known. Then a test will see if the encrypted version match the plain
text
> >
> > version.
> >
> > I do not know if this is possible in some way with Elliptic Curve
> >
> > cryptography or other PK algorithems?
> >
> >
> >
> > Thanks
> >
> > Benny Nissen
> >
> >
> >
>
>
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Thu, 10 Aug 2000 17:49:05 GMT
In article <[EMAIL PROTECTED]>,
Mike Calder <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]>
> writes
> >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.
> >
> >Yep.
> >
> >I'm very surprised to hear someone believes true
> >random isn't available. Shows a serious lack in
> >ideas about modern physics, doesn't it ?
>
> It may be unpredictable, but does that make it random?
From http://www.dictionary.com
Random (adj)
2. Statistics. Of or relating to the same or equal
chances or probability of occurrence for each member
of a group.
So, yes. If it's absolutely unpredictable, it's random.
I'd say that a spectrum exists. One end is "predictable,"
meaning we (can) know with 100% certainty what will happen
next. The other end is "random," meaning we cannot find
even a trend where one thing is more likely to happen than
another.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 10 Aug 2000 18:00:25 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
David Hopwood writes:
> Note that the proofs in the BBS paper (and in the Crypto '84 paper by Vazirani
> and Vazirani proving a reduction to factoring) are all asymptotic, so
> unfortunately we can't make stronger statements relating the exact probability
> of being able to distinguish the BBS output from random with a specific amount
> of work, to the probability of being able to factor or solve the QRP with a
> similar amount of work (at least, not based on those proofs). But if the
> underlying question being debated in this thread is about the general validity
> of probabilistic proof, rather than its application to BBS in particular, then
> there are plenty of other cryptosystems for which exact reductions have been
> proven.
First, thanks to the reference to Vazirani&Vazirani. We can dispense
with the awkward claim that BBS reduces to quadratic reciduosity, and
simply say that it reduces to factoring. If you think you need to check
for short cycles, then you think your opponent can factor your modulus
by guessing cycles.
However, you have made one very unfortunate misstatement, which is that
the proofs are asymptotic. This is not true, at least for the commonly
understood meaning, which would be that they are asymptotic in N, the
modulus, and so don't apply in general to any specific N. The proofs
are NOT asymptotic in N. BBS/Vazirani shows very clearly that for ANY
modulus, if you have an epsilon advantage for guessing the BBS sequence,
you can factor THAT modulus.
(Furthermore, as was shown here, the ability to find short cycles by
guessing immediately leads to factoring in a much simpler way.)
Terry Ritter has claimed in the past that BBS is only an asymptotic
result, part of his general campaign to spread doubt on the technology.
This is completely mistaken and I am sorry to see you add credence to
his misconceptions.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BBS and the lack of proof
Date: Thu, 10 Aug 2000 20:12:22 +0200
tomstd wrote:
>
> Given two primes
> p=121012662526787295907262401512751757545611582897620391004818266
> 981159050711
>
> and
>
> q=375132239070794634471679739337309743812131772704924806435878390
> 190959014553
>
> and a starting x[0] of 1291842616032279148102643839788703561
>
> What is the period of this generator?
You wouldn't get any figure of the period. I guess the answer
is likely to comprise of: (1) According to the 'mathematics' in
the BBS paper, the output of the congruence relation is very
very likely to be very very very big. (2) What the period of
the LSB of the output is (a matter that interests you) does
not belong to 'admissible' topics about BBS (because the paper
left open that question) and is hence 'by definition' of no
interest, point.
M. K. Shen
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Re: PKCS#7
Date: 10 Aug 2000 18:02:06 GMT
Yeah that looks cool. That will do what I want. Thanks.
Does anyone know if the WinAPI or CryptoAPI can do PKCS#7 encoding directly
rather than using outside source code.
Cheers,
Kevin
"Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
news:8mtmdt$mvp$[EMAIL PROTECTED]...
> In article <8ms3ov$[EMAIL PROTECTED]>,
> Kevin Crosbie <[EMAIL PROTECTED]> wrote:
>
> > Has anyone got a good C implementation of PKCS#7?
> > I need to encapsulate a signature hash and certificate in PKCS#7.
>
> Did you check out www.openssl.org ???
>
> --
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
> WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Subject: Re: 1-time pad is not secure...
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 10:57:28 -0700
[EMAIL PROTECTED] wrote:
>Here's a different viewpoint.
>
>I think all the crypto-books are wrong. One-time pad is only
secure
>based on the assumption that random numbers do exist.
>
>But can you prove that random numbers really exist? No.
>Can you generate truely random numbers? No.
>
>It's like 1/x tends to zero but you'll never get zero, if you
use
>enough bytes to hold the number.
>
>One-time pad is only computationally secure, no difference than
any
>other systems. The key-generating process may be duplicated, if
not
>exactly, to some probability. And because the key is so long,
getting
>at least a portion of the key right will be easier than in
systems with
>a shorter key.
>
>Get the picture? You can duplicate the key-generating
parameters:
>computer model, OS, PRNG, date, time, location, hardware,
software,
>room temperature, humidity, magnetic field... The list goes on
and on.
>Then the longer the key, the higher possibility that you'll get
>something right.
>
1, 4, 18, 23, 0, 7, X
What is 'X'?
Nuff said.
Tom
===========================================================
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: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 11:00:53 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>Thomas Kellar wrote:
>>
>> There was a thread on this topic a couple of weeks ago.
>> I received an advertisement for a device that shreds
>> CDs. If anyone is interested the company name/address is
>
>Wouldnt a very strong magnetic field help?
CD's are not magnetic... so you would have to rip the atoms off
the cd to destroy it with a magnet...
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Thu, 10 Aug 2000 18:07:21 GMT
On 10 Aug 2000 15:01:56 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>
>> From my point of view, the whole reason for a proof is to absolutely
>> guarantee something. The sort of proof we have been discussing simply
>> does not do that, presumably because it is not really the same sort of
>> "proof" that students learn in algebra. I assume that what we really
>> have is a *statistical* proof, which is *not* just a different form of
>> proof and just as good, but instead a *lesser* *standard* of proof.
>
>Errr... no. The proof not statistical. It states that the output of a
>BBS generator cannot be distibguished from random data by any
>polynomial-time test by an adversary who cannot decide quadratic
>residuosity.
That is simply false when a short cycle is used. Unless you
absolutely prevent such a thing, you cannot assume in your reasoning
that it has not occurred. On the contrary, if something *might*
occur, you must assume that it *has* occurred, and reason the
consequences from there.
>And this is the way that security proofs work in cryptography: we prove
>relationships between solving different types of problems. It's a
>strict relationship, rigorously proven.
Saying something is "proven" is no advantage unless we need the object
of the proof. Here the issue is *not* whether BB&S is secure; the
issue is whether the reduced version -- including short cycles -- is
secure even if we assume factoring is hard. I am happy to agree that
reduced BB&S is *almost* always secure, but since we can prevent the
short-cycle weakness completely, almost always is not good enough.
And claiming that *must* be secure because the math says so is just
wrong. Using an insecure system is not secure.
>> And we have yet another problem: How can we believe that the short
>> cycle insecurity is the *only* one which this proof allows to exist?
>> We *can* prevent the short-cycle insecurity, because we know about it.
>> But we *can't* prevent other security problems about which we know
>> nothing.
>
>Actually, this is wrong. If there's a distinguisher for the BBS, then
>either it's not polynomial time, or we can solve the QRP in polynomial
>time. The former would be quite interesting; the latter would be an
>extremely important result. The proof is not statistical: these are the
>only two possible outcomes.
Then the proof is wrong. For we *absolutely* *know* that using a
short cycle can be weak (when we traverse the cycle).
Actually, it is your consequence that is wrong: Most problems are
easy to solve when the solution is leaked. What we have here is a
construction which leaks the solution, unless explicitly prevented.
So the failure does *not* impact math theories. Which also implies
that those same theories cannot be depended upon for reasoning about
strength in this and similar situations.
>> For the purposes of this discussion, I believe we have all accepted
>> factoring security. More generally, I am less confident.
>>
>>
>> >One other point, because it keeps coming up. The toy example of 1081 =
>> >23*47 is meaningless in evaluating the *tractability* of finding short
>> >cycles.
>>
>> Of course.
>>
>> >Factoring 1081 is trivial. Hence the proof which reduces
>> >finding cycles to factoring will not apply, because factoring a number
>> >of this size is not difficult. You might as well try to evaluate the
>> >security of AES by cutting it down to something with a 10 bit key.
>>
>> Tiny versions of any scalable cipher are generally not secure, so one
>> might ask, "What good are they?" Well, tiny versions provide valid
>> insight into the structure of a complex system at a size that humans
>> can approach. Such a system actually can be measured and analyzed
>> experimentally, to either verify or refute assertions made from theory
>> alone.
>
>You must be careful when you do this sort of analysis. Examining one
>example is not good enough. Even looking at lots (as you did, if I
>remember from your article) isn't useful if you analyse the data in the
>wrong way.
>
>For example, how is the cycle length related to the size (log_2) of the
>modulus? Is the relationship polynomial or (sub)exponential? In the
>latter case, we've not found anything interesting, because we always
>knew we could distinguish BBS with greater-than-polytime tests; in the
>former, yes, that's interesting.
One can always question experimental design. But only a scalable
cipher allows us to run comprehensive experiments in the first place.
Trying to understand a cipher from experiments on a real-size system
is generally hopeless, unless there are such massive errors that
incredibly sparse sampling would detect them. On a tiny cipher we
expect to have examples of the same sorts of errors, which implies
that they will be represented with greater probability. That is
great, because if the problems were represented with their real-size
probability, we would not even detect them.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Thu, 10 Aug 2000 18:12:16 GMT
On Thu, 10 Aug 2000 09:11:59 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
>[...]
>AFAICS, BBS was never suppsed to be "absolutely secure" in the
>first place. Saying a problem is as hard as factoring does not
>provide any sort of "absolute security".
The assumption is made that factoring is hard, so in that situation,
BB&S should be "proven absolutely secure." Yet it is not. That is a
contradiction. What we actually have is: "proven almost always
secure."
It is *not* sufficient that the assumptions be true: Even when the
assumptions *are* true, BB&S *still* is weak every now and then.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Re: Software license software with PK ????
Date: Thu, 10 Aug 2000 18:15:58 GMT
BTW: Thanks for the info, but this is not a way I like it to turn out.
The problem is related to the need for the end user to send in their public
key to be able to generate a registration.
I would like to be able to generate a registration without any specific
knowledge about the end user.
Benny
"Joseph Ashwood" <[EMAIL PROTECTED]> skrev i en meddelelse
news:uar#HziAAHA.462@cpmsnbbsa08...
> I hate to be the bearer of bad news, but to the best of my knowledge,
there
> are no public key algorithms that do not inflate the size of the encrypted
> data. The closest you could get would be something like a ECC exchange
> (about 160-bits) used to encrypt a couple of blocks of a block cipher of
> your choice. Total: around 500bits (2 public keys, one for each side, and
a
> 128-bit encrypted block) and reasonably secure. You could slim it down
> various ways, by having the program generate a new ephemeral key every
time
> a certain part is run, and storing your key long-term in the program. That
> way all that needs to happen is the user sends their public key with the
> registration, and you send them the block encrypted with the
semi-ephemeral
> key, so you only send the block ciphered data,but the complete transfer is
> inflated by the clients public key.
> Joe
>
> "Benny Nissen" <[EMAIL PROTECTED]> wrote in message
> news:KBbk5.11515$[EMAIL PROTECTED]...
> > Hi All
> >
> >
> >
> > My background is the need for a good public key library implementation
to
> >
> > do software license software (will make a hackers key-generator
useless).
> I
> >
> > am unable to use RSAREF because it output the same size (crypt text) as
> >
> > the modulus size, and this make the output far too big compared to my
> >
> > needs (if I like to make it secure)
> >
> > I need a public key encryption algorithems that maintain the same size
> >
> > public encrypted as decrypted (as with most block cifers).
> >
> > The plain text document will be known, and also the public key will be
> >
> > known. Then a test will see if the encrypted version match the plain
text
> >
> > version.
> >
> > I do not know if this is possible in some way with Elliptic Curve
> >
> > cryptography or other PK algorithems?
> >
> >
> >
> > Thanks
> >
> > Benny Nissen
> >
> >
> >
>
>
------------------------------
Subject: Re: BBS and the lack of proof
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 11:09:49 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>>
>
>> Given two primes
>>
p=121012662526787295907262401512751757545611582897620391004818266
>> 981159050711
>>
>> and
>>
>>
q=375132239070794634471679739337309743812131772704924806435878390
>> 190959014553
>>
>> and a starting x[0] of 1291842616032279148102643839788703561
>>
>> What is the period of this generator?
>
>You wouldn't get any figure of the period. I guess the answer
>is likely to comprise of: (1) According to the 'mathematics' in
>the BBS paper, the output of the congruence relation is very
>very likely to be very very very big. (2) What the period of
>the LSB of the output is (a matter that interests you) does
>not belong to 'admissible' topics about BBS (because the paper
>left open that question) and is hence 'by definition' of no
>interest, point.
Well what if I was making a prng I would really like to know the
period. How do you know the period is not just seven outputs?
Therefore I submit that all BBS generators have a period under
10, prove me wrong without empiracle evidence.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Thu, 10 Aug 2000 17:33:54 GMT
[EMAIL PROTECTED] wrote:
> But can you prove that random numbers really exist? No.
With a more careful definition of terms, Yes (see Chaitin).
> Can you generate truely random numbers? No.
With sufficient care, Yes. If the source has a stationary
P.D., then bias can be removed with nearly perfect efficiency,
too. ("How to Turn Loaded Dice into Fair Coins" by Juels
et al. in IEEE Trans. Inf. Thy., Vol. 46 No. 3 pp. 911-921)
> It's like 1/x tends to zero but you'll never get zero,
> if you use enough bytes to hold the number.
It's not like that at all.
> One-time pad is only computationally secure, no difference than any
> other systems. The key-generating process may be duplicated, if not
> exactly, to some probability. And because the key is so long, getting
> at least a portion of the key right will be easier than in systems with
> a shorter key.
With a truly random key stream, any such duplication of
key is purely coincidental and unpredictable, so it cannot
be used to leak PT information.
------------------------------
From: "Tomas Rosa" <[EMAIL PROTECTED]>
Subject: Re: chap authentication scheme?
Date: Thu, 10 Aug 2000 14:46:23 +0200
"David A. Wagner" <[EMAIL PROTECTED]> wrote in message
news:8ms9ke$dlu$[EMAIL PROTECTED]...
> If g,N are fixed and known in advance and hard-coded everywhere, then
> this attack doesn't work. But the original post showed them sent on
> the wire to the user, which is why I assumed there is an attack.
Good note. But in many systems used nowadays the user will know not only
appropriate p, but also N. Because it should be the user, who has to choose
(generate) public parameters g and N and send them (via some trusted
channel) to the server. On the other hand you are right - it has not been
written in the original concept.
> By the way, there's a second attack here, if you don't expand the password
> using, e.g., OAEP. It _does_ apply even if g,N make the discrete log
> hard. Suppose you use a truly-random 100-bit quantity as your password p.
OK, but would not it be better to let the user to generate the "full-sized"
exponent p < phi(N) and then try to protect this value (in smartcard or
encrypted with the user's passphrase)? As Mark allready mentioned here, it
is just a variant of D-H protocol, which is fully supported in crypto tokens
or libraries nowaday. And this idea conforms to these implementations.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Destruction of CDs
Date: Thu, 10 Aug 2000 11:07:59 -0700
Actually that's one of the recent themes around here. We had a very extended
discussion about it, and the basic rundown was: If you really want to get
rid of the data, use an incinerator, everything else isn't of much import.
Joe
"Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]> wrote in message
news:8muh90$qg8$[EMAIL PROTECTED]...
> I read about destroying CDs something like that:
> Don't microwave your CDs,because it causes
> toxic gas. Put at least two big scratches on the
> reflection layer instead. What do you people here
> think about this method?
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Physical RNG
Date: Thu, 10 Aug 2000 11:35:10 -0700
> Joe, you worry me. You can't just go on bottling up your
> opinions like this. If you disagree with Szopa, just come
> right out and say it plainly withoutb mincing words!
> Go on, tell us what you *really* think instead of just
> dropping hints.
I worry a lot of people. The problem is that I try to avoid saying the words
that make up my opinion of Szopa, especially in a public forum. I have no
respect for his intellect, nor his integrity, nor his skill in
cryptanalysis, nor his ability to determine randomness from biasless, nor
his education, nor anything else that I feel can be made judgement on via a
newsgroup. Also remember I was the one that made the comment something like
Szopa makes me long for the days when we didn't have much more than DS to
deal with.
Joe
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: Destruction of CDs
Date: Thu, 10 Aug 2000 19:39:10 +0100
On Thu, 10 Aug 2000, Mok-Kong Shen wrote:
> Thomas Kellar wrote:
>
> > There was a thread on this topic a couple of weeks ago.
> > I received an advertisement for a device that shreds
> > CDs. If anyone is interested the company name/address is
>
> Wouldnt a very strong magnetic field help?
help wipe a CD? now, i'm no physicist, but i thought CDs were optical
media, so a magnetic field should have no effect. unless you're hoping to
twist the electrons out of their orbits - that's one helluva field!
i once went on a tour of the magnet lab in the university physics
department; they make huge superconducting coils to produce immense fields
for, er, scientific purposes. the problem is that a coil always sets up a
field such that the current moving through the coil exerts an outward
force on the wire (left-hand motor rule and all that), so the coils have
an unfortunate tendency to explode ...
tom
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Thu, 10 Aug 2000 19:45:16 +0100
On 10 Aug 2000, Guy Macon wrote:
> Runu Knips wrote:
> >
> >fvw wrote:
> >> <8mth1u$vpt$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
> >> >Can you generate truly random numbers? No.
> >
> >> yes. time between radioactive decays for instance is a
> >> textbook example of a perfect random generator.
> >
> >I'm very surprised to hear someone believes true
> >random isn't available. Shows a serious lack in
> >ideas about modern physics, doesn't it ?
>
> Heisenberg killed this theory, Chaos theory nailed the coffin shut,
> and Quantum Mechanics presided over the cremation.
well, chaos theory is actually deterministic - the key idea is that simple
deterministic processes can produce stochastic (ie random-looking) output.
sort of physical cryptography :). this leads to the observation that
apparently random information may actually have a simple but well-hidden
structure - this is where strange attractors come in (i think); for
instance, if you measure the time between drips of a tap, the intervals
appear random, but if you plot each interval against the two before it (in
a 3d plot, of course), there's a pattern. or something.
and as for quantum theory ... well, is it necessarily random? couldn't
there be hidden variables? i understood that this had been ruled out, but
that the proof was recently reexamined and found to be toss. now, this was
several years ago, and not from a hugely authoritative source, but hey.
i'll check with a colleague.
tom
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Thu, 10 Aug 2000 17:40:04 GMT
Guy Macon wrote:
> ...Close... ...so very close... Actually, OTP is secure against
> being decoded by cryptanalysis if the numbers are unpredictable,
> which is a weaker claim than random. For example, chaotic
> systems are often unpredictable without being at all random.
No, you have overstated it. Individual outputs of a chaotic
process might very well be "unpredictable" in some sense, but
there could still be strong statistical correlations among
them that could be exploited by a cryptanalyst. (For example,
every 10th value might be close to the value 10 iterations
previous.) "Patternless" might have been a better description.
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Thu, 10 Aug 2000 18:42:41 GMT
<[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>and as for quantum theory ... well, is it necessarily random? couldn't
>there be hidden variables? i understood that this had been ruled out, but
>that the proof was recently reexamined and found to be toss. now, this was
>several years ago, and not from a hugely authoritative source, but hey.
>i'll check with a colleague.
I'm not completely up to scratch on hidden variables theory, but the
only way hidden variables can work (if it can work at all) is as long
as the variables remain so hidden they do not give more informatoin
than copenhagen QM. So in the end, even though the info might exist,
it still doesn't help you, not even theoretically.
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: Uncle Al <[EMAIL PROTECTED]>
Crossposted-To: alt.philosophy.zen,sci.physics
Subject: Re: Japanese Kyudo and Quantum computation
Date: Thu, 10 Aug 2000 11:49:39 -0700
ca314159 wrote:
>
> Functionally, the Zen archer is performing the same
> process we expect a quantum computer to perform:
[snip]
Grantsmanship.
--
Uncle Al
http://www.mazepath.com/uncleal/
http://www.ultra.net.au/~wisby/uncleal/
http://www.guyy.demon.co.uk/uncleal/
(Toxic URLs! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
------------------------------
** 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
******************************
