Cryptography-Digest Digest #761, Volume #13 Wed, 28 Feb 01 02:13:01 EST
Contents:
Re: Was there ever a CRM-114 Discriminator? (Dennis Ritchie)
Sad news, Dr. Claude Shannon died over the weekend. ("John A. Malley")
Re: OverWrite freeware completely removes unwanted files from harddrive ("Trevor L.
Jackson, III")
Re: OverWrite freeware completely removes unwanted files from harddrive ("Trevor L.
Jackson, III")
Re: How to find a huge prime(1024 bit?) (Free-man)
Re: On RC4 in C (Anne & Lynn Wheeler)
Re: Super strong crypto (Bryan Olson)
Re: On RC4 in C (Guy Macon)
Re: how long can one Arcfour key be used?? (Bryan Olson)
Re: super-stong crypto, straw man phase 2 ("Douglas A. Gwyn")
Re: Hash strength question (Bryan Olson)
Re: Rnadom Numbers ("Douglas A. Gwyn")
PCVault (John M)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: encryption and information theory ("Douglas A. Gwyn")
Re: encryption and information theory ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: Was there ever a CRM-114 Discriminator?
Date: Wed, 28 Feb 2001 04:18:49 +0000
Ed Kubaitis wrote (before merciless snipping, and you'll
have to get his internal quotes from the references):
> Actually, I think the three-letter code was used as password, not an
> encryption key. As I recollect, the point of the "discriminator"
> was to weed out bogus voice "recall" messages being sent by the
> Russians to the crew....
>
> > That movie was made around 1959 I think. Even then a 3 letter code would
> > have been *way* too small. Kubrik used 3 letters for "precious bodily
> > fluids" and "poe" ( a reference to the poet maybe?) and wanted an artistic
> > link between the nut case commander and the planes. Other than a few
> > real close calls of actual almost launching nukes, there's not much
> > in that movie that was even close to real.
>
> 1964 actually. And I think you're way too tough a grader on Dr S
> authenticity factors.
Yes, 1964. And the "poe" might have had some second-level reference
to Edgar Allan, but the main one was "purity of essence": General Jack
D.
Ripper's revealed belief in fluoridation as a Commie plot that
sapped his precious bodily fluids. If I recall correctly (it's
been a while) the code that was eventually put into the CRM-114 was
just the permutation "ope".
> A couple years before the movie came out, I actually got a chance
> to spend a few minutes in a B52 cockpit on an AFROTC field trip.
> I thought Dr S did an excellent job of reproducing the "look and feel"
> of the crew areas I saw....
The cockpit and crew-station scenes inside the plane seem better
as simulation of reality than the exterior shots of the flying B52--
the latter were pretty sleazy, actually.
> One thing I *can* testify to though: the computer room in which
> Peter Sellers discovers the left-behind portable radio which tells
> him civilian radio in Alaska is still on the air was an absolutely
> accurate rendering of an IBM 7094 machine room. In fact, I'm almost
> certain it was shot on location in a *real* such machine room.
I'm pretty certain of that as well. I don't think a set designer
would bother to reproduce the smallish extra-index-register display
box atop the main console.
Dennis
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Sad news, Dr. Claude Shannon died over the weekend.
Date: Tue, 27 Feb 2001 20:24:15 -0800
I heard on NPR today that Claude Shannon died this past weekend at the
age of 84.
Claude E. Shannon was a pioneer in communications theory, computer
science, cryptology, information theory and artificial intelligence.
To me he is an Engineering Hero. His bio is on-line at AT&T Research
http://www.research.att.com/~njas/doc/shannonbio.html
Dr. Shannon's paper, "The Mathematical Theory of Communication", is
perhaps one of the most important papers ever published in the 20th
Century. And his follow-on paper, "Communications Theory of Secrecy
Systems" ,is a must-read for all of us in this USENET group.
Both papers are graciously provided on line, the "The Mathematical
Theory of Communication" at
http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html
and "Communications Theory of Secrecy Systems" at
http://www3.edgenet.net/dcowley/docs.html
His work is profound and eye-opening.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files from harddrive
Date: Wed, 28 Feb 2001 04:28:22 GMT
Anthony Stephen Szopa wrote:
> "Trevor L. Jackson, III" wrote:
> >
> > Anthony Stephen Szopa wrote:
> >
> > > Michael Brown wrote:
> > > >
> > > > <SNIP>
> > > > > >
> > > > > > I checked the web pages, but I can't find any description for how the
> > > > > >>>>>(SNIP SNIP)
> >>>
> >>>
> > the OS might never write to the disk at all.
>
> I told you what the coded instructions are.
>
> You and others suggest that just maybe these coded instructions are
> somehow not being carried out.
>
> You are suggesting that maybe sometimes they are and sometimes they
> are not.
No, I am telling you in no uncertain terms that the compiler's run-time library,
the operating system, it's device drivers, the disk controller, and the disk drive
are free to optimize their performance by eliminating redundant writes. If you
read your compiler's documentation you will find that it eliminates "redundant
stores" so that when you write "X = Y;" the compiler may decide that there is no
need to bother. Redundant file writes can be optimized out of existence for
exactly the same reason: executing the action is a waste of time.
>
>
> Urban Legend or FUD.
Facts appear to bother you. Perhaps you should seek professional counseling about
that.
>
>
> Either way, refer us to some research papers that clearly
> address / demonstrate this.
Hardly necessary. Simply read the documentation for DOS. The section on SMARTDRV
covers write-behind caching (note that this program is not a disk cache, but a
track buffer). Simply look up the term write behind caching and apply the
resulting understanding to the question at hand.
If you doubt the documentation you are free to test your own hardware. Simply
write a tiny program that hammers on a single sector many times. If you find the
program completes in less time than it takes your disk to rotate that number of
times you will have proven that it did not write the targeted sector the indicated
number of times.
Note that the fact that you are so naive as to believe that the programs you write
do what you want them to do rather than what you told them to do means that you are
not yet ready to write software for any user other than yourself. You have much to
learn. One of the things you lack is the understanding that the code that opens a
file, writes to it, and closes it is not a series of commands, but a series of
requests.
Note further that sci.crypt is not an appropriate forum for further discussion of
this topic.
>
>
> This is no trivial matter.
Of course it is.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files from harddrive
Date: Wed, 28 Feb 2001 04:30:52 GMT
Benjamin Goldberg wrote:
> Anthony Stephen Szopa wrote:
>
> > This is no trivial matter.
>
> No, it's not a trivial matter. Noone said it was.
I disagree. In the context of sci.crypt it is, indeed, trivial. Then
again, so is my disputing the point ;-)
------------------------------
From: [EMAIL PROTECTED] (Free-man)
Crossposted-To: alt.security.pgp,sci.math
Subject: Re: How to find a huge prime(1024 bit?)
Date: Wed, 28 Feb 2001 05:04:39 GMT
On Wed, 28 Feb 2001 02:51:53 GMT, "Dik T. Winter" <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> > Thomas Boschloo wrote:
> > > Take the proof for infinite primes by the greek. They use a number 'N'
> > > that is composed by multiplying all the primes up to the largest prime
> > > and adding 1. This new number can't be divided by any of the primes you
> > > used to generate 'N' because e.g. the next increment of 'N' can be
> > > divided by two, the next one by three, etc. They all just mis out, so
> > > the new number 'N' must be a prime also! (Not only that, but it is
> > > larger than the largest prime we assumed, thus falsifying the argument
> > > that there is a largest prime).
> >
> > Not correct, here.
>
>Well, I say it is correct. The premissa is: "there is a finite number
>of primes". Multiplying them all together and adding 1 shows that the
>resultant number is not divisible by any prime. Hence by the definition
>of prime it must be prime, contradicting the premissa.
Not exactly. Under that premise, it can be proved that the number
product + 1 is not prime and not composite. That is the
contradiction that proves that the premise is false because a finite
number must be prime or composite.
>
>But let's analize it more completely:
>Def: a prime is an integer number > 1 that is not divisible by any smaller
> number, except 1.
>Theorem: a non-prime > 1 is divisible by a prime.
>Proof: it is divisible by a smaller number which is either prime or non-
> prime, so by infinite descent the result holds.
>Theorem: there is an infinitude of primes.
>Proof:
> Suppose there is only a finite number of primes. Multiply them all
> together and add 1. Suppose the result is non-prime, but according
> to the theorem above it should be divisible by a prime, but none of
> the primes fit, so it is prime. A contradiction, we have found a
> new prime.
No, because you have two "suppose"
>
>The confusion is that the new number is indeed not necessarily prime, but
>when the premissa is "a finite number of primes" we just showed that the
>number *is prime*,
No, it is shown that the number is not prime and not composite.
>
>From a false premissa it is fairly easy to get false conclusions. It is
>only needed to show that a conclusion contradicts the premissa to show
>that the premissa is false, and so the conclusion is not necessarily true.
I agree.
Rich Eramian aka freeman at shore dot net
------------------------------
Crossposted-To: comp.lang.ada,talk.politics.crypto
Subject: Re: On RC4 in C
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2001 05:07:57 GMT
William Hugh Murray <[EMAIL PROTECTED]> writes:
> (Notice that many already complain about the dominance and business practices of
> both of these companies. We seem to have a penchant for attributing to
> predatory practices the results of wise, not to say courageous, investment and
> novel business models.)
>
> Having been through this once, I have more faith in the markets and competition
> than in litigation and regulation. Time will tell. In any case, this too is a
> discussion for another day and another forum. Perhaps over a glass of bubbly
> some time.
there was some case made regarding some execs that might have been
accused of taking a one time shot to quarterly earnings and their
bonus converting a significant number of lease machines to purchased
in the 70s.
there was also june 23rd, 1969 with the separate charging for people
services (aka unbundling; which had been packaged for "free" as part
of customer support).
following has comments supposedly attributed to testimony in the trial
http://www.garlic.com/~lynn/94.html#44
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], finger for pgp key
http://www.garlic.com/~lynn/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 27 Feb 2001 21:31:49 -0800
Douglas A. Gwyn wrote:
>
> Bryan Olson wrote:
> > As I wrote, I think David Wagner had a point that you didn't
> > really get.
>
> If you mean, that entropy couldn't be introduced fast enough
> without using up the bandwidth for overhead
Obviously I mean what I wrote. You had:
| The point is piggy-backing key distribution before one has
| lost the security assurance.
Before reaching the unicity distance, we do indeed have
an assurance against solution of the cipher. But the
change of key over the same channel does not extend the
assurance. After changing the key, we are no farther
from unicity.
When you noted you had your own idea of "provably strong"
based on a "threshold criterion". I asked you to define
this and in your response you edited out the question
instead. Essentially the same happened for your "natural
lifetime". I don't see you will get any security results
based on just inventing new terms.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: comp.lang.ada,talk.politics.crypto
Subject: Re: On RC4 in C
Date: 28 Feb 2001 05:36:48 GMT
Roger Schlafly wrote:
>Actually, a lot of people are unhappy that MS Windows is closed source, and
>that MS uses it together with its monopoly power to enforce undocumented
>APIs,
>bundled products, and system insecurities. Witness the recent Anna K virus,
>the explosive growth of Linux, and yesterday's antitrust hearing.
Imagine yourself writing an email reader. You give the incoming
email the ability to do various things (some with user permission only)
such as display on the screen, be saved to disk, etc.
Now imagine yourself giving the incoming email the ability to:
[1] Send emails without telling the user or asking permission,
[2] Read your address book so as to know who to send to.
Now imagine the media jumping on the 13 year old moron who
decided to eploit your little "feature", and never questioning
your part in all of this.
...Pretty sweet deal Microsoft has, eh?
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: how long can one Arcfour key be used??
Date: Tue, 27 Feb 2001 21:46:01 -0800
Simon Johnson wrote:
>
> Julian Morrison wrote in message
> > How much info is it safe to encode with the one key in Arcfour? Assuming
> > one is using the full 256 bytes possible as key+IV.
[...]
> I think I remember for an average key it is something like
> a few gigabytes before a bias can be detected in the output.
> Not sure if this is correct though?
Yes, see Paul Crowley's page at:
http://www.cluefactory.org.uk/paul/rc4/
Frequent key changes don't significantly effect this bias (at
least not unless changing every byte or two).
--Bryan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super-stong crypto, straw man phase 2
Date: Wed, 28 Feb 2001 06:17:17 GMT
William Hugh Murray wrote:
> In any case, most of us do not worry about keeping secrets from
> nation states for a long time.
Well, you should!
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Hash strength question
Date: Tue, 27 Feb 2001 22:15:28 -0800
Benjamin Goldberg wrote:
>
> Thanks! And while you're clearly right about the XOR method being
> trivially insecure, since
>
> H("acegik") XOR H("bdfhjl") == H("bdfhjl") XOR H("acegik").
>
> What about if each hash chip is seeded with it's index:
>
> H(1||"acegik") XOR H(2||"bdfhjl")
>
> I think it is very unlikely that:
>
> H(1||"acegik") XOR H(2||"bdfhjl") == H(1||"bdfhjl") XOR H(2||"acegik")
It may be unlikely for current hash functions, and
you could probably prove something about random functions,
but collision resistance of the construct does not follow
from collision resistance of H.
--Bryan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Rnadom Numbers
Date: Wed, 28 Feb 2001 06:22:13 GMT
Benjamin Goldberg wrote:
> ... then it takes approximatly O(2^126) time for the NPC solver to
> break the system.
That can't be right. O(2^126) = O(1).
------------------------------
From: John M <[EMAIL PROTECTED]>
Subject: PCVault
Date: Thu, 22 Feb 2001 00:15:56 +1100
Does anyone have any knowledge/comments about PCVault from
http://www.eracom.com.au/products/pcvault.html
especially in comparison to PGPDisk
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Wed, 28 Feb 2001 06:47:19 GMT
Bryan Olson wrote:
> ... I don't see you will get any security results
> based on just inventing new terms.
I always edit out text not relevant to my reply,
and I don't answer every question asked, for a
variety of practical reasons. I'm sorry that you
didn't understand the concept and choose to think
of it as "just inventing new terms". When I say
"threshold criterion" the meaning should be clear
enough to anyone with training in statistics.
When I talk about the "natural lifetime" of a key
that is plain English that ought not to need
explanation: if you use a key for too much traffic
where the plaintext has exploitable statistical
characteristics, then cryptanalysis is enabled,
thus the earliest point before which such
cryptanalysis is practical is the natural point at
which to expire the key and replace it with a fresh
one. I don't have to tell you how the cryptanalysis
would be done, which at any rate would depend on
details of the system, but the *topic* as I
interpreted it is what characteristics a practical
cryptosystem might have that would foil any attempt
at cryptanalysis no matter how clever the analyst.
The idea of frequent injection of key entropy is
based on my own evaluation of what properties of
systems have been found to be exploitable. If you
can devise a practical attack on the example I
posted as "phase 2", I would appreciate hearing it.
One of my working assumptions for that example is
that the basic block encryption thoroughly mixes
the PT and key into each CT bit, which is typical
of any block cipher one ought to consider anyway;
apart from that, feel free to assume that the block
cipher has any sort of cryptanalytic weakness you
wish, then show me how to break the chaining scheme.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: encryption and information theory
Date: Wed, 28 Feb 2001 06:53:45 GMT
Andreas Moser wrote:
> Does the encryption change the entropy, ...
Entropy, like every kind of knowledge, is contextual,
i.e. it must be measured relative to some state of knowledge.
Basically, the ciphertext is much more entropic for the
enemy eavesdropper than it is for the legitimate recipient.
The difference is essentially the entropy of the key.
> isn't there a way to see through the encryption?
Quite often, there is. It's called "cryptanalysis".
Consult basic texts such as those suggested in the sci.crypt FAQ.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: encryption and information theory
Date: Wed, 28 Feb 2001 06:57:24 GMT
John Savard wrote:
> It has been answered that conventional encryption increases the
> entropy of a message by the amount of the key.
> That is true only if the message is not compressed.
No, reversible compresion does not change the entropy.
It does encode it in (usually) fewer bits, which is
an increase in information *density*, also thought of
as a decrease in redundancy. That does make statistical
methods less effective.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
