Cryptography-Digest Digest #16, Volume #11 Sun, 30 Jan 00 16:13:02 EST
Contents:
Re: A Stronger VIC Cipher (was Re: Pencil & paper cipher question) (David Wagner)
Re: Clock drift (was Intel 810 chipset Random Number Generator) ("Trevor Jackson,
III")
Re: Clock drift (was Intel 810 chipset Random Number Generator) ("Trevor Jackson,
III")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Keyword Cipher Cracker program (RREYNARD)
Re: Keyword Cipher Cracker program (RREYNARD)
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Q: DFT (Mok-Kong Shen)
Re: A question about odd grilles (Mok-Kong Shen)
Re: How to password protect files on distribution CD (Dave Howe)
Re: Help needed on peculiar use of cryptography ("Trevor Jackson, III")
Re: *** ECC Strong and Weak combined ("Harvey Rook")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A Stronger VIC Cipher (was Re: Pencil & paper cipher question)
Date: 30 Jan 2000 10:47:01 -0800
In article <8712k4$8f6$[EMAIL PROTECTED]>,
r.e.s. <[EMAIL PROTECTED]> wrote:
> After mulling this over a bit more, I wonder if, instead of literally
> making the seed longer (with all the adjustments that entails), it may
> be better to simply use additional passphrase letters to define two
> independent 10-digit substitution tables to add confusion to the
> transposition keys extracted from the LSFR output. (Details below.)
> This will add about 44 bits of entropy to the 10-digit seed's 33 bits, [...]
If I guess the LFSR's initial fill (2^33 trials), I can recover the inputs
to the transposition tables. (Right?) Is there a way to recover information
about the tables given their inputs, the ciphertext, and a statistical model
for the plaintext and the passphrase?
Here's one approach one might try. Look for repeated table inputs. They
cause the table outputs to repeat in the same positions. Then, I can check
whether that patten of repeats in the keystream looks plausible given the
ciphertext. Does this provide enough information that I can expect to rule
out wrong guesses at the initial fill? If so, that's an O(2^33) break.
------------------------------
Date: Sun, 30 Jan 2000 14:53:55 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
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.
In many cases there is some question as to which side of an issue contains the
error. In this particular case, however, there is no remaining question. I
suggest you inspect the issue very carefully. In a mirror.
------------------------------
Date: Sun, 30 Jan 2000 14:59:22 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Vernon Schryver wrote:
> 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.
Are you able to provide any numeric results of this effort? Specifically, can
you quantify the "very poorly sync'ed" statement in terms of
mean/deviations/extrema?
Numbers have a refreshing concreteness about them.
------------------------------
Date: Sun, 30 Jan 2000 15:14:25 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Guy Macon wrote:
> 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.
He appears to be referring to the accumulated phase change. In an analogue
signal the accumulated change in phase would perform a 1-D random walk about
the initial position. However, this rests on several questionable
assumptions about the distribution of the changes (the steps in the walk)
he's proposing to measure. It also requires that all other effects be held
rigidly constant, which isn't going to happen on a PC.
I haven't munched any of the math but it appears to me that the Nyquist
period for the signal he wants to use is several orders of magnitude of
seconds. 3-6 by (weak) intuition. I haven't done any of the math because
in principle the effect he's describing is questionable; in practice it is
fatuous on the face of it.
One might as well be measuring the decay of the oxygen isotopes in the
quartz. Theoretically this will change the frequency of the crystal, and do
so in a discrete, monotonic way.
------------------------------
From: [EMAIL PROTECTED] (RREYNARD)
Subject: Re: Keyword Cipher Cracker program
Date: 30 Jan 2000 20:14:20 GMT
In article <[EMAIL PROTECTED]>, Glenn Larsson
<[EMAIL PROTECTED]> writes:
>This sounds a bit like the "Known-Structure-Plaintext
>Attack" thingy i wrote on these ol' ciphers back in 1999.
Actually, although it is really not important, the Keyword Cipher Cracker
program is nothing like a "Known-Structure-Plaintext Attack."
The Keyword Cipher Cracker is a 'brute-force' attack on a very specific type of
monoalphabetic cipher, one that uses a keyword (beginning at the letter A) to
generate the cipher alphabet. For example, the cipher alphabet for a ciphertext
whose keyword is 'SECRET" would be - SECRTABDFGHIJKLMNOPQUVWXYZ.
The 25,000 word word list (keyword list) is just a list of common English
words. The program merely searches through the list and 'deciphers' the
ciphertext using every word in the list looking for reasonable plaintext. It
displays on the screen, the top 10 candidates.
As I mentioned in my initial post, it is intended to be a learning tool for
the novice cryptanalyst and to generate interest in cryptography (as is this
reply).
Regards,
Robert Reynard
Author, Secret Code Breaker series of crypto books for young readers (8-16 yr.)
Secret Code Breaker Online at ==> http://codebreaker.dids.com
------------------------------
From: [EMAIL PROTECTED] (RREYNARD)
Subject: Re: Keyword Cipher Cracker program
Date: 30 Jan 2000 20:14:20 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
writes:
>but Bletchley Park has been turned into a museum.
For those unfamiliar with it's location, Bletchley Park is located in England,
about 90 miles north of London and a few hundred yards from the Bletchley train
station. Bletchley is a small village very close to Milton Keynes.
It is open every other weekend. Information can be found at numerous websites
including the following two -
http://www.bletchleypark.org.uk
http://www.cranfield.ac.uk/ccc/bpark/
Regards,
Robert Reynard
Author, Secret Code Breaker series of crypto books for young readers (8-16 yr.)
Secret Code Breaker Online at ==> http://codebreaker.dids.com
------------------------------
Date: Sun, 30 Jan 2000 15:25:04 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
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.
>
> ]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.
>
> ] Easy to correct for.
>
> Then why GPS satellites bother with atomic clocks ? Just get
> some thermostabilized and recalibrated quartz clocks.
>
> ] What causes the frequency to drift
> ]is the physical aging of the crystal.
>
> That's much slower process than thermal drift.
>
> ] 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. I estimate I said that 5 times or so already.
>
> ] Brownian motion of particles has memory (the
> ]position of the particle).
>
> Precisely wrong. Brownian motion has no "memory" of any kind.
Have you ever watched true Brownian motion in a microscope? I did it in 6th
grade. Your mileage may vary.
The position of the moving particle is exactly the same kind of memory as the
memory of a crystal oscillator. The crystal has a physical configuration
composed of position and motion. It is this state (memory) that produces the
harmonic behavior that is the usually purpose of crystal oscillators.
You have confused the "memoryless" source of the Brownian motion, molecular
impacts, with the "memoryful" state of the particle under observation.
Either that you you believe the Brownian motion is an example of quantum
tunneling. Was it a mistake or are you hearing voices?
I suspect the stress of being wrong is getting to you.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: DFT
Date: Sun, 30 Jan 2000 21:24:28 +0100
Douglas A. Gwyn schrieb:
>
> Mok-Kong Shen 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?
>
> Most cryptologic applications of DFT of which I am aware use a
> DFT over a finite field, which is an exact operation with an
> exact inverse.
As far as I understand, one has in general to employ multi-precision
arithmetics. I would like very much to know whether it is possible
to say something concerning the relation between a (given)
employed precision and (certain characterization of) the data in
computations giving exact inverse of the DFT transform. In particular,
if one uses the single precision (say with 32 bits on PC), is it
possible to say that one can do DFT on certain data (i.e. belonging
to certain specifiable category) and is guaranteed to be able to get
the exact inverse?
M. K. Shen
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A question about odd grilles
Date: Sun, 30 Jan 2000 21:24:18 +0100
Boris Kazak wrote:
>
> One workable solution can be to use this central hole right during the
> first quadrant positioning, and ignore it during the 3 remaining
> quadrants. This is easy to do while encrypting and while decrypting.
But this means that the plaintext character put in at that location
is fixed, i.e. does not move as do the other characters taking part
in the whole transpositon effected by the grille. Hence, it seems
better to either ignore it or to put in a null there.
M. K. Shen
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sun, 30 Jan 2000 20:31:51 +0000
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Sun, 30 Jan 2000 02:07:24
GMT]), [EMAIL PROTECTED] (Dave Mundt) said :
> This is true. The fact of the matter is that NO encryption scheme
>is totally impervious to attack. However, the point is, of course, to
>make it simpler for the average user to bite the bullet, whine and pay
>the cost of the dongle.
Hmm. I don't know about the average user, but it is not THAT unusual
for me to buy the full, legal copy, but use the crack anyhow - I have
external parallel-port devices (CDR writer and scanner) that don't
like having the dongle there, and then there is the risk of physical
damage to my parallel port from sheer weight of dongles. If I ever get
raided (not much chance) I have box, original CD, dongle and receipt
to show them - I can't see myself in violation of anything but the
click-install licence, and they aren't enforcable in .uk....
Moreover, the "I will fully install, but will require the CD in the
drive to use me" thing sucks. It's ok for games (I am only doing ONE
thing then, playing games, and want as much junk kept there and not on
my HD as possible) but if I want to use two or three editing packages
on the same files, the cd-rom swapping gets tedious (and I can't use
my external drive if I want to use the scanner)
I don't mind the "personalised key" approach of mIRC and similar
packages though - it's *my* key, so having *my* name on it is no
problem.
>
> This is a reasonable point. However, the original post DOES talk
>about shipping software out in encrypted form, so only a given
>customer could use it. They also imply that they want to do something
>like sending out a software package with many functions (say, G/L,
>Inventory, payroll, etc) and control the end user's access to any
>given set of function by the license number/password assigned to the
>user.
I'm not sure which way this swings. It is feasable to send out
individually-written Scramdisk CDs, each with a unique key, but unless
they only need mounting *once* (for an install) then that would get
pretty old very quickly, and I don't know how Aman feels about
commercial use - I suspect a fee would be involved.
In addition, is is possible to use the "unique" GID of each machine
to hash the key, and write a custom mount utility to use a
scramdisk... but I would suggest it would be simpler to add a decent
encryption to a copy of zip, and do similarly. I'm busy adding CAST to
a copy of zip as I type this :+)
> Your suggested solutions are quite valid though, and, would
>probably meet the needs of the user.
> Frankly, it is a shame that folks WILL use software without paying
>for it. I think mIRC is a good example...I understand that they have
>just had their 10,000th registration...after something like 18 MILLION
>downloads. Of course, this is not to say that there are 18 million
>USERS of mIRC not paying for it...Shucks, I have d/l it several times,
>but, don't use it (too much noise) However, I have recommended it to
>a number of folks, though.
however, the relationship between downloads and registrations doesn't
hold, even for those who ARE registered. I have a valid key for mIRC
as I like the software and wanted to support it (and will also be
first in the queue for SD3) but must have downloaded eight or nine
copies by now - I have been using it for a while, and updates are
sufficiently common that I have used the same key on at least four
versions - and downloaded a couple while I was still deciding which
IRC client to go with.
------------------------------
Date: Sun, 30 Jan 2000 15:41:00 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Help needed on peculiar use of cryptography
"SCOTT19U.ZIP_GUY" wrote:
> 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.
But the risk of collision is smaller than the risk of a typographic error. Consider a
very large
company with 1e5 employees. What is the chance that hashing their SS#s will produce a
collision?
>
> >
> >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: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Sun, 30 Jan 2000 12:57:08 -0800
"Greg" <[EMAIL PROTECTED]> wrote in message
news:86vkrt$hkt$[EMAIL PROTECTED]...
>
> > This depends strongly on the protocol you are using. If a
> > client ever sends or receives message that is not doubly
> > encrypted by the servers key, then you have reduced the
> > amount of work needed for a brute force attack by 2^(0.80*KeyLen).
>
> I don't follow this at all. How does twice encrypting traffic
> improve security if the original secret keys are transmitted
> with what you think is a weak key?
>
That is why I said it is very protocol dependant. If your protocol does not
involve
transmitting the original secret keys with the week key, then you are ok,
otherwise
you are toast.
>
> > If you are using a 256 bit ECC key, the brute force
> > work is 2^51. Such a small key can be brute forced
> > with today's hardware
>
> Okay, I tend to agree, that 51 bits is questionable. But say
> I am using a 163 bit field and I use a key space limited to
> 64 bits? Would you agree that it would remain secure for at
> least a year or two?
>
>
It will probably remain secure for a year or two, but why design obsolense
into your system right off the bat? Will you remeber to bump up the bits in
a couple of years? Will the client let you change the protocol with out
evidence that it is broken? Are you sure the data only needs to be hidden
for
a couple of years?
If you are only saving the clients a second or so at startup, is it worth
the
extra risk?
[EMAIL PROTECTED]
------------------------------
** 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
******************************
