Cryptography-Digest Digest #363, Volume #9 Fri, 9 Apr 99 16:13:04 EDT
Contents:
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: True Randomness & The Law Of Large Numbers (Tom Thomson)
Re: KL-43? (David Ross)
Re: Comments to DOJ re NICS (Eric Williams)
Re: Douglas A. Gwyn : True Jerk ("Dann Corbit")
Re: Comments to DOJ re NICS (Paul Rubin)
PGP Time Zone ([EMAIL PROTECTED])
none (Anonymous)
Re: none ("Trevor Jackson, III")
Re: Announce - ScramDisk v2.02h (Terry Ritter)
Re: Wanted: Why not PKzip? (Sundial Services)
Re: Modulo Reduction (Mok-Kong Shen)
Re: Announce - ScramDisk v2.02h (Patrick Juola)
Re: a question about time and DES cracking ("John E. Kuslich")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Fri, 09 Apr 1999 16:41:59 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 09 Apr 1999 10:51:48 -0500, Jim Felling
<[EMAIL PROTECTED]> wrote:
>You are incorrect here. The sampling must be REPRESENTATIVE, any truly random sample
>will
>automatically be representative, but not all representative samples are random.
What is the operative definition of "representative"?
How do you know that the sample you use for the monobit test is
"representative"?
How can just any sequence be considered "representative", especially
in light of the abnormal behavior of the uniform random walk?
There is no specification in FIPS-140 for how the sample was to be
produced, only that it was to come from a sequence of 20,000 bits.
Therefore presumably any sequence is "representative".
What would tell you that a given sequence was not "representative"?
>Since we are
>dealing with a continuous and time independent process any sampling of this should be
>representative.
You need to prove that. I do not accept it a priori - that is, it is
not self-evident. We have seen several instances where attempting such
a prioi reasoning leads to fundamentally wrong results (cf. random
walk).
>thus the statistical conditions are satisfied.
Even that needs to be proven, consistent with your notion of
"representative".
>( Yes , I do know that if due to
>defects our process becomes time dependent that this will ( potentially ) invalidate
>the
>statistical underpinnings of the above condition. However, such time dependence will
>lead to
>correlation between bits which will tend to produce results that in our continuous
>sampling should
>lead to it tripping up on the testing due to the internal correlation.)
As Feller states clearly:
+++++
"Thus, contrary to widespread belief, the time average for any
individual game has nothing to do with the ensemble average at any
given moment."
+++++
And here are some comments of Kolmogorov:
+++++
"In everyday language we call random those phenomena where we cannot
find a regularity allowing us to predict precisely their results.
Generally speaking, there is no ground to believe that random
phenomena should possess any definite probability. Therefore we should
distinguish between randomness proper (as absence of any regularity)
and stochastic randomness (which is the subject of probability
theory). There emerges the problem of finding reasons for the
applicability of the mathematical theory of probability to the real
world".
"The frequency concept based on the limiting frequency as the number
of trials increases to infinity does not contribute anything to
substantiate the application of the results of probability theory to
real practical problems where we always have to deal with a finite
number of trials."
--A. N. Kolmogorov (quoted in Li & Vitanyi)
+++++
These two experts do not accept the stochastic characterization of
randomness.
Bob Knauer
"I am making this trip to Africa because Washington is an international city, just
like Tokyo,
Nigeria or Israel. As mayor, I am an international symbol. Can you deny that to
Africa?"
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (Tom Thomson)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Fri, 09 Apr 99 15:34:20 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
(much longwinded rambling snipped - the paragraph quoted summarises it all
quite adequately.)
>For the Monobit Test, the sample and the distribution are the same
>thing because they are produced by the same process. There is no way
>to distinguish one from the other. If the distribution is not random,
>neither is the sample, in which case the Monobit Test is invalid,
>since it is a statistical test which requires a random sample. But the
>determination that the distribution is not random came from the
>failure to pass an invalid test, and that determination is invalid
>too.
I have to start wondering whether I've fallen down a rabbit hole, whether rck
is one of the mad hatter's aliases. The failure in logic in the above is
astounding.
Look, it's really very simple.
If the distribution is not random, it is not random. It doesn't matter what
the monbit test says - however, in this case it gets it right and says that
there is an unacceptably low probability of it being random. So you can't
claim the test is invalid in that case.
If the sample is random, the monbit test is valid; you can't claim the test is
invalid in that case.
You can't argue "the monobit test is wrong to say the distribution is not
random, because the monobit test doesn't work if the distribution is not
random"; if the distribution is not random and the monobit test says the
distribution is not random, then (by some lucky coincidence) the monobit test
got it right.
If the sample is random, the monbit test is valid. If the monobit test says
that there's a very low probability that this is a random sample from random
distribution, then that is indeed the case. So unless an event of extremely
probability has occurred, either the distribution or the sample is not random.
Since the generating process is the same for both, the sample is random only
if the distribution is random. So an event of very low probability has
occurred.
It is very easy to see that if the monobit test fails, the probability that
the generator is random is low. It may in fact be random, but there is only a
low probability that this is the case; it may be non-random, and the
probability of this is of course the complement of the probability that it is
random.
The are two casse where you can't make a useful deduction from the monobit
test
1) when it says "yes this is probably random" that result can be produced by
a non-random sample from a non-random distribution.
2) when it says "no this is probably not random" that result can be produced
by a nonrandom sample from a random distribution.
The case in question cannot be case 1, since that's not what the monbit test
said. It can't be case 2, since in this experiment the sample is random
whenever the distribution is. So we are in neither of these cases.
Try reading something elementary on logic, preferably with reference to poof
by reduction (and note that this is a case where proof by reduction is valid
even in intuitionistic or constructive mathematics, so you won't find an
escape by that route).
------------------------------
From: [EMAIL PROTECTED] (David Ross)
Subject: Re: KL-43?
Date: Fri, 09 Apr 1999 17:59:09 GMT
On Fri, 09 Apr 1999 15:22:23 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>Dan <[EMAIL PROTECTED]> wrote, in part:
>>Does any one know what ecryption the KL-43 uses??
>
>Probably no one who is allowed to tell you...that sounds like a designation
>used by the U.S. military for a current or recent encryption device.
No telling just how (or in what sequence) the NSA comes up with KL-
& KY- nomenclature.
The KL-43 is a solid-state device with a small LCD & what appears to
be a built-in modem - it was built by TRW in the early '80s.
And yet... the KLB-47 appears to be a rotor-based mechanical cipher
unit built by Teletype Corp. It uses a "Model 28" style keyboard and
a paper strip printer. In the KLB-47 motor subchassis, you'll see a
selenium rectifier stack, a device which passed into history around
1960...
go figure...
David Ross [EMAIL PROTECTED]
------------------------------
From: Eric Williams <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.guns
Subject: Re: Comments to DOJ re NICS
Date: Fri, 09 Apr 1999 10:45:51 -0700
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> Eric Williams <[EMAIL PROTECTED]> wrote:
> >I think there wouldn't be much of a problem getting a random-looking
> >string of letters and digits written down correctly, people would tend
> >to check those things over and make sure they got them right, and we're
> >only talking about 12 characters or so for the signature (which could
> >probably be shortened if need be by only using a thumbnail). Retailers
> >handle more than that much information all the time for credit card
> >verifications.
>
> If you're talking about a public key digital signature, it would
> more typically be about 60 characters (320 bit DSA signature).
> If you mean a secret-key message authentication code (MAC), it could
> be much shorter, but in that case it could only be verified by a person
> or device in possession of the secret key, who could therefore sign
> other documents with it.
Yes, I was thinking of a MAC, thank you for pointing out the
difference. A 64-bit MAC could be represented with about 12 readable
characters. If you want to go to 128-bit (eg: MD5), you're up to about
26 (maybe a couple more if you throw in some check digits), but a
typical credit card verification involves about 20 digits, so that is
not much of a leap.
I think a MAC would be sufficient for this application, the key (or
keys) would remain with DOJ. Since the government is the only party who
is interested in generating and verifying signatures, I don't think the
complexity of a public key system is necessary.
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Douglas A. Gwyn : True Jerk
Date: Fri, 9 Apr 1999 11:31:10 -0700
R. Knauer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 08 Apr 1999 07:45:20 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
>
> >hapticz wrote:
> >> truth is relative.
> >
> >And you're asserting that as an absolute?
> >If not, it's self-defeating.
>
> It is also contradictory.
>
> Bob Knauer
>
> Signature files traditionally present comments from a population with an
IQ over 100.
> I thought it would be appropriate to present comments from the other half
of the population,
> namely the one with an IQ under 100. After all, they do make up 50% of the
human condition.
> Never mind that they also tend to become politicians. Here is a
representative example:
>
> "People blame me because these water mains break, but I ask you, if the
water mains
> didn't break, would it be my responsibility to fix them then? WOULD IT!?!"
> - Marion Barry, Mayor of Washington DC
You have the wrong impression of Mr. Gwyn. He is a frequent and useful
poster to the net, and goes out of his way to be helpful. I read everything
he posts. I suggest you do a DejaNews search of Mr. Gwyn's postings and you
will see that he is a very courteous and helpful person.
Your choice of thread title suggests what about *you*?
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
Crossposted-To: talk.politics.guns
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Comments to DOJ re NICS
Date: Fri, 9 Apr 1999 18:32:25 GMT
In article <[EMAIL PROTECTED]>,
Eric Williams <[EMAIL PROTECTED]> wrote:
>Yes, I was thinking of a MAC, thank you for pointing out the
>difference. A 64-bit MAC could be represented with about 12 readable
>characters. If you want to go to 128-bit (eg: MD5), you're up to about
>26 (maybe a couple more if you throw in some check digits), but a
>typical credit card verification involves about 20 digits, so that is
>not much of a leap.
Actually the scheme you suggested (encrypting a hash) isn't exactly
a MAC in the usual sense, but the idea is the same.
Credit card verifications involve the card number, expiration date,
and amount going in one direction, and a 6-digit authorization code
coming back. Note that at most retailers these days, this is done
automatically--the merchant swipes the card through a reader and keys
in the amount. The authorization code (if approved) is automatically
printed on the ticket. At places with no card reader, they normally
don't phone in the card numbers unless the transaction is over a
certain amount. (Because of the increased exposure, they pay a higher
fee to the card company than if they had a card reader.)
In your system, the stuff going to the DOJ in place of the card number
and expiration date would be *all* the data from the form (name, address,
etc.) plus the MAC. Also, in the case of a field audit of a dealer,
they'd want to verify a whole stack of registrations and not just
a single one. So it's just not workable unless the data is machine
readable. But if it is, it has to get signed by a DOJ computer, so
there's no guarantee that the data wouldn't actually stay there.
>I think a MAC would be sufficient for this application, the key (or
>keys) would remain with DOJ. Since the government is the only party who
>is interested in generating and verifying signatures, I don't think the
>complexity of a public key system is necessary.
I guess that's plausible. It means though that field auditors have
to carry equipment containing the secret key. If the auditors can be
robbed or bribed, the key is vulnerable.
------------------------------
From: [EMAIL PROTECTED]
Subject: PGP Time Zone
Date: Fri, 09 Apr 1999 18:48:08 GMT
Hi,
I would like to know how could I change the time zone of PGP.
Actually I am in GMT tine zone. How could I change it to EDT time zone.
Thanks!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Fri, 9 Apr 1999 18:30:01 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: none
TEST
------------------------------
Date: Fri, 09 Apr 1999 15:36:55 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: none
I seem to have noticed this kind of message just prior to the previous
attacks on this news group. Perhaps we ought to expect one.
Anonymous wrote:
>
> TEST
>
>
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 17:10:12 GMT
On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Andrew Haley) wrote:
>[ Newsgroups list trimmed ]
>
>Lincoln Yeoh ([EMAIL PROTECTED]) wrote:
>
>: I like the idea of superencryption too, and I don't know why so few
>: people seem to like it. So far I have not had a good answer to how
>: an attacker would know if he or she has succeeded.
>
>The answer is simple. Kerckhoff's maxim says that your attacker knows
>the cryptosystem you're using, but does not know the key. If you're
>using superencryption, your attacker knows which systems you're using.
That's fine if you always use the same ciphers in the same order. But
if the ciphers are dynamically selected by keying, or just dynamically
selected frequently by communications under cipher, the attacker does
*not* know "which systems you're using." Kerckhoff's maxim does not
apply.
I suggest that each communication include a small encrypted control
channel, over which a continuous conversation of what ciphers to use
next takes place. This would be an automatic negotiation, somewhat
like occurs in modern modems, from cipher selections approved by the
users (or their security people).
>Of course, your attacker must now analyze the compound cipher, which
>is almost certainly harder to do than than attacking a single cipher.
Yes. Even if each cipher used has known weaknesses, those may not be
exploitable in the multi-ciphering case.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Fri, 09 Apr 1999 09:00:01 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: Re: Wanted: Why not PKzip?
Arthur N. Klassen wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Because its encryption is incredibly weak (known plaintext).
>
> I've been thinking about this one... Isn't this mainly a concern for
> people trying to protect Zip-encrypted install-sets from pirates (as
> spamless' example at the end of that post suggested)? or are there eight
> bytes of boilerplate to be had in any zip-compressed file?
>
> Methinks I should do some research here, but I would be willing to guess
> that totally unique files not disclosed anywhere else could be "safely
> enough" encrypted using Zip + passphrase. Am I out to lunch here?
More or less, yes you are, Arthur. ;-) ;-) There is a definite need
for secure self-extracting compressed files, but PKZIP cannot provide
it. I understand that there are programs in development that would
allow you to place a truly secure self-extracting wrapper around a file,
or perhaps a ZIP. Placed in such an "outer envelope" a file would be
secure. But definitely not with ZIP alone.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Modulo Reduction
Date: Fri, 09 Apr 1999 20:39:50 +0200
Sassa wrote:
>
> > Can anybody help me with modulo arithmetic dealing with large numbers?
> > e.g. 1621^133 mod 2419 = ?
>
> these are not too large numbers.
> at least can be calculated with pocket calculator:
>
> 1621^133 mod 2419 = (((1621 mod 2419)*1621 mod 2419)*1621 mod 2419).. mod 2419
One can under circumstances make good use of short cuts.
1621^2 mod 2419 = 607 hence 1621^133 mod 2419 = 607^66*1621 mod 2419.
607^2 mod 2419 = 761 hence
1621^133 mod 2419 = 761^33*1621 mod 2419
761^3 mod 2419 = 728 etc. etc.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Announce - ScramDisk v2.02h
Date: 9 Apr 1999 13:16:35 -0500
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>
>On 9 Apr 1999 11:10:56 GMT, in <7ekn80$kc1$[EMAIL PROTECTED]>, in
>sci.crypt [EMAIL PROTECTED] (Andrew Haley) wrote:
>
>>[ Newsgroups list trimmed ]
>>
>>Lincoln Yeoh ([EMAIL PROTECTED]) wrote:
>>
>>: I like the idea of superencryption too, and I don't know why so few
>>: people seem to like it. So far I have not had a good answer to how
>>: an attacker would know if he or she has succeeded.
>>
>>The answer is simple. Kerckhoff's maxim says that your attacker knows
>>the cryptosystem you're using, but does not know the key. If you're
>>using superencryption, your attacker knows which systems you're using.
>
>That's fine if you always use the same ciphers in the same order. But
>if the ciphers are dynamically selected by keying, or just dynamically
>selected frequently by communications under cipher, the attacker does
>*not* know "which systems you're using." Kerckhoff's maxim does not
>apply.
Unfortunately, this isn't the case.
If the system is dynamically selected by keying, then the exact
selection becomes part of the key. If you are taking a set of cyphers
and reordering them, Kerchoff's maxim suggests that you have to assume
that the attacker knows the set of cyphers and just doesn't know
the order.
-kitten
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: a question about time and DES cracking
Date: Fri, 09 Apr 1999 13:06:08 -0600
Not true if you have special hardware to do the brute force crack AND you approach
the problem properly.
Take Word 8 and Excel 8 for instance. There are many many more passwords than
there are keys. The RC4 encryption and MD5 (modified) hash used here result in a
key space of 40 bits but a password space that is zillions of times larger. True,
some of the passwords are duplicates, but not enough so that a brute force
password search is not ridiculous.
A key search, on the other hand, is a very reasonable proposition given the proper
hardware. At CRAK Software we can search the entire Word 8 and Excel 8 keyspace
at a rate of a few million keys per second. This gives an exhaustive search for
all possible keys in a few days. Adios 40 bit RC4 encryption!
Visit http://www.crak.com for details on how it is done.
JK
Sundial Services wrote:
> Steve wrote:
> >
> > The length of time required depends on the cracks/second that John is
> > running at and the keyset & keylength that you are running at.
> > i.e.:
> >
> > running at 50k cracks/second
> > 1-6 character passwords, all lowercase: time in seconds = 26^6/50000
> > figure it out.
> > >
> > >i'm running john the ripper DES cracker on my home linux password file.
> > >
> > >i have to say that i'm extremely surprised to see how slowly the
> > >incremental cracker works. it's been working for weeks, and i've only
> > >obtained about 10 cracked passwords.
> > >
> > >does anybody know any order of magnitude estimates on unix password hacking
> > >and time on a typical pentium II/300? are we talking decades, years or
> > >months?
>
> It sounds like DES is doing its job. Brute-force cracking of any
> reasonable password scheme is truly a waste of time.
--
CRAK Software (Password Recovery Software)
Http://www.crak.com
[EMAIL PROTECTED]
602 863 9274 or 1 800 505 2725 In the USA
------------------------------
** 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
******************************
