Cryptography-Digest Digest #782, Volume #12 Tue, 26 Sep 00 23:13:01 EDT
Contents:
RSA T-shirt ("Jeff Moser")
Re: IBM analysis secret. ("Brian Gladman")
Re: RSA T-shirt ("Rich Ankney")
Re: RSA T-shirt (Mean R. K. Oily)
Re: IBM analysis secret. (SCOTT19U.ZIP_GUY)
Re: RSA T-shirt ("Jeff Moser")
Re: differnetials... (John Savard)
Re: A Different Kind of Quantum Computer (John Savard)
Re: Question on biases in random-numbers & decompression (David Hopwood)
Re: Question on biases in random-numbers & decompression (Bruno Wolff III)
Re: RSA T-shirt (David A Molnar)
Re: Steganography and secret sorting (Matthew Skala)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
----------------------------------------------------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: RSA T-shirt
Date: Tue, 26 Sep 2000 18:04:42 -0500
Has anyone actually received their RSA t-shirt from the early patent release
promo?
I was told it was sent, but have yet to receive it.
Jeff
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: IBM analysis secret.
Date: Wed, 27 Sep 2000 00:42:01 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (DJohn37050) wrote in
> <[EMAIL PROTECTED]>:
>
> >Don Coppersmith wrote an article on DES published in the IBM Journal of
> >Research and Development when he says that IBM knew of the potential for
> >differential analysis (they had another name for it) and designed DES to
> >resist it. And that this info was kept secret, as they saw no reason to
> >help an adversary, as it was a powerful attack. He also listed all the
> >security criteria of the S- boxes.
> >Don Johnson
> >
> Having worked in the government for 26 years. I would take anything
> a corporation says with a grain of salt. Numberous times govenment
> employess did all the work and then later the BIG CORPARATIONS with
> money acted like they did something. My view is that the boys at IBM
> never where given the reasons for DES and just went along with the NSA
> just as they most likely were never given an honest reason why it was
> 56 bytes instead of 64.
bits, not bytes, if you are referring to the DES key length.
And the earlier statement is about what Don Coppersmith has said, not about
what IBM has said.
Brian Gladman
------------------------------
From: "Rich Ankney" <[EMAIL PROTECTED]>
Subject: Re: RSA T-shirt
Date: Tue, 26 Sep 2000 19:45:04 -0400
Not yet. I won't get upset till next week:-)
/ Rich
Jeff Moser wrote in message <8qra2a$efa$[EMAIL PROTECTED]>...
>Has anyone actually received their RSA t-shirt from the early patent
release
>promo?
>
>I was told it was sent, but have yet to receive it.
>
>Jeff
>
>
------------------------------
From: [EMAIL PROTECTED] (Mean R. K. Oily)
Subject: Re: RSA T-shirt
Date: Tue, 26 Sep 2000 23:45:27 GMT
"Jeff Moser" <[EMAIL PROTECTED]> wrote:
>Has anyone actually received their RSA t-shirt from the early patent release
>promo?
>
>I was told it was sent, but have yet to receive it.
Until you receive it, I guess you'll just have to be content to pull your
pants up to your armpits, wear a plastic pouch full of pens and a laser
pointer in your shirt pocket, a calculator on your belt with functions like
"hyperbolic cotangent", and plastic rimmed glasses that have been repaired
with band-aids. The shirt will round that out nicely when it finally comes.
--
"Mean R. K. Oily" is actually 0751 329864 <[EMAIL PROTECTED]>.
0123 4 5 6789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5x5poker.com.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: IBM analysis secret.
Date: 26 Sep 2000 23:48:43 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<4raA5.15985$Cl1.394240@stones>:
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (DJohn37050) wrote in
>> <[EMAIL PROTECTED]>:
>>
>> >Don Coppersmith wrote an article on DES published in the IBM Journal
>> >of Research and Development when he says that IBM knew of the
>> >potential for differential analysis (they had another name for it)
>> >and designed DES to resist it. And that this info was kept secret,
>> >as they saw no reason to help an adversary, as it was a powerful
>> >attack. He also listed all the security criteria of the S- boxes.
>> >Don Johnson
>> >
>> Having worked in the government for 26 years. I would take anything
>> a corporation says with a grain of salt. Numberous times govenment
>> employess did all the work and then later the BIG CORPARATIONS with
>> money acted like they did something. My view is that the boys at IBM
>> never where given the reasons for DES and just went along with the NSA
>> just as they most likely were never given an honest reason why it was
>> 56 bytes instead of 64.
>
>bits, not bytes, if you are referring to the DES key length.
>
>And the earlier statement is about what Don Coppersmith has said, not
>about what IBM has said.
>
>
I am glad man that you caught the error.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Re: RSA T-shirt
Date: Tue, 26 Sep 2000 19:06:41 -0500
> Until you receive it, I guess you'll just have to be content to pull your
> pants up to your armpits, wear a plastic pouch full of pens and a laser
> pointer in your shirt pocket, a calculator on your belt with functions
like
> "hyperbolic cotangent", and plastic rimmed glasses that have been repaired
> with band-aids. The shirt will round that out nicely when it finally
comes.
nono.. you have me all wrong.. I roam around nude, wear contacts, and have a
cerebral copy of Mathematica.. For the sake of humanity.. I decide to cloth
myself with this t-shirt!
Jeff
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: differnetials...
Date: Wed, 27 Sep 2000 00:11:38 GMT
On Tue, 26 Sep 2000 17:58:19 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote, in part:
>Gotcha actually... hehehe
Since you're learning calculus, I suppose now is not the time to
discuss the Riemann zeta function, which is the route that links
analysis with number theory...
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A Different Kind of Quantum Computer
Date: Wed, 27 Sep 2000 00:09:24 GMT
On 26 Sep 2000 18:16:35 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
>>http://xxx.lanl.gov/abs/quant-ph/9910073
>I would not worry about it. I do not believe it.
>I suspect some referees do not as well-- note the revision history of
>the paper.
I was astounded the PostScript version had the first page sideways.
But the fact that the referees weren't uniformly happy with the paper
doesn't necessarily mean it's impossible. Bold new ideas are often not
recognized at first.
Although, most ideas not recognized at first are indeed not any good.
Like the old joke: "They also laughed ... at Bozo the Clown".
You can never tell about these things. (I think the gravitomagnetic
generator using Bose-Einstein condensates, though, will turn out not
to be the tractor beam it is anticipated to be: just as a bar magnet
doesn't pick up pith balls, I suspect even if they do generate a
significant gravitomagnetic field, it will only pull or push on other
Bose-Einstein condensates in the vicinity.)
Anyways, maybe some *other* idea will improve quantum computers in the
next 50 years. Although I'm not even sure the limitation of quantum
computing this is meant to remove is significant for cryptography;
ordinary quantum computers being sufficiently dangerous in their own
right.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Tue, 26 Sep 2000 05:15:17 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.compression
Subject: Re: Question on biases in random-numbers & decompression
=====BEGIN PGP SIGNED MESSAGE=====
Benjamin Goldberg wrote:
>
> I've been looking for a way to convert a stream of unbiased random bits
> into an unbiased stream of random numbers in an arbitrary range, and I
> think I've hit on an idea that hasn't been suggested before:
>
> Take an arithmetic dececoder, and initialize it to believe that the
> values 0, 1, 2 are equiprobable, and no other values will occur. Then
> feed it the stream of random bits. This should result in an unbiased
> stream of random numbers in the range 0..2.
A simpler, almost equally efficient method is to find a power of 2 (2^n)
that is just greater than a power of 3 (3^m), e.g. 2^27 and 3^17. Then
convert blocks of n bits into blocks of m trits. When the block of
bits has a value >= 3^m, subtract 3^m from it, and use the fact that
the result is an unbiased value between 0 and 2^n - 3^m - 1 to generate
more trits. For example, 2^27 - 3^17 > 3^14, so the algorithm would
look like this:
for (k = each 27-bit value) {
if (k < 3^17) {
convert k to base 3 and output 17 trits
} else {
k = k - 3^17;
if (k < 3^14) {
convert k to base 3 and output 14 trits
} else {
// could go further here, but it won't add much
// efficiency, so just discard k.
}
}
}
This has the advantage of requiring only single-precision arithmetic,
it generalises to any base, and the output is obviously unbiased if the
input is. The input block size (27 bits in this case) should be less than
the processor word size, but as large as possible subject to there being
a good fit between the input and output block sizes.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOdAiZTkCAxeYt5gVAQFEHQf/SMFjp3NmrVFJusmWTQaLS+AptPQRnB4P
JMRrGqOJkfbXCBxyVzm2TacCIyoOXGqp5A/iTqdxwRQSOTCEoo0TiRFBPQA/TUhn
p25F970smCaJC9WTzVY3IofiF9RnXSi/CFhzEDRJVdSYlTxmSiDfgu7LmK92d3rU
m1sF1YWMzoFlOiNbYpKzBHmCPm3dYIGB6zqkIhTRrPcgcxe4AWgvqX1x8vqFaNtT
OVLfNAzJEILpK3P4y1HDWX25OkVphb2TmZd/mw0JXvBF4SvZ4+9m7jFWup3G3B7W
8yAOQG8KkbWgV6EBE5hG58ELtklA3LQzYCQGIwfYIumYUJoosp1/Pg==
=z8zj
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Bruno Wolff III)
Crossposted-To: comp.compression,sci.crypt.random-numbers
Subject: Re: Question on biases in random-numbers & decompression
Date: 27 Sep 2000 01:24:19 GMT
On Mon, 25 Sep 2000 19:19:15 -0400, Bob Harris <[EMAIL PROTECTED]> wrote:
>
>This type of process was discussed a few months ago at
> http://boards.straightdope.com/sdmb/showthread.php?threadid=25283
That link was helpful. It help me come up with a simplified way of using
the extra information when a retry was needed.
I have a die rolling perl module that I am including here, a long with
a very simple test program. These are free for public use. I have only
done minimal testing of this module.
Besides minimizing the entropy used to generate a single unbiased roll,
there is a function that will make multiple rolls of the same sided die
that will try to conserve even more entropy by combining some of these
rolls together. The test program shows that the savings for D6's is
very roughly 30%.
============================Test Program==============================
#!/usr/bin/perl
use Roll;
@roll1 = nD6(600);
$entropy1 = entropy;
foreach $roll (@roll1) {
$roll1{$roll}++;
}
@roll2 = ();
for($i=0; $i<600; $i++) {
push @roll2,D6;
}
foreach $roll (@roll2) {
$roll2{$roll}++;
}
print @roll1, " Entropy $entropy1 $roll1{1} $roll1{2} $roll1{3} $roll1{4} $roll1{5}
$roll1{6}\n";
print @roll2, " Entropy ",entropy-$entropy1," $roll2{1} $roll2{2} $roll2{3} $roll2{4}
$roll2{5} $roll2{6}\n";
============================Roll.pm module=================================
package Roll;
# This package provides for generating random dice rolls. A hit counting
# function (for the game Titan) is also provided. Entropy comes from
# /dev/random. The program is designed to conserve on the entropy used to
# generate rolls. This includes preserving left over bits accross rolls
# and allowing for a way to batch rolls together. The random numbers
# generated have no bias (assuming there is none in the data from
# /dev/random).
# Dm - Generate a random integer from 1 to m. Bad values for m will
# return a value of 0.
# nDm - Generate n random integers from 1 to m. The rolls will be batched
# together in order to use entropy more efficiently. Bad values for
# n or m will result in an empty list being returned.
# D6 - Shortcut function for calling Dm with m = 6.
# nD6 - Shortcut function for calling nDm with m = 6.
# hits - The first argument is the minimum value to count. The rest of
# the arguments are a list of numbers. The number of numbers in that
# list greater than or equal to the test value is returned.
# D2 - Returns one random bit from /dev/random. Bits are buffered in blocks
# - of 8.
# entropy - Returns how many bits of entropy have been used.
use Exporter();
@ISA = qw(Exporter);
@EXPORT = qw(Dm nDm D6 nD6 hits D2 entropy);
# Do not generate numbers greater than this value. This should 2 to the minimum
# number of bits preserved by either integer or floating point operations,
# power.
$maxint = 2 ** 30;
# Mark random bit buffer as empty
$bits = 8;
open(RANDOM, '/dev/random') || die "Couldn't open /dev/random.\n";
# Keep track on entropy for the curious
$entropy = 0;
# Return a random bit
sub D2() {
my $i;
if ($bits >= 8) {
die "Couldn't read /dev/random.\n" unless sysread(RANDOM, $string, 1) == 1;
$bits = 0;
}
$entropy++;
vec($string, $bits++, 1);
}
# Return the number of bits of entropy used
sub entropy() {
return $entropy;
}
# Return an m-sided die roll
sub Dm($) {
my $range = 1;
my $num = 0;
my $m = $_[0];
return 0 if $m < 1 || $m >= ($maxint/2) || $m != int($m);
while (1) {
while ($range < $m) {
$range *= 2;
$num = $num * 2 + D2;
}
return $num + 1 if $num < $m;
$range -= $m;
$num -= $m;
}
}
# Return n m-sided die rolls
sub nDm($$) {
my @rolls = ();
my $roll = 0;
my $n = $_[0];
my $m = $_[1];
my $mc = 0;
my $mm = 1;
my $i = $maxint / 2;
return @rolls if $n < 1 || $n >= $maxint || $n != int($n);
return @rolls if $m < 1 || $m >= ($maxint/2) || $m != int($m);
# Get the maximum number of rolls it is safe to combine
while ($m < $i) {
$i /= $m;
$mc++;
$mm *= $m;
}
while ($n >= $mc) {
$n -= $mc;
$roll = Dm($mm) - 1;
for ($i=0; $i<$mc; $i++) {
push @rolls, ($roll % $m) + 1;
$roll = int($roll/$m);
}
}
# Don't use exponentiation because there might be rounding problems
$mm = 1;
for ($i=0; $i<$n; $i++) {
$mm *= $m;
}
$roll = Dm($mm) - 1;
for ($i=0; $i<$n; $i++) {
push @rolls, ($roll % $m) + 1;
$roll = int($roll/$m);
}
return @rolls;
}
# Return a standard 6 sided die roll
sub D6() {
Dm(6);
}
# Return a list of standard 6 sided die rolls
sub nD6($) {
nDm($_[0],6);
}
# Return the number of hits in a list of die rolls
sub hits($@) {
my $i = 0;
my $j = 1;
for (; $j<scalar(@_); $j++) {
$i++ if $_[$j] >= $_[0];
}
$i;
}
1;
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: RSA T-shirt
Date: 27 Sep 2000 01:26:51 GMT
Mean R. K. Oily <[EMAIL PROTECTED]> wrote:
> pointer in your shirt pocket, a calculator on your belt with functions like
> "hyperbolic cotangent", and plastic rimmed glasses that have been repaired
> with band-aids. The shirt will round that out nicely when it finally comes.
actually, the function "modexp" would be more appropriate for this crowd.
or better yet "findord" (but that one takes a while).
-David ("what's that?" "a grouping calculator.")
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Steganography and secret sorting
Date: 26 Sep 2000 19:29:49 -0700
In article <8qr63k$hne$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>You can then chip away at M by using division and modulus operations.
You don't need to use division and modulus on message-sized integers.
You can use an arithmetic decoder to get full information value from the
channel with minimal effort.
The arithmetic decoder is a black box. You give it a source of bits, and
then you can feed it positive integers m1, m2, m3, ... . It'll give you
back integers k1, k2, k3, ... with each ki in the range 0..mi. The
integers coming out of the arithmetic decoder will contain exactly the
same amount of information as the bits it consumes from the bit source, no
more or less (subject to a little bit of slop due to numerical precision).
It's a bit of code that is often used in compression algorithms, sometimes
with further enhancements to account for non-uniform distributions of the
integers being extracted. _The Data Compression Book_, by Mark Nelson and
Jean-Loup Gailly, gives a good introduction to how arithmetic decoders work.
In this application, you "decode" the message bits with an arithmetic
decoder, using N, N-1, N-2.... as the ranges for the integers to extract.
It'll map messages of the right length to permutations in a nice bijective
fashion. 32-bit integer math is fine. I alluded to this in my original
posting, although I may have neglected to mention that an arithmetic
decoder was a good way to generate the numbers; I sort of assumed the
reader could figure that out. I also gave an estimate (from Stirling's
approximation to the factorial) for exactly how many bits you could encode
for a given N.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Wed, 27 Sep 2000 02:28:11 GMT
Mok-Kong Shen wrote:
> Bryan Olson schrieb:
> > No need to follow the path. Just recognize that when
> > all other input blocks are held constant, the input
> > differential on block i always becomes the final output
> > differential on block j.
>
> Then you have at least a work factor equal to the
> number of blocks of the message. And you have to
> manage that all messages for your investigation
> have the same length.
Probably about the square of the number of blocks
in the chosen messages, since we have to find an input
block that works (most don't). I didn't bother to
calculate the optimal message size; a thousand blocks
should be more than enough. I expect there are faster
attacks, but five minutes is quick enough.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
