Cryptography-Digest Digest #47, Volume #13 Mon, 30 Oct 00 15:13:00 EST
Contents:
Re: BEST BIJECTIVE RIJNDAEL YET? ("Brian Gladman")
Re: Q: Computations in a Galois Field ("Brian McKeever")
Re: Graphics and Encription (Mok-Kong Shen)
Re: Q: Computations in a Galois Field (Roger Schlafly)
Re: Padding scheme? (Benjamin Goldberg)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: XOR based key exchange protocol - flawed? ([EMAIL PROTECTED])
CAST - test vectors ? ("Falissard")
Re: Padding scheme? (SCOTT19U.ZIP_GUY)
Re: Searching for a good PRNG (Tom St Denis)
Re: XOR based key exchange protocol - flawed? (Tom St Denis)
Re: RSA Multiprime (Tom St Denis)
Re: How do I detect invalid passwords? ([EMAIL PROTECTED])
Re: RSA Multiprime (Simon Johnson)
Re: rc4 proprieties (Ichinin)
Re: Psuedo-random number generator (David Schwartz)
Re: Psuedo-random number generator (David Schwartz)
Re: Visual Basic (Ichinin)
----------------------------------------------------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Mon, 30 Oct 2000 17:13:21 -0000
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Brian Gladman) wrote in
> <x8aL5.3966$zO3.120805@stones>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Brian Gladman) wrote in
> >> <eN0L5.3659$zO3.111060@stones>:
> >>
> >>
> >> >
> >> >But in arithmetic coding the original file length does need to be
> >> >encoded in some way and Matt has a neat way of doing this (and one
> >> >which I like). But his scheme is just one of many possible ways of
> >> >encoding
> >>
> >> I think you don't know what he did since a length field is not
> >> use in Matts arithmetic coding.
> >
> >I did not say there was a length field - I just said that length is
> >encoded and I do know how he does this.
> >
>
> The legth is not added to the file. Zero information is added to
> Mastts compressest files.
I certainly did not claim that the length is 'added' to the file - what I
said was that it was encoded in the file, which is quite different.
Moreover, while the encoding adds no _data_ , it certainly adds
_information_ since the file length could not be recovered if it did not.
Brian Gladman
------------------------------
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Mon, 30 Oct 2000 09:25:52 -0800
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brian McKeever wrote:
> > No. It is easy to come up with examples of rings where some elements
> > lack inverses.
>
> Could you give us an example of a non-invertable element in a ring with
> prime order?
Well, I'm a little rusty, but let's try this:
let R have p=prime elements. There is only 1 way to define + (since there
is only 1 group of order p, up to isomorphism). Now define a*b=0 for any a,
b in R. It's easy to check that we satisfy the ring axioms (most
importantly, * obviously distributes over +), and it should be clear that
none of the elements is invertible.
Another way to see it is this ring doesn't have a mulitplicative identity,
so it can't have invertible elements.
Brian
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Graphics and Encription
Date: Mon, 30 Oct 2000 18:25:52 +0100
wtshaw wrote:
>
> Grayscale is a lesser messy medium than real colors. It seemed like a
> good area to look at. Ther particulars are really cut and dried for me
> now. The essence of grayscale stego can be changing pixels in an
> subvisually decernable manner, but the added information units need not be
> one-to-one with pixels.
I have never done such stego and my knowledge in that is
also poor. But it is my understanding that one (pseudo-)
randomly picks some pixels from the picture, maybe in
certain restricted region of a picture, and then modify
the pixel values. I use to think, however, that it should
be much easier to do stego by modifiying numerical data
that are so abundant, e.g. measurements of physical
processes. It is in my view at least as normal for a
person to send to a partner numerical data as pictures.
That is, for serving as cover materials before the
scrutinating eyes of a controller, numerical data are just
as good. So I don't quite understand that doing stego
with numerical data seems to have been neglected.
M. K. Shen
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Mon, 30 Oct 2000 10:18:35 -0800
Brian McKeever wrote:
> > > No. It is easy to come up with examples of rings where some elements
> > > lack inverses.
> >
> > Could you give us an example of a non-invertable element in a ring with
> > prime order?
>
> Well, I'm a little rusty, but let's try this:
> let R have p=prime elements. There is only 1 way to define + (since there
> is only 1 group of order p, up to isomorphism). Now define a*b=0 for any a,
> b in R. It's easy to check that we satisfy the ring axioms (most
> importantly, * obviously distributes over +), and it should be clear that
> none of the elements is invertible.
>
> Another way to see it is this ring doesn't have a mulitplicative identity,
> so it can't have invertible elements.
Rings are usually defined to have a multiplicative identity.
Sometimes the cutesy name "rng" is used for rings without identity.
If there is an identity, then consider 0, 1, 1+1, 1+1+1, ... .
If the ring has prime order p, then there are p of these terms,
and so it enumerates the ring. Using the distributive law and
other laws, addition and multiplication on these terms must be
the familiar arithmetic mod p, and hence it is commutative
and has inverses (ie, it is a field).
If the ring does not have prime order, then strange things can happen.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Padding scheme?
Date: Mon, 30 Oct 2000 18:27:55 GMT
SCOTT19U.ZIP_GUY wrote:
>
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> <[EMAIL PROTECTED]>:
>
> >I'm not certain if this padding scheme is new. If it's not, don't
> >sue me :)
> >
> >messagesize and blocksize are measured in bytes.
> >
> >x = (messagesize + 1) mod blocksize
> >if( x == 0 )
> > y = 0
> >else
> > y = blocksize-x
> >append y Truly Random bytes to the message
> >append a final byte that has the lower log2(blocksize) bits set to y,
> >and the upper bitlength(byte)-log2(blocksize) bits filled in from
> >your Truly Random bitsource.
> >
> >To remove the padding, read the message up to the last byte, use a
> >mask to extract y, and discard the y previous bytes.
> >
> >Note that the scheme requires that blocksize be fewer than
> >2**bitlength(byte) bytes, and works best if blocksize is a power of
> >2.
> >
> >Does anybody see any weakness in this scheme?
> >
>
> The main objection I see is the same when people bitch about the
> "random bits" in a OTP. The weaknes is you have to count on having
> such bits. I have nothing agains using random bits. But I prefer to
> have a sound method with out the use of the "random god" and then add
> random later.
I don't see anything unsound about the method. To give a more concrete
example of my algorithm, I'll fill in things that were left as
parameters. Assume bytes are 8 bits each, and the cipher blocksize is
16 bytes (those are what I'd left as parameters). Let xx be the number
of bytes in the message. Append 15-(xx mod 16) bytes of padding.
Append 4 bits of padding. Append the number of complete bytes of
padding as a 4 bit value. The final result will be a message whose
length is a multiple of 16 bytes. The bytes and bits of the padding
could be all 0s, or all 1s, or generated from a PRBG, or from a TRBG;
regardless, the amount of padding depends entirely (100%) on the length
of the original message, not on the output of the bit generator.
However, it is desired that the bits of padding not be distinguishable
from random, so as to avoid giving the opponent known or probable
plaintext.
To strip off the padding, read all the data, logical and the value 0xF
with the last byte, and strip off that many of the preceding bytes.
If the blocksize were 32 bytes, we would instead append 31-(xx mod 32)
bytes of padding, followed by 3 bits of padding, followed by a 5 bit
number indicating the number of complete bytes of padding.
To strip off the padding, read all the data, logical and the value 0x1F
with the last byte, and strip off that many of the preceding bytes.
> But I would prefer to use the random number as a number use to
> rotate the source file and then DSC to mate it in. Then optimal end
> treatment such as Matts or mine that works on any file to match the
> block size of the encryption used. That is what I would so if for some
> reason I want to padd out to match the encrypted block size.
This statement of yours is completely "out there." Perhaps you should
get your head out of your ass and read what I wrote. Nowhere do I use
my random bits as numbers... they're just garbage data, junk, fill,
un-looked-at bits-and-bytes. The reason I want randomness is to avoid
giving known or probable plaintext.
> The other error I feel that is there is when you start doing this
> for real the field you use to contain the data must be able to account
> for all bit patterns you still have to play same games with this so
> that every combination of bits is possible. Even if you try to add a
> constant to a file the way I did there are optimal end considerations
> that come out in the details.
Clearly you are the type of person, who, if given a large bottle of
"clue musk," could not get a clue.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 30 Oct 2000 18:35:19 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<XUhL5.4086$zO3.128477@stones>:
>I certainly did not claim that the length is 'added' to the file - what I
>said was that it was encoded in the file, which is quite different.
>Moreover, while the encoding adds no _data_ , it certainly adds
>_information_ since the file length could not be recovered if it did not.
>
> Brian Gladman
>
Your wrong the lemght info is not encoded in the file. You can change
the bits in the file to anything you want and the lenght would not change.
The length that the operating system allocates for the file is something
different. The data encrypted is the file data. Nohting in that data
has any need for a length encoding.
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]
Subject: Re: XOR based key exchange protocol - flawed?
Date: 30 Oct 2000 10:43:58 -0800
Zero-Knowledge MIME Encapsulated Message
--C89J9Q56E8NYNY82YZQFMR84W9RVJ7KYW6V5RH1E536W1CIE
Content-Type: text/plain
Mike Connell <[EMAIL PROTECTED]> writes:
> Call the faked Pa value Pa', and the faked Xa value Xa', that means,
> after step 4:
>
> a computes XOR of Pa Pb Xa Xb
> b computes XOR of Pa' Pb Xa' Xb
>
> so the attacker must create Pa' and Xa' so that
>
> Pa' XOR Xa' == Pa XOR Xa
>
> I dont see how this can be done when the attacker doesn't know
> Xa. Could you expand a little on this attack?
He doesn't have to do this. The MITM computes one key with respect
to A, and a different key with respect to B. He runs your whole
protocol separately with respect to A and B. At the end he shares
a key with A, and shares a different key with B.
Now when A sends to B, the MITM intercepts, decrypts using the key he
shares with A, and re-encrypts using the key he shares with B. This
is standard operating procedure for an MITM.
Ob
--C89J9Q56E8NYNY82YZQFMR84W9RVJ7KYW6V5RH1E536W1CIE--
------------------------------
From: "Falissard" <[EMAIL PROTECTED]>
Subject: CAST - test vectors ?
Date: Mon, 30 Oct 2000 18:54:45 GMT
I am seeking test vectors, along with intermediate values,
for CAST-5. The results of the key schedule would be nice to have.
I find RFC2144 is too concise and is of no help
for debugging when you initially try to implement CAST.
Thanks in advance to any kind cryptographic soul...
http://os390-mvs.hypermart.net
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Padding scheme?
Date: 30 Oct 2000 18:41:14 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY wrote:
>>
>> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
>> <[EMAIL PROTECTED]>:
>>
>> >I'm not certain if this padding scheme is new. If it's not, don't
>> >sue me :)
>> >
>> >messagesize and blocksize are measured in bytes.
>> >
>> >x = (messagesize + 1) mod blocksize
>> >if( x == 0 )
>> > y = 0
>> >else
>> > y = blocksize-x
>> >append y Truly Random bytes to the message
>> >append a final byte that has the lower log2(blocksize) bits set to y,
>> >and the upper bitlength(byte)-log2(blocksize) bits filled in from
>> >your Truly Random bitsource.
>> >
>> >To remove the padding, read the message up to the last byte, use a
>> >mask to extract y, and discard the y previous bytes.
>> >
>> >Note that the scheme requires that blocksize be fewer than
>> >2**bitlength(byte) bytes, and works best if blocksize is a power of
>> >2.
>> >
>> >Does anybody see any weakness in this scheme?
>> >
>>
>> The main objection I see is the same when people bitch about the
>> "random bits" in a OTP. The weaknes is you have to count on having
>> such bits. I have nothing agains using random bits. But I prefer to
>> have a sound method with out the use of the "random god" and then add
>> random later.
>
>I don't see anything unsound about the method.
Well I do and until you write code and start testing
I see no point in continuing the argument you don't have
working code. If you ever get code then will or can run samples
and check. Which is what one can do with my code or Matts.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Mon, 30 Oct 2000 19:00:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : Tom=E1s?= Perlines 1Hormann <[EMAIL PROTECTED]> wrote:
>
> :> I am searching for a good PRNG in software, preferrable for FREE.
[...]
>
> :> Does anybody know a good URL???
>
> : http://www.fourmilab.ch/hotbits/generate.html
>
> : :-)
>
> That may be a good URL - but to save people visiting it
unnecessarily, it
> is linked to a hardware RNG which you can access over the web.
What is your point?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Mon, 30 Oct 2000 19:04:02 GMT
In article <[EMAIL PROTECTED]>,
Mike Connell <[EMAIL PROTECTED]> wrote:
>
> Erm,... this is what I first wrote:
>
> #1. a -> b : Pa
> #2. a <- a : Pb
> #3. a -> b : (Xa)Pb
> #4. a <- b : (Xb)Pa
> #
> #Then a and b compute the XOR of Pa,Pb,Xa,Xb. This gives them a
> #substantional number of shared secret bytes to construct a session
> #key from.
>
> I guess that it's technically not a step in the protocol itself, as
it
> is the result of the protocol. It is however, the entire point of
> doing the protocol ;)
>
> > Also what is to stop me from faking being one side of the
> > conversation? Unless a shared secret was negotiated before hand,
> > nothing.
>
> Isn't that what you just did? The reason I dont think it will work is
> that both parties have keybits, and the attacker can only get them
> from one party. However, if you can point out where the flaw lies, I'd
> be greatful ;)
You're missing the point. Not one step of your protocal stops me from
*completely* faking being one party. There is no trusted agent or
secret secret shared previously. I.e it's stateless when the protocal
begins.
>
> > It's a friggin law of nature my friend.
> > That is why things like EKE/etc... exist.
> >
>
> Otway-Rees? [Modified] Needham-Schroeder?
Law of nature says "you are you and I am me, then who is he?".
Essentially you can *say* "I am me" but how do I know that?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA Multiprime
Date: Mon, 30 Oct 2000 19:01:38 GMT
In article <8tk70d$n3t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Has anyone had much of a chance to work with the RSA Multiprime
version
> of the algorithm yet?
Technically RSA is always multi-prime.
The math does not change except you compute modulo multiple primes (i.e
N = pqr) and you find 'd' by e^-1 mod lcm(p-1,q-1,r-1)...
Some variants such as N = (p^r)q or N = Pq where P is much bigger then
q can be weak though...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do I detect invalid passwords?
Date: Mon, 30 Oct 2000 19:09:36 GMT
> No, that would defeat the point of using a strong password protocol,
I was only proposing the use of the strong password protocol to prove
knowledge of the hash, for that purpose it is quite suitable. However
it is
a valid point, and I'm sure there's some way around it, I'm just not
sure
immediately what it is.
> because the hash can be verified off-line. Generally all of these
> protocols will produce a shared secret, as well as authenticating the
> user. Use that shared secret to derive keys for encrypting, decrypting
> and/or authenticating any data that needs to be sent.
The immediate problem is that the shared secret is effectively one-time
(otherwise there are other attacks that can be mounted on the systems
involved).
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: RSA Multiprime
Date: Mon, 30 Oct 2000 19:13:30 GMT
In article <8tk70d$n3t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Has anyone had much of a chance to work with the RSA Multiprime
version
> of the algorithm yet?
>
> -Jeff
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
I suppose by this you mean: E=Public-Key, N=P*Q*R*...., D=Private-key
Well, the same maths should work, i.e. D=E^(0(n)-1) mod 0(n)
where 0(n) = (P-1)(q-1)(r-1).
I think that this construction is weaker than two prime RSA for a given
modulo size, because if you choose say three 250-bit primes to make 750
bit modulo then the two prime version would use 375-bit primes. I would
presume that the 375-bit primes would be more difficult to break than
250-bit primes.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: rc4 proprieties
Date: Mon, 30 Oct 2000 07:27:10 +0100
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> Dave Hazelwood
><[EMAIL PROTECTED]> writes:
>
> >It was never copyrighted or patented as the company chose to keep
> >it as a trade secret.
>
> copyright applies to trade secrets. copyright only applies to the
> explicit code, not to the algorithm (copyright is a protection of
> expression not idea.)
...also, copyright itself does _not_ need to be registered or anything
anywhere, you automatically get copyright to your creations even without
the (C) sign, so claiming that it was not copyrighted is not so true.
(Just a minor legal thing)
Regards,
Ichinin
(P.S: now we know why people patent Xor and Rotations...)
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Mon, 30 Oct 2000 11:25:45 -0800
"Trevor L. Jackson, III" wrote:
>
> Terry Ritter wrote:
>
> > And if you want to use overall network delays as your base, presumably
> > you will assure that the Opponents will not be reading the traffic on
> > the network. Otherwise, they can read the differences as well as you.
> > Better, probably.
>
> As I'm sure you know, the worst threat is not that the Opponents can read the
> differences better than we can. The worst case occurs when the Opponents control
> the differences. In that case our OTP pad "jest happens" to be a trivial pattern,
> and we'll ascribe the flaw to the exigencies of true randomness rather than enemy
> activity.
Fortunately, the enemy would have no access to the uncompensated clock
we're using to measure these delays by. He also would have no access to
our network card's oscillator. So while he could potentially reduce the
amount of randomness, he can't reduce it to zero. If you're worried
about this (and you should be) you can and should take more samples over
a larger interval. It may also help to let the randomness in your
earlier samples decide how and when you take your later samples, rather
than following a predictable process.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Mon, 30 Oct 2000 11:22:28 -0800
Terry Ritter wrote:
>
> On Sat, 28 Oct 2000 21:27:18 -0700, in
> <[EMAIL PROTECTED]>, in sci.crypt David Schwartz
> <[EMAIL PROTECTED]> wrote:
>
> >> However, this sort of "phase noise" is typically on the order of
> >> picoseconds, while the main clock is on the order of nanoseconds.
> >> This "phase noise" can of course be measured with special equipment.
> >> But such measurements are vastly, vastly below what can be measured by
> >> conventional software, which was the original claim, now conveniently
> >> recalled for us here:
> >>
> >> >>>For a more realistic counterexample, consider true quantum randomness
> >> >>>in the offsets between the CPU oscillator and the clock oscillator
> >> >>>on a network card. This can be measured in software.
> >
> > Actually, the original claim was:
> >
> >> There is NO way that ANY computer program can generate
> >> "absolutely random numbers". They will fail the test
> >> that they are generated by the formula; random numbers
> >> have the property that no rule not observing the actual
> >> numbers after some point does better than chance at
> >> predicting anything after that point. Computing is not
> >> the same as observing.
> >
> > I defy anyone to predict the result or demonstrate a statistical
> >randomness of less than 64 real bits from the MD5 checksum of 16 64-bit
> >TSC values sampled on the reply from pinging a computer 2 hops away on a
> >1Ghz Pentium machine. The algorithm must be: Sample TSC, ping, wait for
> >reply, sample TSC, ping, wait for reply, sample TSC, repeat until you
> >have 16 TSC samples (counting the first).
>
> Oh, please. Your claim was for "true quantum randomness." If you had
> that sort of randomness you would not need an MD5 checksum.
That's nonesense. Suppose I had a stream of bits where one in a million
of them were zeroes and the rest were ones. Suppose which ones were
zeroes and which were ones was due to true quantum randomness. You could
still predict the bitstream contents correctly all but one-in-a-million
times just be saying they're all zeroes. The MD5 sum ensures that the
entropy is distributed over all the bits evenly.
> And "I defy anyone" is the randomness equivalent of "break this, and
> if nobody does it must be secure." That is not cryptography.
If you can't show a weakness, you can't claim one.
> > The error in your analysis is that you forget that this phase error is
> >summed over many cycles. If I ping my router once and then ping it
> >again, the difference in the offset between the router's CPU clock and
> >my CPU clock from the first ping to the second will be the sum of the
> >phase errors over all the cycles inbetween the two pings.
>
> In the sense that one oscillator will have a slightly different
> frequency, there will be a constantly increasing phase difference over
> time (but modulo a full cycle only). If the period between pings is
> known externally, predicting the phase difference will be
> straightforward. That sort of predictable value is virtually useless
> in cryptography.
You know that's not what I'm talking about.
Imagine you have a 100Mhz clock and a 500Mhz clock. At the moment,
they're in perfect synch, that is, the 100Mhz clock always rises at the
same instant the 500Mhz clock does. Now you let the clocks run for 50
milliseconds. They'll no longer be in synch. There will be numerous
components to how far out of synch they are. If any of those components
reflect true randomness, then you are back the one in a million case
above. Even if every element is predictable save one, the final output
will be truly unpredictable at least some of the time.
> And although you handwave the ability to measure the phase difference,
> it will be interesting to watch you try. Ordinary equipment cannot do
> that because there is no need for that information. Normally,
> high-speed clocks are hidden, because it is quite normal for clocks to
> be somewhat different. The circuit design must handle this and hide
> it from the rest of the system.
It's easy. You measure the phase difference with reference to another
clock at much higher frequency. For example, you can measure the phase
difference between the two 100Mhz bit clocks in the network cards with
reference to the 1Ghz clock driving the processor. You just have to wait
long enough so that the accumulated thermal jitter has a 50% chance of
exceeding one clock cycle at 1Ghz.
> Note that this sort of constantly increasing phase has absolutely
> nothing to do with quantum randomness.
It's not increasing at a constant rate due to microscopic thermal
variations.
> > Yes, the error in a single phase is tiny, but very many phases occur
> >per millisecond and pings take on the order of milliseconds. So the
> >difference between the clock offset on the first ping and the clock
> >offset on the second ping is the sum of the phase jitter over hundreds
>
> First, "phase jitter" tends to be Gaussian and is BIPOLAR about the
> mean frequency. That is how we define the mean frequency from
> measured different values. So "phase jitter" does NOT add.
The jitter in it doesn't add linearly. It adds roughly as the square
root of the time, just like brownian motion.
> The phase difference between oscillators does increase, but only at a
> constant rate based on their different frequencies. That is expected,
> measurable, predictable, and virtually constant. It is not
> particularly useful, even if it could be measured.
Nonsense. The rate at which the ocillators run is subject to
microscopic thermal variation.
> >of cycles. And, of course, the two quartz clocks will jitter
> >differently.
>
> You cannot measure crystal oscillator jitter on a computer without
> special hardware support. It is ridiculous to even mention.
You just grab the TSC the instant a lower-speed oscillator triggers. If
the TSC is sufficiently faster than the other oscillator, then you can
grab the phase offset.
Imagine two 100Mhz state machines that hand data to each other. From a
1Ghz Pentium, I send a byte into the first state machine which hands it
to the second and then hands it back to me. If I grab the instruction
counter before and after, I can measure the phase offset between the two
100Mhz clocks to an accuracy of 10%. For more accuracy, I can just pass
it through more times. Since both 100Mhz clocks are independent of my
1Ghz clock, each pass is a separate trial, so I can measure the jitter
to any level of accuracy I want (although the jitter is changing, so
it's not clear what exactly I'm measuring, but accuracy is not the
problem).
DS
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Visual Basic
Date: Mon, 30 Oct 2000 07:34:24 +0100
Paul Schlyter wrote:
> Ouch !!!!!!!!!!!!!!!!!!!!!!!!!!
>
> Aren't there any static initialization of arrays in VB?
> I guess not... :-(
Jomenvisst:
Stuff = Array(1, 2, 3, ... , N)
For X 1 to (N)
Debug.print Stuff(x)
Next X
Regards,
Ichinin
------------------------------
** 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
******************************
