Cryptography-Digest Digest #290, Volume #11 Thu, 9 Mar 00 19:13:01 EST
Contents:
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: Cellular automata based public key cryptography (Tim Tyler)
Re: Your Recommended Choice On Std Crypto Parts (Benjamin Gittins)
Crypto Patents: Us, European and International. (Glenn Larsson)
Re: Universal Language (Jim Gillogly)
Re: Court cases on DVD hacking is a problem for all of us (Arlo Minkey)
Re: Cellular automata based public key cryptography (Tim Tyler)
Re: Protocol question -- detecting patching of software ([EMAIL PROTECTED])
Re: Cheating in co-operative open-source games, how can we protect from it? (Edward
A. Falk)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David A.
Wagner)
Re: Best language for encryption?? (Paul Schlyter)
Re: why xor?(look out,newbie question! :) (Edward A. Falk)
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: PGP Decoy? ([EMAIL PROTECTED])
Re: Passphrase Quality ? ("r.e.s.")
Re: Crypto.Com, Inc. (Will Dickson)
Re: CONFERENCE ON NATURALISM -- FINAL NOTICE ("Douglas A. Gwyn")
ATTN > Nigel Tsang ("TJ")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 9 Mar 2000 22:04:04 GMT
In a previous article, <[EMAIL PROTECTED]> writes:
>In article <8a92m7$30v$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>> How will the attacker tell that his attack has been unsuccesful or
succesful,
>
>His bank account gets credited by some huge amount.
It might work, but I would say it probably wouldn't. It is highly probable
that the server of the bank has socket connections which are much faster for
other banks than for the regular clients. Consequently, if the attack fails
the error propagation will make the receiving bank perceive this, notify the
sender and the sender succesfully re send the message - before the attackers
legitimate request to see the credit of his account is likely to have been
handled.
>> how will he be able to try 2^16 or even 2^9 times?
>
>Keep trying until you hit paydirt.
It was presumed that it was essential that the attacker could identify "his"
message only by knowing the exact time of the transaction - Otherwise he
would not know which message to attack. If he keeps on trying (maybe he is
assuming that all succeeding messages between the two banks will be attempts
to resend "his" message), he will suffer a great risk of revealing that an
attack is taking place, and thereby exposing himself, by mistakenly
corrupting a very large number of non-related messages.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Mar 2000 22:05:35 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> *Finite* CA and FSM are equivalent in power.
:>
:> Some *infinite* CA and TMs are equivalent in power.
:>
:> No *finite* CA (or other FSM) is equivalent to a TM in its ability to
:> evaluate large, complex functions - since they run out of memory. [...]
: Thanks for the explanation. I like to ask a further dumb question.
: The CA I have seen are two dimensional. If I understand you correctly,
: an infinite two dimensional CA can be equivalent to a TM. Would an
: infinite three dimensional CA, which could certainly be built, be
: able to provide more power than a TM? If not, are there any reasons
: to support that argument? Thanks.
The /answer/ to the question is "no". Spatially infinite 1D, 2D and 3D
automata are all equivalent in these terms. However, the /proof/ of
this is beyond my capacity here ;-)
To confuse matters, I'll mention that there *is* a sense in which an
infinite cellular automata can be *more* powerful than a Turing machine(!)
A Turing machine can only do one thing at a time. If it is presented with
an infinite quantity of input data, it could be severely I/O bandwidth
limited.
An infinite cellular automata can do lots of things simultaneously.
Given certain types of function with an infinite input, and requiring an
infinite output, it can calculate the results in a finite time. By
contrast, a TM would never even finish reading in all the inputs, let
alone process them.
Consequently there are types of calculations a CA can perform, which a TM
cannot ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Be good, do good.
------------------------------
From: Benjamin Gittins <[EMAIL PROTECTED]>
Subject: Re: Your Recommended Choice On Std Crypto Parts
Date: Thu, 09 Mar 2000 22:05:36 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> The MQV key exchange (M is from Menezes) has a mathematical proof of
> security.
> It's part of the p1363, so that's a standard. Public domain code has
> been around for a long time.
>
Do you know where i can find, outside of subscribing to IEEE, the spec
for the MQV key exchange? Is there an independ document describing the
process..
Is the MQV key exchange process independent of ECC / D&H style problems.
Is using an ECC, like described in p1363, going to have potential
patent $ issues. ( Number of patents on web site look daunting )
> Once you have key agreement, you had better be secure. If speed is
> critical, don't waste time with too many checks. The overhead of key
> agreement should include a check, after that assume you're going to
> fly. No point in sending anything if things don't check to begin
with.
I understand, I was actually indending to make sure that the key
agreement were as pesimistic as possible, to use the safer/longer hash
values.
My thinking was to switch Hash function after successfull negotiation.
So to use SHA-1 during key exchange, and the first 2(n?) packets of
real data, then move to a faster MD4/5 for the bulk of the data
transfer?
Because sending One packet / wait reply, has large delays anyway, the
extra overhead in protecting it will not be noticed, but sending
_large_ volumes of data after it, the SHA-1 hash overhead would begin
to be noticeable.
>
> > In short, I don't want to have intrinsincly weak design, like what
> > happenened with SSH v1.x, nor do I want to use 'bad choice'
> > components.. Definitly the Key Exchange protocol should be bullet-
proof.
>
> Then MQV is something you want to check out. Use it with Twofish and
> SHA-1. the hard part is gluing it together securely. Don't be in a
> hurry.
>
Definitly not.
Thanx again ;-)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Crypto Patents: Us, European and International.
Date: Tue, 07 Mar 2000 18:52:10 +0100
Hi.
My current encryption algorithm is "tip-toeing" around
areas that COULD be covered by some patents, So - I have
some questions about patents.
1.
- What KINDS of commercial patents are there that affect
crypto or rather "mathmatical algorithms" ? I know that
NSA and it's "international collegues" organisations have
priority power at their individual patent offices.
2.
- What WIDE-ASPECT (as in covering too much) patents exits
today that block the progress of cryptographic research or
deployment?
3.
- How do GATT and software patents work together?
4.
- Anyone have a link to a search engine for European patents?
(like the one at www.patents.ibm.com)
In Sweden, the current legislation does NOT approve software
patents, the patent law clearly states that ONLY copyright
will be awarded to software products, but a patent engineer
told me that everything could be "loosening up" and software
patents could be on the way.
The Swedish patent law (1967:837,paragraph 1) cannot approve
ONLY mathmatical algorithms as patentable, it (according to
the patent engineer i spoke to) also have to have a physical
or a graspable "technical effect" and have "uniqueness".
(In spite of this, there are some algorithm/software patents
in Sweden, could be from earlier legislation or something.)
- What's the situation on the planet - Any direct thoughts or
insights?
Regards,
Glenn
Sweden
P.S: If you want to speak privately, the email
adress is a valid adress. (checked occationally)
_________________________________________________
Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)
This is punishable by a fine or 6 month to 2 years
imprisonment (Paragraph 49)
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Universal Language
Date: Thu, 09 Mar 2000 22:40:37 +0000
Darren New wrote:
> [EMAIL PROTECTED] wrote:
> > Huh? Esperanto doesn't have grammatical gender. Whatever gave you that
> > idea? See <http://www.esperanto.net>.
>
> An Esperanto book I bought probably 20 years ago. Either they've updated the
> language to simplify it even more, or I'm misremembering something. Ah well.
> Sorry about that.
Perhaps your memory merged grammar and word-building. Most nouns default
to masculine if the sex is relevant, but there's no grammatical gender.
The -in- suffix will turn a general or masculine noun into a feminine one,
such as "knabo" for boy and "knabino" for girl. Various back-formations
can lead to humorous results such as "fraulo" for young man and "fraulino"
for young woman, or "bovo" for bull and "bovino" for cow, but again they
are not distinguished grammatically. Esperanto hasn't changed in this
regard. Proposals have been floated to make it less sexist, by which is
meant that there should be a neutral form of each noun separate from the
masculine and feminine, and a masculine suffix like the feminine -in- should
be used whenever the distiction is important; these proposals haven't been
universally accepted.
It seems to me M-K Shen is asking for an "a priori" language such as
Dalgarno's philosophical language, or like Loglan/Lojban. I find Lo***an
very difficult to learn despite its logical structure... and I don't
think it's just the vocabulary that makes it tough. I doubt that there
are any fluent speakers of it, though a few conversations in these
languages had been held the last time I was paying attention to them.
Interestingly, Heinlein in his short story "Gulf" postulated that Loglan
(not referenced by name) was successful and allowed people who knew it
to think faster and better. Whorf/Sapir lives on...
--
Jim Gillogly
18 Rethe S.R. 2000, 22:27
12.19.7.0.8, 12 Lamat 16 Kayab, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Arlo Minkey)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Thu, 09 Mar 2000 22:42:01 GMT
tapeguy <[EMAIL PROTECTED]> wrote:
>OT but relevant to those concerned: there have been many folks that I
>have read about in usenet threads using the OnStream tape drives with
>DeCSS to make copies of DVDs. I know from first hand experience that
>it works very good. The OnStream drive works like a drive letter under
>windows and plays the movies back directly from the tape drive with no
>problems. Storage capacity of up to 5 full length DVDs per tape and
>retail costing of the drive starting at under $300.
What's a good newsgroup to read more about this?
--
"Arlo Minkey" is actually 4578 609231 <[EMAIL PROTECTED]>.
0123 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Mar 2000 22:28:02 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
: Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: : The CA I have seen are two dimensional. If I understand you correctly,
: : an infinite two dimensional CA can be equivalent to a TM. Would an
: : infinite three dimensional CA, which could certainly be built, be
: : able to provide more power than a TM? [...]
: The /answer/ to the question is "no". Spatially infinite 1D, 2D and 3D
: automata are all equivalent in these terms. [...]
Having written this, I've concluded that there's a weak sense in which it
is possible to construct functions (with infinite numbers of inputs and
outputs) that would produce an output after a finite period in an
n-dimensional automaton - but would take an infinite time to compute in an
n-1 dimensional one.
Consequently - in a pretty weak sense - TM < 1DCA < 2DCA < 3DCA.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I see you're already stuffed.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Protocol question -- detecting patching of software
Date: Thu, 09 Mar 2000 23:17:37 GMT
> * Program code contains a cryptographically secure checksum algorithm.
>
> * Server issues a challenge that says: Here is an initialization
> vector. Compute your checksum and send the result back to me.
>
> This doesn't work either though, as the tampered program merely
> keeps an untampered copy around and computes the checksum on that.
> Obviously, the checksum will have to include some sort of dynamic
> but known-to-the-server state. If the program is a game, the
The solution is that the server, let's call it A, has to be responsible
for computing the checksum k, since he is trusted. In practise, that
would mean the server A sends the client, let's call it B, a piece of
executable code, say c, that is unknown to the client before it has
received it. The client then has to execute the code, while the server is
waiting for a given timeout time long. The executable code sends back a
cryptographically strong checksum of the client program. If the client
does not provide the correct checksum in the given timout time t, or it
provides the wrong checksum, the server marks the client as tampered and
disconnects.
To make this protocol secure, several factors have to be taken into
acount:
- The executable c may not be predictable by the client. That means, it
must be as hard as possible to know in advance what c will exactly look
like. I'd be rather interested in the structure of c that would make it
cryptographically secure in this context.
- Client B must not be able to analyse c in a way that would enable B to
provide a correct checksum for a tampered client, within the given time
t.
As I'm not really a cryptographer I cannot say if there's been some
research in that field. To me it at least seems possible that a
cryptographically strong solution for the nature of c could be found,
given some assumptions on the time it takes B to analyse and understand
it, of course (you have to assume someone doesn't play your network game
on a PC, but on several supercomputers run by the NSA). Note that the
executable c can exchange messages with A during t.
Well, but it might be a bit too much work for securing a network game...
but if the game is good, I'm not so sure wether the NSA doesn't take the
challenge and attaches several supercomputers to it to break your tamper
protection...
Best regards,
Erich Steinmann (not working for the NSA)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Cheating in co-operative open-source games, how can we protect from it?
From: [EMAIL PROTECTED] (Edward A. Falk)
Date: 09 Mar 2000 23:27:44 GMT
In article <8a5o3n$380$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
>Peter Henningsen <[EMAIL PROTECTED]> wrote:
>> open source games/virtual worlds. Specific ways of cheating that we want to
>> guard against are falsifying of game scores, creating God-characters by
>> hacking code instead of earning similar status in the game world, or
>> tainting an evolutionary process in a virtual world by falsely propagating
>> and promoting artificial life entities. In all these cases, files on the
>> user's computer must be protected from tampering by the user himself. Since
>> we are developing free games, and cannot afford to do much processing on
>> central servers, it is not an option either to run the code on a server for
>> protection.
>
>Can you consider your games in terms of a state to which users apply
>some kind of transition to evolve it to the next state?
>
>How about something like this :
>
>3. The server hashes the "previous game state" and compares it to
> the hash. Then it checks to see that the transition is consistent
> with the new game state -- this may be too expensive for you, unless
> there is a nice way to check consistency faster than actually
> computing the new state?
Would it be sufficient for the server to spot-check, instead
of testing every transition?
--
-ed falk, [EMAIL PROTECTED] See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
and read 12 Simple Things You Can Do ******!***************************#**
to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 9 Mar 2000 15:02:51 -0800
You're not thinking like an attacker.
The attacker doesn't care *which* try succeeds, so he doesn't
need to check every time (that'd be silly). Instead, he just
tries over and over again, and checks his bank statement at the
end of the month.
The point is, sure, maybe if you use this, you might happen to
get lucky, and the various properties of your system might conspire
to make the obvious attacks fail. But you're not getting
cryptographic-quality strength here, you're just getting lucky,
and that's hardly the type of security foundation I'd want to
build on.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 9 Mar 2000 22:59:31 +0100
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> I don't think you can say C is "weakly typed", at least
> not the current standard, because the compiler will actually
> check stuff for you if you let it. Consider, in contrast, things
> like Smalltalk and LISP,
These languages are polymorphic, i.e. their variables can change type
during the execution of a program. So if A is an int while B is a
float, and you do the equivalent to A=B; then the float won't have
been converted to an int, instead the variable A will now too be a
float, in a polymorphic language.
Don't confuse weak typing with polymorphism: weakly typed languages
are still statically typed.
> or even early C.
.... or FORTRAN ....
--
================================================================
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: why xor?(look out,newbie question! :)
From: [EMAIL PROTECTED] (Edward A. Falk)
Date: 09 Mar 2000 23:38:01 GMT
In article <89u7ij$94j$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <89tvbk$3nk$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> cypher=(text + rnd)mod 256
>> on each byte of plain-text.Theoreticly,it should
>> produce uniform distribution of same interval as
>> rnd number,right?
>
>
>> ps.And when you already here,could you give me a
>> short comment on my initial idea of
>> encryption.What would be your line of attack,if
>> U need to decrypt it?
>
>The point is the PRNG used. If you use for example
>a linear congruential generator your algorithm is
>weak, if you use a belived strong block cipher or
>a one way hash function like SHA1 in order to create
>the "keystream" your algorithm is strong.
It's also vitally important to find a better way to seed the PRNG.
Using a simple hash of the passphrase would seed the PRNG the same
way every time. You must not do this. If the attacker gets even
two messages that were generated with the same stream of random
numbers, then both messages are trivially broken. The PRNG must
generate a different stream *every* time it's used.
Question to people who know this stuff better than me: Suppose
you seeded the PRNG with the hashed passphrase xor'ed with some
reasonably random number. Send the random number in the clear.
Let the receiver xor with the hashed passphrase to get the seed.
This should cause the PRNG to generate a different stream every
time, but does it introduce a new weakness?
--
-ed falk, [EMAIL PROTECTED] See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html #**************F******!******!*!!****
and read 12 Simple Things You Can Do ******!***************************#**
to Save the Internet **#******#*********!**WW*W**WW****
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Thu, 09 Mar 2000 23:39:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> :> *Finite* CA and FSM are equivalent in power.
> :>
> :> Some *infinite* CA and TMs are equivalent in power.
> :>
> :> No *finite* CA (or other FSM) is equivalent to a TM in its ability to
> :> evaluate large, complex functions - since they run out of memory. [...]
>
> : Thanks for the explanation. I like to ask a further dumb question.
> : The CA I have seen are two dimensional. If I understand you correctly,
> : an infinite two dimensional CA can be equivalent to a TM. Would an
> : infinite three dimensional CA, which could certainly be built, be
> : able to provide more power than a TM? If not, are there any reasons
> : to support that argument? Thanks.
>
> The /answer/ to the question is "no". Spatially infinite 1D, 2D and 3D
> automata are all equivalent in these terms. However, the /proof/ of
> this is beyond my capacity here ;-)
>
Tim is correct. Theoretically, CA could be
made to do quantum computation (QC) which
could be more *efficient* than TM. There are
models of QC which are alternative to TM but
there is no proof I am aware of that any type
of QC is more powerful than TM in terms of
*what* can be computed.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp.discuss,alt.security.scramdisk
Subject: Re: PGP Decoy?
Date: Thu, 09 Mar 2000 23:40:28 GMT
> Russell Horn wrote:
> >
> > For example, I have sensitive information in a word file. When I encrypt
> > it, I provide the word document and, say, a midi file. I am then forced
> > by police or whoever to "reveal" my public key. I do so, but release my
private key, you've meant
> > secondary key. They use this on the file which happily decrypts to a
> > midi file instead of the sensitive word document.
>
> The police will wonder what is in the rest of the cyphertext. It is hard
> to hide the fact that the file consists of two parts, one that decrypts
> to the midi file and an other 'unused' part. The police will want both
> keys if they are clever.
But what about the following: The software provides a way to provide an
arbitrary number of files upon encryption. But it also provides a way to
fill up the cyphertext with random numbers that would grow the size of
the file in such a way that there could equally have been encrypted
several other files.
Then, nobody can force you to give *all* private keys, because you can
always say, that there's only one file encrypted and the rest is random
data provided by the program (at best, automatically). If the public key
encryption is cryptographically strong, it shouldn't be possible to
distinguish the random data from real encrypted files, thus making it
possible to claim that there's only one file encrypted in the cyphertext,
and giving the key for the unsuspicious file of the two or more that
actually have been encrypted.
The disadvantage of this method is that you will up your disk with a lot
of random junk. I guess the most secure would be to also encrypt the
random chunk, so weaknesses of the encryption cannot be used as criterion
at all.
Best regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Thu, 9 Mar 2000 15:51:55 -0800
The "password grid" method you propose seems good in theory, but in =
practice it has a serious flaw. There will be a tendency to do more =
than merely look at the grid when reading the symbols along a fixed =
path. Especially with repeated use, there's a great risk of physically =
affecting the grid in some seemingly insignificant way that nevertheless =
leaves clues about the path (e.g. touching the grid in any way as the =
path is traced out). If not extremely careful, the grid ends up =
advertising the password instead of hiding it.
BTW, the password grid idea isn't new, and was specifically and strictly =
forbidden in one of my former workplaces decades ago.=20
-- r.e.s.
"Ken Y. Ramoil" <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
| "Stephen P." <[EMAIL PROTECTED]> wrote:
|=20
| >i wonder if you understand what i'm asking. let's say i easily say =
"Uncle"
| >so if i 'know' my password then when they make me say "Uncle" out =
comes my
| >password. but if i had some way of generating a password that i =
simply
| >can't
| >remember because it's too long then they wouldn't be able to get the
| >password out of me. what would be a secure way to have a password =
that i
| >don't need to remember .. instead i would just need to know how to =
generate
| >when i want to use pgp?
|=20
| Yes there's a way to do that and I believe it works rather well, but =
for
| some reason it hasn't been well received when I've presented it in the
| past. I'll give it another shot. Take a look and tell me why you don't
| think this is a good password strategy:
|=20
| http://www.5x5poker.com/grid/
|=20
------------------------------
From: [EMAIL PROTECTED] (Will Dickson)
Subject: Re: Crypto.Com, Inc.
Date: Thu, 09 Mar 2000 23:52:53 GMT
[EMAIL PROTECTED] (Tony L. Svanstrom) wrote:
>
>Animals can spend a long time before we can detect an earthquake being
>very very afraid; and that is just as much "magic" as telepathy would be
>to us.
IIRC this happens because some animals have a geomagnetic sense
(homing pigeons in spades, but other animals such as dogs also have it
although it is less acute). Shortly before the earthquake the local
geomagnetic field goes subtly wonky and they can sense this.
Presumably a magnetometer could pick up the signal, and equally
presumably nobody has yet managed reliably to isolate the signal
pattern that indicates an incoming quake, or we'd have heard about it.
This is possibly a problem in paracryptology of a sort.
So in a tenuous way this part of the thread is almost back on-topic!
:-).
Will.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CONFERENCE ON NATURALISM -- FINAL NOTICE
Date: Thu, 09 Mar 2000 23:58:09 GMT
John Myre wrote:
> ... If you say
> "miracle" then you are done, and can never discover anything else.
The way Feynman used to put it, if you start out with some notion
as an unshakeable certainty, then you're not in a position to learn
anything about it. If, on the other hand, you allow some doubt,
then further investigation should be able to change your degree
of certainty one way or the other. (This is easy to see using the
Bayesian approach.)
------------------------------
From: "TJ" <[EMAIL PROTECTED]>
Subject: ATTN > Nigel Tsang
Date: Thu, 09 Mar 2000 23:58:37 GMT
I recieved an automated mail from you today, which is generated by a virus.
Thought you should know :O(
It sends an attachment called "PRETTY PARK". exe which then does the dirty.
Sorry to bear bad news.
TJ
------------------------------
** 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
******************************
