Cryptography-Digest Digest #987, Volume #8 Thu, 28 Jan 99 11:13:03 EST
Contents:
128 bit Everest, 64 bit Coin (handWave)
Re: Idea for plaintext steganography ("Kevin G. Rhoads")
Re: My comments on Intel's Processor ID Number (Brad Templeton)
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
Re: Unicity, DES Unicity and Open-Keys (Mok-Kong Shen)
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
Re: hardRandNumbGen (Mok-Kong Shen)
Re: Who will win in AES contest ?? (Thomas Pornin)
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
Re: Who will win in AES contest ?? (Fabrice Noilhan)
Re: Who will win in AES contest ?? (Fabrice Noilhan)
Coin Toss Theory (handWave)
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
Re: hardRandNumbGen (Mok-Kong Shen)
Re: Spread Spectrum (John Bailey)
Crypto Culture ("hapticz")
----------------------------------------------------------------------------
From: handWave <[EMAIL PROTECTED]>
Subject: 128 bit Everest, 64 bit Coin
Date: Thu, 28 Jan 1999 01:38:54 -1000
I
made
some rough
calculations
yesterday comparing
64 bit keys to 128 bit keys.
There are about 2^64 atoms in a coin.
There are about 2^128 atoms in Mount Everest.
The Universe has about 10^88 particles or 2^291 particles.
All of the gold owned today could fit in my house.
Donations are welcome.
handWave
------------------------------
From: "Kevin G. Rhoads" <[EMAIL PROTECTED]>
Subject: Re: Idea for plaintext steganography
Date: Thu, 28 Jan 1999 03:44:59 -0800
Now add Haiku and you'll have something.
Automated Haiku generation is old hat. Computer generated Haiku
can be fairly reasonable as Haiku (at least to me, I'm no poetry
expert) and you can use the even/odd number of letters in each
word (as an example) as your one bit.
Of course, THEY may become suspicious if you start sending
lots of Haiku all of a sudden (no matter who THEY are for you).
--
Kevin G. Rhoads, Ph.D. (Linearity is a convenient fiction.)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Brad Templeton)
Subject: Re: My comments on Intel's Processor ID Number
Date: 28 Jan 1999 01:51:44 PST
In article <[EMAIL PROTECTED]>,
Bruce Schneier <[EMAIL PROTECTED]> wrote:
>I wrote a column on Intel's Processor ID number for ZDNet. You can
>read it at:
>
>http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
>
>Bruce
The processor serial number is precisely as useful as the one in
a dongle for software copy protection. Which is to say, useful
in interfering with many people, but not foil against a determined
attack which involves patching the binary where the instruction that
fetches the serial number is. But no copy protection is safe
against that.
But it's also rarely done.
The odd thing was Intel promoting transmission over the web.
I don't mind Intel putting in the serial number but the idea
that my web browser would transmit information from my machine
such as its serial number with a web hit is something we're
strongly against -- and something I doubt the web browser
vendors would ever do, at least not if the public knew about it.
There have been serial numbers in our machines for ages. Every
ethernet card has a unique serial number anybody can fetch.
MS Windows and other operating systems have been serialized for
a long time, though I don't know if there are documented calls to
get them. Software can easily create a unique number and store
it somewhere non-obvious, immune to attack by the typical base level
PC user. No browser has ever sent these numbers and I would expect
none ever will, unless the user asks them to.
Hell, the browsers didn't even implement multi-site cookies or
userid/password pairs even if the user consents to them.
--
Brad Templeton http://www.templetons.com/brad/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Thu, 28 Jan 1999 13:08:31 GMT
In article <[EMAIL PROTECTED]>,
"Peter K. Boucher" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> [snippety snip]
> > Consider a hypothetical M-DES Standard (hereafter, M-DES) which would
specify
> > a total of 2M pre-defined and publicly known 64-bit different blocks of
data,
> > for various choices of M = 0, 1, ... Now, when Bob wants to send a message
to
> > Alice, he needs to negotiate a M-DES cipher with Alice, which includes a
> > 56-bit secret-key [Note-1] and a publicly defined value for M, say M = 14.
> > The value of M is chosen by Bob according to his security needs [Note-2],
and
> > accepted (or not) by Alice. To use M-DES, Bob would privately choose one
> > 64-bit "key" at will (from the public list of 2^14 "keys") and then
> > repeatedly use this choice to XOR-encode one by one each of all 64-bit DES
> > ciphertext blocks which are calculated with the 56-bit secret-key he shares
> > with Alice -- without disclosing his choice (i.e., anyone else would ignore
> > the choice). Thus, Bob's choice is an "unknown key" to anyone else,
including
> > Alice -- providing open ignorance.
>
> A well-known stream-cipher with variable-size keys might work as well
> (or better, for flexibility's sake) for your notion of M-DES.
No, it won't ... as you say below ;-) Besides, I have the impression you did
not have time yet to actually read the paper, so you ignored the other
security features --- such as M key collision.
> For
> example, generate M bits randomly, use these as, hypothetically
> speaking, an RC4 key. You pre-encrypt the entire message with the
> stream cipher, then encrypt with DES. Your recipient (and any
> attackers) must brute-force the M-bit stream-cipher key.
This is well-known, with well-known problems. For example, the one you cite
below. Further, the probability of repeating the M key for the same text
(message headers, for example) is not zero and increases with time, for all
messages -- however, pratically null in the M-DES scheme because the 64-bit
ciphertext itself is random and that is what is XOR-ed with the M bit key ...
;-)
>
> One problem with this approach is that you must include known-plaintext
> in your protocol, if your recipient wants to be sure he has correctly
> guessed the M-bit "whitener."
Which problem is just absent in the M-DES scheme, no? Perhaps, on purpose '-)
And, which considerably weakens your suggestion -- perhaps too much to be
useful and that is why this scheme is not used, though already discussed in
the literature. Look for "cascadng ciphers".
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Thu, 28 Jan 1999 15:12:34 +0100
wtshaw wrote:
>
> Then, there is the spread spectrum approach, using several weak ciphers,
> to handle fractionated parts of the message. An attacker would not only
> be looking for the keys to each cipher, but the combination of the ciphers
> used.
Yes, I believe combinatorial explosion is the most effective blow
against the analyst. Just a tiny remark: The encrypted fractionated
pieces may themselves be fractionated and intermixed and sent through
different channels or in different packages of the same channel and
at separate time points. To do all that one needs informations which
should be kept secret (time varying according to some agreed upon
schedule), and that amounts effectively to provision of certain
'extentions of key length' particularly of interest with respect to
the Wassenaar regulation.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 14:08:52 GMT
In article <78nunt$2uq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Markus Kuhn) wrote:
snip...
> Diversity is a good idea, and the world could use three
> algorithms. Good systems will implement all three, such that
> if one gets seriously hit, you can quickly hot-switch to a backup.
> This would be similar to how we have both RIPEMD-160 and
> SHA-1 as high-end message digest functions at the moment
> as ISO standard alternatives. Standardization of single algorithms
> could be dangerous, which is why ISO, ITU, and IEEE have so far
> always standardized several alternative algorithms together.
> May be we will end up with AES-Red, AES-Green and AES-Blue instead
> of just AES.
>
> Markus
>
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
>
Actually Diversity is a very good idea. But Diversity is not what
the AES thing is all about. The AES is about narrowing peoples
options to make the real job of breaking codes much easer. What
is needed is some trusted third party that would test any ones
methods and post the current results giving various measures
of time real key strength and known attacks. As new attacks
become publiclly known then the rating would contimually change.
As people submit new programs then new ones will be tested.
This would make a moving target of available methods that
would make it much harder for the whole net to suffer some
major breakdown due to the failure of a few choosen methods.
It would be nice if the NSA could tell us the results of
there tests on the AES candidates. But looking at there past
history and since it is OK to lie as recent government policies
seem to indicate could we trust them to tell the truth even
if the head NSA man is swearing on a bible to tell the truth.
I leave that for you good folks to decide.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Thu, 28 Jan 1999 16:10:36 +0100
Patrick Juola wrote:
> Sure. If the key is "as random as" the message, then Shannon's
> proof of secrecy goes through. In particular, if your messages
> are bounded by a given length N, then if you can get N bits of
> randomness, from whatever source, hardware or software, then
> you can achieve perfect secrecy.
>
> How you get them is, of course, your problem. The difficulty is
> in *proving* that a given sequence of N bits is contains N bits
> of randomness (or more formally that a given generator produces
> exactly random bits). But it's fairly easy to gather *MORE* than
> N bits -- as much more as you feel confident that it is unlikely
> to be more less than N bits of randomness in the resulting sample.
>
> Furthermore, I note that "sound scientific basis" doesn't necessarily
> rely on a formal, mathematical proof. We use the acceleration of
> gravity g = 9.8 m/sec on the basis of experiment rather than any
> first-principle analysis. Similar experiments show that, for instance,
> English text contains just over one bit of randomness per character.
> If you need a thousand bits of randomness, get a thousand characters
> of English text from a secure source, distill them appropriately with
> a trusted hashing function. Better yet, get 1500 characters to allow
> for sloppy engineering -- you'd never run a wire at its rated wattage,
> would you? Take the resulting 1000 bit string, XOR it with the plaintext,
> and voila. A scientifically sound method of securing 1000 bit secrets.
Thank you for the very lucid description of a sound standpoint in
practice ('applied' cryptography as against 'theoretical' cryptography).
We must be realistic, since theoretical stuffs may not be realizable
in the real world and since 'absulute' security is never required
(does it matter if a cipher is cracked after 100 years?) Incidentally,
in another thread I also suggested distiling bit sequences out of
natural language texts as raw materials.
>
> Well, the usual definition is "work factor" -- the ratio of work
> necessary to read a message without the key vs. with the key.
> Again, "sound scientific basis" does not necessarily rely on proof;
> if you are willing to accept (as many scientists do) that RSA is
> as secure as factoring, then the work factor to crack an RSA code
> can be made as large as you like by raising the modulus appropriately.
> If you don't believe that RSA is as secure as factoring.... well, there
> are other methods out there with various conjectures about their
> difficulty of solution. If you don't believe *any* conjectures, you're
> arguably in the same camp as people who don't really believe that
> the force of gravity is constant just because it's always been constant
> so far....
I appreciate your opinions and in particular agree with you that
formal proofs are not always needed but can be substituted with
'practical' yet scientifically sound procedures. One should never
be pedantic but one certainly should not be on the other hand
a 'believer' of 'religious assertions' (totally unfounded big
words of someone).
M. K. Shen
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Who will win in AES contest ??
Date: 28 Jan 1999 15:13:42 GMT
According to <[EMAIL PROTECTED]>:
> it may be possible that DFC is to dam good for general use so it needs
> to be put down quickly
<advocacy>
DFC is The Good And Right Cipher and it will win, even in the improbable
case of unfair competition.
</advocacy>
<cheap philosophy>
If we do not assume that there exists somewhere a community of honest
cryptographers, there is little point in doing public research at all.
Therefore we have to believe that NIST is fair and the AES process
truly open.
</cheap philosophy>
<realism>
If the NSA is so powerful, it must have terrific gadgets such as
microscopic brain waves analyzors implanted in each of us or other
cool stuff; therefore resistance is futile.
</realism>
<realism part II>
If the NSA threatens us, and "dscott@whatever" is our savior, then
we are all doomed, to say the least.
</realism part II>
> but if you want better securtiy and don't care about time try looking
> at scott19u.
We all care about time. By the way, I could not access this piece of
software, but I once tried to look at scott16u, and I would say that the
1000$ reward is not enough to convince me to unscramble the horrible
piece of junk-asm-translated-into-pathetic-C code you dare to call "a
description of the algorithm". Maybe scott19u is better in that regard,
but I think spending three hours watching TV would be a more intelligent
use of my time than such an expression of poor programming abilities.
--Thomas Pornin
PS: just so you do not bother telling it yourself: I am employed by the
NSA to discredit you, because you are too dangerous for us.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 14:22:48 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
snip...
>
> >So those of you who print performance tables and ranking lists
> >might want to include an entry for 16-round Serpent as well ...
>
> Only if it becomes an AES submission.
I see limit the field don't allow improvements from the
competation. WHY?
>
> >Brian Gladman made in his presentation also the interesting
> >suggestion that the AES contest should select not a single
> >but three winners. These winners should be diverse in their
> >technology, such that a cryptoanalytic breakthrough could
> >not kill all three of them simultaneously. For instance,
> >we could have one simple easy to validate high-performance
> >winner (RC6?), one ultra-conservative winner (Serpent?), and
> >one winner that performs nicely on 8-bit embedded controllers
> >with only a few bytes of RAM and a few hundred bytes of ROM.
>
> I think that would be a disaster.
>
> Bruce
I am surprised you would be openly against Diversity
since even the ignorant who happily shell out big bucks
for your book ought to be smart enough to know that
one should never put all there eggs in one basket.
Oh please high GOD of Crypto can you tell why this would
be such a disaster or is your statement that it would
be a disaster enough for the masses so that no clarifaction
is needed?
David Scott
P.S. use scott19u then reencrypt with your AES candidate
of choice.
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: Who will win in AES contest ??
Date: 28 Jan 1999 11:53:49 GMT
According to Sam Simpson <[EMAIL PROTECTED]>:
> There is a "proof" of DFC's security?
There is a proof of DFC's security against some classes of attacks. This
does not provide any kind of security proof against other attacks. But
this is interesting though. See http://www.dmi.ens.fr/~vaudenay/dfc.html
for further information.
Fabrice
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: Who will win in AES contest ??
Date: 28 Jan 1999 11:50:46 GMT
According to Brian Gladman <[EMAIL PROTECTED]>:
> It would be useful to know whether you are saying that having three winners
> would be a disaster or whether you are saying that having three winners
> using these criteria would be a disaster
The main goal of the AES is to have a standard. This means that you're
looking for an encryption algorithm which will work on various platforms
so that they can send and receive encrypted datas. Thus, having three
winners would be a Bad Idea (tm); one will be able to use whatever
algorithm he likes but there must be a standard... and only one.
Fabrice
------------------------------
From: handWave <[EMAIL PROTECTED]>
Subject: Coin Toss Theory
Date: Thu, 28 Jan 1999 07:23:09 -1000
A "fair coin toss" is an often used concept for scholarly cryptographic
papers. The theory behind this randomness is seldom discussed because it
so obvious. The elasticity of the skin, the trembling of the muscles, air
currents, tidal pull, and myriad other subtle influences contribute to
the randomness of the results. It is the complexity of "analog" reality
which imparts unpredictableness. A skilled juggler may be able to toss
one coin slowly with repeatable results, but I defy any juggler to toss a
coin 1 meter high, rotating over 15 hz to gain any advantage over a
layman. Spinning the coin as it is launched from the fingertips, I can
make it a blur, so that may be about 20 to 50 hz.
Please comment upon the Large Signal sources of randomness, and small
signal components of randomness in a fair coin toss. Is thermal noise
important? Which quantum effect is predominant? Is the spin rate a
quantifiable contributor to the auto-correlation of recorded sequences of
bits from coin tosses? Who has done this research in the past?
handWave
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 13:47:42 GMT
In article <[EMAIL PROTECTED]>,
Robert Harley <[EMAIL PROTECTED]> wrote:
>
snip ...
> 3. Security.
>
> Don't overlook that security is more important than anything else!
> Imagine if some variant of DES had been chosen that was faster on the
> chip-du-jour in 1975 but got broken in 1985? The whole AES landscape
> would be very different.
>
> A few candidates are easily ruled out but it would be a mistake to
> assume that the rest are all equal.
>
> For now, the various AES teams are involved in guerilla warfare,
> trying every avenue to criticize the others. Read carefully and
> separate the wheat from the chaff. When Bruce Schneier and colleagues
> comment on 32-bit performance they criticize DFC as "The modular
> multiply does a nice job of diffusing bits, but hurts performance
> significantly." They're praising it with faint criticism!
>
If the contest was to actually be of real help then security
would be of the very highest concern. But you miss the whole
point of the contest. The Clipper chip failed so the NSA needs
a way to make people use a common encryption method that they
can break and yet appear to be not involved in its selection.
If it is true as your appear to think of Bruce and his colleagues
using the praising with faint criticism then it may be possible
that DFC is to dam good for general use so it needs to be put
down quickly and who is more respected by the unwashed crypto
masses than Mr B.S. himself. Of course you could be wrong.
> At heart I'm a bit of a speed-demon but mostly a mathematician. There
> are some fast candidates, but that's not enough. There's plenty of
> advocacy going on, but much of it doesn't really matter. There are
> guys with good reputations involved. I respect that. But the
> clincher is:
>
> WHAT CAN YOU PROVE? WHAT IS HARD, COLD FACT?
>
snip ...
>
> I'm defending DFC because it melds the best of the old DES era and the
> new mathematical one; because it has gone through the AES process to
> date with as much distinction as the other good candidates, withstood
> attempts to break it, and because on top of that it is backed up by
> guarantees, when all the others have to offer is rhetoric.
>
> So forget all the business with "candidate A is bla% slower/faster than
> candidate B on processor X, but on Y mumble mumble".
>
> None are perfect. But one comes with proof. The others don't.
>
> WHAT ARE YOU PEOPLE THINKING?
>
> =:-)
>
> Bye,
> Rob.
>
Rob I find it surprising that it comes with proof and the others
don't. If what you say is true. And again I say if true. That is
if it really has proof of its security and the others don't. Then
it CAN NOT WIN the AES contest since having a real secure encryption
method is not what BIG BROTHER wants people to use. These are just
my thoughts but if you want better securtiy and don't care about
time try looking at scott19u.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Thu, 28 Jan 1999 16:38:22 +0100
R. Knauer wrote:
>
>
> Statistical tests are useless if applied to finite random numbers
> generated by a TRNG.
Are you going to REWITE the whole scientific theory of probability
and statistics?????
After having built a hardware generator, do you test it or simply
'believe' that it is o.k.? If you do test, which tests do you perform?
Do you ever consider that the output can have bias? If yes, what
is a bias and how do you detect the bias and quantify it? What tools
do you have in doing all these if you exclude ALL statistical tools???
Since we have argued so much and in that process also touched PRNGs,
I suppose the following paragraph taken from a brand new book by
O. Goldreich, Modern Cryptography, Probabilistic Proofs and
Pseudorandomness, Springer-Verlag, 1999, may interest you (page 77):
Thus, pseudorandom generators are efficient (i.e. polynomial-time)
deterministic programs which expand short randomly selected seeds
into longer pseudorandom bit sequences, where the latter are
defined as computationally indistinguishable from truly random
sequences by efficient (i.e. polynomial-time) algorithms. It
follows that any efficient randomized algorithms maintains its
performance when its internal coin tosses are substituted by a
sequence generated by a pseudorandom generator.
Also interesting is a quotation Goldreich puts at the beginning of
chapter 3 of his book:
If two objects are indistinguishable, in what sense are they
different?
Since you so often use the term 'crypto-grade', let me also remind
you that there are cryptologically secure PRNGs, the best known
one being that of BBS (see any textbook on modern cryptography).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Spread Spectrum
Date: 28 Jan 1999 12:25:18 GMT
On Thu, 28 Jan 1999 07:13:03 GMT, [EMAIL PROTECTED] wrote:
>Greetings,
>
>Would appreciate hearing from anyone who understands Spread Spectrum
>technology.
How about the answer at:
http://www.dejanews.com/getdoc.xp?AN=101299484
------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Crypto Culture
Date: Thu, 28 Jan 1999 10:51:34 -0500
it seems funny, we spend millions of hours sorting thru all the available
perceptive data to create a workable coherent knowledge of the world, the
universe, and (maybe) each other, all embodied in a thing called "culture",
and then we expend huge efforts trying to scramble the same info so that no
one can understand what each other is trying to say!
--
best regards
[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
******************************
