Cryptography-Digest Digest #97, Volume #13 Sat, 4 Nov 00 15:13:01 EST
Contents:
Re: Crypto Export Restrictions (Scott Craver)
Re: RSA vs. Rabin (David A Molnar)
Re: Crypto Export Restrictions (Scott Craver)
hardware RNG's (Dido Sevilla)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: RSA vs. Rabin (Fritz Schneider)
Known-plaintext attack on chaining modes (was Re: Give it up?) (David Hopwood)
Re: Hardware RNGs (David Hopwood)
Re: Rijndael question (David Hopwood)
Re: Calculating the redudancy of english? (Richard Heathfield)
MathLabs2000 ("azarider")
Re: Crypto Export Restrictions (Scott Craver)
Re: Crypto Export Restrictions (Scott Craver)
Re: Crypto Export Restrictions (David Schwartz)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: 4 Nov 2000 18:12:13 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>Scott Craver wrote:
>>
>> If you want people to analyze your PRNG, output source
>> code or good pseudocode (no steps missing, no ambiguous
>> bits) for the PRNG part of the software.
>Have you read the help files?
Yes. No pseudocode. Could you perhaps tell me which specific
"help file" contains the source or pseudocode for the algorithm?
I only see long-winded English descriptions which are not
sufficiently unambiguous. Pseudocode should look like normal
code, just a bit more relaxed and a bit more readable.
>If you want to discuss your own imaginings go right ahead.
>Apparently there are several others here to keep you company.
There doesn't seem to be any choice, until you have the
honesty or courage to let analysts scrutinize your algorithm.
BTW, "uses no mathematical equations" is just a plain lie.
You should change this statement because it is (a) fraudulent
and (b) lets people know that you have never taken a course
in abstract algebra, and thus don't know that "mathematical
equations" need not involve numbers.
-S
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: RSA vs. Rabin
Date: 4 Nov 2000 18:08:16 GMT
Quisquater <[EMAIL PROTECTED]> wrote:
> 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 ?
Scan and post TIFF files?
-David
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: 4 Nov 2000 18:25:15 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>I am very glad you posted this.
>
>If they don't even have the G-2 to get it from the Help Files
>themselves they sure as hell won't get a clue from what you
>posted.
It's kind of someone else to work to translate your
descriptions into real pseudocode, but the onus really
is upon you to do this.
Your response to analysts is very belligerent, very
adversarial, and suggests that you really don't want
people cryptanalyzing your cipher. You should make the
effort to post pseudo- or bits of source- code, so
experts can scrutinize it. Until then, you are, as
you have been for years, peddling software that nobody
can take seriously, or distinguish from a fraudulent
product.
>Nothing in this world comes easy. These guys wanted to be spoon
>fed. I hope they are wise enough to know that they get what they
>pay for.
Isn't your software free?
>Cheers.
-S
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: hardware RNG's
Date: Sun, 05 Nov 2000 02:38:57 +0800
I wonder why people have to be so paranoid regarding hardware RNG's to
be used for cryptographic purposes. As long as there is reasonable
shielding to keep egregious sources of non-randomness from overly
biasing the noise generator circuit's input that should be good enough.
I'm just wondering how an electronic noise generator (such as one I've
mentioned in a previous post that uses the base-emitter junctions of two
transistors) could become maliciously biased by an attacker... I'm a
computer engineer by training and know a little of these things, and my
understanding of the situation is that for some malicious person to bias
a hardware RNG sufficiently he'd have to be able to bombard the area
where the RNG is with significant quantities of RF radiation, enough
that other electronic devices in the vicinity would receive noticeable
quantities of interference as well (and wouldn't that make everyone
suspicious?). Attempting to read out the results of the RNG seems to me
a difficult task too, as how can the attacker be sure that the signal
he's getting actually comes from the RNG and not from some other source
of small-signal "random" electronic noise in the vicinity? In a typical
locale there are lots of these!
People say it's not that simple to make a hardware RNG. Maybe so if
you're going to use it to generate numbers for a national lottery or
some other application where mathematically provable randomness is your
goal. But for cryptography, I think it should be enough for a hardware
RNG to be reasonably unbiased and impervious to manipulation and
monitoring by malicious entities. If an attacker can't actually bias
the RNG in a useful way, or read the values it produces, then I guess
that the RNG will not be a source of security problems. Of course, such
raw random bits must be decorrelated and it would be far preferable to
use the random bits only to seed a PRNG rather than be directly used.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 10:50:25 -0800
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >Scott Craver wrote:
> >>
> >> If you want people to analyze your PRNG, output source
> >> code or good pseudocode (no steps missing, no ambiguous
> >> bits) for the PRNG part of the software.
>
> >Have you read the help files?
>
> Yes. No pseudocode. Could you perhaps tell me which specific
> "help file" contains the source or pseudocode for the algorithm?
>
> I only see long-winded English descriptions which are not
> sufficiently unambiguous. Pseudocode should look like normal
> code, just a bit more relaxed and a bit more readable.
>
> >If you want to discuss your own imaginings go right ahead.
> >Apparently there are several others here to keep you company.
>
> There doesn't seem to be any choice, until you have the
> honesty or courage to let analysts scrutinize your algorithm.
>
> BTW, "uses no mathematical equations" is just a plain lie.
> You should change this statement because it is (a) fraudulent
> and (b) lets people know that you have never taken a course
> in abstract algebra, and thus don't know that "mathematical
> equations" need not involve numbers.
>
> -S
The info is there.
Dear Problem Child, just read it.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 10:52:10 -0800
Scott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >
> >I am very glad you posted this.
> >
> >If they don't even have the G-2 to get it from the Help Files
> >themselves they sure as hell won't get a clue from what you
> >posted.
>
> It's kind of someone else to work to translate your
> descriptions into real pseudocode, but the onus really
> is upon you to do this.
>
> Your response to analysts is very belligerent, very
> adversarial, and suggests that you really don't want
> people cryptanalyzing your cipher. You should make the
> effort to post pseudo- or bits of source- code, so
> experts can scrutinize it. Until then, you are, as
> you have been for years, peddling software that nobody
> can take seriously, or distinguish from a fraudulent
> product.
>
> >Nothing in this world comes easy. These guys wanted to be spoon
> >fed. I hope they are wise enough to know that they get what they
> >pay for.
>
> Isn't your software free?
>
> >Cheers.
> -S
The onus is on you: That is if you have the intelligence and energy
and interest.
If not: forget about it.
------------------------------
From: Fritz Schneider <[EMAIL PROTECTED]>
Subject: Re: RSA vs. Rabin
Date: Sat, 4 Nov 2000 10:55:42 -0800
Reply-To: Fritz Schneider <[EMAIL PROTECTED]>
On Sat, 4 Nov 2000, Quisquater wrote:
> Francois Grieu wrote:
> > I always wished I could read the original Rabin paper. <SNIP>
> >
> > Anyone know how to get the original paper, preferably electronicaly ?
There is a scanned version online:
http://ncstrl.mit.edu/Dienst/UI/2.0/Describe/ncstrl.mit_lcs%2fMIT%2fLCS%2fTR-212
You might have to do some surgery on the URL if my mailer
truncates it.
-- fritz
------------------------------
Date: Sat, 04 Nov 2000 04:22:29 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Known-plaintext attack on chaining modes (was Re: Give it up?)
=====BEGIN PGP SIGNED MESSAGE=====
Eric Lee Green wrote:
> Mok-Kong Shen wrote:
> > Tom St Denis wrote:
> > > A good test for a block cipher is given a ciphertext block C and
> > > (let's say this is an AES cipher) and 127 bits of P (the plaintext)
> > > you cannot guess the last bit faster then brute force without the
> > > key.
> >
> > But known-plaintext attack (the zero bytes mean that
> > part of the plaintext is known) is one of the commonly
> > considered attacks, isn't it?
>
> That is why you do not use a block cipher in straight ECB mode.
>
> If you're using it in CFB mode,
[I'll assume full-block feedback.]
> the first thing encrypted is a random salt
> value. This basically means that as prior block's cryptotext is EOR'ed
> with the current block's crypto-text, each subsequent block has a
> seemingly-random value EOR'ed with it, which should resolve any known-
> plaintext attack problems.
It prevents a chosen-plaintext attack [*], but not known-plaintext.
For full-feedback CFB,
C[i] = P[i] XOR E[K](C[i-1])
so (C[i-1], C[i] XOR P[i]) is a known plaintext/ciphertext (pt/ct) pair.
For CBC,
C[i] = E[K](P[i] XOR C[i-1])
so (P[i] XOR C[i-1], C[i]) is a known pt/ct pair.
For full-feedback OFB,
S[i] = E[K](S[i-1])
P[i] = C[i] XOR S[i]
so (C[i-1] XOR P[i-1], C[i] XOR P[i]) is a known pt/ct pair.
I.e. for each of these modes, having known message plaintext allows
calculating pt/ct pairs for the underlying cipher (in the case of OFB,
n+1 consecutive known message blocks are needed to find n pairs).
[*] Strictly speaking, a chosen-plaintext attack is only prevented under
the assumption that an attacker cannot obtain a partial ciphertext,
then submit the next block of the plaintext for encryption without
the IV being reset. Protocols that use chaining modes should try to
prevent this situation, since it also allows attacks that break
semantic security, even for an "ideal" block cipher.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOgOOrTkCAxeYt5gVAQHYXAgAmR94xXwjK5qBJlD3faECuRRt25sFlqvv
Yw3YeTslfTZ3gnE7lJmUwQQKLPwmRHbskIPODIdebeeN+RY1JZd3xnfqBeUKJjIN
qLnI6djB4IuqsI0/usZXWgYV/rFglT4Gqk29QeSkhXFa81alJ5+Yr2+BOQbRwnHU
RE+Gr8ExSNn8Vx7lzFKhfRGqLZd6H79u3UaLA4HRCkHNAoViQh0999KolcgTOUMz
/aS4jmYpi0TdKx/w6d6wl9erN5SQ9bwY75t+CSw7gfUHPPYKERnU0mBVAtW4Igrm
RuCwQFUfYccgdfL5ddHevD+y2R9vPIgR7OAQrQAKt9oi3r321QJmXQ==
=7wJm
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 04 Nov 2000 01:13:17 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hardware RNGs
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> Paul Crowley wrote:
> > Alan Rouse wrote:
> > > Hashing does not increase entropy, whether one pass or multiple.
> >
> > No, of course not. However, at least it doesn't *reduce* entropy
[context restored]
> > until you already have enough for your state to be unguessable,
> > unlike many preprocessing techniques suggested for entropy sources.
> > It's also much harder to get wrong. [...]
>
> Actually I will differ with you there, you seem to be making the common
> mistake of assuming that SHA-(whatever) offers perfect entropy
> consolidation,
Although it doesn't offer perfect entropy consolidation (why would it need
to?), it can reasonably be expected to offer very good entropy consolidation -
better than a von Neumann compensator, or most of the other commonly suggested
alternatives. (Note that a von Neumann compensator will not remove
correlations between bits.)
> we have no such proof, and my belief at least is to the
> contrary. To test my theory of non-perfect entropy reduction would be
> compute intensive or human intensive, but I believe that if you take a
> start value, feed that into the hash function, feed the result into the
> hash function, etc. I believe you will find a loop sooner than full
> exhaustion (2^256 for SHA-256).
The expected period of an iterated 256-bit random function is on the order
of 2^128. I would expect SHA-256 to be indistinguishable from a random
function in that respect. In any case, the period is not really relevant
here, because we are regularly adding somewhat-random material to the input
(assuming a design similar to Yarrow or /dev/random), and that will
disrupt any cycles.
> This reveals non-perfect entropy
> because it reveals that from that start value, the nth value in the
> chain can be guessed with probably higher than 1/{output space} without
> computing the value.
>
> Granted the space will be enormous, for SHA-256 I'd expect the length
> of that loop to be somewhere on the order of 2^200+ values in length,
> but I don't expect it to be perfect.
Perfect entropy was not claimed. What is needed is output that is
computationally indistinguishable from random, as well as recovery from
state compromise, chosen entropy inputs, and similar attacks described
in [1] and [2].
[1] John Kelsey, Bruce Schneier, David Wagner, Chris Hall,
"Cryptanalytic Attacks on Pseudorandom Number Generators,"
Fast Software Encryption, Fifth International Workshop
Proceedings (March 1998), Springer-Verlag, 1998, pp. 168-188.
http://www.counterpane.com/pseudorandom_number.html
[2] Peter Gutmann,
"Software Generation of Practically Strong Random Numbers"
(updated June 2000),
Original version presented at the 1998 Usenix Security Symposium.
http://www.cryptoengines.com/~peter/06_random.pdf
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOgNiQjkCAxeYt5gVAQFRNwgAyzhgzkJRD3T/9vNYjUpMrpJl0ZyDIOLa
c0+C/f+7v9Ug3RdzKbbey93yC4oZARaUv0+Eeq2PAH5olxH3zWKgZBzMmU33dGyl
iWTbvgniDVXFHVa65eayzFGyqIXhzjBZ8fRnRNdKFhvPLmSETW92bWQvOPHTCHzO
esZWTQwrs3ngDgp3ZRSY6khVj5qdVdP17s9GuIc97afp5OsWlgjZP3GAUVKNvUHN
X8BsuhmM5ATV1U83Y6Is/5gHdAsjSpvogVtD4+b89/7KtB0o3UzcaZT6Gmc3RwJL
lppNciC+TLScV/HvhW+DMriWustAh8/yH2KnRDwawxJ66Y/FmaJg1A==
=q2r0
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 04 Nov 2000 04:55:43 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Rijndael question
=====BEGIN PGP SIGNED MESSAGE=====
Manuel Pancorbo wrote:
> On Rijndael doc especifications is pointed out that decryption is somewhat
> slower than encryption, above all in 8-bit enviroments.
[...]
> So I wonder if the server machine could use the "decryption" algorithm as
> encrypter and thus the client machine should use the "encryption" algorithm
> as decrypter, in order to compensate both working speeds.
Yes, this will work fine, and any attack on that usage would also be an
attack on some applications of Rijndael as a pseudo-random permutation,
so you can assume that people will be analysing it for such weaknesses.
Alternatively you could use CFB mode, for example (see Applied Cryptography,
2nd edition or Handbook of Applied Cryptography), in which case only the
encryption direction of the block cipher is needed.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOgOWiDkCAxeYt5gVAQEg2QgAw9R6/y0fjSE6J6O+nrJgrVYBtJSolraW
wnqqbGJnNiJTmAhawbvhF8W1WczLsXgcWvndEf8Nz96KVafft4waajyCZKyfMAgU
orAYRkV5pbEwRVyfIaUAeEpIo1rwOiFdDDtrBP1qSIBUhnSHZRIzFaP13bpVpQb+
boDS73wTIvfOlL9bxsB3AS4zbRGd5zK3ur6CXHa5f8TDiScW2nRSkgrwg2PgFgov
FyoC2ms015TJrzR53+Ic7AShtHZnd5+nxyejSe4isefNYMtAxtDBE428m482BSCn
LXOnxwRHmJEMJRp1rReEgGSt3ZGrnClgeXGMfJ4D+Tgz2976BohG5A==
=YPcH
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 04 Nov 2000 19:09:20 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Calculating the redudancy of english?
[EMAIL PROTECTED] wrote:
>
> 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? ;)
No idea. Here's a single letter frequency analysis for Sir Arthur Conan
Doyle though - all the Holmes stuff, plus quite a bit of poetry and
other stuff, all from one CD-ROM:
> freq
Ch Count %age Ch Count %age
e 426789 12.254 m 95164 2.732
t 310189 8.906 w 84321 2.421
a 283105 8.128 f 74147 2.129
o 273295 7.847 y 71729 2.059
i 243642 6.995 g 62301 1.789
n 234709 6.739 p 57631 1.655
s 223011 6.403 b 51607 1.482
h 220827 6.340 v 35344 1.015
r 202167 5.804 k 26714 0.767
d 149508 4.293 x 5717 0.164
l 141406 4.060 j 4898 0.141
u 103381 2.968 q 3187 0.092
c 96394 2.768 z 1796 0.052
Looks rather modern, doesn't it?
I'll post the Bard's equivalent when I manage to unearth the CD.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: "azarider" <[EMAIL PROTECTED]>
Subject: MathLabs2000
Date: Sat, 4 Nov 2000 20:37:46 +0100
sorry for my question but does anybody know where to get this program?
need to encrypd a prepaid code
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: 4 Nov 2000 19:20:55 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>The info is there.
>
>Dear Problem Child, just read it.
Again, I look at the help files, and see no source nor
pseudo-code. I ask, again, what help file contains the
pseudo-code? If the info is there, you could answer
this question.
Again, I point out that until you provide real pseudo-
code for your algorithm, your method is indistinguishable
from a fraudlent one.
Again, I point out that there are plenty honestly secure
PRNGs, which do not stop and wait for the user to shuffle
decks of cards for it. This allows those other algorithms
to run at nice, fast, normal speeds.
And, again, I point out that it is a lie to say that
your system involves "no mathematical equations." I
don't even see why you consider this false statement a
selling point---perhaps you are targeting the product to
Luddites and anti-intellectuals?
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: 4 Nov 2000 19:28:17 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>Scott Craver wrote:
>>
>> It's kind of someone else to work to translate your
>> descriptions into real pseudocode, but the onus really
>> is upon you to do this.
>
>The onus is on you: That is if you have the intelligence and energy
>and interest.
Uh, no, the onus is upon _you_, because it is _your_ product.
Nor is the onus upon consumers to perform their own automobile
crash tests.
Without letting experts scrutinize your algorithm, you can not
back up the single claim that your product is not a piece of
worthless snake-oil. Your angry attitude, towards those who
would help you scrutnize the algorithm, only reinforces the
perception of Original Absolute Whatever as insecure.
>If not: forget about it.
Sorry, no can do. As long as you have that web site up
peddling what appears to be snake oil, people have the
responsibility to follow-up to your posts, and otherwise warn
consumers that they should be using ciphers and PRNGs that have
been thoroughly tested.
Not to mention the performance issue of a piece of software
requiring the user to do part of its calculations, using
counters or playing cards. Nutty!
-S
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 11:48:11 -0800
Terry Ritter wrote:
> However, the issue here has nothing at all to do with short-term
> stability:
Yes, it does. The actual instant of the keyboard scan is determined by
the short-term stability of the oscillator that controls that scan.
> The issue here is that a slow, 10's of milliseconds,
> keyboard scan process inherently quantizes keystroke timings.
Yes, quantizes them with respect to an oscillator whose frequency and
phase is completely unpredictable.
> 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.
Yes, and that moment depends upon the phase relationship between the
keyboard processor's clock and the CPU's clock. So long as those two
clocks aren't produced by the same generator, that is truly random. Now
there are some motherboards (more and more these days) where those two
clocks come from the same generator. Even in those cases, a master clock
is multiplied by a PLL (or similar device) to get the CPU clock, so
there's still massive, unpredictable phase jitter between the two
clocks.
> 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.
It is not deterministic both because the generation of that clock
itself is unpredictable and because the generation of the clock by which
you are multiplying it is unpredictable. As I said, uncompensated
crystal oscillators vary by several parts per billion from second to
second.
DS
------------------------------
** 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
******************************
