Cryptography-Digest Digest #716, Volume #10 Fri, 10 Dec 99 08:13:01 EST
Contents:
Re: Synchronised random number generation for one-time pads (Johnny Bravo)
Linear Structures (Raphael Phan Chung Wei)
Re: Random Numbers??? (Johnny Bravo)
Re: NASA measurements, was: NSA future role? (Gurripato)
Re: Shamir announces 1 sec break of GSM A5/1 (Gurripato)
Re: Shamir announces 1 sec break of GSM A5/1 (Gurripato)
Re: Digitally signing an article in a paper journal (KloroX)
Re: Digitally signing an article in a paper journal (KloroX)
Re: Shamir announces 1 sec break of GSM A5/1 (Oyvind Eilertsen)
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: Linear Structures ("Douglas A. Gwyn")
Re: weak algorithm, too hard for me (JPeschel)
Re: old Microsoft Mail 3.0b encryption? (JPeschel)
Attacks on a PKI ([EMAIL PROTECTED])
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Synchronised random number generation for one-time pads
Date: Fri, 10 Dec 1999 03:17:39 GMT
On Thu, 9 Dec 1999 23:17:10 -0000, "Charles Meigh"
<[EMAIL PROTECTED]> wrote:
>Thanks everyone, I hadn't come across the problem of interception and
>forgery yet. I think I'll add a decent physics textbook to my shopping
>list as well as cryptology. I'm still thinking that there might be some
>vastly wide choice of 'celestial' events that could produce truly random
>numbers that will still be sufficiently similar observed from any two (or
>more) points on the globe, which would make OTP use more economical.
Your problem is that what your two people can see, the attacker can
see too. Even if they both start at the same microsecond when
recording information, the attacker has less microseconds to start
checking then the keyspace in a properly designed cipher.
The attacker just starts recording the data and when a message comes
in, he just checks it against every microsecond starting point and
eventually decrypts the message in short order.
Best Wishes,
Johnny Bravo
------------------------------
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Linear Structures
Date: Fri, 10 Dec 1999 16:18:51 +0800
We often hear that at least some part of the block ciphers should be
non-linear otherwise it would be easy to obtain the unknown key bits.
What is the justification for that? By saying non-linear, does that
mean with respect to the XOR operation?
--
Regards,
Raphael Phan
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Random Numbers???
Date: Fri, 10 Dec 1999 03:30:18 GMT
On Thu, 09 Dec 1999 22:27:17 -0800, John
<[EMAIL PROTECTED]> wrote:
>I have been kicking around random # generators. I have 3 sets of 1000
>random #s. Are they? How can you tell? Integers range from 0 through
>255 inclusive.
<snip>
This is far too small a sample to do anything meaningful with.
Generate about 20 million values, write them to a file as bytes, and
run the statistical tests on them. You will never be able to prove
randomness, but you can get a good probability check on the randomness
of the values.
Best Wishes,
Johnny Bravo
PS: And no, we don't want you to post the 20 million values here. :)
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: NASA measurements, was: NSA future role?
Date: Fri, 10 Dec 1999 08:11:01 GMT
On Thu, 09 Dec 1999 08:19:11 -0700, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>NASA people told me that the problem was a bit more subtle. Reporting of
>measurements in US units was changed to reporting in metric units for
>some items. This was done quietly. People deal with measurements in
>differing systems all the time. It's harder when things are changed
>quietly. No one with enough experience to see the difference in the
>numbers was working on the project.
>
It remind me of a Star-wars experiment back in the 80�s. A
ground laser was to send up a beam to a mirror aboard a space shuttle.
Unfortunately, the software was told that the mountain the laser was
in was X miles instead of X feet (the beam probably blasted down to
the floor, I imagine). Error corrected, successsful hit. Even in US
units.
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Fri, 10 Dec 1999 08:14:39 GMT
On Thu, 09 Dec 1999 15:29:44 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]=NOSPAM
>(Gurripato) wrote:
>> Another proof is that, in many countries, that demonstration
>>would break the law, so researchers are forbidden from proving it.
>>Absence of proof does not imply proof of absence.
> Don't you love it when asshole politicans make a stupid fucking
>law and then use the law as proof no one can break something becasue
>its against the law. Are they really that stuoid?
>>
Guess they are smarter than we think. Want to prove that
gravity does NOT pull things down? Make it illegal to throw objects
to the floor: nobody will be authorized to do it, therefore nobody
will be able to check it, therefore the original assertion is not
refuted, therefore it is correct, which is what we want to
demonstrate.
I wish I could do my lab experiments the same was. I would be
writing my Nobel address right now.
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Fri, 10 Dec 1999 08:17:42 GMT
On Thu, 09 Dec 1999 20:55:30 GMT, [EMAIL PROTECTED]
(Troed) wrote:
>>Third the majority of the data from the cell phones is unencrypted
>>anyways. I seriously doubt the majority of privacy violations are
>>based on broken crypto.
>
>No, GSM voice communication is always encrypted.
>
I once read that GMS encryption only works from the calling
person to the nearest "cell", and the rest of the path it goes
unencrypted. Can anybody confirm/refute this?
------------------------------
From: KloroX <[EMAIL PROTECTED]>
Subject: Re: Digitally signing an article in a paper journal
Date: Fri, 10 Dec 1999 11:06:02 +0100
Reply-To: [EMAIL PROTECTED] (this is spam bait)
On Thu, 9 Dec 1999 14:25:08 -0800, "Roger Schlafly" <[EMAIL PROTECTED]>
wrote:
[...]
>And what is the objective value of your authorship games?
In my specific case, a university that forces me to publish with my
work address, even though the paper I wish to publish is the result of
work privately financed by myself, carried out in my free time, and
unrelated to the subjects I am paid to work on at the university. The
motivation is that my university receives public funding for every
paper I publish from my work address, while I wish to publish from my
home address because in either case I get no share of the funding.
My alternatives are not publishing at all, or (in the interest of
science) publishing anonymously or under pseudonym (and perhaps be
able to reveal my identity after I retire and the thing does not
matter any more).
>You might be able to sneak it in. An MD5 hash is only 32 hex
>digits, so you might slip in:
> The author acknowledges the benefit of grants 143DD59E0,
>49ACA831, A3984578, 4FF3A801.
This is an interesting suggestion. It does involve a measure of
cheating (the grants do not exist). Another idea I came across is
writing in the paper the URL of a web page containingr additional data
relevant to the paper but not published because of size, and embed a
hash in the URL (specifically in the file name, which I can choose
freely). This involves no cheating.
------------------------------
From: KloroX <[EMAIL PROTECTED]>
Subject: Re: Digitally signing an article in a paper journal
Date: Fri, 10 Dec 1999 11:06:03 +0100
Reply-To: [EMAIL PROTECTED] (this is spam bait)
On Fri, 10 Dec 1999 01:40:23 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Several questions:
> 1. What is at stake?
> 2. Who are the opponent? What is your threat model?
I answered a similar question earlier in the thread, before seeing
your post. You may read about the background there. The threat could
be losing my job (in the worst case), or be subjected to career or
financial reprimands.
>Suggestions:
[...]
> Give the unopened manuscript envelope to a lawyer you trust.
Anyone who knows a lawyer he can trust raise his hand...
Seriously, what is the advantage of the multiple-hash scheme? Making
it less likely that a collision will be found (i.e., another plaintext
that yields the same hash), or facilitating verification (increasing
the likelihood that at least one of several hash algorithms will still
be easily available after several years)?
------------------------------
From: Oyvind Eilertsen <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: 10 Dec 1999 11:19:24 +0100
[EMAIL PROTECTED]=NOSPAM (Gurripato) writes:
> I once read that GMS encryption only works from the calling
> person to the nearest "cell", and the rest of the path it goes
> unencrypted. Can anybody confirm/refute this?
Only the "over-the-air" part of GSM communication is encrypted.
--
�yvind.
<[EMAIL PROTECTED]>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 10 Dec 1999 10:26:44 GMT
Dave Knapp wrote:
> An individual nucleus (or any other kind of quantum system) has a
> constant decay probability per unit of time. As a result, the
> integral probability that it has decayed by a certain time is
> exponential, but the probability of decay is constant.
Well, yes, the probability of decay within the next yay many
seconds *given* that there has been no prior decay is constant,
leading to an exponentially decreasing probability that there
has been no decay since one started the clock. This is better
done with formulas than words.
In the context of the discussion topic, the important thing
is that the randomness is inherent even in a single nucleus.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify
Date: Fri, 10 Dec 1999 10:31:12 GMT
"Trevor Jackson, III" wrote:
> I thought so too. Then I reied to install the latest Microsoft(tm) tools.
> Visual C now refuses to install unless Internet Explorer is present. I am
> unable to conceive of a legitimate reason for such "persuasive" market
> positioning.
That is simply the result of Visual Studio's help system having
been changed to HTML rather than Microsoft's old proprietary
format. Looks like progress to me.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Linear Structures
Date: Fri, 10 Dec 1999 10:40:23 GMT
Raphael Phan Chung Wei wrote:
> We often hear that at least some part of the block ciphers should be
> non-linear otherwise it would be easy to obtain the unknown key bits.
> What is the justification for that? By saying non-linear, does that
> mean with respect to the XOR operation?
Linearity means linearity over GF(2), i.e. {0,1} elements and
{XOR,AND} operators, but it would be an equal problem for any
field; linearity means that there is a simple algorithm for
solving a large system of simultaneous equations, such as the
encryption equations for the key variables using a known-PT
attack (if the cipher is linear).
A nonlinear system can be measured by how closely it can be
approximated by a linear system. Bent functions are as far
from linear as is possible, which is why researchers have
been studying them.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: weak algorithm, too hard for me
Date: 10 Dec 1999 10:56:28 GMT
Gaccm [EMAIL PROTECTED] writes:
>so how were you able to solve it?
Well, I have a lot of password recovery tools on my
site, but I guess I didn't put up the link to Quintero's
site. You can find information on WS FTP and a
link to a decryptor here:
http://www.securiteam.com/exploits/WS_FTP_Pro_s_weak_password_encryption_
algorithm.html
or you can do it by hand.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: old Microsoft Mail 3.0b encryption?
Date: 10 Dec 1999 11:41:14 GMT
>[EMAIL PROTECTED] (Keith A Monahan) writes:
>I'm looking to write a small program that converts microsoft
>mail files over to regular text files. I've briefly looked
>over the data file it puts out and it appears encrypted.
>There does seem to be some form to the file and it may just
>turn out to be some simple XOR cipher. Since I'm sure
>Microsoft didn't release the file format or encryption method
>AFAIK, I'm hoping someone wrote a little cracker where I could
>steal the algorithm/format from. The generation of products
>developed around the same time by Microsoft have all been long
>broken.(ie MS-Word, MS-Access,)
>
>I've looked on the popular key recovery sites around including
>Joe's. I very well may have missed it, though.
I guess I don't have one. If this is one of those stored passwords
and all you want to do is see behind the asterisks, try
Snadboy's Revelation.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Attacks on a PKI
Date: Fri, 10 Dec 1999 12:04:33 GMT
Having read much of the literature on PKI, it is fairly conclusive that
this whole PKI thing is an exploitation of people's ignorance.
I am currently compiling a list of attacks on a PKI, and if you know of
any then please post some.
David
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 10 Dec 1999 07:41:35 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony T.
Warnock) wrote:
>The main point is that in designing a radioactive decay counter, the dead
>time of the detector (or it's altered state), that is, the time right after
>a hit, will be a time which gets lots of decays. An interval of the dead
>time, T, which starts at a hit is more likely to get a hit than the same
>interval delayed to after the dead time. It only makes the design a bit
>more complicated.
If I understand you correctly, you are saying that an individual
Radium atom is more likely to decay into a Radon + Alpha particle
if another Radium atom just did. This can't be correct - I must
be misunderstanding your meaning. Each "hit" is a radium atom
decaying in a sample that has many, many atoms. How does an
individual radium atom "know" that an atom on the other side of
the sample just decayed? I can see how an isotope that decays
to neutrons could cause a chain reaction (amount of bias would
depend on how close to critical mass the sample is) but I the
decay of radium atoms only puts out alpha particles, which
don't cause nuclear chain reactions.
Here are a couple of chunks I pulled from some web sites.
"The most abundant isotope of Radium is Radium 226, which
decays into Radon plus alpha particles with a half-life
of 1620 years."
"The emission of radioactivity by an atom occurs spontaneously
and quite unpredictably. However, in a sample containing
many radioactive atoms, the overall rate of decay appears
to be governed by the number of nuclei left undecayed.
The time taken for half the radioactive atoms in a sample
to decay remains constant and is called the half-life.
Radioactive substances decay exponentially with time, and
the value of the half-life for a substance can vary from
a fraction of a second to billions of years."
The best web site for this kind of info seems to be
[ http://www.karaolides.com/alevel/alevel.html ],
and I would especially call attention to this subpage;
[ http://www.karaolides.com/alevel/node14.html ].
Highly recomended.
I have been doing a bit of thinking and I believe that, oddly
enough, a sample of Radium that has a rate of decay that
changes according to the half-life formula does not imply
that the rate of "hits" to a Geiger counter or other detector
of ionizing radiation will change. In other words, the
intensity (particles per second) of the radiation at the detector
does not get dimmer. Here is why:
Consider a flat plate of radium that is emitting alpha
particles. Only the alpha particles from the surface
atoms will reach the detector, as radium (and just about
any other solid) blocks alpha particles very well.
As each Radium atom decays, it forms Radon. If the atom
is at the surface the Radon, being a gas, escapes. Thus
the surface of the radium sample stays 100% radium, and
decay just makes it thinner, which has no effect on the
intensity of the radiation. (the edges of the plate will
also erode, which will reduce the effective area. this
effect is easy to remove by using a mask that covers the
edges of the sample. Ordinary paper stops alpha
particles.)
I was all ready to calculate the second by second bias
caused by the Radium half-life of 1620 years, but I
don't think that it causes a bias until the plate gets so
thin that it starts getting holes in it.
It is trivial to shield out virtually all sources of outside
ionizing radiation, and easy to make the radium source have
much more output than even the unshielded background.
The detector only detects ionizing radiation, so most cosmic
rays, neutrinos, etc. will pass right through without causing
a hit.
My conclusion is that, using a careful design, the time between
arrival of alpha particles at your detector is a true random
number, the bias caused by imperfections in the timing circuit are
less than 1 in 10 to the minus 15th power, the bias caused
by external sources are less than 1 in 10 to the minus 16th power,
and that both of the above biases may themselves be somewhat
random, thus decreasing the bias by an unknown amount.
For an example of a non-careful design, with measured data on entropy,
compressability,, etc, see [ http://www.fourmilab.ch/hotbits/ ] and
[ http://www.fourmilab.ch/hotbits/how.html ]. As an engineer who
works with very precise measurements, I know that I could be much, much
better at eliminating bias than the described setup.
When I combine the low amount of bias from the technique above with
the MOM (Massive Overkill Method) by XORing the results of various
psuedorandom generators with the methods listed in the following web
sites,
http://www.random.org/essay.html
http://webnz.com/robert/true_rng.html
http://www.clark.net/pub/cme/P1363/ranno.html
http://world.std.com/~dtd/random/forward.pdf
http://lavarand.sgi.com/
and with the fact that the only bias that survives the MOM is a
bias that is shared by every single RNG that feeds the MOM, the
resulting random numbers are almost certainly true random, even
though you can never absolutely prove such an assertion.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 10 Dec 1999 08:00:26 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony T.
Warnock) wrote:
>Another (not very problematic) property is that the number of counts in a
>fixed amount of time is more likely to be even than odd.
Why would this be so?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 10 Dec 1999 08:04:50 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>Well, yes, the probability of decay within the next yay many
>seconds *given* that there has been no prior decay is constant,
>leading to an exponentially decreasing probability that there
>has been no decay since one started the clock. This is better
>done with formulas than words.
Prior decay of the same atom or some other atom?
Prior decay of the same atom implies memory that I don't
believe the atom has. Prior decay of some other atom
implies interaction that I don't believe happens in the
case of alpha particle emmitting decay.
------------------------------
** 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
******************************
