Cryptography-Digest Digest #31, Volume #13 Sun, 29 Oct 00 03:13:01 EST
Contents:
Re: Steganography books ("Our Man In K-Space")
Graphics and Encription (wtshaw)
Re: Psuedo-random number generator (David Schwartz)
Re: ciphertext smaller than blocksize ([EMAIL PROTECTED])
Re: Graphics and Encription (wtshaw)
Re: Psuedo-random number generator (David Schwartz)
Re: JAWS/JAWZ patent, and another one ("dixon mcknight")
Re: DMCA bans fair use (Sundial Services)
Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your ("John A.
Malley")
Re: Is OPT the only encryption system that can be proved secure? (Richard Heathfield)
Re: Is OPT the only encryption system that can be proved secure? (Richard Heathfield)
Re: Rijndael and PGP (Richard Heathfield)
Re: Psuedo-random number generator (Terry Ritter)
Re: DMCA bans fair use (Dido Sevilla)
Re: Psuedo-random number generator (Terry Ritter)
Re: Graphics and Encription (Dido Sevilla)
----------------------------------------------------------------------------
From: "Our Man In K-Space" <[EMAIL PROTECTED]>
Subject: Re: Steganography books
Date: Sun, 29 Oct 2000 02:43:39 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
> Yes, they do, but technically a spectral "line"
> is a very high concentration of energy in an
> extramly narrow bandwidth, a "delta" function
> as it were, as you would observe
> in the response of a gas. Solids generally have
> more spread out responses. They have spectral
> distributions, but they are not generally called
> "lines" since their distributions are more
> curvey than spikey.
bah humbug! spectral lines of a gas are a combination of gaussian and
lorentian curves, due to quantum uncertainty, pressure of gas and
doppler shifts. don't try tell me that loooks anything like a delta
function :P
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8
iQA/AwUBOfuO2mECkjbdfY7gEQJLVwCggcU31Zk8Bj2e8IVjLwdeOuDZtvcAnjNZ
eIzf/cRinKvVlzv7k5kq+uuG
=/vJo
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Graphics and Encription
Date: Sat, 28 Oct 2000 20:48:45 -0600
Regarding graphics there are some overlapping topics that deal with
efficiency for encryption per se and with providing room for
stegnography. For using stegnography, the perceived images must maintain
some integrity, but the eye is sufficiently poor that there is
considerable room for hanky panky.
A unversal side benefit of decreased resolution of graphics is efficiency
in file size, compression by throwing out useless information. But if
stegnographic information is to be added, being able to add back
information to a file is necessary.
Color presents its own problems, and I continue to make some progress
there, but it is with grayscale that things have really taken off in the
past few days. Obviously, in grays, color problems are eliminated
variables, something scientifically preferable.
Commonly two grayscales are used 16 grays, 4 bit, and 256 grays, 8 bits.
Beyond this statement bits don't mean a poot here, as you are shortly to
learn how to convert to many useful numbers of grayscales, and there are
several fairly justified ones that make good sense.
A few days ago, I reasoned this out: 256 is just an arbitrary number
grays, much too good for the eye, but 16 can look bad and grainy. My GIF
program handles 1, 2, 4, 8, 16, and 32 bits of colors or grays, which
includes 2, 4, 16, 64, and 256 grays. If given a fixed number of values
in the color table, pixels with other values will be assigned the closest
value allowed.
Therefore, all that you need do is construct a file with a sorted x number
of allowed grays, paste in a graphic with greater number, and
automatically the picture is reduced in resolution. I quickly produced
blank graphics files with 81 grays and 27 grays for eventual used with
trit graphics. Many others are possible, and I'll list them at another
time.
As predicted, two things were immediately evident, the eye cannot tell the
difference between 256 and 81 grays, and 27 grays is worlds better than
16. Too many believe that none can descriminate beyond 16 shades, but
that is bunk from some poor slob who wanted the world simplier than it is,
or someone with very poor eyesight.
Considering a small test file, and do not expect linear savings for large
files, it took 110K for a PICT file, 103K for 256 grays, 73K for 81 grays,
45K for 27 grays, and 38K for 16 grays. For simple graphics savings,
going to 81 grays from 256 makes sense. Less information stored as a
result of allowing only useful data means considerable savings, from the
example, 25%, with no deterioration of visual image. This is not
compression but is trimming the fat.
--
Pangram: Move zingy, jinxed products; hawk benign quality fixes.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 21:27:18 -0700
> 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).
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.
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
of cycles. And, of course, the two quartz clocks will jitter
differently.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ciphertext smaller than blocksize
Date: 28 Oct 2000 21:33:23 -0700
Zero-Knowledge MIME Encapsulated Message
--RSHFHMW98RSRCK72CIZH4C3US55GKB1A29ACB7QCTI69P6LS
Content-Type: text/plain
[EMAIL PROTECTED] (Marc) writes:
> Ciphertext stealing is a nice method for keeping the ciphertext
> size identical to plaintext size, when the plaintext is larger
> or equal to the blocksize of the algorithm.
It doesn't actually do this, if you count the size of the IV which
must be sent along with the ciphertext. If the IV can be sent out
of band, then it does work.
> Does anyone know a similarily clever method for handling plaintexts
> *smaller* than the blocksize? The only that comes to my mind is
> to pad the plaintext with zeros, encrypt it, and crop it to the
> plaintext size. Then the ciphertext can be built by XOR with
> the plaintext.
You can use a variant of ciphertext stealing here as well, again
wtih the caveat that you don't count the size of the IV. The
idea is that, on input, you do:
PT1 = plaintext padded with nulls
CT1 = E(IV xor PT1)
and then send CT1 as the IV, and truncate the IV to the length of
the plaintext, sending that as the ciphertext.
To recover, decrypt CT1 (what the decryptor thinks is the "IV") to get
IV xor PT1, and then xor with the truncated IV (what the decryptor
thinks is the "ciphertext") to recover the plaintext.
Ob
--RSHFHMW98RSRCK72CIZH4C3US55GKB1A29ACB7QCTI69P6LS--
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Graphics and Encription
Date: Sat, 28 Oct 2000 22:16:34 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> My GIF
> program handles 1, 2, 4, 8, 16, and 32 bits of colors or grays, which
> includes 2, 4, 16, 64, and 256 grays.
Oops!
64 grays would be 6 bits, but that would be doable with the technique I
describe. 8 bits is 256 grays, etc.
--
Pangram: Move zingy, jinxed products; hawk benign quality fixes.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 22:38:43 -0700
David Schwartz wrote:
> 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
> of cycles. And, of course, the two quartz clocks will jitter
> differently.
Actually, I left out another source of increase in the randomness.
Consider a ping generated by my computer's CPU. It then has to be sent
by network card, received by the other machine's network card, processed
by that machine's CPU, sent back out to that computer's network card,
and finally received by my network card. Each of those steps involves a
state machine driven by one clock shifting data to a state machine
driven by a clock coming from a different uncompensated quartz
oscillator. So the difference between the arrival delta of the first
ping and the second ping is the average phase jitter, multiplied by the
average number of cycles between the two samples, multiplied by the
number of times one clock switched to another.
If I ping a machine through a router, that will typically be PC,
network card, switch's network card, switch's CPU, switch's network
card, router's network card, router's CPU/fabric, router's other network
card, switch's network card, switch's CPU, switch's other network card,
my network card, my PC. That's 12 handoffs. Some switches only involve
one handoff instead of two. Ditto for some routers. So the actual number
can vary.
DS
------------------------------
From: [EMAIL PROTECTED] ("dixon mcknight")
Subject: Re: JAWS/JAWZ patent, and another one
Date: 29 Oct 2000 07:07:01 +0100
This if from the JAWZ SEC filing last November. Filings since then haven't
mentioned receiving the patent. Note that the algorithm has been "refined"
to address security and performance issues. This company got flamed on the
cypherpunk and coderpunk lists a couple years back when they hyped the
algorithm with a cracking contest.
http://www.secinfo.com/d1zf8a.67.htm
INTELLECTUAL PROPERTY MATTERS
JAWS has applied for patent protection in the United States. The US Patent
Office has confirmed receipt of the application and JAWS has qualified to
have its patent application reviewed and evaluated. JAWS has not
registered any of its trademarks, trade names or service marks but
has acquired the XMAIL tradename from British Telecom PLC. JAWS owns the
copyright in all the software created by its employees and the copyrights
which it has contractually acquired. JAWS maintains strict
confidentiality practices with its employees including contractual
obligations by the employees. JAWS' business is not dependent on a single
license or group of licenses.
BUSINESS OF THE ISSUER
JAWS has offices in Calgary, Alberta, Canada where it provides complete
information security solutions to its clients. These solutions include
the development of proprietary encryption software using the JAWS L5
encryption algorithm. The algorithm secures binary data in various
forms, including streamlining or block based data.
The L5 encryption algorithm was developed and refined over approximately 15
years by its inventor Jim Morrison. Jim Morrison was Chief Programmer at
JAWS from March 1, 1998 to April 20, 1999.
On October 20, 1997, JAWS Software Ltd. (a company controlled by Jim
Morrison) resolved to assign and assigned all of the right, title and
interest in the L5 algorithm, and other miscellaneous intellectual
property, to JAWS Technologies, Inc. (the Alberta corporation) (see Item 13
- Exhibit 10.1.10). In October 1998, during JAWS patent application
process, there was a further assignment of the L5 algorithm, and other
miscellaneous intellectual property,
to JAWS by Jim Morrison personally (see Item 13 - Exhibit 10.1.11) in
order to fulfill the requirements of the patent application process.
My attention was drawn to this company when I read this article. I had to
bookmark it for future reference as I watched the company's "progress."
http://www.informationweek.com/702/02iujaw.htm
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
--
Posted from [24.4.252.18] by way of f114.law10.hotmail.com [64.4.15.114]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
Date: Sat, 28 Oct 2000 23:15:20 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: DMCA bans fair use
Roger Schlafly wrote:
>
> The Digital Millennium Copyright Act (DMCA) is a US law that ...
Unfortunately the failure of this idea lies in the word "US." Nice idea
but there are several hundred other countries in this world where it
doesn't mean a hill o' beans.
If a cryptographic protection scheme is really going to be secure then
there is only one way to do it: make the cryptosystem actually secure.
Making laws that stipulate that certain forms of decryption are illegal
won't stop the decryption unless it's impossible.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your
Date: Sat, 28 Oct 2000 23:35:40 -0700
anish wrote:
>
[snip]
> I too would like to say the same about the thesis , search for the same
> turned out to be futile .
Someone suggested calling the MIT archives to request a copy for some
charge. Also, University Microfilms in Ann Arbor, Michigan, USA, has
copies of all US Ph.D. theses for sale at
http://www.umi.com/hp/Support/DServices/order/
I checked. Dr. Kaliski, Jr.'s Ph.D. thesis is NOT available from UMI.
Our only recourse is order his thesis from MIT - see
http://libraries.mit.edu/docs/theses.html
John A. Malley
[EMAIL PROTECTED]
------------------------------
Date: Sun, 29 Oct 2000 06:46:45 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >C compilers never even /see/ comments, because they're stripped out by
> >the preprocessor.
>
> Hopefully
No, it's guaranteed, and most implementations let you view and check the
preprocessor output if you prefer, and even feed preprocessor output
directly into the compiler rather than just trust the preprocessor to
pass the right thing in.
> >If you write your
> >programs as ISO C conforming programs, you can be /sure/ of one of two
> >things:
> >
> >a) your program will port correctly to another ISO C conforming
> >implementation, even on a completely different operating system, or
> >b) if it doesn't, you have a valid complaint against the compiler
> >vendor.
> >
> >I've never had to resort to b).
>
> Why are the bug reporsts even in gcc errors are being found
> and correct all the time.
gcc gets more peer review than any other compiler because the source is
available. Furthermore, because it is seen as being jointly owned by the
whole community, people are keener to improve it. And gcc has a lot of
users. And gcc is open about the existence of bugs, unlike some compiler
vendors.
Therefore: a) gcc probably gets more bug reports than other compilers
despite (probably) containing fewer bugs.
b) gcc's bugs get fixed very quickly in comparison with other
compilers.
c) all compilers approach ISO C asymptotically - they'll get
closer and closer without ever quite managing it. gcc has approached it
very closely indeed, and approaches it ever closer with each passing
day.
> SHall we let this threas die too. Or do you always have to have the
> last word.
Always? No. I'm easy with 50-50.
--
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
------------------------------
Date: Sun, 29 Oct 2000 06:53:45 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
"Trevor L. Jackson, III" wrote:
>
> Richard Heathfield wrote:
>
> > That's the marvellous thing about the ISO C Standard. If you write your
> > programs as ISO C conforming programs, you can be /sure/ of one of two
> > things:
> >
> > a) your program will port correctly to another ISO C conforming
> > implementation, even on a completely different operating system, or
> > b) if it doesn't, you have a valid complaint against the compiler
> > vendor.
> >
> > I've never had to resort to b).
>
> This belongs in another news group with the rest of the enclosing thread.
Agreed. I really should stop fighting with Mr Scott. It must be terribly
dull to watch.
> NTL,
> this statement amounts to the claim that you've never encountered a bug in a C
> compiler claiming ISO conformance. There could be many reasons why this claim
> might be true.
Indeed. For example, someone who has never written a C program could
claim the same thing. :-)
Lack of bugs in C compilers claiming conformance is not one of
> them.
Right. I don't think there's such a thing as a perfect implementation,
but I do think they get closer and closer, and I think that the bugs
that do exist tend to be round the ragged edges of the Standard, where
interpretations vary about what the Standard actually means.
Anyway, like you said, it's terribly off-topic and I should shut up, so
I will.
--
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
------------------------------
Date: Sun, 29 Oct 2000 07:06:09 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
JPeschel wrote:
>
> Richard Heathfield [EMAIL PROTECTED] writes:
>
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >That's not what he said. He said "thrown", not "throne". It was a pun,
> >which is a kind of joke based on homophones which have distinctly
> >different spellings and meanings.
> >
>
> A pun? I'd say Ashwood accidentally misspelled throne, as "pretender
> to the thrown" doesn't make any sense. Doesn't seem to qualify
> as a humorous non-sequitur, either.
I thought it was funny. I guess I must just have a weird sense of
humour.
Worse, did I credit Ashwood with a weird sense of humour too?
--
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: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Psuedo-random number generator
Date: Sun, 29 Oct 2000 07:42:03 GMT
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.
And "I defy anyone" is the randomness equivalent of "break this, and
if nobody does it must be secure." That is not cryptography.
> 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.
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.
Note that this sort of constantly increasing phase has absolutely
nothing to do with quantum randomness.
> 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 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.
>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.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DMCA bans fair use
Date: Sun, 29 Oct 2000 15:47:14 +0800
Sundial Services wrote:
>
> Roger Schlafly wrote:
> >
> > The Digital Millennium Copyright Act (DMCA) is a US law that ...
>
> Unfortunately the failure of this idea lies in the word "US." Nice idea
> but there are several hundred other countries in this world where it
> doesn't mean a hill o' beans.
>
That is total BS. The United States wields such a great deal of power
in today's world that legislation that happens in America winds up
affecting the rest of the world more than anyone realizes, though
technically, it shouldn't. If the DMCA really is just a U.S. law, then
why in the name of all that is holy did Jon Johansen, who isn't a
citizen or even a resident of the United States, get hassled the way he
is just because he publicized DeCSS? Take note, he didn't even *write*
the bloody thing. True, the law may not be worth a hill o' beans in
Norway, but the kid got arrested and is under trial just the same. Why
are even non-US sites being harassed for even linking to the DeCSS
code? Like it or not, the United States and especially its corporations
do have the kind of power to enforce their laws overseas if they see
fit, and national borders don't mean a hill o' beans to them. To those
of us who live in the Third World, the key words are "grand
Imperialism."
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Psuedo-random number generator
Date: Sun, 29 Oct 2000 07:52:00 GMT
On Sat, 28 Oct 2000 22:38:43 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>David Schwartz wrote:
>
>> 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
>> of cycles. And, of course, the two quartz clocks will jitter
>> differently.
>
> Actually, I left out another source of increase in the randomness.
>Consider a ping generated by my computer's CPU. It then has to be sent
>by network card, received by the other machine's network card, processed
>by that machine's CPU, sent back out to that computer's network card,
>and finally received by my network card. Each of those steps involves a
>state machine driven by one clock shifting data to a state machine
>driven by a clock coming from a different uncompensated quartz
>oscillator. So the difference between the arrival delta of the first
>ping and the second ping is the average phase jitter, multiplied by the
>average number of cycles between the two samples, multiplied by the
>number of times one clock switched to another.
Quantum phase jitter certainly is not multiplied by the number of
cycles between samples. Only the mean phase difference is multiplied,
and that is a an expected constant rate difference, which is also
exposed by the timing of network traffic.
Synchronization delays will add, but that is deterministic, not
quantum.
> If I ping a machine through a router, that will typically be PC,
>network card, switch's network card, switch's CPU, switch's network
>card, router's network card, router's CPU/fabric, router's other network
>card, switch's network card, switch's CPU, switch's other network card,
>my network card, my PC. That's 12 handoffs. Some switches only involve
>one handoff instead of two. Ditto for some routers. So the actual number
>can vary.
Yes, and every time you do it you get pretty much the same result.
You can't measure the amount of quantum randomness which exists with
ordinary computing equipment.
There may be some variation depending upon synchronization delays.
That is not a quantum randomness issue, however, so this can be
modeled and predicted.
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.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Graphics and Encription
Date: Sun, 29 Oct 2000 15:51:53 +0800
wtshaw wrote:
> Oops!
>
> 64 grays would be 6 bits, but that would be doable with the technique I
> describe. 8 bits is 256 grays, etc.
By the way 64 gray levels is good enough for most people; i.e. a picture
that has 64 gray levels is for most people practically indistinguishable
from a continuous tone black and white photograph. Any more than that
is too much and has more information than most human eyes can
distinguish. The only reason why 8 bits (256 grays) is used universally
in computer graphics is because most computers have a bias towards
working with 8 bits at a time, and it's much more convenient to do so
than to have 18 bits for an RGB triple... And hence, great
possibilities for stego. I think the key document here is the
Colorspace-FAQ.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
** 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
******************************
