Cryptography-Digest Digest #677, Volume #10 Fri, 3 Dec 99 19:13:01 EST
Contents:
Re: Peekboo Ideas? >> Question ... (Steve K)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tom McCune)
iaPCBC: confidentiality and integrity in one shot (James Muir)
Re: NSA should do a cryptoanalysis of AES (Shawn Willden)
Re: Why Aren't Virtual Dice Adequate? (Mickey McInnis)
Re: Peekboo Ideas? >> Question ... (Keith A Monahan)
Re: cookies (SCOTT19U.ZIP_GUY)
Re: Simpson's Paradox and Quantum Entanglement (John R Ramsden)
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: smartcard idea? (Shawn Willden)
Re: Use of two separate 40 bit encryption schemes (Shawn Willden)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
Re: Encrypting short blocks ([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Peekboo Ideas? >> Question ...
Date: Fri, 03 Dec 1999 22:18:43 GMT
On Fri, 03 Dec 1999 16:26:17 -0500, [EMAIL PROTECTED] wrote:
>Question
>
>When you are creating password with 'Use Key' is this operation creating THE
>SAME password for the same public + private keys selected, time after time ?
Oboy, I know that one!
No. There was some discussion of PRNG implementation during shared
secret generation, in the PB e-list.
Hopefully Tom will have his system back up & online pretty soon; until
then, the only living Peekboo expert is incommunicado. Maybe folks
could consolidate their questions & hold off 'till Tom shows up on the
network again? Then you could get timely answers, I bet.
:o)
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Fri, 03 Dec 1999 22:29:19 GMT
In article <828lod$kv5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
<snip>
>The fact of the matter is that your card can be comprised ANY PLACE, whether
>it be locally, over the wire, at the company, at the credit card verification,
>etc. If I would place orders online, I would be trying to LIMIT my
>susceptibility to attack, and by ensuring a decent encryption package is
>in use, I could do that.
>
>Is this more clear?
Thanks Keith,
You give the credit card level of security a higher rating than I do, so that
speaks better of your confidence in the software than if I had made that
statement.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: iaPCBC: confidentiality and integrity in one shot
Date: Fri, 03 Dec 1999 22:16:09 GMT
iaPCBC stands for integrity aware plaintext ciphertext block chaining.
It's been proposed as a new mode of operation for block ciphers. It
claims to provide data confidentiality and integrity with one
cryptographic operation. See
http://www.research.att.com/~smb/papers/iapcbc.ps
http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt
for a complete description.
Has anyone analyzed iaPCBC yet? If so, can someone point me to the
analysis?
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 03 Dec 1999 15:31:34 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
"Douglas A. Gwyn" wrote:
> This points up a supremely important fact: Real computer security
> has to be built in from the ground up, with no loopholes anywhere.
> You could probably achieve it with a capability-based architecture
> and extremely good security review throughout system design, but
> even so, at some level some user will screw up and hand over the
> keys to an untrustworthy agent.
Could you explain what you mean by a "capability-based" architecture? I've puzzled
over the term a bit and I can't figure out what you mean by it. Whose capability
and for what? And how does it relate to architecture?
Thanks,
Shawn.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 3 Dec 1999 22:40:40 GMT
Reply-To: [EMAIL PROTECTED]
snews.austin.ibm.com> <[EMAIL PROTECTED]> <828rmr$[EMAIL PROTECTED]>
Organization:
Keywords:
In article <828rmr$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Guy Macon)
writes:
|> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
|>
|> >In sci.crypt Mickey McInnis <[EMAIL PROTECTED]> wrote:
|> >
|> >: 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".
|> >
|> >Signing your messages usually provides some protection. I have difficulty
|> >in imagining a one-way function (of the type used when creating message
|> >digests) which offers the same type of security as an OTP - but perhaps
|> >one is possible.
|>
|> If I understand it correctly, you can use any sort of compression
|> and/or encryption you choose either before or after the OTP, and
|> the result will still be an unbreakable (but often impractical)
|> encyption. So the question is whether such a spoofing protection
|> exists.
|>
|> Lets say that A and B swap CD-ROMS so that each has a A -> B OTP
|> and a B -> A otp. Let's further assume that they send an identical
|> length message once per day whether they have something to say or
|> not, that neither of them communicates with anyone else, and that
|> they shut down and go to a physical meeting if they recieve a
|> message that is the sort of random junk one would expect from a
|> man in the middle taking wild guesses. In theory, unbreakable
|> by the man in the middle, right? Pardom my possible cluelessness,
|> but wouldn't inserting a fake message be just as hard to do?
|>
|> Stopping a message or storing it and sending it later are still
|> possibilities for the man in the middle.
|>
|>
|>
The spoofing "weakness" of an OTP comes when the enemy 1) Somehow
obtains a matching ciphertext and cleartext that is being sent from
A to B. (Guesses the cleartext, obtains an identical cleartext message
A sent to another correspondent C, etc.) 2) The enemy has to be able
to stop the original message from reaching B and send his own
altered message to B.
The most obvious way this would happen is A is the "boss". A sends
an identical cleartext to multiple correspondents, each of whom has
his own OTP. The enemy corrupts correspondent C and obtains a cleartext
that he knows A will send B in the next message. The enemy has a
matching cyphertext/cleartext pair for the message A sends B.
>From this, he can obtain that day's pad. With this pad, he can
send a false message to B, encrypted with the correct pad for today's
message. Something like "Go to the phone booth at the corner of
4th and Main with a red carnation on your lapel at 6 O'clock." would
allow you to capture the correspondent.
It's somewhat contorted, but entirely possible, circumstances, and
one of the well-known limitations of OTP's that you should be aware
of.
I suspect the weakness is strong enough that you shouldn't use
OTP for authentication, except in very special circumstances.
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Peekboo Ideas? >> Question ...
Date: 3 Dec 1999 22:53:53 GMT
Steve,
Steve K ([EMAIL PROTECTED]) wrote:
: then, the only living Peekboo expert is incommunicado. Maybe folks
: could consolidate their questions & hold off 'till Tom shows up on the
: network again? Then you could get timely answers, I bet.
Let's hope for our sake that he gets back soon. I can't STAND reading post
after post after post with the same subject! Consolidate or die! :)
: :o)
: Steve K
Keith
: ---Continuing freedom of speech brought to you by---
: http://www.eff.org/ http://www.epic.org/
: http://www.cdt.org/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: cookies
Date: Fri, 03 Dec 1999 23:53:06 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Steve K) wrote:
>On Fri, 3 Dec 1999 13:08:37 -0500, E-mail <[EMAIL PROTECTED]> wrote:
>
>>
>>
>>Many web sites are pretty insistent about taking cookies. Why?
>>
>>I am suspicious about it because I see it as violation of privacy
>>and possibly a means of breaking into data not mentioned in the
>>reasons they give.
>
>The one decent use for cookies (that I know of):
>
>When registered users log in to a company's site, a cookie is set that
>identifies that user as being currently logged on. Then, when moving
>from page to page inside the site-- or even from server to server in
>some cases-- a cgi program can read the cookie and grant access.
>The alternatives to this all seem pretty messy and failure prone.
>
>On the other hand, here's from a ZDNET atricle quoted in HNN:
>
>> Novell chief Eric Schmidt has admitted that he has been
>> the victim of credit card theft. Speaking at San Francisco's
>> Digital Economy conference he blamed the theft of his
>> personal information on browser cookies. He labeled cookies
>> as "the biggest disaster for computers in the past [few] years."
>
>Since you seem to be concerned about privacy issues, you might want to
>take a look at Internet Junkbuster:
>
>Junkbuster is a local proxy that selectively blocks domains specified
>by the user. You can also specify domains whose cookies you want the
>proxy to admit, in one of the Junkbuster config files. It even has a
>function for spoofing cookies, though I have not had much luck with
>that feature so far.
>
>If you specify the domains of the major tracking sites-- the ones hit
>counters and banners come from-- you instantly get faster browsing and
>a reduced profile. It also kills the referrer field that is sent out
>with URL requests, and lies to websites about your browser and OS.
>
>http://www.junkbusters.com/ht/en/ijbfaq.html
>
>Steve K
>
>---Continuing freedom of speech brought to you by---
> http://www.eff.org/ http://www.epic.org/
> http://www.cdt.org/
I give free cookies at my site to those with active X or javasrcipt turned
on.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (John R Ramsden)
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Sat, 04 Dec 1999 06:51:11 GMT
"Bob Greer" <[EMAIL PROTECTED]> wrote:
>
> karl malbrain wrote in message ...
> >
> >
> > Simpson's description of VINGH as a SUBJECTIVE/OBJECTIVE problem -- WHO is
> > trying to change ownership of WHAT property for their SINGULAR benefit.
> > HISTORY is a MAJORITY subject.
>>
>
> "I love Big Brother."
Imagine what he must sound like talking! I picture him thumping the table
at each uppercase word.
(In one of his previous posts the one word, "nb", that _should_ have been
in uppercase wasn't :-)
Cheers
===========================================================================
John R Ramsden ([EMAIL PROTECTED])
===========================================================================
"Never try and keep up with the Joneses. It's cheaper to drag them
down to your level."
Quentin Crisp
===========================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NP-hard Problems
Date: Fri, 03 Dec 1999 22:50:48 GMT
Bill Unruh wrote:
> Well, it is not known if there are any NP hard problems.
[...]
Check your referenes. NP-complete is a proper
subset of NP-hard, so they do exist.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NP-hard Problems
Date: Fri, 03 Dec 1999 22:47:39 GMT
James Pate Williams, Jr. asked:
> What are some problems that are NP-hard but not NP-complete? I know
> circuit-satisfiability is both NP-hard and NP-complete. In a textbook
> I have r.e.-hard and r.e.-complete are defined where r.e. =
> recursively enumerable. Are r.e.-hard and r.e.-complete the same as
> NP-hard and NP-complete? MP (membership problem) and HP (halting
> problem) are both r.e.-hard and r.e.-complete.
A problem X is NP-Hard if and only if there exists
a polynomial-time reduction from an NP-complete
problem to X. The definition of NP-hard is not as
well established as NP-complete, and references
differ as to whether it is a set of languages (in
which case only decision problems are NP-hard) or
a set of general computational problems.
A problem meets the request criteria if it is
not in NP and NP-c problems polytime reduce to it.
One example is the halting problem.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 03 Dec 1999 16:00:28 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
anonymous intentions wrote:
> Unless of course you create a rechargeable device in the HID proximity
> card, but then you have the issue of spoofing via RF. Contactless isn't such
> a great idea even if it is only transmitting a session hash.
I don't think there's anything inherently weak about contactless
communications. Even with contact-based communications, we always assume that
an attacker can see and/or modify all of the messages. The problem with
current-generation contactless cards is that they use weak crypto. The reason
they do is because the current induced by the RF field is too weak to power a
current-generation processor capable of performing DES operations in a
sufficiently short time. With good cryptographic algorithms that are more
efficient (AES) and more power-efficient processors contactless cards will
become useful for applications that require relatively good security.
> Contacts would
> be better if they contained a pin on-board the card itself or on an
> interpreter module on the card in which the PIN would never leave the card
> or IM itself. Even better than that is a biometric thumbstamp that would
> activate PIN access on the card interpreter.
Yes, a biometric device on the card itself is a very good idea, and there are
such card-embeddable devices available on the market. I don't know how much
they cost or what limitations they might have, but assuming there are no
significant problems, I think a thumbprint reader on the card is ideal. It
provides very easy to use, high-quality authentication without compromising the
user's privacy (by causing his or her fingerprint to be stored in a database
somewhere).
Shawn.
------------------------------
Date: Fri, 03 Dec 1999 16:09:23 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Use of two separate 40 bit encryption schemes
Eric Lee Green wrote:
> Shawn Willden wrote:
> > double encryption to 41 bits. However, if you triple-encrypt your packets
> > with 40-bit DES before transmitting them, you can get 80-bit
> > strength (you
> > can use either two or three 40-bit keys, but if you use two
> > keys, make
> > sure to alternate their usage).
>
> One thing to note for us Amurricans is that the BXA would consider this to be
> an 80-bit cipher, rather than multiple applications of a 40 bit cipher, and
> would regulate it as such. Obviously I cannot say what a foreign government
> would believe, but given the amount of incest at top levels, I suspect their
> policies would be similar.
Yup. Building/writing a device/program that automated the triple-encryption
would result in something that is not exportable. Seems like it would be
difficult to stop a user from applying the encryption operation three times,
though.
Shwan.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 04 Dec 1999 00:01:21 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>On Fri, 03 Dec 1999 16:25:21 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>> Again asshole check it out I have.
>
> Vulgarity, the refuge of the incompetent. I see that you are no
>longer interested in even attempting to maintain a logical and
>reasoned discussion. Then again, logic was never one of your strong
>suits Mr DS.
Actually it was one of my strionges suits mr ASSHOLE the proof
is there but your to fukching dumb to see it.
<snip>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 04 Dec 1999 00:05:49 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>: Douglas A. Gwyn wrote:
>:> Brian Chase wrote:
>
>:> > I think what I'm finding most disturbing, if not just outright disgusting,
>:> > is how quickly disregarded are Scott's challenges to the conventions of
>:> > the cryptology community. Sure he's an asshole, but as a community is it
>:> > not true that we don't conclusively know how secure the contemporary
>:> > algorithms are?
>:>
>:> Neither does D.Scott! The main problem with his arguments is that
>:> he asserts weaknesses in everybody's encryption schemes except his,
>:> but doesn't *demonstrate* the weaknesses. When he claims, for
>:> example, that CBC itself creates exploitable weaknesses, yet there
>:> happen to be solid mathematical papers demonstrating that CBC used
>:> with a *strong* block cipher is not substantially weaker than the
>:> block cipher by itself, it is incumbent on *him* to prove his claim,
>:> or at least to exhibit an error in the previous work that proved the
>:> opposite. That's not only standard professional practice, it's
>:> plain common sense. Since he doesn't make a convincing case,
>:> preferring to curse and challenge the integrity of anyone who
>:> disagrees with him, it is not surprising that he is being almost
>:> entirely ignored by the professional community.
>
>: No. You have egregiously misstated his position. AFAIK his position is
>: that CBC does not meaninfully strengthen a block cipher in comparison with
>: methods that diffuse information more widely tha[n] neighboring blocks.
>
>Indeed. This is my perception of his position also.
>
>While he's stated that he views the common chaining modes as weak, he's
>*never* - to my knowledge - stated that they weaken the underlying block
>cypher.
>
>Rather - as I understand it - his position is that they needlessly
>expose the block cypher to direct attack, by a failure to distribute
>information needed to decrypt the message over as wide as possible
>an area.
>
>Obviously, such a failure to diffuse allows any attacks based on known
>partial plaintexts to function. Or any attacks based on choosing
>partial plaintexts for that matter.
>
>A proper use of diffusion would require *full* plaintexts, or *full*
>chosen texts to be used before any such attack could succeed.
>
>As everyone knows, a partial plaintext is more common than a full one.
Well Mr Bravo doesn't seem to understand this BASIC concept so
one has to be careful when one uses the word "everyone" you have
to realize that some people are just to retarded to understand simple
logic. But you are correct in your wording of why the 3 letter chaining
modes are weak.
>
>This is likely to weaken the cypher /even/ if the only attack known on
>the cypher is the use of brute-force.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
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 23:12:04 GMT
David,
Thanks for the response.
David A Molnar ([EMAIL PROTECTED]) wrote:
: In sci.crypt Keith A Monahan <[EMAIL PROTECTED]> wrote:
: > if I've decided to use my CC with that company, I've already made the
: > decision that I feel they will be fairly trustworthy.
: Note that trusting them not to do something evil with yout CC# is not the
: same thing as trusting them to keep your CC# of the the hands of
: evildoers.
Exactly. The only thing people can hope for is that the company is
handling the information responsibly. It's a shame that there isn't
some sort of security auditing certificate you could look for when
shopping/eating at places.
Many/most merchants can be trusted with the former. The latter
: is trickier. Remember the case when ppl got into Netcom's accounting and
: had access to all subscriber CC# ?
Sure I remember that. I can probably name 5 ISP's which have had big
problems. I always read companies' privacy/security policies online and
they always talk about SSL encryption and blah blah. But you KNOW alot
of these companies store your credit card info in plaintext on some
networked NT server, or even worse, plaintext on a unix box.
Keith
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypting short blocks
Date: Fri, 03 Dec 1999 23:06:23 GMT
Markus Peuhkuri wrote:
> What I want is following property: given message M1 (length N
> bits) produces same encrypted message E1 (length N bits) every
> time run. Message M2 produces message E2, which is different
> from E1 iff message M2 is different from M1.
Be sure and look at the "small codebook" problem.
Your blocks are small enough that an attacker
could search for collisions exhaustively or
construct the input/output dictionary. Perhaps it
is not an issue in your application, but look
carefully as there is a long history of people
missing this kind of threat.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 3 Dec 1999 15:24:40 -0800
Shawn Willden <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Douglas A. Gwyn" wrote:
>
> > This points up a supremely important fact: Real computer security
> > has to be built in from the ground up, with no loopholes anywhere.
> > You could probably achieve it with a capability-based architecture
> > and extremely good security review throughout system design, but
> > even so, at some level some user will screw up and hand over the
> > keys to an untrustworthy agent.
>
> Could you explain what you mean by a "capability-based" architecture?
I've puzzled
> over the term a bit and I can't figure out what you mean by it. Whose
capability
> and for what? And how does it relate to architecture?
He's referring to the likes of CAL-TSS, designed in 1968/1969 by Butler
Lampson, Howard Sturgis, and 4 others (myself included). The idea was that
the access to OPERATING SYSTEM OBJECTS would flow down from DIRECTORY SYSTEM
OBJECTS through a capability list, with accumulated restrictions -- each
capability for the OBJECT, (like read, write, execute, copy) could be turned
off before access to the object was handed to the application, which could
in turn remove more bits before calling sub-sections, etc. Removing the bit
was permanent for the life of the individual capability in the process's
list.
Each OPERATION on an object required a CAPABILITY, which was checked for the
required access at the time of the OPERATION, without needing to give the
application program access to the DIRECTORIES at all, per se, as is done
under unix, dos, etc. Karl M
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Fri, 3 Dec 1999 23:14:43 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Many-worlds interpretations of QP are can be completely
:> deterministic, and show no need for randomness.
: How do you think the branching into different worlds is determined?
The "Many-Worlds" answer to this question would be: All branches occur.
No decision about which branch is followed is ever made; all branches
exist simultaneously.
: If it is not equivalent to conventional QM randomness, it will not
: agree with the experimental evidence.
MWI is exactly consistent with other interpretations - provided
experiments such as interfering "observers" are not conducted.
Individual observers are still unable to make reliable predictions
about certain types of experimental outcome - and yet the universe
in which they exist may be completely deterministic.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Try not to kill anyone this time.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Fri, 3 Dec 1999 23:16:41 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Until such a scheme is demonstrated, "true atomic randomness" is
:> of the same utility to a cryptographer as a "perfectly straight line"
:> is to a student of geometry.
: You must not be much of a geometer.
<fx: giggles>
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
No individual raindrop ever considers itself responsible for the flood.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sat, 04 Dec 1999 00:15:24 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Eric Lee Green wrote:
>> And what good does this all do if the data being sent is stored on your hard
>> drive "in the clear", ready to be read by anybody who compromises the
> security
>> of your computer? And what good does that do if you use your birthday as your
>> password, a date that everybody in your office knows? IMHO, infecting your
>> computer with the NSA Virus (a hypothetical[?] virus that sends a CC: copy of
>> all your EMAIL to NSA headquarters prior to encrypting it) is a lot easier to
>> do than breaking the encryption on the already-encrypted EMAIL.
>
>This points up a supremely important fact: Real computer security
>has to be built in from the ground up, with no loopholes anywhere.
>You could probably achieve it with a capability-based architecture
>and extremely good security review throughout system design, but
>even so, at some level some user will screw up and hand over the
>keys to an untrustworthy agent.
Its amazing how often people make this statement that real
security has to be built in from the ground up. But why when it
comes to compression before encyption most people ignore the
information added by most compression methods? And they
tend to use chaining that goes out of its way not to difuse information
through out the file. It is as if people turn there brains off in these
areas. Any one have theorys as to why? You already know by
theories on the subject.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
** 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
******************************
