Cryptography-Digest Digest #669, Volume #10 Thu, 2 Dec 99 20:13:02 EST
Contents:
Re: Quantum Computers and Weather Forecasting ("Trevor Jackson, III")
Re: more about the random number generator (CLSV)
"Fingerprinting" an algorithm? (John Savard)
Re: Any negative comments about Peekboo free win95/98 message encryptor program ?
(Steve K)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
----------------------------------------------------------------------------
Date: Thu, 02 Dec 1999 19:26:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
John Savard wrote:
> Quantum computers potentially offer the possibility of performing a
> computation in parallel for an enormous number of different
> combinations of input parameters, and then producing a result for only
> one such combination if that combination produces a result that meets
> certain criteria.
>
> This may be useful to extend the range and accuracy of weather
> forecasting.
>
> Although chaos theory sets an irreducible limit to the useful range of
> advance forecasts of weather, based on the growth of random inputs
> caused by nonlinearities in the system,
>
> in practice, the limit imposed by the limitations in the precision and
> detail of input data about the state of the weather at a given moment
> impose a stricter limit.
>
> It is theoretically possible to obtain information about the missing
> components of the state of the Earth's atmosphere at a given time by
> the following technique: for each possible set of values for the state
> of the unobserved part of the Earth's atmosphere, run the equations
> backwards to obtain a long-term "prediction" of the weather on
> preceding days. That hypothetical state of the atmosphere which
> produces the longest-term accurate forecast in the reverse direction
> is the state most likely to be correct.
>
> Quantum computers would seem to directly lend themselves to such a
> computation, should they become practical. (However, the limit on
> search algorithms may be fatal, as even the square root of the number
> of possibilities here is prohibitively large.)
>
> Perhaps there is a mathematical technique possible that avoids such
> extravagance, by working with the state of the weather several days
> ago, and incrementally updating missing parts of the atmospheric state
> in response to forecast errors. The principle would be the same: to
> use the depth of available atmospheric data in time to substitute for
> the lack of detail in our knowledge of the state of the atmosphere at
> any one moment.
A critical threshold exists in all such modeling systems. One must insure
that the error bounds on the modeled state values grow more slowly that
the information gained at each step. In essence, the backward prediction
has to converge.
One may run such a simulation backwards by increments, and thus detect
improbable initial states early in the search. The ability to prune the
state/search space reduces the size of the problem but does not improve
the "convergence" rate.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Fri, 03 Dec 1999 00:24:42 +0000
Anton Stiglic wrote:
> Brian Chase wrote:
> > Naive question here. Let's say you had access to some "optimum
> > compressor" which would take arbitrary data sets distill them into their
> > most compact form. By definition, the resulting data must have no
> > predictable redundancies, yes?
Correct.
> > Could you use optimally compressed data
> > sets as sources for random numbers?
That would be nice, however optimal compression can not be computed
in reasonable time.
> Your input would have to be random, so might as well just use the input
> (you'd have more bits of randomness).
> If you don't use random input, and I know about the compression algo
> you use, I could just reverse the output (decompress) and look at the
> results. If they don't look random, I know you are not using random inputs,
> and might be able to predict futur outputs.
In Kolmogorov complexity an incompressible string is
as random as you can get. The intuition is that a string that is
optimally compressed has no redundancy or patterns that you can
use to compress it. Because it has not (useful) patterns it is
also random. If you could decompress a string into a larger
random string. That larger string obviously has some patterns
so it isn't random.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: "Fingerprinting" an algorithm?
Date: Fri, 03 Dec 1999 00:41:59 GMT
On 19 Nov 1999 09:21:36 -0700, crippa <[EMAIL PROTECTED]>
wrote in sci.crypt.research:
>Is it possible to construct an enciphering algorithm Ex which
>will give the enciphered message a fingerprint?
>(Not to be confused with a digital signature.)
>The fingerprint will assure any reader of the enciphered message
>-even a reader without the appropriate key- that the underlaying
>plaintext was enciphered with the Ex algorithm.
>That is, Alice sends an enciphered message, having
>this fingerprint, to Bob. If Eve intercepts the enciphered
>message and performs the fingerprint verification algorithm
>she will conclude that enciphering algorithm Ex was used.
This sort of thing can be done, for key escrow purposes, with
tamper-resistant hardware.
Can it be done algorithmically?
Let us suppose that all we're trying to prove is that "This ciphertext
is the output of the X algorithm", without proving that the input to
the X algorithm was plaintext. We may constrain the choice of the
algorithm, but we mustn't limit its security (unduly, even if the
ultimate intent is to impose some limit).
Would the following be a way?
Let us take our plaintext, and a checksum of it.
Let us subject the checksum repeatedly to a one-way transformation.
If we can encipher our plaintext, using our key, so that we can make
that checksum match the transformed versions of the checksum,
then providing the final enciphered message and the original checksum
would prove that _parts_ of this process were carried out.
But it wouldn't really prove that the required algorithm was used,
unless the checksum had some properties that it was difficult to
control unless only the required algorithm was used, and that would
usually limit the security fatally.
If we encipher the same message twice with two different keys, and
supply the "difference" between the keys, and this relates to some
kind of "difference" between the two encrypted messages - would that
help?
This doesn't really seem to be the kind of thing doable in software,
although it suggests some kind of zero-knowledge proof...
Ah, yes. First, XOR the message with random bits.
Encipher both the random bits and the enciphered message using
Algorithm X, but with two different keys. Include a secure hash in
what is enciphered.
Then allow someone to request _one_ of the two keys at random.
(Require a hash of the message to be submitted to a trustworthy
authority before a Diffie-Hellman handshake, in which a bit in a
standard position in A^(xy) will be taken as the choice, takes place!)
Then the two keys are protected by being XORed with the agreed
Diffie-Hellman session key, and the message is sent.
So software can tell a trusted authority that a message was enciphered
in Algorithm X before that authority will allow it to be sent.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
program ?
Date: Fri, 03 Dec 1999 00:40:35 GMT
On Thu, 02 Dec 1999 12:09:41 -0500, [EMAIL PROTECTED] wrote:
>Any / negative comments / evaluations / possible back-door entry / stableness /
>known software & hardware conflicts /
>about Peekboo free win95/98 message encryptor program ?
I have been playing with Peekboo for a couple of weeks, and at least
it is bug free as far as a user can tell. Key and shared secret
generation, as well as text and file encryption, work without a hitch.
I am inclined to trust the author, because,
1) He is a 17 year old High School student, and,
2) He has posted sensible stuff to sci.crypt, and obviously knows
something about both programming and cryptography.
It is too soon to grant Peekboo a "highly trusted" status, because it
has yet to be reviewed by recognized authorities on crypto software.
However, I expect it to pass with flying colors, because it uses only
previously published cipher and PRNG algorithms, that are considered
quite strong.
Source code for lcc-win32 is available on the Peekboo home page, along
with a few public keys contributed by users.
It's no replacement for PGP, but it certainly has potential. Peekboo
is small enough to send as an e-mail attachment without ruffling any
feathers, and designed specifically with crypto newbie users in mind.
------------------------------
Date: Thu, 02 Dec 1999 19:52:45 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Mickey McInnis wrote:
> In article <826ur2$dqh$[EMAIL PROTECTED]>, "r.e.s." <[EMAIL PROTECTED]>
>writes:
> |> "John Savard" <[EMAIL PROTECTED]> wrote ...
> |> : [EMAIL PROTECTED] (Guy Macon) wrote, in part:
> |> : > [EMAIL PROTECTED] (Tim Tyler) wrote:
> |> : > > http://www.io.com/~ritter/GLOSSARY.HTM#OneTimePad
> |> : > > http://www.io.com/~ritter/GLOSSARY.HTM#ReallyRandom
> |> : >
> |> : > Good info! I have a clueless newbie question about something that
> |> : > I found while reading the above:
> |> : >| "Nor does even a theoretical one time pad imply unconditional security:
> |> : >| Consider A sending the same message to B and C, using, of course, two
> |> : >| different pads. Now, suppose the Opponents can acquire plaintext from
> |> : >| B and intercept the ciphertext to C. If the system is using the usual
> |> : >| additive combiner, the Opponents can reconstruct the pad between A
> |> : >| and C. Now they can send C any message they want, and encipher it
> |> : >| under the correct pad. And C will never question such a message,
> |> : >| since everyone knows that a one time pad provides "absolute" security
> |> : >| as long as the pad is kept secure. Note that both A and C have done
> |> : >| this, and they are the only ones who had that pad."
> |> :
> |> : >It seems that the attacker needs to also have to know that A sent
> |> : >the same message to B and C. Knowing B's plaintext and knowing
> |> : >that B and C got the same message resolves to knowing C's plaintext.
> |> : >I see no way that a man in the middle attacker can know whether or
> |> : >not A sent the same message to B and C.
> |> :
> |> : The attacker can't know that for sure. But such an active attack is
> |> : still possible: it is at least _possible_ that, if two messages of the
> |> : same length are involved, this has happened. If this is done, either
> |> : the false message is inserted, or C will simply recieve undecodable
> |> : nonsense. (The idea is that the _chance_ of both messages being the
> |> : same is MUCH greater than the chance of a particular message guessed
> |> : at random.)
> |> [...]
> |> : While not disproving the security properties the OTP does have, it
> |> : shows that there is still a possibility of attack that can very easily
> |> : be overlooked - and has been overlooked, as I haven't seen this
> |> : mentioned anywhere else - *an OTP does not provide perfect
> |> : authentication of any message sent to more than one recipient*.
> |>
> |> In practice, though, who would use a "pure OTP" without
> |> further strengthening? (Even if the OTP is theoretically
> |> "unbreakable", it seems appropriate to say that any
> |> OTP *implementation* can, in practice, be relatively
> |> strong or weak.)
> |>
> |> (I notice that
> |> http://www.io.com/~ritter/GLOSSARY.HTM#MessageKey
> |> explains how the use of message keys can thwart
> |> exactly the type of scenario envisioned above.)
> |>
> |> --
> |> r.e.s.
> |> [EMAIL PROTECTED]
> |>
>
> This is a well known and much discussed "weakness" of a one-time-pad.
>
> A properly used OTP "absolutely" prevents the enemy from determining
> the cleartext from the cyphertext by cryptographic means. It doesn't
> "absolutely" prevent him from sending a false message that looks
> real.
>
> It can also happen if the enemy can somehow "guess" the cleartext, even
> if it's only sent to one correspondent. If the enemy thinks he might
> know the text, he could try to substitute text this way and would
> send a "proper" message if he guessed right. If he gets it wrong,
> the correspondent would get garbage.
>
> There is another well-known cryptographic "weakness" in OTP and many
> other cryptosystems. Unless you pad the messages, the enemy knows the
> length of the message.
>
> I wonder if there's something analagous to an OTP that will provide
> the same degree of "absolute" protection from "spoofing" as OTP
> does from "breaking".
A simple mechanism is to use a shared secret. Assume that in addition to the (large)
message
key repository each pair of correspondents is given a unique "signature" value. For
purposes
of illustration this could be small; 64-256 bits. To send an authenic message one
appeads the
"signature" to the message, encoding it with the keypad. On receipt of a message the
decoder
unmasks the "signature" region and compares the result with the secret value. Since
the
premise of the "signature" is that only the sender and receiver known the valid
signature
value, and because the signature ciphertext is not reused, the message must have come
from one
of the two inposession of the secret "signature" value.
This approach does not prevent replay attacks.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 2 Dec 1999 16:50:38 -0800
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
: Anthropologists have observed that all societies have processes that
: are based on the "urge to explain". These urges are supposed to be
: the source of religious institutions and of "natural philosophy".
: It's not hard to use the same desire for understanding to explain
: why people might resist admitting the inexplicable, unsolvable, or
: unpredictable into their world view.
However,
Anthropologists have observed that all societies have processes that
are based on the "urge to mystify". These urges are supposed to be
the source of religious institutions and of "natural philosophy".
It's not hard to use the same desire for mystification to explain
why people might resist admitting the explicable, solvable, or
predictable into their world view.
I include "natural philosophy" due to the increased willingness,
especially since the 60's, of philosophers & scientists to entertain
more-mystical world-views. (This is intended as an observation, not as
a value judgement.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: 3 Dec 1999 00:53:51 GMT
Well, the Peekboo author hangs out here quite frequently, I'm surprised Tom
has chimed in yet! :)
Well I can't answer all the questions but...
1. possible back-door entry questions is answered easy enough.
http://www.cell2000.net/security/peekboo/pb_backup.zip
is where you can download the source. Look for yourself. There is more
likely an error in implementation leading to insecurity than a backdoor.
You should be able to use some publically available test vectors ...
Note: I'm not insinuating there ARE implementation errors here.
2. As far as stableness/software/hardware conflicts go, I have never seen
the program act unpredictabily or crash on me. I've used it under Win95
and Win98 with no problems...I think most 'stableness & software' problems
are a direct result of just running under Windows. I've found that if you
don't have a 'healthy' Windows machine, everything is bound to crash
eventually.
Peekboo is a pretty cool little program. I don't think it's been
evaluated by many people in this forum yet. I'm not sure why but it
hasn't really attracted much attention. Peekboo is the sort of program
I'd write (for myself, not for release) just to demonstrate to MYSELF
that I knew what I was doing. That is, if I had the time! :)
I trust it's security enough to send a message across irc, but I wouldn't
choose to use it to say, encrypt my credit card to another person. Certain
programs have certain uses and this one fits the bill pretty good. Before
I could FULLY TRUST the program, I would like to see a> smart people evaluate
it or b> take the time to review the source myself and run some tests.
Keith M
[EMAIL PROTECTED] wrote:
: Any / negative comments / evaluations / possible back-door entry / stableness /
: known software & hardware conflicts /
: about Peekboo free win95/98 message encryptor program ?
: It is listed on site http://www.counterpane.com/products.html because it is
: using Blowfish [ some sort of endorsement from Blowfish creator ].
: The main site is at http://www.cell2000.net/security/peekboo/index.html
: The program is provided in 1 [ ONE ] executable only >> extremely secure in
: extremely insecure win95 environment.
: Executable is extremely small >> less than 50 kB.
: Peekboo is freeware & current Source Code publicly available.
: The program is modestly new [ the first Public Key on site is dated Sep 28 /
: 1999 ]
: Peekboo is a free win95/98 message encryptor program. It has many features which
: will be discussed on the other pages. It basically allows for secure
: communication with any person (even people you have not physically met yet)
: using any text medium (such as email or chat programs).
: Current Release is v1.73 (Nov 23rd 1999)
: The main problem it tries to solve is insecure transportation of text messages
: over any text medium (such as email, chat and usenet). To obtain this goal I had
: to add symmetric ciphers to actually encrypt the message, a hash function (which
: is used in many places) and diffie-hellman key exchange. Nothing else was added
: (such as swap file cleaning, file wiping) because they would not solve my
: problem.
: The author is claiming these features :
: Diffie-Hellman Key Exchange
: Secure method for people to share a private key remotely.
: Simple to use.
: Uses a 2048 bit strong prime as the modulus
: *** Group Shared keys planned for V2.0 ***
: Seven Symmetric Ciphers
: Allows you to use the symmetric cipher you feel most comfortable with.
: Includes: Cast, Blowfish, RC4, RC5, RC6, Twofish and Rijndael.
: 160 bit symmetric keys. Each message uses a independent symmetric key which is
: the hash of the shared key and a 128 bit random SALT.
: File Encryption
: Simple to use file encryption routines.
: Compact
: The executable is only about 50 kb. The size is growing slowly as new features
: are added, although right now it's quite comparable to the popular cryptosystems
: [only 75 times smaller].
: Any input will be appreciated.
: --
: Thanks, Richard
------------------------------
** 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
******************************
