Cryptography-Digest Digest #284, Volume #10 Tue, 21 Sep 99 03:13:03 EDT
Contents:
Re: Glossary of undefineable crypto terms (was Re: Ritter's paper) (Mok-Kong Shen)
Re: Second "_NSAKey" (Greg)
Re: Second "_NSAKey" (Greg)
Re: Second "_NSAKey" (Greg)
Re: Clinton Administration Continues to BS on Encryption Export Regs (Greg)
Re: Yarrow: a problem -- am I imagining it? (Scott Nelson)
Re: Clinton Administration Continues to BS on Encryption Export Regs (Greg)
RSA encryption algorithm. (Jeremy Botha)
Re: Second "_NSAKey" (Greg)
Re: Yarrow: a problem -- am I imagining it? (Eric Lee Green)
Re: some information theory (Anti-Spam)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Glossary of undefineable crypto terms (was Re: Ritter's paper)
Date: Tue, 21 Sep 1999 06:56:59 +0200
Joseph Ashwood wrote:
>
> [snip]
> > How 'hard' are these REALLY? A citation from A. Salomaa says that
> > there are no provable lower bounds for the amount of work of
> > a cryptoanalyst analysing a public-key cryptosystem.
> There can be no lower bounds or upper bounds placed on human cognition,
> simply because we do not understand it. If you are talking about lower
> bounds of the work necessary to break a public key, it is trivial to prove
> that no common method could possibly drop below O(n), where n is the length
> of the key, this is because you obviously must read the key before you can
> break the key, outside of that I am not aware of any progress.
>
If I understood correctly, you are saying what Salomaa wrote was
nonsense.
M. K. Shen
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:42:02 GMT
> Does anyone want to explain how this purported "back door"
> operates, even if the NSA does hold the matching private key
> (MS claim they don't)?
Let's say you are the NSA and you want to stop my encryption
from keeping your eyes shut to my e-mail. You slip in (and who
is to say MS has not provided this means either?) your own CPDLL
that will broadcast to your covert site my plain text in simply
crypto, but it also encrypts as it normally would. You have
now a CPDLL operating off the NSA key that does more than encrypt-
it spills the plain text to the NSA.
> I believe that even if the NSA has the key, it doesn't further
> weaken the already fatally flawed MS operating systems
I agree...
> (in other words, to use the NSAkey requires greater access
> to the machine than can be gained from using the key).
But you assume it is hard for them. What if MS made it easy?
>I also believe that the good folks at Cryptonym know that,
> but didn't want to let the facts get in the way of a good story.
It is more than a good story. It represents conspiracy to commit
fraud between MS and NSA. This is obvious.
> Why do so many people wishing to defend intellectual freedom undermine
> their case by using political/nonrational statements as weapons?
Because it's fun? :)
No, seriously, this is one time NSA has been caught with its
pants down. And for all we know, someone at MS allowed the
symbols to ship in hopes it would be discovered. Perhaps they
resent big brother?
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 05:02:19 GMT
> > It was interesting to see that there is a third key in the test
> > versions of Win2K.
>
> I found this to be the only credible claim in their statement.
Let me guess: _KGBKEY!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 05:10:05 GMT
> > > AFAI can tell, there is no explanation of what the
> > > second key could do that the primary key could not do.
> > Due to quality control, getting a CSP signed by the primary
> > key is much more bureaucratic than possibly was desired
> > during the technical review.
> OK, assume that two keys are used for efficiency reasons.
> Like the developers get one so they can diddle around with
> modules and not threaten the master corporate key. In this
> and all like scenarios Microsoft(tm) would simply say so.
> They haven't. They issued a stupendously silly exuse.
This scenario would never happen like we see the evidence today.
For example, if a weak access point were exposed, it would not
find its way into shipment, or the primary key would be useless.
Second, if it were by some strange chance to find its way into
shipment, then it would not find its way into shipment for
all 32 bit operating systems. Obviously, it is not to help
test anything or it would not be there in ship builds everywhere.
> > > ... Thus there must be some reason they want to hide the actual
> > > capabilities of the second key.
> >
> > No, we know what the capabilities of the backup key are, by an
> > examination of the object code where that key is used. It acts
> > the same as the primary key (in authenticating a module), after
> > the primary key has failed to authenticate.
When it comes to highly sensitive aspects of any OS, this makes
no sense at all.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: Clinton Administration Continues to BS on Encryption Export Regs
Date: Tue, 21 Sep 1999 06:06:06 GMT
> > The US government is threatening every American with arrest, jail,
> > forfeiture of money and property, and even death if any American
> > defies their misguided restrictions on encryption.
>
> No, they're not. When you make such hysterical exaggerations,
> people tend to discount whatever else you're saying, too.
Yes, they are. Ask Zimmerman.
> > WE have a democracy with the right to privacy, peaceful assembly,
> > free speech, and justice.
>
> The government of the US is *not* a "democracy". Nor should it be.
Unless you want to tyranny the people. I would say it like this:
democracy- two wolves and a lamb deciding lunch.
republic- a land with laws preventing a vote on lunch
representative republic- representatives looking out
for the interests of their respective flocks
and trying not to allow a vote on lunch to
occur or at least provide alternatives
that might appeas the wolves.
Welfare State- the means to get the lambs to want a
democracy.
I sort of changed this a little from another post I saw somewhere.
> > Restricting encryption is a clear attempt to destroy democracy ...
>
> No, it's an attempt for the people in power to gain even more
> control over the populace. "Destroying democracy" is unlikely
> to have been even an implicit goal.
Actually, Stalin & Hitler strove to build democracies in their lands.
Democracies allowed them to violate the civil rights of small
groups of people. In a democracy, there is no appeal to the
mob vote. That is why Hitler did so well against the Jews.
In America, it is becoming class envy warfare. The haves v. the
have nots. And this is widening, so I suspect they will exploit it
further using democracy as a club for every one to hit each other
over the head with.
Look at the UN security council. It is a pure democracy. They
have the final say in the world. There is no world court for
anyone to appeal to. Iraq could not appeal anything done to it.
In the case of Iraq, the cause seems good. But this power can
be used against minorities without just cause. Give it time.
The UN is getting out of control more and more, and it is just
a matter of time.
I gotta tell you, I feel for the feds. They really have a legit
task at hand that requires peeping into e-mail. They have to
find evidence of criminal and terrorist activity in and around
America. But when they go around killing children at Waco just
to serve a warrant against the leader, or when they kill a mother
in Ruby Ridge while she holds her infant daughter, then you have
to ask, is it just the terrorists they are aiming at?
I for one have absolutely zero trust in any government official.
Do they trust me to go down to the store and buy a gun without
doing any paper work at all? No. So why should I trust
them with my military, my tax dollars, my laws, etc.?
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Yarrow: a problem -- am I imagining it?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Sep 1999 06:00:22 GMT
On 20 Sep 1999 20:39:08 -0700, [EMAIL PROTECTED]
(David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>> It does make me wonder though, why Yarrow didn't use
>> SHA1(160bit counter + 160 bit key) as the final output.
>
>This is a bad idea.
>
>It requires very strong assumptions about SHA1 if the resulting
>construction is to be secure, and I don't think those particular
>assumptions have received much scrutiny.
>
>Triple-DES is far better.
If it were a choice between Triple-DES and SHA1,
that might be true, though I'd like to know what
"very strong assumptions" you're referring to.
But Yarrow currently bases it's security on both
3DES and SHA1. Dropping 3DES from the loop would
make the code smaller and faster, and on the surface
it seems to make it more secure. I assume that
Counterpane had a really good reason for including it,
not just vague fears that SHA1 was less secure.
I.e. which of the desired properties for the
block-cipher does 3DES do better?
. It is resistant to known-plaintext and chosen-
plaintext attacks, even those requiring enormous
numbers of plaintexts and their corresponding
ciphertexts,
. Good statistical properties of outputs, even given
highly patterned inputs.
Or was there some other important factor which they
didn't mention in the documentation?
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: Clinton Administration Continues to BS on Encryption Export Regs
Date: Tue, 21 Sep 1999 05:47:46 GMT
> You cannot flip a coin and have it land BOTH heads and tails. The
> Administration's stalling tactics continue.
I am not sure what you mean. Did they change their minds again?
If so, that is good, because their announcement to relax strong
encryption exports was non sense. As long as they have the right
to examine the software to issue a license for its export, it is
meaningless and compromised in the very nature of the process.
> I am not going to be satisfied until this Administration and this
> Government Unconditionally Surrenders all of its objections to
> unrestricted encryption.
Imagine if everyone used overwhelmingly strong crypto. We could
put Project Echelon out of business and there would be no such
thing as a secured web server since every web server would be
secure.
> The Catholic Church has backed down over the centuries on the Earth
> being the center of the universe, the Heavens revolving around the
> Earth, the "tenet" of there being no such thing as action at a
distance
> (radio waves), "Man" being gods special unique creation in the
Universe
> (life existing only on Earth), birth control, evolution, etc.
>
> This Administration and this government must not be allowed to
continue
> to restrict encryption in any manner whatsoever.
Or gun rights for that matter...
> This Administration must be persuaded to accept advances in
technology
> and the discovery of new information just like the Church. We do not
> need violent repression from this government any more than we need
> violent repression from the church.
You go guy! How do you intend to change their minds?
>
> The US government is threatening every American with arrest, jail,
> forfeiture of money and property, and even death if any American
> defies their misguided restrictions on encryption.
You almost think we were the enemy of the state? Oh, I forgot.
We are the enemy, according to the 1933 amendment to the 1913
trading with the enemy act. Now it makes sense.
>
> WE have a democracy with the right to privacy, peaceful assembly,
free
> speech, and justice.
Excuse me. Democracy is two wolves and a lamb deciding lunch.
We have a republic with democratically elected representatives.
>
> Restricting encryption is a clear attempt to destroy democracy with
the
> right to privacy, peaceful assembly, free speech, and justice.
No it isn't. It is a clear attempt to violate to tyranny.
>
> You either have it or you don't.
Well I sure don't got it, do you? :)
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jeremy Botha <[EMAIL PROTECTED]>
Subject: RSA encryption algorithm.
Date: 21 Sep 1999 05:57:31 GMT
Hi all.
I'm currently trying to code a single-byte-at-a-time RSA encryptor /
decryptor. Basically, you give it N and the public key (where N is the
modulus of the public and private keys) and it calculates possible private
keys, then proceeds to test them. (Yes, this is arb)
My problem is that I'm trying to code this in C/C++, and encryption /
decryption requires *huge* numbers. I've tried long ints, long long ints,
and finally in a fit of desperation, doubles. doubles seem to work okay,
apart from the irritating fact that they loose precision, so when I decrypt
the cypher it doesn't return to plaintext.
Has anyone here tried anything in a similar vein? If so, I'd appreciate
some pointers on what I can do to stop the program misbehaving.
Jeremy
--
Jeremy Botha ([EMAIL PROTECTED])
"Emacs sucks, vi forever!"
===== BEGIN GEEK CODE BLOCK =====
d+(-) s++ a-- C++ UL++ P+ L++ E--- W-- N++ K+ w-- PS+ PE
y+ PGP t+ 5++ x R+ tv b++++ DI++ D++ G e++ h-- r++ y?
====== END GEEK CODE BLOCK ======
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 05:14:33 GMT
> There's probably no way to resolve the difference unless
> more facts are forthcoming.
Wait a minute. What about the obvious? It cannot be a test
key because it shows up in every ship build of every 32 bit
OS. We can rule that out.
It is not a Microsoft key. They would not need two in case
they lost the first. We can rule that out.
Let's see. Can it be that NSA wanted a way to replace a MS
signed CPDLL with their own and not let anyone know, including
MS? That makes sense given all the facts. It is the only
obvious conclusion one can draw. It is the only one. I would
put money on it.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Yarrow: a problem -- am I imagining it?
Date: Mon, 20 Sep 1999 22:57:57 -0700
> Eric,
>
> I have a question regarding the design of Ocotillo. After gathering
> entropy to key the block cipher during initialization, Ocotillo uses
> any additional entropy that accumulates to perturb the counter used as
> the input to the block cipher. Why does Octillo use this accumulated
> entropy to perturb the counter used as input to the cipher as opposed
> to using the entropy to rekey the cipher?
There are two basic problems there:
1) estimation of how much entropy has been gathered. It doesn't do much
good to rekey the cipher with only a few bits of entropy (see the Yarrow
paper) because that can be easily attacked via predictive methods.
2) Gathering adequate entropy in order to rekey the cipher.
In actual deployments I do recommend rekeying the cipher when 128 bits
of "fresh" entropy have been gathered. For the particular application
that Ocotillo was originally written for, I calculated that I would be
long finished with the PRNG by the time that 128 bits of "fresh" entropy
had been gathered, and thus did not bother implementing that portion of
the code.
I will most probably implement that portion of the code, however, for a
server application that has to issue possibly thousands of session keys
during the course of a day. This second application of Ocotillo is
interactive in nature, will run on Linux and FreeBSD as its initial
platforms so will have access to /dev/random (we may eventually do a
port to Solaris and SCO Unix since they are our two biggest other
platforms, but I don't envision ever porting that application to the
huge variety of obscure platforms that the original Ocotillo design was
intended to run on), and thus will have a much different entropy
gathering mechanism. That will be issued as version 0.2 of Ocotillo when
possible (I will probably be another couple of weeks on the program I'm
currently working on before I can even attempt to look at that problem).
Oh, as for why I bothered to perturb the counter in the first place -- I
added that prior to putting the MD5 on the output of the PRNG. I was
concerned about known-plaintext attacks upon the block cipher. By gently
perturbing the counter, I could at least make that a little more
difficult. The MD5 on the output was another more general solution to
cryptographic attacks upon the encryption algorithm. In reality, of
course, there is little chance of that happening, but as I mentioned, I
am utterly paranoid when it comes to design. I don't profess to be a
"crypto god", so I'd rather be overkill than road kill.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: Anti-Spam <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Tue, 21 Sep 1999 00:00:52 -0700
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Anti-Spam
><[EMAIL PROTECTED]> wrote:
> >Tim Tyler wrote:
> >>
> >**** WHOLE LOTTA LOTTA STUFF WE FAST FORWARD OVER *****
> >
> >
> >The statement on resulting bit-stream pseudo-randomness still stands as
> >true for the use of a binary file. If the algorithm used to compress
> >the original file into a "compressed and *random* " output file relies
> >only and totally on any or all possible substring (bit patterns) in the
> >original uncompressed file, in any combination, accessed in any order
> >(front of file, back of file, middles of file, round and round file..)
> >no matter how complex, involuted and twisted, AND this operation must
> >reverse the process on the compressed output to reproduce the original
> >input, the result will be a new file of bits whose substrings will
> >evidence some correlations and thus fail some or all tests for
> >statistically valid random bit patterns.
> >
> >Random bits exhibit no correlation or dependence on any bits that appear
> >before them or that follow them in the file. Unless randomness is
> >injected into the process of compression from some true random exernal
> >source, the resulting file's bits are pseudo-random.
>
> Actually it is very hard to define what a random file is. Once you have
> any file and start talking about it. It is not random but you could make
> up some defination that if it passes some certain tests. You could call
> it random. But if you keep making up more tests there are really no random
> files. But if you take what you call a random file by your tests. And if you
> run my decompression method. You will get a nonrandom file by some
> of your tests. You may have to run it more than once if you cooked the
> example by compressing a random file to get another random file. But
> the expanded file will most likely not pass all your random tests.
> Do something your mind my think is fair using quatum measurements.
> Take many long runs. Most but not all will pass your test for randomness.
> The fact is a random file really refers to how the file was generated but
> it can still fail your tests for randomness. And just becuase it fails does
> not mean it was not generated in a random way. But take one that
> passes all your tests. Decompress it. It will more than likely fail
> your test for randomness even though the compressed specially
> generated file passes. I know this is hard for you to grasp but
> think about it.
>
Not hard to grasp, the point is already understood. The tests for
randomness provide only confidence levels as to the likelihood that the
observed bits are from a random source. A truly random source produces
an output (bits in this case) whose values at any instant are
uncorrelated with any future or past output value. The standard
statisitical tests to which I refer provide a probabalistic estimate as
to just how likely it is that the observed sequence came from such a
source.
The tests of which I speak only tell us this - if a sequence fails any
one of the tests to the level of confidence chosen, we can chose to
reject this sequence as originating from a random source. We could look
at some more of the sequences and judge again, and if it continues to
fail one or more tests, reject it as random with some probability (as
given by the level of confidence). There is a finite probablity for a
truely random sequence to fail one or more of the tests. To do so
repeatedly is less probable, but still there's a non-zero probability.
If the sequence passes all of the tests to the level of confidence
chosen, we can accept it with some probability (as given by the
confidence levels) as coming from a random source.
The confidence levels can be set so high that even a sizable number of
true random sequences fail them (false negatives.) The levels can be
set so low that a sizable number of pseudo-random sequences can pass
them (false positives.)
A deterministic, fully reverseable (no matter how "gnarly") algorithm
applied to determinstic data/files to generate an output faces in
general a tough row to hoe when trying to pass all of those tests with a
high level of confidence. Look at the history of pseudo-random number
generators. Quite a few of them can be successfully predicted by
algorithms fed just short lengths of their outputs. Linear Congruential
Generators are a good example. Jim Reeds and Joan Boyar showed us that
LCGs are entirely predictable. And Linear Feedback Shift Registers fell
to the Berlekamp-Massey Algorithm.
I do encourage you to continue your research with your compression
algorithm, and I suggest an analysis of it in the same vein as Jim
Reed's, Joan Boyar's, Berlekamp and Massey's analyses on those other
algorithms.
[EMAIL PROTECTED]
------------------------------
** 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
******************************
