Cryptography-Digest Digest #999, Volume #10 Sat, 29 Jan 00 10:13:01 EST
Contents:
Re: "Trusted" CA - Oxymoron? (Topher)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Vernon Schryver)
Q: DFT (Mok-Kong Shen)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Guy Macon)
Re: How to password protect files on distribution CD (Dave Mundt)
Re: Q: DFT ([EMAIL PROTECTED])
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Block chaining (SCOTT19U.ZIP_GUY)
Re: Mac encryption algorithm? (Paul Schlyter)
IDEA (Arie Gerszt)
Re: Help needed on peculiar use of cryptography (SCOTT19U.ZIP_GUY)
Re: NEC claims New Strongest Crypto Algor (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Topher)
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Fri, 28 Jan 2000 14:41:55 GMT
On Fri, 28 Jan 2000 05:15:14 GMT, Anne & Lynn Wheeler
<[EMAIL PROTECTED]> wrote:
>for the most part, the bank doesn't care what your DNA is ... they
>just care that only the person that open/own the account & is
>authorized to use the account ... is the person that uses that
>account.
They don't even care about that. What they care about is that any
transactions they make (transfers of money on your orders) aren't
repudiated in such a way that they have to take the loss.
--
Topher
Intranet Inc.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Date: 28 Jan 2000 10:14:42 -0700
In article <[EMAIL PROTECTED]>,
Sandy Harris <[EMAIL PROTECTED]> wrote:
> ...
>From here it looks as though you're advocating at least three clearly
>nonsensical propositions:
>
> 1) clock drift has enough randomness to be interesting for
> cryptographic purposes
>
> 2) a protocol involving connections to an Internet time server
> can be secure enough to trust for cryptographically important
> random numbers
>
> 3) IPSEC or other cryptography can solve problem 2
> ...
>As for your third point, it traps you in a vicious circle. IPSEC and most
>other cryptographic protocols require random numbers. If you need IPSEC
>to generate your random numbers, you're sunk.
>
>I'd suggest you read RFC 1750 and mull over it a while.
There are bigger reasons rooted in RFC 1305 that make the idea
obviously silly and ignorant.
NTP does not need or want IPSec. NTP timestamps have carried optional
authenticators since long before the IPSec effort was started in the IETF.
They were originally based on DES. In typical NTP implementations there
is elaborate machinery to compensate for the errors that computing those
authenticators would otherwise cause. I'm not sure I agree, but it seems
Dave Mills (Father Time in the NTP world) would figure that using IPSec
would mess up NTP significantly, because the IPSec rigamarole is both much
larger than NTP's authenticators and not easily factored into NTP ticks.
One of the unfixable vulnerabilities of using NTP error signals over the
Internet to generate random numbers has absolutely nothing to do with
enemies changing bits in timestamps or forging them. It is that NTP error
signals depend on both the difference between the two clocks and the
difference or assymmetry in the delays from the client to the server, and
from the server back to the client. NTP cannot tell distinguish between
a 1 second error in the client clock and a 1 second difference between
the delay sending packets to the server and the delay receiving responses
from the server.
If an enemy discovers that your NTP packets pass through a router, then
the enemy can probably load one of the two output queues of that router
with traffic that goes no closer than that router to either the NTP client
or server. One way to do that is with ICMP Echo-Requests and -Responses
or with UDP packets and ICMP TTL-Exceeds, as with `ping` or `traceroute`.
If the average size of one output queue is increased by 0.01 packet, then
the error signal reported by NTP will increase or decreased by 0.01 of
the wire-occupancy of the packet at the router, with the sign of the change
depending on which queue is increased. The wire occupancy of a 1000 byte
packet at 1.54 Mbit/sec is more than half a millisecond. If your enemy
increases the load of one T1 port of a router in the path of your packets
by 1%, your enemy will have changed your NTP error signal by 50
microseconds. I don't know much about thermal noise, but 50 usec sounds
like enough to swamp the supposed random value.
Of course, none of this affects other killers for the idea of using NTP
for random numbers. Would you want a time keeping program that involved
several packets per second? People with the least clue about NTP doesn't
know that NTP involves packets about every 90 seconds. They also know
that the total error signal every 90 seconds only few of bits. Even if
NTP error signals were not known to be dominated by changes in temperature
and by operating system hassles, who would care about a few random bits
every 90 seconds? There's also the problem that NTP comparing the total
number of oscillations of two crystals after 90 seconds does not seem
likely to get close to what was described as Brownian motion.
Never mind that NTP syncrhonization of cheap PC clocks as close as
50 usec over the Internet without any enemy interest is something
to write home about.
Note that I've been interested in synchronizing computer clocks for a
while. For example, in 1972 or 1973, I distributed ticks from some
ovenized clocks in a small network. The clocks were very poory sync'ed
to the primary atomic standard for the U.S., which was a few hundred feet
way in the same building.
--
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: DFT
Date: Sat, 29 Jan 2000 11:56:27 +0100
DFT, like all such transforms, has an inverse. However, due to the
unavoidable rounding errors of real computations involved, a vector
of integers might not get back to exactly the same values. What
techniques can one best employ to obtain an exact inverse?
(Simple employment of multi-precision arithmetics might not be a
reasonable cure in all cases, I surmise.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Date: 29 Jan 2000 05:51:10 EST
In article <86tbei$tkb$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Michael Kagalenko) wrote:
>
>Michael Sierchio ([EMAIL PROTECTED]) wrote
>]Sandy Harris wrote:
>]
>]> Ritter and Schryver appear to have understood you completely and to have
>]> demolished your first two points rather thoroughly. If anyone is failing
to
>]> understand, it seems to be you.
>]
>]Precisely.
>]
>]Anyone with half as much brainpower as confidence knows that these two
fellows
>]have earned their chops and have studied the matter. I would treat an
>]admonishment from either of them as an act of grandmotherly kindness, and
>]leave it at that.
>
>
> Thier alleged experience fails to instill in me any awe, considering
> blatant and obvious errors they make in every reply to my posts.
>
You DO know the joke about the drunk driving the wrong way on
the freeway, don't you?
------------------------------
From: [EMAIL PROTECTED] (Dave Mundt)
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sat, 29 Jan 2000 10:55:32 GMT
I concur. Hence the reason that SOME companies resort to the
hardware solution of a "dongle", a hardware key that hangs off the
parallel port and is queried by the software to see if it can run.
These things are an adequate solution, but, inconvenient for the
user, and, are guarenteed to shut them down when damaged. Also,
although the technology workes pretty well now, there can be conflicts
that make it hard to print through these devices.
I wonder, though, WHY you think this is necessary? It would be
much simpler to distribute the software, and, like most other software
packages, require a license number to be entered before it can install
or run.
Seems to work for Microsoft well enough...
Regards
Dave Mundt
Johnny Bravo <[EMAIL PROTECTED]> wrote:
>On Fri, 28 Jan 2000 18:02:17 -0800, GJJ
><[EMAIL PROTECTED]> wrote:
>
>
>>BTW - I have no personal or professional interests in the above
>>companies and have not tried any of their products so I can't vouch for
>>them...
>
> I can; copy protection can't.
> There is no possible copy protection that can't be recopied or bypassed.
>If nothing else than by distributing the encrypted files with a valid
>decryption key. For those silly schemes where the customer's name is used
>to make an encryption key, a key generator is easy enough to reverse
>engineer as the program has to take the customer name, compute the same
>key to compare it against the entry. Anything the computer can do, a
>cracker can duplicate, then put it into a program that does the same
>calculations and generates the keys.
> For larger and more complicated programs, for some it will be worth the
>cost to purchase a bound manual and tech support. Some companies are
>offering an outstanding product for free and making money of the support,
>ala Sun Systems and the massive package Star Office.
>
> Best Wishes,
> Johnny Bravo
>
Remove the "REMOVE_THIS_" from my email address to get to me...
I hate Cullers who gather from newsgroups
Visit my home page at http://www.esper.com/xvart/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: DFT
Date: Sat, 29 Jan 2000 12:02:53 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> DFT, like all such transforms, has an inverse. However, due to the
> unavoidable rounding errors of real computations involved, a vector
> of integers might not get back to exactly the same values. What
> techniques can one best employ to obtain an exact inverse?
> (Simple employment of multi-precision arithmetics might not be a
> reasonable cure in all cases, I surmise.)
>
> M. K. Shen
>
Have you measured the error between the original
integer sequence and the real sequence got back from inverse-DFT ?
Maybe it is sufficient to apply a rounding to the
real sequence obtained from I-DFT to yield the original
integer sequence.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 07:10:50 EST
In article <86taml$2nk$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Michael Kagalenko) wrote:
>
>Guy Macon ([EMAIL PROTECTED]) wrote
>]In article <86qqvg$l1o$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>](Michael Kagalenko) wrote:
>]
>]> Again nope. This cycle-by-cycle period variation produces clock drift,
>]> which grows with time. Precisely how it does so can be evaluated using
>]> fluctuation-dissipation theorem. If I feel like it, I might even do
>]> the computation one day.
>]
>]This flies in the face of my 20 years of experience as an Electronics
>]Engineer, including working with high precision time references at
>]Odetics and CD/DVD jitter measuring circuits at Disc Manufacturing, Inc.
>
> You did not see what I describe because you weren't looking for it.
> The good place to look would be metrology publications.
I was in charge of metrology at Perkin-Elmer Wangco, and did some very
advanced netrology work for Parker-Hannifin. I am well aware of the
literature. Do you have a citation for me, or just as assertion?
And don't tell me what I have or have not looked for. You don't know.
For your information, the CD and DVD mastering industry uses the
best possible methods of heasuring jitter. Most of the veryu high
end test equipment was designed to meet our stringent needs.
>]What causes clock drift (two clocks with diverging ansers as to what
>]time it is) is simply the difference between the actual and desired
>]frequency.
>
> That is one reason. The other reason is the presense of dissipation
> in resonant system, or, in other words, wide resonance curve. Atomic
> clocks are more precise because they make use of very narrow resonance
> curves.
You are confusing precision with accuracy.
>] Easy to correct for.
>
> Then why GPS satellites bother with atomic clocks ? Just get
> some thermostabilized and recalibrated quartz clocks.
Because you can't correct for somethiong if you lack a reference
to compare it with.
>] What causes the frequency to drift
>]is the physical aging of the crystal.
>
> That's much slower process than thermal drift.
In a thermostabilized circuit? Or would you prefer a corollation
between the numbers you get and the room temperature?
>
>] If it was caused by a brownian
>]style drift caused by jitter (what you call "cycle-by-cycle period
>]variation"), the frequency would reset when I turned off the
>]electronics overnight.
>
> You don't understand the point I am making. The frequency doesn't
> get "reset" if you turn off the circuit. In fact, average
> frequency does not change.
If it doesn't get "reset" if you turn off the circuit overnight,
it isn't thermal.
> I estimate I said that 5 times or so already.
You need to learn the difference between repeating an assertion
again and again and responding to legitimate objections.
I need more than "Michael Kagalenko says so" before I will
deny what I have seen with my own eyes.
>] Brownian motion of particles has memory (the
>]position of the particle).
>
> Precisely wrong. Brownian motion has no "memory" of any kind.
Bullshit. Brownian FORCE has no "memory" of any kind.
Brownian MOTION (position over time) has "memory", and
plenty of it.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 07:23:07 EST
In article <86tava$2el$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Michael Kagalenko) wrote:
> I am not interested in discussing coin tosses.
I would't either if I were you. I just blew your argument out
of the water, so you are "not interested in discussing" it.
> So far, you seem to have finally acknowledged that simply
> counting the number of quartz cycles per time interval
> (measured by more precise means) can allow to recover truly
> random data.
Evidence, please. You are claiming that I at some point said
the opposite. Go ahead and try to find the quote instead of
just making things up. What I said and have always said is
that everything has a true random component. I also said
that such true randomness is very hard to glean from things
that only appear to be random, and that you have chosen a
method with a VERY small true random component.
> You seem to be backtracking on your
> earlier flat denial that this happens,
Prove it. Give me the message ID of this "flat denial"
that you have fabricated out of thin air.
>and now claim that it is simply too small to be measured.
As I have always claimed. Prove otherwise.
>This latter position is not correct either, but we'll get to that.
This from someone who has never laid a finger of a jitter test set.
Amazing.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 07:30:26 EST
In article <86tbj6$4pc$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Michael Kagalenko) wrote:
> Well, once again, the claims that you make are incorrect. The thermal
> drift that I am speaking of exists.
Prove it. You are saying that thermal drift is brownian. I say that
I have measured it and it isn't. Did you measure it? Can you give me
a name of someone who has? I think not.
>]I can tell you why you are wrong. You have failed to understand
>]the effect of increased international travel on language diversity.
>]Once you become an expert on this you will see that quartz crysyals
>]don't act the way you think they do. If you disagree with me, it's
>]because you don't know enough sociology and linguistics. Do your
>]homework. Please, retake your classes in these subjects once again,
>]this time paying attention.
>]
>]See? I can do it too!
>
> You may have an experience in Electrical engineering, however , you
> do not understand statistical physics required to appreciate my point.
> It's as simple as that.
That's really funny! I parody your sophmoric debating trick and you
reply by doing it again! You aren't fooling anyone, you know.
Since when does it take statistical physics to look at a value
recorded over time and determine whether the variation is gaussian
or 1/F (what you call "Brownian")? A first year technician can
tell the difference.
Are you SHURE that you heard the joke about the drunk driving
the wrong way on the freeway?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Block chaining
Date: Sat, 29 Jan 2000 15:08:57 GMT
In article <Ritk4.254$[EMAIL PROTECTED]>, "Adam Durana"
<[EMAIL PROTECTED]> wrote:
>I came up with a new method of block chaining, which I call "broken block
>chaining" or BBC. Maybe it needs a new name? Here is how it works.
>
>We have a cipher with a 128 bit block size. The chaining uses two sizes, a
>large block size, which is 128 bits in this case, and a small block size,
>let this size be 8 bits. First you take 128 bits of plaintext, encrypt it,
>then you take the first 8 bits (small block size) from the left of the
>ciphertext and save it, write it to a file, or whatever, this is the output.
>You then move the remaining 120 bits over to the left so there are 8 bits of
>free space on the right. Take 8 bits of plain text and fill in the 8 bits
>of free space. Then with that 128 bits of data encrypt it again. Take the
>first 8 bits from the left side of the cipher text and continue to repeat
>the process until there is no more plain text.
>
>So what do you think of this? Obviously it will take longer than current
>methods of chaining, and what the "small block size" is set to will directly
>affect the speed. I like this because if you use a good cipher you can
>spread data accross all the data after it, and several bits before the data.
>
I like the basic idea. But if I were to use it I would treat the file as a
ring so that 2 passes occur making the data spread through the whole
file not just trailing portions.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Mac encryption algorithm?
Date: 29 Jan 2000 14:14:24 +0100
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> Then again, probably because the designers had PCs at hand,
> a few crypto algorithms are little endian.
Little endian was around before the PC was introduced. Some people
are surprised to learn that the good ol' Apple II was little endian
(as opposed to the Macintoshes, which are big endian).
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Arie Gerszt <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: IDEA
Date: Sat, 29 Jan 2000 14:24:59 GMT
Hi
I am a student from Switzerland. I was
searching for a good resource concerning
the IDEA encryptio algorithm. I was looking
for a C/C++ source for compiling under Linux.
Does anybody have some good links, hints or
other resources concering IDEA and linux?
Thanks for your help,
regards arie
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Help needed on peculiar use of cryptography
Date: Sat, 29 Jan 2000 15:19:17 GMT
In article <86t26p$8vq$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
>Sgwbutcher <[EMAIL PROTECTED]> wrote:
>> I think the most important points are (1) this is permanent encryption--is no
>> "legitimate" reason why the cyphertext would ever be decrypted and (2) the
>> domain of the plaintext is very small, 0-9 and short length cyphertext and
> (3)
>> the information value of the cyphertext should be the same as the plaintext,
>> that is, if plaintext A identifies a particular record over 5 years, then
>> cyphertext A should reference the same records and no others.
>
>You might have the company pick a very long, fixed string and keep that
>string secret. Then concatenate this string, or "salt", with each of
>the ID numbers.
With a long string or salt as you call it you are risking that more
than one ID could map to the same hash. In reality you can never fully
hide the encrypted ID since it would have to be unique if it was to match
unique records. I would not use a hash for this kind of work where zero
collisions are required.
>
>Feed the result to a one-way hash function. One such candidate is
>SHA-1. It will be very difficult (almost impossible) to retrieve
>the original ID number from the result. At the same time, one
>ID number will map to one ciphertext, and the same one everywhere.
>So you will be able to do your work.
>
>The reason the company picks a "salt" is to prevent you or anyone
>else from guessing identifiers and feeding them to the hash function.
>That is, it prevents someone from computing hash(1001) and looking
>for the result in your documents. The company must keep this salt secret
>for as long as the data is valuable..but I think that's the only secret
>they have to keep.
>
>Code implementing SHA-1 is available in a variety of languages. A web
>search will turn up some of them, I think.
>
>How does this sound?
>
>Thanks,
>-David
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Sat, 29 Jan 2000 15:30:02 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John Sa
>>
>> But if there were some way to place that kind of obstruction in the
>> cryptanalysts' path without such a simple way to avoid it, it would be
>> useful. Creating "fake" keys that aren't used would be useless, but
>> that may be another matter entirely.
>>
>I've brought this up before, but it is relevant: One can manufacture a
>key that will work in the GVA for a given block, but it will be wrong.
>Perhaps, you could do it for two, but it would be wrong.
>
>The problem is exactly what you want, dangling the appearance of success
>before the cryptanaylist, then dashing the house of cards with the next
>block. In all of this, I assume reasonable security in generating a good
>set of keys to begin with.
It would be quite possible to any one who exaimed my contest that in method
such as scott19u can have many fake keys. That is you encrypt your message
with the secret key of your choice. And than you create a false key be taking
some safe message and generating a key that would casue the fake message
to be mapped to the same cipher text. This is quite easy when one has over
a million bytes of key space for most messages. You could then leave the fake
key around for someone on a fishing expedition to find and they would think
they discovered something hot. But this whole approach relies on one useing
decent encryption. The short keyed AES methods that the NSA wants fools to
use would never have keys long enough to do this kind of real encryption.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
** 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
******************************
