Cryptography-Digest Digest #358
Cryptography-Digest Digest #358, Volume #10 Mon, 4 Oct 99 03:13:07 EDT
Contents:
Re: Blowfish exportable? (Johnny Bravo)
Re: A simple preprocessing scheme for plaintexts (wtshaw)
Re: Is 128 bits safe in the (far) future? (Scott Nelson)
Re: crypto export rules changing ("Melinda Harris")
Re: radioactive random number generator (Boris Kazak)
Re: radioactive random number generator (John Larkin)
Re: radioactive random number generator (Scott Nelson)
Re: Random number generation ("j.w.altena")
Re: radioactive random number generator (Dan Day)
Re: Perfect Shuffle Algorithm? (Dan Day)
Re: Factoring public keys attack? (UBCHI2)
Re: Schrodinger's Cat and *really* good compression (Dan Day)
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Blowfish exportable?
Date: Sun, 03 Oct 1999 18:48:26 GMT
On Sun, 3 Oct 1999 13:28:53 -0700, dogHaus [EMAIL PROTECTED] wrote:
[This followup was posted to sci.crypt and a copy was sent to the cited
author.]
I am developing software that includes encryption capabilities. The
encryption is only used to encrypt communications between my client
software and a central server.
Blowfish looks suitable for my needs - if I embed Blowfish, will my
client software still be exportable overseas?
Since you didn't say where you are exporting from, we can't give you an
appropriate answer. Contact your government and ask them.
Johnny Bravo
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A simple preprocessing scheme for plaintexts
Date: Sun, 03 Oct 1999 18:52:58 -0600
In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote about a scheme.
Interesting. As I see it, anything that diffuses text could be along the
lines of cipher block chaining modes, that I mostly avoid, can help.
Merely do the procedure to the blocks of plantext, encrypt, and preform
the prodedure again on ciphertext blocks. Several variations are
possible.
--
Sometimes a small mistake can lead to fortunate reward.
Charlie Chan
--
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Is 128 bits safe in the (far) future?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 04 Oct 1999 01:40:00 GMT
On Sun, 03 Oct 1999 20:05:23 +0200, "Thomas J. Boschloo"
[EMAIL PROTECTED] wrote:
Arne Hoffmann wrote:
... but in a paper of Ralf Senderek I read this:
__
snip
If you assume the size of a high-performance computer system performing
keytests is 0.3 mm for electronic or optical transfer of information, it
can only perform 1 000 000 000 000 operations (10^12) per second,
otherwise it has to be smaller. Over a period of 317 years or 10 003 759
200 seconds that will sum up to 10 003 759 200 000 000 000 000
operations. This ability to perform no more than 10^22 operation during
317 years is truly not sufficient for testing 10^22 different IDEA-keys
because every keytest requires more than a single operation cycle. But
even if it was possible to do a keytest that fast, the large number of
10^38 IDEA-keys would be searched for no more than 0.000 000 000 000 000
029 percent. Thus a specific IDEA-key will not be found even if "lots"
of those high-performance computers will work parallel to test the keys.
But if the size of one functioning component is 1 Angstrom unit (1e-10
m), and the size of the computer system is 0.3 x 0.3 x 0.3 mm^3, the
numbers would become different.
(3e8 m/s) / (1e-10 m) = 3e18 operations a second
(0.3 mm)^3 / (1e-10 m)^3 = 2,7e-11 m^3 / 1e-30 m^3 = 2,7e19 units
Multiplied this becomes 8,1e37 operations a second. This is 2^126 bits
(I didn't aim to get this number!). So with four of those machines you
would exhaust the keyspace of IDEA in just one second.
A box of (3476 km)^3, in which our moon would fit, filled with these
mighty units however would do 1,3e68 operations a second. Equaling 2^226
operations a second. Running this for a hundred years (2^10 seconds)
would just about crack a 237 bit key (could be a hundred years later if
you have bad luck).
Back to the real world; my P150MMX does 1,5e8 operations a second. Not
10^12 or 10^18 ;-) And a circuit the size of an angstrom will probably
never be, maybe a few thousand angstroms. So you could at least
substract 15 bits from your for ever safe number of bits. And it will
never be the size of the moon, so you could gain another 30 bits there.
So that leaves 190 as the ultimate safe number of bits?
Please review these numbers (rougly) and comment,
Thomas
BTW We're not talking about the next few hundred years! We are talking
about the _far_ _far_ future, with a lot of technology, time, money and
resources at our disposal!
The current _known_ limits do allow 128 bit keys to be broken
in the _far_ _far_ future. It's not
Cryptography-Digest Digest #361
Cryptography-Digest Digest #361, Volume #10 Mon, 4 Oct 99 15:13:02 EDT
Contents:
Re: radioactive random number generator (-Bodnar,B.L.)
Re: Compress before Encryption ("Douglas A. Gwyn")
Re: Cryptanalysis of 2 key TDES (Jerry Leichter)
Re: radioactive random number generator ("Dave VanHorn")
Re: Findkey (Jim Gillogly)
Re: factoring with quadratic sieve (Bob Silverman)
Re: Factoring public keys attack? ("Richard Parker")
Re: A simple preprocessing scheme for plaintexts (Mok-Kong Shen)
Re: Irish schoolgirl wins European Young Scientist Award ("Douglas A. Gwyn")
Re: EAR Relaxed? Really? ("Douglas A. Gwyn")
Re: radioactive random number generator (Tim Tyler)
Re: radioactive random number generator (Herman Rubin)
Re: radioactive random number generator (Herman Rubin)
Re: Ritter's paper ("Trevor Jackson, III")
Re: Is 128 bits safe in the (far) future? (Scott Nelson)
Re: 512-bit key broken in microseconds?! (Thomas Pornin)
Re: Yarrow + Panama: an idea (long) (John Myre)
From: [EMAIL PROTECTED] (-Bodnar,B.L.)
Crossposted-To: sci.electronics.design,sci.electronics.equipment
Subject: Re: radioactive random number generator
Date: 4 Oct 1999 13:52:41 GMT
In article [EMAIL PROTECTED],
Boris Kazak [EMAIL PROTECTED] wrote:
jjlarkin wrote:
Radioactive decay is not only messy to implement, it produces a random
pulse train, hardly suitable for turning into nicely distributed
gausian noise.
A zener diode is a great noise generator. Bias a 10-volt zener at about
0.5 ma, and you'll get nice wideband noise across it. Amplitude will be
about 300 nv per root Hz (300 nv times the square root of the bandwidth
of the following amplifier). If the amp has a decent highpass response
(ie, cut out low-frequency 1/f noise) the result will be excellently
random gausian noise with very low autocorrelation for reasonable
sample rates. Just digitize it, or slice it and clock into a shift
register.
If you want perfect 1:0 balance and even lower autocorrelation, stir
the zener's random output into the guts of a pseudo-random shift
register.
easy!
John
---
And one more elegant idea - feed the output of this Zener diode
into a Voltage Controlled Oscillator, feed the output of this VCO
into a flip-flop, and at any time when needed sample a random bit.
Best wishes BNK
What's wrong with a "random pulse train"? Radioactive decay follows Poisson
statistics. Look at this as the output of a random variable (i.e., a function
which outputs a "random" signal). Now, do a transformation into ANY other
random variable. The "inverse transform algorithm" is the one which usually
used.
The procedure is well-described in any book on applied probability theory. It
is nothing more than a mapping from one function into another one. Here's a
trivial example which shows the approach:
All software based pseudorandom number generators used in discrete event
simulation have a uniformly distributed output between (0,1). Suppose you do
not want a uniformly distributed output -- you want an exponentially
distributed output. Also, let's say we're dealing with time. The distribution
for the exponential is 1-exp(-rt) where "t" is time and 1/r is the mean time
difference. The inverse transform algorithm works as follows (the
mathematical details are left to the reader):
- plot the uniformly distributed random numbers on a vertical axis (i.e., the
"y" axis ranges from 0 to 1).
- plot the desired distribution
- pick the random number you obtained from the uniformly distributed generator
and draw a line to the right until you intercept the distribution's plot
- drop a vertical line to the "x" axis.
- the number you get is the corresponding random number from the exponential
pdf.
In practice, this inversion would be done numerically: t = -(1/r)*ln(u) where
"u" is the random number from the uniform pdf. "u" is used instead of "1-u"
since both are uniformly distributed. "t" is exponentially distributed.
The same approach can be used to map ANY distribution into ANY other
distribution.
Bohdan Bodnar
Lucent Technologies, Inc.
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Compress before Encryption
Date: Mon, 4 Oct 1999 17:09:54 GMT
Richard Parker wrote:
As I understand it, Scott suggests that his scheme is a bijection from
the set {0,1}* to itself, and thus it is a permutation or symmetry of
the set {0,1}*.
So, it is clear that naming Scott's scheme "one-to-one compression" is
misleading since all lossless compression is one-to-one. A better
name would indicate Scott's belief that his scheme is a permutation or
symmetry of the set {0,1}*. Perhaps "symmetric compression" would be
a better name, although this might be to too easily confused with
symmetric encryption.
Okay, that's consistent with what I thought I understood he
