Cryptography-Digest Digest #242, Volume #10 Wed, 15 Sep 99 17:13:03 EDT
Contents:
Re: Sources of randomness (Medical Electronics Lab)
Re: Can you believe this?? (Anton Stiglic)
Re: Can you believe this?? (Anton Stiglic)
Re: Ritter's paper (David Wagner)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Tom Knight)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Tom Knight)
Word 8 Encryption Described In Detail ("John E. Kuslich")
Re: Can you believe this?? (John)
Re: Can you believe this?? (John)
Re: Can you believe this?? (John)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out ("Globalhead")
SCOTT19U.ZIP_GUY/Questions Please (tunafish)
Re: Sources of randomness (Scott Nelson)
Re: Can you believe this?? (jerome)
Re: Sources of randomness ([EMAIL PROTECTED])
Re: General encryption question (jerome)
Re: Second "_NSAKey" ("Trevor Jackson, III")
Re: Ritter's paper ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: Wed, 15 Sep 1999 12:29:42 -0500
Terry Ritter wrote:
>
> On Tue, 14 Sep 1999 11:01:26 -0700, in <[EMAIL PROTECTED]>,
> in sci.crypt "John E. Kuslich" <[EMAIL PROTECTED]> wrote:
>
> >If you have ever tried to design an electronic circuit that produces a
> >"random" stream, you will appreciate the difficulty of removing any
> >periodic (correlated) data.
> >[...]
>
> I have, and it is do-able, as long as one is aware of what is
> required.
>
> Please see my *preliminary* designs and the characterization of the
> results they produce:
>
> http://www.io.com/~ritter/NOISE/NOISRC.HTM
> http://www.io.com/~ritter/NOISE/NOISCHAR.HTM
You can find another independent design and its characteristics on
my web pages too. It's not that hard, it's just engineering
detail. Isolating the source is probably the most important
detail, and knowledge of shielding and grounding helps a lot.
But once you've got a nice signal, it's straight forward to
go into the digital domain and remove all the periodic information.
You don't need a hash function, you just need a filter.
I would bet there are several hundred good RNG designs. Many thousands
of not so good ones. The hard part is testing, it takes a lot
of time and effort to collect many megabytes of data and run it
thru all the possible tests.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 13:40:39 -0400
>
> /dev/urandom is NOT a valid source for key generation/challenge string.
> /dev/random is a good source for high quality entropy to seed a secure
> random number generator. Even the authors themselves have said that
> /dev/urandom should only be used for simple programming uses (like games and
> such). If you would like, I can dig up the article that says it. Better
> invest in a secure RNG.
I'd be interested in reading a well written article on that subject.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 13:46:10 -0400
>
If you are expecting 10 bits of randomness, and get just 1 bit,
this is bad, you can't say the opposite.
as
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Ritter's paper
Date: 15 Sep 1999 09:42:55 -0700
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> There are several gaps here. The grlaring one is that we have no ciphers
> (excluding OTP) that are secure. We have only ciphers that are not secure or
> whose security we are unable to determine. Note that last: it does not mean
> we "think" they are secure. It means we do not know.
Why do you think we have no ciphers that are secure?
If that were true, we would be able to trivially determine whether
any given cipher is secure -- the answer would always be "no". :-)
I think you have forgotten to make a clear distinction between
ciphers with unknown security and insecure ciphers. Your reasoning
supports the conclusion that we have no ciphers with known security;
it does not support the conclusion that we have no secure ciphers.
------------------------------
From: Tom Knight <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Wed, 15 Sep 1999 18:55:40 +0100
Daniel James wrote:
>
>
> Indeed, in the preface to "Zodiac", his first published novel, he says that he
> knew he was on the right track when one of his friends read the manuscript and
> described the central character as "an asshole".
>
> But then, of course, books can influence opinions even if the author does not
> intend that they should...
>
Yeah, but the author shouldn't be held responsible, IMHO.
>
> Cheers,
> Daniel.
------------------------------
From: Tom Knight <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Wed, 15 Sep 1999 19:05:51 +0100
> If a 'democratic' means of 'encouraging' an end to these
> criminals were
> easily accessible to the average Netizen I believe enough would
> participate to make this a new global political force to be recconned
> with.
>
Wow. Like a kind of twisted, charity-funded version of Special
Circumstances. This one's definitely going in the RPG bag.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Word 8 Encryption Described In Detail
Date: Wed, 15 Sep 1999 11:43:46 -0700
Please view a summary of a new article published by CRAK Software at
http://www.crak.com/Word8doc.html
All the details of the Word 8 encryption process are revealed so that
anyone with basic programming skills can write software to recover Word
8 Documents. C, C++ and Delphi code examples are given and structured
storage access is explained so that the relavent streams of the Word 8
structured storage may be reliably accessed.
This article is now available at http://www.crak.com
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 11:47:46 -0700
I agree. How can I get my encrypter "peer reviewed" without
giving away the "family jewels?" I have had many who
claim they are in the encryption community "assult me" for
not giving up the source code.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 11:51:10 -0700
I have been told this before. I agree, if my only client
is going to be someone in the encryption community.
As a programmer, will I ask Microsoft to give me the source
for Windows '98, or will they sell it to me? If someone can
so easily decompile a program, then why cry for the
source that you "already can get?"
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 11:56:43 -0700
Yes, yes, I have been reading DDJ since its first issue,
when it was called Computer Language. The 1996 article
does not "debunk anything" but only proves that in a
computer magazine, that is what I'd expect. I never said
not giving up the source makes a good encoder, but was only
trying to point out why some people don't. Besides, I think
discussions like this are more fit for the talk. groups.
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Globalhead" <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Wed, 15 Sep 1999 14:05:27 -0800
In article <[EMAIL PROTECTED]> , Daniel James
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Tom Knight
>wrote:
>> I'd still say that [Stephenson] never seems to be
>> trying to influence opinions. None of the characters in his books can be seen
>> as heroic mouthpieces.
>>
>
>Indeed, in the preface to "Zodiac", his first published novel
For the sake of accuracy I should point out that "Zodiac" was Neal
Stephenson's second published novel. His first was "The Big U", if memory
serves.
Larry --
"Kids! Bringing about Armageddon can be dangerous.
Do not attempt it in your own home."
-- "Good Omens", by Terry Pratchett and Neil Gaiman
ICQ No. 37523426
------------------------------
From: tunafish <[EMAIL PROTECTED]>
Subject: SCOTT19U.ZIP_GUY/Questions Please
Date: Wed, 15 Sep 1999 15:12:13 -0400
Hi Scott
I have read alot of your posts here, and I think you have a point which
I would like to explore here. What you seem to be sayong is the
following (among other things !):
1. Why should the nist give us wonderfull advanced algorithms for the
21st century free on a plate, curtesy of the nsa?
2. You dont like the 3 chaining technique they use and the compression
because you say it weekens the encryption.
Point 1: Yes why would our government kindly give us free secure
encryption software free. Very good question. My theory goes somthing
like this:
The nist wanted to know what is available out there , like throughing
the net out to catch any fish...
And they seem to have caught some good fish....2fish , mars, etc....the
aes candidates...
What they seem to have done is deliberaltely weeken these algorithms by
asking those who submitted to make certain modification to the code...
Since I am not a cryptographer, I dont know apples from pears if 2fish
is fishy or not....I think there are very few who can for certian verify
if there is weekness in 2fish or any of ther other aes submissions...ok
but these guys are NOT GOING TO POST HERE and tell US 2fish is strong
and ok to use....
These top cryptographers, most of them dont go public and certainly work
for government institutions...so we will probably never know if any of
the aes submissions has an inherent weekness or not...Could it be that
our government is weening us away from strong algorithms which they cant
break ( IDEA etc) , by replacing those with the so called Advanced AES
standards...
Now Point 2:
Could you explain your claim that 3 chaining and and the compression
used weekens the ciphers...you have just made a statement and no
clarification...please explain to a non-cryptographer what this means
Just as a matter of interest , I use pgp (the original DOS version and
not the new GUI version)...., is there also this tripple chaining
weekness in it which you so dislike...
Tuna Fish
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Sources of randomness
Reply-To: [EMAIL PROTECTED]
Date: Wed, 15 Sep 1999 19:50:39 GMT
On 14 Sep 1999 12:11:30 -0700, [EMAIL PROTECTED]
(David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>> But CRC, a.k.a Linear Feedback Shift Register, is usually much
>> smaller and faster than a cryptographically secure hash. If
>> the object is to distill random bits from a biased source,
>> it seems a better choice to me.
>
>Smaller, faster, and almost certainly less secure[1].
>My advice: stick with a cryptographic hash function (e.g., SHA1).
>
>
>[1] One can prove that CRCs are adequate for distilling entropy: the
> leftover hash lemma says that if you use a LFSR with a n-bit output
> and a random (uniformly-distributed) feedback function, and if you
> have at least 3n bits of Renyi entropy of order 2 in the source
> (different from the usual measure of entropy!!!), and if you never
> use it more than once, then the n-bit output has close to the uniform
> distribution.
>
> However, this approach is terribly wasteful of random bits, requires
> stronger-than-usual assumptions on the distribution of the inputs,
> and in practice is probably highly susceptible to deadly implementation
> errors.
>
Even if 3n were always necessary, 1/3 of the theoretical best
in exchange for the absolute guarantee of maximal entropy
isn't my idea of "terribly wasteful." And 3n is an _upper_
limit, not a typical case.
There's a tradeoff here between wasting computing power
and source bits. Both resources are remarkably cheap,
and if you can, then waste them both. In my experience tough,
source bits have always been "cheaper." YMMV.
Security isn't an issue until we're talking about what you
do with the random bits you've collected. In fact, if you
want to talk about avoiding implementation errors, the KISS
principle says we should use the simpler CRC over SHA1, not
the other way around. This is especially true if the bits
are being collected for something other than cryptography.
(Yes, I know this is sci.crypt, but there still isn't a
sci.random, so all serious random discussions happen here.)
On the subject of deadly implementation errors, here's one
to avoid; Don't use the random bits directly as the session key.
Consider a server where:
new_bits = SHA1(old_bits + <a few random bits>)
session_key = new_bits
Imagine further that Mallet can monitor all communication
with the server. Mallet initiates his own session, which
gives him the current session key. With this info, Mallet
then tries all possible combinations of <a few random bits>
and can easily determine the next session key, and decrypt
the next secure communication. With the second session key,
he can determine the third, and so on, and so on.
Much better is to use a secure hash of the random bits
as the session key:
new_bits = SHA1(old_bits + <a few random bits>)
session_key = SHA1(new_bits + <a constant>)
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Can you believe this??
Date: 15 Sep 1999 19:52:49 GMT
Reply-To: [EMAIL PROTECTED]
posted by somebody on coderpunk
> The essential reference on these issues:
> ftp://ftp.isi.edu/in-notes/rfc1750.txt
>
> Other good stuff is on the Linux /dev/random page
> http://www.openpgp.org/random
>
> and in the Yarrow stuff at:
> http://www.counterpane.com
On Wed, 15 Sep 1999 13:40:39 -0400, Anton Stiglic wrote:
>I'd be interested in reading a well written article on that subject.
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Sources of randomness
Date: Wed, 15 Sep 1999 20:03:00 GMT
Mok-Kong Shen wrote
> If I understand correctly, this means that we don't have to bother
> too much about the raw sources of randomness (which may even contain
> essential periodic components) as long as we can put them in to
> a good program like Panama and obtain from that a sort of 'distillate'
> which is of good random quality.
The "as long as" hides too much. We have to bother
a great deal about the random source. The sole point
is that we only need to worry about whether we have
collected enough entropy; the redundancy that came
along with it doesn't hurt.
[...]
> If one consequently follows this line of reasoning, one finds that
> it isn't necessary to employ physical sources but that text materials
> etc. can serve the same purpose as well.
One finds no such thing. A fixed text has zero entropy.
A choice from N fixed texts has at most lg(N) bits. In
general, selecting or generating the text requires at
least as much entropy as it yields.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: General encryption question
Date: 15 Sep 1999 20:06:39 GMT
Reply-To: [EMAIL PROTECTED]
one solution may be to put the encrypted exe in a datafile,
read it, alloc a memory space, prevent the paging on it
(mlock(addr,len) on unix), decrypt it and execute it in it.
you want ot prevent your application to core dump too.
i dont know a good way to do that. you can grep for 'dumpable'
in linux kernel. if dumpable = 0, you cant core.
i think that putting a setuid bit will work. but not very clean.
On Wed, 15 Sep 1999 18:15:58 +0200, Dr.Gunter Abend wrote:
>
> Is it possible to decrypt and execute a file/application
> without at any time leaving it in a decrypted state on the
> hard drive?
------------------------------
Date: Wed, 15 Sep 1999 16:21:23 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
David Wagner wrote:
> In all seriousness, yes, I agree that both approaches to "spiking"
> the crypto would probably work. But why would the NSA go to the
> extra effort (and extra risk of disclosure) of asking Microsoft to
> add a "_NSAKEY", when it could have used other, less costly, less
> risky methods? This seems to me to be the key question your
> scenario should answer if it is to be a persuasive explanation.
This appears to be a sensible question. So far there is no evidence that
the NSA has any role in this fiasco. IMHO, it is easier to believe that a
person or persons within Microsoft(tm) were acting as wanna-be NSA spooks
rather than believe that the NSA actually did something so crude.
Microsoft(tm) has a long history of hiding things in their software and
lying about it. As far back as PC-DOS 2.0 (development team mantra: "DOS
isn't done until Lotus won't run!") they have been embedding secret
features in their software. The most notorious example is that of
Windows(!tm) version 3 which had secret authentication routines in its
installation tools aimed at convincing users that it would not run on
competitors' software (e.g., DR-DOS).
We may not be able to determine what the actual purpose of their "backup
key" may have been, but it fits the pattern of Microsoft's past behavior.
Occam's razor indicates that we need not invoke any dark agencies in order
to explain the facts available.
------------------------------
Date: Wed, 15 Sep 1999 16:01:47 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
David Wagner wrote:
> In article <[EMAIL PROTECTED]>,
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> > There are several gaps here. The grlaring one is that we have no ciphers
> > (excluding OTP) that are secure. We have only ciphers that are not secure or
> > whose security we are unable to determine. Note that last: it does not mean
> > we "think" they are secure. It means we do not know.
>
> Why do you think we have no ciphers that are secure?
> If that were true, we would be able to trivially determine whether
> any given cipher is secure -- the answer would always be "no". :-)
>
> I think you have forgotten to make a clear distinction between
> ciphers with unknown security and insecure ciphers. Your reasoning
> supports the conclusion that we have no ciphers with known security;
> it does not support the conclusion that we have no secure ciphers.
Agreed. The statement should have been: "...we have no ciphers that are KNOWN
secure".
Sorry for the poor phrasing.
------------------------------
** 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
******************************
