Cryptography-Digest Digest #96, Volume #13 Sat, 4 Nov 00 13:13:00 EST
Contents:
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: Calculating the redudancy of english? (SCOTT19U.ZIP_GUY)
Re: RSA vs. Rabin (Quisquater)
Brute force against DES ("Samir")
Re: Q: Computations in a Galois Field (Mok-Kong Shen)
Intel's Firmware Hub RNG ("Kirk Klobe")
Turing's writing on Enigma (Mok-Kong Shen)
Re: BENNY AND THE MTB? ("Matt Timmermans")
Re: Crypto Export Restrictions (Terry Ritter)
Re: Crypto Export Restrictions (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 4 Nov 2000 15:21:27 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Matt Timmermans <[EMAIL PROTECTED]> wrote:
>
>: I've stayed out of these threads, because I'm not actually a proponent
>: of bijective compression as a means to increase the security of your
>: ciphers.
>
>Though:
>
>"If you consider compression to be an important first step before
> encryption, because it minimizes redundancy in the plaintext, then you
> can appreciate this bijective quality, because bijectivity implies that
> the compression adds no known plaintext to its output." ;-)
>
>: [...] allow me to describe bicom's encryption:
>
>You don't /really/ describe how you go to a cyphertext that's in bytes
>rather than blocks. I guess that's not immediately relevant to
>encryption (and is described to some extent on
>http://www3.sympatico.ca/mtimmerm/bicom/bicom.html ) but seems to be
>a cause of misunderstanding on this thread.
I am not sure people minds want to see a description. Even those
that can read code seem to prefer not to belive. But the really
nice thing about this "fully bijective" property is that its
easy to test. One can map from any block size to fintiely odd
and then map to any other block size. I think the ending technique
has changed. One can look at my early code and Matts early arithmetic
compressor to see the changes. I have code at my site that maps
to and from various block sizes include one of odd or even block
strutures. If one takes a look at my DSC program it maps from
a file of 8 bit blocks to finitely odd then to a file of 8 9 9 8 9
and so on then finally to 8 bit files. Matt has explained his
current method of mapping from fintily odd to 8 bit byte files
several times in the past. Matts code is effectively creating
a finitely odd file. That is converted directly to a byte orientated
output just like his compressor. I can explain it but it will
be different than Matts explantion. But here goes anyway.
Take a fintely odd file ( it has a one bit at end followed by
infinte number of zero bits) Phase one group into 8 bit chuckc
chop off trailing zero bytes. if the last byte of resulting file is
not a 10000000 (and can't be 00000000 since it must have at least one 1)
your done output the file. Know if its the 10000000 look at previous
bytes until you find a something else other than a 10000000 if that
something else is a 00000000 drop the last byte. If not your dont.
Either way your done.
This is about the simplist way to do it with my simplist explantion
going in reverse direction is just the opposite sometimes you add
data sometimes you don't. The problem with current approved methods
of padding it that you always add in the general case and this makes
them not fully bijective and they add information to a file. MInor
point but true. With at loss of the fully bijective feature one
could easuly use a few extra rules and make the current standards
work if one wanted to. But committes don't useually have that much
smarts. For padding to larger then 8 bit fields change 8 to the number
and increase the above examples with more zeros. But best to stuck
with 8 bit fies as Matt did in BICOM even when using full RIJNDAEL
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Calculating the redudancy of english?
Date: 4 Nov 2000 15:34:28 GMT
[EMAIL PROTECTED] wrote in
<ovVM5.17047$[EMAIL PROTECTED]>:
>Kristopher Johnson <[EMAIL PROTECTED]> wrote:
>> Dictionary entries aren't representative of "real-world" letter or word
>> frequencies.
>
>Actually, I wondered how representative the entirety of Project
>Gutenburg was when I read that post. I suppose it's reasonably close
>on letter frequencies, but it must be starting to drift on word
>frequencies already.
>
>(The argument being that since it includes only works out of copyright
>protection, it lags behind 'modern' english by a century or more for
>many samples.)
>
>While we're on that topic though, what about the difference in content
>too. How close to ideal are the charateristics of say the complete
>works of Shakespeare for deciphering the average usenet post? ;)
>
One easy fix is to first use a compression routine tuned to the
kind of messages your using. I am sure there will be other. But has
an example. You could use several various standard files of the type
you with to encrypt. Then use comething like my "fully bijective
adaptive huffman conditional" compressor to compress the file
use the slected standard files catenated to gether as a conditonal
file. Then encrypt this with a bijective encryptor of your choice.
You could use scott16u of you trust me. Or Matts BICOM if you want
the hottest Rijndael code. You cold also use both together in series
for the encryption. You would still get fully bijective compression
encryption. If someone uses the wrong keys they will get a file
back that will only have the letter frequences that match the condition
file used. Also only those characters that are in the condition file
will be in the wrongly decrpted text. Also if your in a nonfree country
like the UK where I guess the appropriately name R.I.P. law is in
effect. You can give any key and claim that it gives the correct message
since if the decrypt and recrypt the same cipher text will come back.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: RSA vs. Rabin
Date: Sat, 04 Nov 2000 17:05:26 +0100
Francois Grieu wrote:
> I always wished I could read the original Rabin paper. Unfortunatly,
> the best thing I ever found is an abstract:
> <http://ftp-pubs.lcs.mit.edu/abstracts/MIT-LCS-TR-212.html>
>
> Anyone know how to get the original paper, preferably electronicaly ?
I've the original paper (with the original signature of Michael Rabin).
What to do ?
------------------------------
From: "Samir" <[EMAIL PROTECTED]>
Subject: Brute force against DES
Date: Sat, 4 Nov 2000 17:23:37 +0100
(Excuse my English, I'm French...)
I search some informations about the brute force against DES.
I can use 20 computers, for a known-plaintext attack. So I have
only one plain text and the corresponding cipher text.
I known the fact that can have many keys, in French we says there
are "collisions", and in English ?
About the network, I finished the client/server application in MFC
and I have no problem.
But my problem is : I have no idea about the strategy to use in the attack ?
Is the best way to the server to search with ramdom selection ?
I learn there are some optimizations, like the property : for all key K,
and all plaintext P : DES(K,P) = ~(DES(~K,~P)),
so I can test K and ~K, with this property, in less time than testing K
and ~K separately.
What about others optimizations ?
I wish to make it clear that I'm not trying to attack DES directly ;-) I fix some
bits in the key, in order to reduce the time of research...
thanks !!
--
Samir Bellabes
Etudiant - Student
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sat, 04 Nov 2000 17:51:31 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > I like to ask some questions: The choice of the mapping of
> > x to 1/x in Rijndael has presumably much contributed to
> > resulting in a very good substitution of that cipher. Is
> > this fortuitous or is that mapping intrinsically good for
> > all GF(2^m)? Are there other mappings of comparable quality?
> > Does the choice of the polynomial effect the diffusion
> > properties of the resulting substitution, if not why?
> > Thanks.
>
> It uses inversion in GF(2)^8 if I am not mistaken. and I have said
> already that no the choice of a the modulus DOES NOT change the
> diffusion properties.
Look again into the document of Rijndael under Chapter 2.
It says GF(2^8) there.
You said to have found no change of diffusion properties
from experiments. What I want is the theoretical ground
of that, if the fact indeed 'exactly' holds (note my
word 'why').
M. K. Shen
------------------------------
From: "Kirk Klobe" <[EMAIL PROTECTED]>
Subject: Intel's Firmware Hub RNG
Date: Sat, 04 Nov 2000 16:59:25 GMT
I have been looking over the (very scant) documentation for Intel's 82802
Firmware Hub (in the 800 series chipsets) declaring it has "dedicated
hardware that harnesses thermal noise to generate random and indeterministic
values". However, I cannot find any specific details on how "good" this
built-in functionality is. Does anyone have any deeper information or
research to share?
- Kirk
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Turing's writing on Enigma
Date: Sat, 04 Nov 2000 18:05:14 +0100
I have just accessed the following URL
http://www.pro.gov.uk/news/InTheNews/Enigma/Enigma1.htm
which shows Turing's writing on Enigma. The little pages
shown can be clicked upon to have them displayed in larger
formats.
M. K. Shen
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Sat, 04 Nov 2000 17:12:15 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Matt Timmermans <[EMAIL PROTECTED]> wrote:
>
> : I've stayed out of these threads, because I'm not actually a proponent
of
> : bijective compression as a means to increase the security of your
ciphers.
>
> Though:
>
> "If you consider compression to be an important first step before
> encryption, because it minimizes redundancy in the plaintext, then you
> can appreciate this bijective quality, because bijectivity implies that
> the compression adds no known plaintext to its output." ;-)
Cruel, Tim.
I do know that this is one of the reasons that other people like bijective
compression -- it would be rude of me to ignore them, yes? It also adds
another fun property that I get to implement.
> You don't /really/ describe how you go to a cyphertext that's in bytes
> rather than blocks. [...]
The arithmetic encoding page
(http://www3.sympatico.ca/mtimmerm/biacode/biacode.html) did that pretty
well, I thought, even though it seems to be written for laymen on speed.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 18:04:03 GMT
On Fri, 03 Nov 2000 23:14:26 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> Crystal oscillators do drift with temperature, but not much, in
>> relative terms. These devices are specifically engineered to drift as
>> little as possible (consistent with cost). So if one was depending on
>> frequency changes to produce unknowable values, a crystal oscillator
>> would be the absolute *last* device one would want to use.
>
> You are confusing compensated oscillators with uncompensated
>oscillators. Cheap oscillators like those used to generate clocks for
>computers and network cards are not particularly stable with respect to
>temperature. The reason is exactly what you said, cost. It costs more to
>make it stable, so they're seldom made more stable than neccesary.
Strangely, I included a whole list of URL's, several of which were the
description of actual cheap crystals. The figures I used were clearly
for raw, uncompensated, cheap crystals, worse than those shown. Good
crystals are at least an order of magnitude better, and compensation
improves on that.
>> "Microscopic temperature variations" will produce tiny frequency
>> changes, but they will be far too small to notice (unless the crystal
>> is used in radio, where down-conversions magnify the relative change).
>> The changes are also reproducible and predictable, given knowledge of
>> the temperature. Even worse, frequency changes can be inferred and
>> tracked, when deterministic events occur at somewhat different times
>> than expected. This is not cryptographic strength.
>
> With a 500Mhz Pentium, a one part per billion drift will give a single
>bit of entropy in two seconds.
That is both a misunderstanding of the concept of drift, and a
misunderstanding of the issue:
When an oscillator drifts, the frequency does change. Then the
frequency is some different relatively-constant frequency. It does
not jump around over long measurement. The only "entropy" possible in
drift is an uncertainty about how much and when. But as drifting
occurs, the rate of change is relatively constant and predictable.
That is not entropic change.
The issue here is the keyboard scan process and the way it quantizes
keypress timings. The ability to predict the scan process is not
affected by small variations in clock rate. We can make deterministic
predictions from a key scan process, and then use any time variations
we find to resynchronize our predictions.
> typical uncompensated crystal
>ocscillator has a repeatability of about 8 parts per billion from second
>to second. That is, the average cycle time for one second compared to
>the average cycle time over the next second will typically differ by
>about 8 parts per billion. This is measurable. Really.
Tiny variations in the keyboard processor clock just mean that the
quantization of keystrokes by the scan occurs at a slightly varied
rate, not that quantization does not occur. The problem with
measuring human keystroke timing to microsecond accuracy is the
quantization inherent in a deterministic scan process which may be
about four orders of magnitude longer.
>> PC keyboards generally are scanned by a single-chip processor which
>> has its own crystal for the processor clock oscillator. A cheap
>> crystal might drift +/- 50 PPM (Parts-Per-Million) with -/+ 10 deg C
>> temperature change (and much less thereafter). [ See, for example:
>
> You are confusing the drift of the average with the drift from cycle to
>cycle. Even with apparently constant temperature (not in an oven, but
>nothing specifically changing the temperature either, the oscillator
>dithers.
On a cycle-by-cycle basis, IF we can measure the length of each
individual clock cycle to high precision, the cycle lengths will vary
somewhat. (That is a very big IF, since the naive approach would
require a count rate of, say, a million times the oscillator frequency
under test, which is already 100 MHz or better.) (Another approach is
to show the oscillator signal on a spectrum analyzer, averaged over
time. This also shows the relative probability of extreme variations
-- vary low -- and the balance between higher and lower frequency
variations.)
Cycle-by-cycle variations are oscillator phase "jitter," and are the
result of analog noise. But analog noise is bipolar with zero mean,
and so tends to average out over time. The longer the measurement,
the less the probability of seeing phase variation in the result.
Over long measurement, this goes to zero. This is not the source of
drift.
>> With a keyboard processor clock of 5 MHz, 50 PPM is 250 Hz. So
>> instead of having the original frequency of 5,000,000 cycles per
>> second, we now have 5,000,250 or 4,999,750, across 20 deg C. That is
>> a 500 Hz change out of 5,000,000 Hz, which is 1 part in 10,000 or
>> 1/100th of a percent.
>>
>> So if we have a keyboard scan rate of 20 msec, and the temperature
>> changes by 20 deg C, we might get a 20.001 msec scan. But knowing the
>> scan rate to this precision would lead to pretty good deterministic
>> prediction estimates, even *with* temperature changes.
>
> Wrong. The temperature changes vary from region to region inside the
>case.
But the only thing we care about is the temperature of the keyboard
processor clock crystal, not "region to region inside the case."
>> > In any event, the presence of the word "like" is the sentence above is
>> >there because this is not the only source used. Other sources are used
>> >that have better randomness in them, such as low-order TSC bits sampled
>> >at packet arrival.
>>
>> But if those other sources really are "like" the keyboard, they can't
>> be nearly as helpful as you first implied.
>
> Nonesense. You really have nothing but an argument from personal
>incredulity.
And yet I am the one who gave URL's for crystal characteristics:
http://www.kita.or.kr/catalog/it/it_2.html
http://www.ofc.com/piezo/papers/pcso.html
http://www.anodynecomp.com/joyous/crystals/z49up.html
http://www.cmindhk.com/crystal.htm
www.lecroy.com/labs/volumeIVJitterTiming/default.asp#clockoscillatorstability
That is hardly an exclusive list: there are many, many other URL's,
presumably many which are even more on-topic.
Crystal oscillator performance is a long-studied, well-understood
field, and those understandings do not fit your portrayal of reality.
That is hardly "personal incredulity."
If you have scientific results, where are those described? Where can
we see the base upon which you form your opinion? How do we know that
you measured what you think you measured: How can we know what
experimental procedures were followed, and what forms of errors were
eliminated? Where is the reasoning which fits your claims into the
body of existing work?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 18:07:08 GMT
On Fri, 03 Nov 2000 23:26:37 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> http://www.kita.or.kr/catalog/it/it_2.html
>> http://www.ofc.com/piezo/papers/pcso.html
>> http://www.anodynecomp.com/joyous/crystals/z49up.html
>> http://www.cmindhk.com/crystal.htm
>> www.lecroy.com/labs/volumeIVJitterTiming/default.asp#clockoscillatorstability
>
> Of all of these references, only two deal with short-term stability.
>One gives a figure of 5 x 10^10. This is consistent of my own
>measurements using a 500Mhz CPU clock signal which showed 8 ppb
>differences from second to second. No effort is made to stabilize these
>oscillators and multipliers because none is needed.
No doubt one could spend literally days searching for the
most-appropriate list of URL's to address the issue.
However, the issue here has nothing at all to do with short-term
stability: The issue here is that a slow, 10's of milliseconds,
keyboard scan process inherently quantizes keystroke timings. It is
not possible to measure the actual moment of key movement; instead one
can only measure when the key is reported by the keyboard processor.
As a result, measuring keystroke timings to the microsecond largely
consists of measuring the current phase of the keyboard scan process,
which is deterministic. That is the illusion of entropy, and not
entropy itself.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
