Cryptography-Digest Digest #491, Volume #10 Tue, 2 Nov 99 00:13:03 EST
Contents:
Re: Doesn't Bruce Schneier practice what he preaches? (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Compression: A ? for David Scott (Tim Tyler)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Unbiased One to One Compression (SCOTT19U.ZIP_GUY)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
www.digitalme.com (Michael Kinney)
Re: What is the deal with passwords? (John Kennedy)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Tom St Denis)
Re: Doesn't Bruce Schneier practice what he preaches? (Mr. E. Yankoil)
Re: What is the deal with passwords? (John Kennedy)
Re: the ACM full of Dolts? (Tom St Denis)
Re: need LFSR information (Scott Nelson)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Louis)
Re: What is the deal with passwords?
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.security.scramdisk
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Tue, 02 Nov 1999 00:32:37 GMT
In article <[EMAIL PROTECTED]>, John Kennedy
<[EMAIL PROTECTED]> wrote:
>On Mon, 01 Nov 1999 16:53:29 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>>In article <[EMAIL PROTECTED]>, John Kennedy
> <[EMAIL PROTECTED]> wrote:
>>>On 1 Nov 99 05:34:47 GMT, [EMAIL PROTECTED] () wrote:
>>>
>>>>Roman E. Liky ([EMAIL PROTECTED]) quoted:
>>>>: >Here's an example, Counterpane Systems has a nice little freeware
>>>>: >utility called Pasword Safe.
>>>>
>>>>Probably an exception was made here simply because this is intended as a
>>>>convenience for users who can't be bothered to memorize passwords, or do
>>>>anything else they ought to - of course, using PGP or ScramDisk makes
>>>>better sense from a security standpoint, but not everyone will find them
>>>>convenient enough to use.
>>>
>>>They make considerable hay out of the fact that the utility uses
>>>Blowfish encryption. The point of Blowfish is security. There's no
>>>other reason to care if Blowfish is part of the utility. But what good
>>>is Blowfish encryption without open source? It contradicts Schneier's
>>>own advice, does it not?
>>>
>>>I don't mean to make a mountain out of a molehill here, but this is a
>>>puzzling contradiction.
>>
>> It is really not that puzzling you just have to think about it. You may
>>come to the same conclusion that I have.
>
>Which is?
Which is propably very similar to yours.
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Tue, 02 Nov 1999 00:41:10 +0100
[There are time and again more than one simultaneously not yet
responded posts on both side of us. I have just sent a post,
of Tue, 02 Nov 1999 00:11:17 +0100, asking you a few basic questions
in order to clear up misunderstandings. So the present post could be
irrelevant, depending on your answers. However, I try nonetheless to
respond to the following issue, though on the assumption of the
(questionable) verbatim copying rule.]
Tim Tyler wrote:
>
Mok-Kong.Shen wrote:
> : Then use simply totally disjoint characters on each side and with
> : appropriate modification of the string on side2 and you are guaranteed
> : to have the same type of problem:
>
> : Side1 Side2
> : ABCD PQR
> : EF S
> : GHIJ T
> : XYZ UV
>
> : Now XYZABCDABCD --> UVPQRPQR. A modification gives:
> : UVEFGHIJ --> XYZEFGHIJ --> UVST
>
> UVEFGHIJ -> XYZST -> UVEEFGHIJ.
>
> Your problem in translation is they you are /still/ only replacing the
> "side2" strings with the "side1" strings and *not* visa versa.
>
> You *must* replace words from each side with those from the other, or
> the scheme will not work.
I certainly do in the same way as with an ordinary dictionary. But
I assumed a verbatim copying if no proper entries (on the proper
side) can be found. In the above the (purposedly modified) string
UVEFGHIJ is given on side2. UV can be translated to XYZ because
there is an entry UV on side2 of the dictionary. For EFGHIJ no
entry can be found on side2 of the dictionary. So verbatim
copying applies. The result is therefore XYZEFGHIJ. Now this string
is on side1. Hence for translation one matches it with the entries
of side1 of the dictionary and obtains UVST (this time there is
no non-matching entry problem.)
Please note the remark within brackets that I put at the beginning.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Reply-To: [EMAIL PROTECTED]
Date: Mon, 1 Nov 1999 23:38:23 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
:>: "Tim Wood" <[EMAIL PROTECTED]> wrote:
:>:>Assuming that the attaker can _choose_ the plaintext
:>:>it makes no difference what compression is used. The plaintext chossen
:>:>is the binary string *after* compression.
:>:
:>: Yes as I have admitted many times if you can get the enemy to
:>: completely encrypt a file of your choice. Then he can control exactly
:>: the complete file that goes into the encryption phase of the program.
:>: IN this case it would be essetntially the same as giving the enemy a
:>: different file with out using the compression at all becasue this would
:>: be like not using compression at all. [...]
:>
:>A case where I appear to disagee with David Scott ;-)
:>
:>*Even* if the enemy can control the plaintext of the message, compression
:>can /still/ offer _some_ security benefits...
:
: I am not sure we disagree. I feel over all there still are some security
: benefits. But in this one rare case we are allowing the enemy the to give
: us a file to use. [...]
I see:
The chosen file could be a monster file that could not be compressed.
Yes - my comments would be appropriate for *known* plaintext attacks -
but do not apply to *chosen* plaintext attacks.
Apologies for this mistake on my part.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
It's meaningless to speak of domesticating a child.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Tue, 02 Nov 1999 01:22:37 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Tim Tyler wrote:
>>
>
>> However, I am happy to try to look at things using your terms. If your
>> algorithm looks up "side2" entries in your dictionary and replaces them by
>> the equivalent "side1" entry (when decompressing - and does the reverse
>> when compressing), then your dictionary *must* have each entry
>> twice, with the second lot of entries reversed (as follows):
>>
>> Side1 Side 2
>> ABCD <-- HG
>> HTHN <-- UK
>> XYZ <-- PQ
>>
>> HG <-- ABCD
>> UK <-- HTHN
>> PQ <-- XYZ
>>
>> If you fail to do this your system is unlikely to work.
>
>Why on earth MUST a dictionary be of this form (every entry on
>one side is also present on the other)? Have you ever seen an
>English-French dictionary like that? Note that you have yourself
>given an example where on the left side (my side1) are English
>alphabets and on the right side (my side2) you exclusively use
>/, [, etc. Why MUST your dictionary not ALSO be of this nature?
>Quite evidently, there are currently much misunderstanding between
>us. For example, I took the verbatim copying rule out of a follow-up
>from Scott where he commented on my example. But this you told me is
I am sorry if I confused this is a common thing with the both
of us. I will let you argue this out with TIM. But I think you
are looking at this wrong.
In the above tim just tried to make it easyer for you but I think
it confused even more. Maybe it would be better if you don't
even think in term of dictionarys but in terms of pairs of strings.
each pair is made of a short string and a long string. When you
run this part of prgrram that does string replacement don't think
of decompressing and compressing think of just string replacement.
The hope is that when you want compressing done your file will mostly
be sustituting the long strings for the short strings. But if the strings
are at random in the oringal file somethimes your replace long
with short and vice verca. But his method is really for this phase the
same for compression and decompression if you run it twice you get
back where you start.
>non-existent in your scheme. Now, to be able to properly do further
>arguments and not waste unnecessary time and effort because of
>differences in definitions etc., I like to propose that some
>fundamental stuffs be thoroughly cleared up. Let me ask you therefore
>a few questions (allow me for simplicity to continue to use side1 to
>denote the uncompressed side and side2 to denote the compressed side):
>
>(1) Must the symbol sets that appear on both sides of a dictionary
> be identical? (I presume not. See your own example.)
>
>(2) If the answer to (1) is no, what does one do in case (when
> translating a string from side2 to side1) one encounters
> (unexpectedly) a symbol that only appears on side1 of the
> dictionary? (Should one do a verbatim copying, issue an error
> message to the user, or what?)
>
>(3) MUST a dictionary have the form above or not? Besides the
> two criteria that you gave in an earlier post, namely
>
> No string in the tables should contain another such string
> as a substring.
>
> No leading symbols in any string should exactly match the
> trailing symbols in a different string.
>
> what else exactly must a dictionary also satisfy?
>
>Thank you in advance.
>
>M. K. Shen
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: Unbiased One to One Compression
Date: Tue, 02 Nov 1999 01:25:48 GMT
In article <SEoT3.5613$[EMAIL PROTECTED]>, gtf[@]cirp.org (Geoffrey T.
Falk) wrote:
>In article <7v9je1$255s$[EMAIL PROTECTED]>,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>>In article <%PPR3.385$[EMAIL PROTECTED]>, gtf[@]cirp.org
> (Geoffrey T. Falk) wrote:
>>>In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>>>>Geoffrey T. Falk <gtf[@]cirp.org> wrote:
>>>>: Again: Simply not being "one-on-one" itself, in general, only helps
>>>>: the attacker if he can guess X and then compute Comp(Decomp(X)).
>>>>
>>>>No. Not at all. No, no, no, no, no!
>>>
>>>OK, then give an example where the "not 1-1" helps the attacker, where
>>>he does not know "X" and cannot compute Decomp(X).
>>
>> I assume you mean by cannot compute Decomp(X) there exists
>>many such X for a test key that don't decompress. And I am assuming
>>that you mean by don't know X the attacker does not know before the
>>attack what the unencrypted correct message is.
>
>No, that's not what I meant. I meant, assume the attacker only has
>a partial break and cannot use the Comp(Decomp(X)) test to determine
>whether his partial break is correct. Therefore he is reduced to
>exhaustive search of the key space.
I still am not sure what you are driving at. I hope Tim does.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 00:52:50 GMT
In article <7vkumt$2jgi$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <7vksa7$i2i$[EMAIL PROTECTED]>, Tom St Denis <tomstdenis@my-
deja.com> wrote:
>
> >Does anybody have any thoughts along these lines?
> Just one do you ever read or think about the carp you post.
Most of the time :)
> >btw I don't mean to plug peekboo, but it really is the only
encryption
> >software I can find that doesn't use passwords. Feel free to list
> >other software in replies.
> >
> And people call my stuff snake oil. This last set you wrote
> is priceless.
Why is it priceless? Peekboo honestly doesn't rely on passwords. Can
you explain where I errored?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 00:53:42 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> So how does PeekBoo store the users private key?
>
With 'fwrite()' how else would I store it?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 00:51:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>
> >It uses modern cryptography, yet I
> >can talk to joe.blow without knowing a password. Is it safe? I
would
> >like to think so. Basically the assumption that good passwords can
be
> >easily memorized is long since dead.
>
> Well, it is true that you don't need passwords for safety against
> eavesdroppers.
True but you *can never* truly protect against mitm attacks. If you
can prove to me how.
> Does your program protect such things as your private key for
> public-key communications against someone who obtains physical access
> to your computer? If so, how does it do so without a password? By
> letting you store it on a floppy disk that you can hide somewhere in
> an unencrypted form?
Why would I protect against such things? Even PGP can fall quickly
with a remote malicious virus. What is more likely though, mr Savard.
Then you enter my house, steal my floppy disk with peekboo, or trick me
into running a program which can remotely steal anything you want?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Michael Kinney <[EMAIL PROTECTED]>
Subject: www.digitalme.com
Date: Tue, 02 Nov 1999 01:05:18 GMT
Novell has a new web site that alls one to put all their personal
information into it's database. I was wondering if anyone has heard how
good their security was.
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Mon, 01 Nov 1999 20:13:30 -0500
On Mon, 01 Nov 1999 16:49:59 -0500, Anton Stiglic <[EMAIL PROTECTED]>
wrote:
>So how does PeekBoo store the users private key?
I know nothing about PeekBoo but there's nothing that says private key
*has* to be encrypted. It could be left up to you, you could protect
it physically.
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Tue, 02 Nov 1999 02:55:33 +0100
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
> >us. For example, I took the verbatim copying rule out of a follow-up
> >from Scott where he commented on my example. But this you told me is
> I am sorry if I confused this is a common thing with the both
> of us. I will let you argue this out with TIM. But I think you
> are looking at this wrong.
> In the above tim just tried to make it easyer for you but I think
> it confused even more. Maybe it would be better if you don't
> even think in term of dictionarys but in terms of pairs of strings.
> each pair is made of a short string and a long string. When you
> run this part of prgrram that does string replacement don't think
> of decompressing and compressing think of just string replacement.
I (at least subjectively) do think that a dictionary is nothing
but a mapping between entries (strings) on one side to corresponding
entries (strings) on the other side, i.e. the compression operation
is a string replacement. What is not yet very clear to me are the
set of exact rules that such a mapping must satisfy, in particular
for cases where no valid entries in the dictionary can be found.
The verbatim copying is very likely a misunderstanding on my part.
I expect that the next response from Tim Tyler will make things
clearer for further argumentation.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Tue, 02 Nov 1999 02:43:45 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> Since a TV contains a physical amplifier feeding it zero signal does
not
> generate zero output. The noises from the early stages, e.g., tuner,
get
> amplified even if there is no antenna signal.
>
Same idea applies to audio singals (i.e record at 8khz without an input
source). Although there is only about 1/1000th of a random bit per
sample though. (The entropy is in the lsbs which differ +/- ~4 from
normal of 80h or 8000h)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mr. E. Yankoil)
Crossposted-To: alt.security.scramdisk
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Tue, 02 Nov 1999 02:50:59 GMT
[EMAIL PROTECTED] (Larry Kilgallen) wrote:
>If viewing the source is the only basis for your trust, then you
>have to know that you are better able than Bruce Schneier to tell
>what constitutes proper construction of the software.
>If you view malice from Bruce Schneier as a threat, they you have
>to know that you are able to detect such malice better than Bruce
>Schneier is able to hide that malice.
>I know more about Bruce Schneier than I do about you, and I would
>not be inclined to bet on you in such a competition.
>On the other hand, I know a _lot_ about _myself_, and I would not
>be inclined to bet on myself in your position competing against
>Bruce Schneier.
That doesn't make sense. If the source code for Password Safe is released,
it will be closely examined by not just one other person, but by many
highly competent professional and amateur cryptographers and programmers,
all eager to catch the master in a mistake. Personally I don't stand a
chance of finding irregularities in cryptographic source code, but if the
code is released and discussed on sci.crypt, it will soon become clear to
me and everyone else whether or not it has flaws.
--
"Mr. E. Yankoil" better known as [EMAIL PROTECTED]
01 2 3456789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Mon, 01 Nov 1999 21:52:40 -0500
On Tue, 02 Nov 1999 00:51:16 GMT, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
>> Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>>
>> >It uses modern cryptography, yet I
>> >can talk to joe.blow without knowing a password. Is it safe? I
>would
>> >like to think so. Basically the assumption that good passwords can
>be
>> >easily memorized is long since dead.
>>
>> Well, it is true that you don't need passwords for safety against
>> eavesdroppers.
>
>True but you *can never* truly protect against mitm attacks. If you
>can prove to me how.
>
>> Does your program protect such things as your private key for
>> public-key communications against someone who obtains physical access
>> to your computer? If so, how does it do so without a password? By
>> letting you store it on a floppy disk that you can hide somewhere in
>> an unencrypted form?
>
>Why would I protect against such things? Even PGP can fall quickly
>with a remote malicious virus. What is more likely though, mr Savard.
>Then you enter my house, steal my floppy disk with peekboo, or trick me
>into running a program which can remotely steal anything you want?
Depends. You have a point, but I can set up a virus free system for
encryption for a lot less money that it would take to make my house
burglar proof.
For very high security I would use encrypted private keys, but
unencrypted private keys may be perfectly acceptable for some
purposes.
Encrypted private keys can have another advantage, I don't need to
keep them with me or on my machine at all. Hushmail keeps your
encrypted private key for you and you can access it from any machine
with a suitable browser.
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Tue, 02 Nov 1999 02:47:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : SCOTT19U.ZIP_GUY wrote:
> :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> :> >SCOTT19U.ZIP_GUY wrote:
>
> : Let me repeat: If one has an initial frequency distribution that
> : the analyst can't figure out, then he can't do any compression or
> : decompression properly.
>
> I don't understand.
>
> You're saying that the analyst can't decompress because he lacks
frequency
> information about the distribution of possible plaintexts?
>
> I generally assume that the opponent has the cypher-machine
(including any
> decompressor).
>
> If your are saying "the opponent cannot decompress", are you making
> different assumptions from me?
You could build a random huffman tree for example and use it with your
friend. This would make decompression randomly decrypted ciphertext
awkward to say the least. However randomly created trees are hardly
optimal, and optimal trees are hardly random...
[part of your sig]
> On the other hand, you also have five fingers.
>
This is true.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: need LFSR information
Reply-To: [EMAIL PROTECTED]
Date: Tue, 02 Nov 1999 03:03:48 GMT
On 15 Oct 1999, "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>Scott Nelson wrote:
>> I wrote a program to calculate maximal length LFSR's,
>> using "that chordic nonsense." After 32 bits, it
>> can only find "probable" polys. The list of Probable
>> polys include all maximal length LFSR's but might include
>> a few less-than maximal length polys as well.
>>
>> Hardly the best way to find LFSR's, but it's faster than
>> straight out brute force, and the code's already done.
>> On my Pentium 166, it takes 23 seconds to find all 16 bit LFSR's.
>>
>> For those interested, there's a copy (with source) on my ftp site
>> ftp://helsbreth.org/pub/helsbret/random
>
>The site has not been available. I've tried several times over the last
>~18 hours.
>
I've just updated the program to include all the factors of the
Mersene numbers 2^512-1 or less. For those numbers
(and of course the Mersene primes 521, and 607)
it now proves the polys are maximal. LFSR's larger than 512
are still only "probable."
There's also a striped down version (lfsr_s) which only works
up to <sizeof(long) in bits> but should be easier to understand
and/or port to other machines, and it's faster.
I've also added the search method "once" and fixed the "start at"
feature, so it can now reasonably be used to test existing polys.
I've re-tested all the polys in the first edition
Applied Cryptography and only the ones I listed before we're bad.
(For those few who care, the bad ones are;
33,16,4,1,0 - should be 33,6,4,1,0
82,41,8,7,6,0 - should be 82,41,8,7,6,4,0
98,7,4,3,1,0 - should be 98,7,4,3,2,1,0 or 98,27,0
119,45,0 - should be 119,8,0 or 119,38,0
172,2,0 - should be 172,7,0 )
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Louis <[EMAIL PROTECTED]>
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Tue, 02 Nov 1999 02:55:25 GMT
Proposal: Inexpensive Method of "True Random Data" Generation
The digital camera watching a TV set in a Faraday cage idea doesn't seem
like an inexpensive method!
The idea to "use various system timers to extract data from relative
inaccuracies. Put it through some entropizing algorithm, mix well."
would be extremely slow since the quartz crystals are extremely well
correlated.
>(1) how random is the TV "snow" to start with?
Pretty good, it is generated from amplified electronic noise which is
quite unpredictable.
> (2) what happens when you shoot the snow with the digital cam?
> how random are the digital pictures?
Not a good idea, you loose bandwidth and add some periodic signals.
You'd better take the luminance (intensity) signal directly from the
circuit of your TV.
> (3) what would be a good "mixing, distilling"
> algorithm to be applied to the entropy in the snow-files ?
See below...
> (4) what would the throughput rate be in bits per second?
The bandwith of the luminance is safely one MHz.
> (5) what about automating the procedure so that the
> camera could take say 20,000 pictures a day?
That makes things very slow. The monitor you're looking at right now
can give you 7 million pictures a day!!
A problem with using the signal from a video camera is that it would be
the sum of a "random" part and a periodic part. Suppose for example
that one pixel in your camera does not respond as well to light. Every
time the image scan would pass through that pixel, the random intensity
would be decreased and your random bit would have more chance of being
zero! This would be repeated on every image, always at the same
location.
Here is a general observation for electronically generated noise:
-part of it is truly random,
-part of it is periodic (most likely appears as a periodic modulation of
the output),
-the distribution changes as the circuit is influenced by external
conditions (which may be short term, like someone talking next to the
circuit would induce a mechanical modulation that could influence the
circuit's output, cosmic rays; Long term changes could be changes in
relative humidity which fluctuate with the weather and seasons; and
anything else)
-the random distribution changes as the circuit ages, the change being
partly random, partly predictable (near the end of its life, the circuit
may give a "1" for one million "0"; its entropy throughput is likely to
go down).
Therefore, the "mixing, distilling" algorithm should be able to adapt to
the non-random part of the circuit's output, which is present on every
time scale.
Louis
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: What is the deal with passwords?
Date: 2 Nov 99 03:12:32 GMT
Tom St Denis ([EMAIL PROTECTED]) wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] (John Savard) wrote:
: > Well, it is true that you don't need passwords for safety against
: > eavesdroppers.
: True but you *can never* truly protect against mitm attacks. If you
: can prove to me how.
You got me there. You can't do that without a shared secret, you're quite
correct. But then, since you know that, why are you saying we don't need
passwords?
: Why would I protect against such things? Even PGP can fall quickly
: with a remote malicious virus.
True.
John Savard
------------------------------
** 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
******************************
