Cryptography-Digest Digest #265, Volume #9 Mon, 22 Mar 99 12:13:03 EST
Contents:
Re: RC4 file encryptor (please take a look) (Bryan G. Olson; CMSC (G))
Re: SHS (Sha) (Bryan G. Olson; CMSC (G))
Re: Testing Algorithm (hash) (Bryan G. Olson; CMSC (G))
Test Vectors ("Tim Fowle")
Re: Random Walk (R. Knauer)
Re: Random Walk (R. Knauer)
Re: Is TEA Algorithm safe???? (Mark Carroll)
Re: Random Walk (R. Knauer)
Re: RC4 file encryptor (please take a look) ([EMAIL PROTECTED])
Re: Newbie, what a stupid term... ("Tim Mavers")
Re: Newbie, what a stupid term... (John Savard)
Re: Random Walk (Herman Rubin)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Doug Stell)
can not open pgp.cfg ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G))
Subject: Re: RC4 file encryptor (please take a look)
Date: 22 Mar 1999 10:25:49 GMT
[EMAIL PROTECTED] wrote:
: You're right I used the wrong term. It should read public/private
: portions of the key.
Cryptographers call the value combined with the master key "salt".
I dislike the method. First, I don't see why anyone would want to
throw out password entropy, as the get_public_key function does.
Second, we can easily derive a session key from the
passphrase and a one-time salt, so there's no motivation for
the non-portable and inconvenient mouse-based randomness
generator.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G))
Subject: Re: SHS (Sha)
Date: 22 Mar 1999 10:50:54 GMT
[EMAIL PROTECTED] wrote:
: that's the one. The problem is I can't read the sub-script text. If anyone
: has a .TXT translation I could use that.
You can find it in several formats, including .txt at:
http://csrc.ncsl.nist.gov/fips/
--Bryan
------------------------------
From: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G))
Subject: Re: Testing Algorithm (hash)
Date: 22 Mar 1999 11:16:19 GMT
[EMAIL PROTECTED] wrote:
: BTW, is that book really that good? I have only heard good things
: about it, which is why I want to get it.
Yes, /Applied Cryptography/ is an excellent book, and quite
readable.
If you intend to do crypto implementation, then there's another
book you cannot afford to be without: the (unfortunately)
similarly titled /Handbook of Applied Cryptography/ by Menezes,
van Oorshot and Vanstone, CRC Press, 1997.
--Bryan
------------------------------
From: "Tim Fowle" <[EMAIL PROTECTED]>
Subject: Test Vectors
Date: Mon, 22 Mar 1999 11:30:51 -0000
Not sure if this might be a good idea but a group (say
sci.crypt.Test.vectors) specifically for test vectors. It something that
people (including myself) are after every now and then when they try new
code.
Could also keep some longer binary tests there without annoying people.
Anyone else want it?
(PS if this has be talked about before or already exists just ignore me)
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Mon, 22 Mar 1999 13:13:01 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 21 Mar 1999 18:13:15 -0700, Shawn Willden <[EMAIL PROTECTED]>
wrote:
>(1) Why are you using a random walk as the model for a random number
>generation process?
I am not. I have never proposed using the random walk as a model for
crypto-grade random number generation.
I am using the random walk as an example of how one can be deceived by
naive intuition and a false belief in the vague notion of the "law of
averages".
I have consistently (and obsessently) stated that crypto-grade random
numbers are those produced by a TRNG, which is a process that is
capablel of generating all possible finite sequences equiprobably,
namely in an independent and equidistributed manner.
If the random walk fails that specification, then it is unsuitable for
a TRNG.
>It's a rather poor one, as it imposes severe
>constraints on the relationship between one output and the next. Further,
>it contains a concept of infinite memory which should definitely *not* be
>a characteristic of a RNG.
The uniform one-dimensional random walk is the same as the uniform
Bernoulli process in terms of how the bits of the sequence are
generated. The UBP is the same as the so-called "fair coin toss",
which has been used extensively to model random processes.
A year ago in these same discussions, someone commented that the UBP
is not a good model for generating crypto-grade random numbers - but I
do not recall the reason why he said that. Repeated attempts to get
people to comment on why the UBP may not be suitable has fallen on
deaf ears. Perhaps the reason for not accepting the UBP as a model for
the TRNG is the fact that it will not meet the specification unless p
= q = 1/2 perfectly, which we know is impossible for even the most
carefully built TRNG.
Do you have reasons why you think the UBP is not suitable to the
generation of crypto-grade random numbers based on the specification
above? If so, please let us know your considered thought based on
concrete reasoning, with references too.
>(2) If you are not, in fact, looking at the output of the random walk
>process, but rather trying to point to some attributes of the underlying
>random variable by analyzing a random walk produced by that variable, why
>are you doing this, and can you make your point more clearly? I
>understood the quotes from the book regarding the supposed
>counter-intuitiveness of the behavior of random walk processes, but your
>conclusion is not obvious to me. I'm not saying you're wrong, just that
>you haven't made your argument well.
I am not offering any arguments. I am merely quoting what I read in
books. In Li & Vitanyi, for example, I read several times that
attempts to characterize random numbers, or the processes that
generate them, with statisitical tests are futile. Even Kolmogorov
himself chimes in with the same sort of comments.
The reason that I personally offered, which apparently you missed in
my post the other day, is as follows. It is an accepted fact that one
cannot generate random numbers algorithmically. But, if you could use
algorithmic statistical tests to decide whether numbers were being
produced randomly, then you could use those algorithms to generate
random numbers, which contradicts the original premise.
One simple method of doing that would be to subject the output of PRNG
to statistical tests and output those that succeed and reject those
that fail. The digit expansion of pi would make a good PRNG for that
purpose because most of the output has the appearance of randomness
according to statistical testing.
Another way to put all this is that because statistical tests are
algorithmic in nature, they are really nothing more than tests for
pseudo-randomness. And we know that pseudo-randomness is not good
enough for crypto-grade randomness.
>(3) What does the fact that decimal expansions of transcendentals have
>certain statistical properties have to do with whether or not those same
>properties are to be expected in good RNGs?
My contention (based primarily on the comments of others) is that if I
gave you the output of the expansions (not necessarily just the
decimal expansion) of these transcendentals, you would consider them
random based on statistical tests. That is, they have the *appearance*
of randomness based on pseudo-random statistical tests.
>For an RNG to be any good it has to produce output that is unpredictable.
Unfortunately the criterion of "unpredictability" is too vague to be
of any analytical value other than a qualitative guide to the motive
behind crypto. The reason is that obscurity can also pass for
unpredictability, and we know that is not a good way to build
cryptosystems. Unpredictability is an intuitive notion, and therefore
cannot serve as a formal specification. It is very valuable in guiding
you to the formal specification, since whatever it is that makes
numbers crypto-grade random also makes them unpredictable.
The best specification for a crypto-grade random number generator that
I am aware of is that it is capable of generating all possible finite
sequences equiprobably, namely in an independent and equidistributed
manner. With that specification for crypto-grade randomness, the
cryptanalyst can have no reasonable certainty that the plaintext he
has decrypted is the intended message, because it is just one possible
plaintext out of a sample space of 2^N equiprobable plaintexts of
length N.
Bob Knauer
"If you think health care is expensive now, wait until it's FREE!"
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Mon, 22 Mar 1999 13:29:01 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 22 Mar 1999 03:59:43 GMT, karl malbrain <[EMAIL PROTECTED]>
wrote:
>> The surest way to contract a major illness or get into a condition
>> poor health is to have lots of money from insurance. If you are not
>> ill before you get treatment, you sure as hell will be afterwards.
>No, sorry, but illness is NOT contracted from having any sum of money. As
>example from the reverse: check the TUBERCULOSIS infection rate among those
>WITHOUT enough money to afford adequate VENTILATION/HOUSING. And I believe
>that you can check CDC-ATLANTA for bacterial transmission rates to hospital
>in- patients (assuming that was YOUR reference at all.)
Consider this news item from the AP:
+++++
(HOUSTON) -- Hospitals in Houston are sending out letters to
former patients who may have been exposed to Hepatitis C in blood
transfusions as far back as 11 years ago. Some of those who could have
picked up the virus in the transfusions may not show signs of illness.
Hospitals across the country are sending out letters as ordered by the
U.S. Department of Health and Human Services more than a year ago. Up
to 300, 000 people may have been exposed. Hepatitis C is a potentially
lethal liver disease.
+++++
It looks like people who had money for expensive operations got
transfusions and therefore got zapped by hepatitus, whereas people who
could not afford luxury operations did not get transfusions and were
spared.
>> >And again to the CAESARS -- not everyone was GIVEN the GIFT of learning to
>> >read in the first place. TENSOR CALCULUS was as applicable then as now.
>> Yes, but it was not known at that time.
>That is total BULLSHIT. The mechanics of MATHEMATICS have been widely known
>since HUNTER-GATHERORS became FARMERS, 5K or so years ago.
Are you suggesting that hunter-gatherers were doing tensor calculus on
their clay tablets? Please, gimme a break willya.
>I might suggest you catch up on missed titles: CONNECTIONS by James Burke.
I have read similar books on the "law of unintended consequences" and
they make for enjoyable reading. But that does not mean that the
people in Caersar's day could break the Caesar cipher easily.
One day we will be able to factor the product of large prime numbers
with quantum computers. When that finally happens, it is not correct
to look back and say that we were enabled earlier because the
machinery was there to do it and all we had to do was put the pieces
together correctly.
The worldview espoused by existential metaphysics demands the concrete
actualization of a potential act for it to be real.
Bob Knauer
"If you think health care is expensive now, wait until it's FREE!"
------------------------------
From: [EMAIL PROTECTED] (Mark Carroll)
Subject: Re: Is TEA Algorithm safe????
Date: 22 Mar 1999 13:36:28 +0000 (GMT)
In article <7cs0s9$5kk$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Mark Carroll) writes:
>>In article <[EMAIL PROTECTED]>, melih <[EMAIL PROTECTED]> wrote:
>>>Can anyone tell me if TEA algorithm is safe (I am told it is not safe
>>>however the reason as to why is what I am after).
>>>
>>>If not, does TEA Extensions solve the problems that made the TEA unsafe?
>>
>>I can't remember what the breaks are but the papers seem fairly
>>well-known. Nothing too damning, but enough.
>
>enough under what assumptions? i mean if your threat model does not include
>the NSA or anyone with a major bankroll and you want a fast cipher would
>TEA still be acceptable?
XTEA would probably still be a better option - it's still fast - but
for most purposes I'd say yes to TEA too, unless you want the data to
be secure for a long time or you anticipate anything more than a
casual attack. I suppose you could even bump the number of rounds up
by three or something to make it more awkward for an attacker who knew
what the standard results against TEA were but didn't know how to
extend them appropriately. (Maybe the result about some keys being the
same as others would still stand and be easily verified though.)
But, yes, you're right, the threat model is everything. I would expect
TEA to be secure against a few weeks' work by a competent attacker for
some time yet, but we all know that such predictions are pretty
dangerous in this game. (-: If you can be bothered, and don't mind
a bit of the plaintext being discovered, I suppose you could chain
the TEA-encrypted blocks with the occasional IDEA-encrypted block
(with a different key), so you get pretty good speed overall but
more security.
Or, am I hopelessly mistaken and you gain no extra security at all no
matter how you chain blocks together? If so, expect many followups to
correct me. (-: I'm just thinking out loud here...
-- Mark
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Mon, 22 Mar 1999 13:46:39 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 22 Mar 1999 07:19:29 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>> Oh, come on - read Feller, fer chrissakes. It's all there.
>I did read Feller, certainly before you did, probably before you
>were born.
Hey, dude - don't pull rank on me. I was already grown up before you
were no more than a lascivious look in your father's eye.
>It was a classic work, widely used as a general
>reference for basic applications of probability theory in Agency
>articles decades ago.
Which edition did you read? You are aware that Feller made significant
revisions in the 3rd edition. It is the 3rd edition that I am
referring to.
>And I take exception to your distortion of the legitimate point he was making.
You can huff and puff all you want, but that will do no good.
Give us reasons to believe your contention. And while you are at it,
give me reasons that my contention is incorrect. Here - I will present
it one more time:
If statistical tests could be used to characterize a process as
random, they could be used to generate random numbers from that very
process it has characterized as random.
For example, all that would be needed to generate random numbers
algorithmically would be to pass the output of a pseudo-random number
generator thru the statistical tests and accept that output which
passes those tests and reject that output that fails those tests.
Statistical tests by their very nature a algorithms. They are only
tests for pseudo-randomness - that is, they only test for the
*appearance* of randomness based on some pre-conceived notion of what
constitutes randomness - such as the lack of 1-bit bias or whatever
other algorithmic criterion one can concoct.
I realize that appeals to authority are weak, but I did adapt that
argument above from the comments made by Kolmogorov as quoted and
expounded upon in Li & Vitanyi's book on Kolmogorov Complexity. I also
tapped heavily on the considerations of modern physicists, and quoted
several comments from Williams & Clearwater's book on quantum
computing. Now I am adding Feller's comments as new arrows to my
quiver.
Now stop all that blustering and pontification and tell us in
unequivocal terms what is wrong with maintianing the position that I
hold. But plan on jumping up high if you do, because I am standing on
the shoulders of giants.
Bob Knauer
"If you think health care is expensive now, wait until it's FREE!"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 file encryptor (please take a look)
Date: Mon, 22 Mar 1999 13:46:22 GMT
>
> I dislike the method. First, I don't see why anyone would want to
> throw out password entropy, as the get_public_key function does.
>
> Second, we can easily derive a session key from the
> passphrase and a one-time salt, so there's no motivation for
> the non-portable and inconvenient mouse-based randomness
> generator.
If you (for example) hash your password and use that as a salt, you provide
another method of checking for valid passwords. You should really hash
something else. The mouse was the best easy idea I cam up with.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Tim Mavers" <[EMAIL PROTECTED]>
Subject: Re: Newbie, what a stupid term...
Date: 22 Mar 1999 10:33:08 -0600
Shawn Willden wrote in message <[EMAIL PROTECTED]>...
>More usefully, an attacker could take a dictionary, hash every word in it
and
>then just match the resulting hashes against the contents of a system's
>password file. He's almost guaranteed to get a few hits.
>The salts makes all of this significantly harder by ensuring that there are
a
>large number of different encryptions of a given password. If users then
>choose reasonably good passwords, the attacker will find it very difficult
to
>guess passwords.
But I though the salt value (in it's native form) is also stored along with
the password (at least in the examples previously given in this thread).
Doesn't that negate any "randomness", e.g.:
My password is stored in ciphertext
The salt value is also stored
A hacker could then run a dictionary hash using the salt value above. I
must be missing something.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Newbie, what a stupid term...
Date: Mon, 22 Mar 1999 16:32:39 GMT
[EMAIL PROTECTED] (Myself) wrote, in part:
>On 21 Mar 99 20:14:47 GMT, thermal and electromagnetic action caused
>[EMAIL PROTECTED] ()'s brain to produce the following pseudorandom
>thought:
>>The next time the password is typed in, the computer can check that it is
>>right, because in the password file the computer has kept both a copy of
>>the one-way-scrambled password and salt combination and a copy of the salt
>>value.
>So if the salt value is saved, what's the point in computing it in the
>first place? I've been trying to understand this for some time, and I
>think I must be missing some basic point. Does it just throw in extra
>bits so it has something longer to hash, because of a weakness in the
>hash function?
>>Hence, with the salt and the password, it just does the scrambling over
>>again, to see that it gets the same scrambled result as before. It doesn't
>>try to unscramble, because that can't be done.
>How would this be different than if the salt had been left out
>completely, and the password been hashed by itself?
Well, the salt overcomes a weakness in the *password*; there might not be
enough possible passwords to prevent someone from trying them all.
But if the salt is known, won't that mean that one still has the same
number of passwords to try?
Yes: if one is aiming at finding *one* password. But if one is aiming at
looking at a -lot- of passwords (because some people will be careful enough
to use a password that isn't just a word in the dictionary) then one needs
to precompute the hashes of these words ... for every possible salt value.
John Savard
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Random Walk
Date: 22 Mar 1999 11:29:12 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Sun, 21 Mar 1999 20:37:28 -0500, "Trevor Jackson, III"
><[EMAIL PROTECTED]> wrote:
>>The Rand Tables are not "true random". Far from it. They were heavily
>>conditioned during and fater the generation process.
>Then take that up with Feller.
Feller was a theoretical probabilist. How could he judge that
the thermal noise process was turning out independent bits of
equal probabilities without testing?
They are physical random numbers, but the independence and
equidistribution properties were not that good. There was a
modification made, which improved this; however, the large
use of them to generate random data did not look very random.
Whether this would have been a liability for cryptographic purposes,
I do not know. But it was more than statistically significant, it
was statistically striking.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: Mon, 22 Mar 1999 15:19:47 GMT
On Sat, 20 Mar 1999 03:46:01 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>John Savard wrote:
>> The use of KEA with FORTEZZA at least appears to indicate that the NSA now
>> trusts public key methods - with *unclassified*, but sensitive,
>> information.
Initially, some of us thought the above statement was meant as a joke.
>Actually, the STU-III secure phone system has for many years used
>a nice scheme ...
In Whit Diffie's landmark paper, "The First Ten Years of Public Key
Cryptography," he gives the cover name of the algorithm and has a
picture of the STU-III. The algorithm was described as "The
Government's extensions to public key cryptography suitable for
handling classified information" or something very much like that. To
my knowledge. this was the only statement that could be made about the
algorithm, which I first encountered over 15 years ago.
>... whereby the users have "crypto ignition keys" where
>the private key is embedded in an on-CIK chip,
Actually the private key is "split" between the phone and the CIK.
Therefore, the CIK works only in one phone. The CIK, if compromised,
is useless by itself.
>...multiple levels of access are distinguished (the highest one is
>displayed on the remote unit),
It does contain clearance levels in the certificates and displays the
highest level of the intersecton of the ranges in the certificates.
>...and a Key Management Center is used to disown
>compromised CIKs.
It does use a Compromised Key List (CKL), which is a primative form
of a CRL. The CKL is issued by the NSA's Central Facility.
>Unfortunately the details of the algorithms
>don't seem to have yet been openly published.
True. The algorithms used for classified traffic are themselves
classified. Only the cover names are unclassified.
------------------------------
From: [EMAIL PROTECTED]
Subject: can not open pgp.cfg
Date: Mon, 22 Mar 1999 15:48:44 GMT
Hi, I have PGP 5.0 on Unix. I would like to know why the file pgp.cfg is not
installed. Everything seems OK when I compiled source code. How should i do to
create pgp.cfg file.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
