Cryptography-Digest Digest #871, Volume #11 Sat, 27 May 00 14:13:01 EDT
Contents:
Re: Attack on SC6a (sci.crypt cipher) ("Scott Fluhrer")
Best crypto if encrypted AND plain text are known (and small) ? (TheGame)
Re: Comments requested: One way function blast() (zapzing)
Re: More on Pi and randomness ("Trevor L. Jackson, III")
Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (No User)
Re: Retail distributors of DES chips? ("Trevor L. Jackson, III")
Re: looking for an 8-byte long output hashing function ("Trevor L. Jackson, III")
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
(Joe@Joe's.bar&grill.org)
Re: Another sci.crypt Cipher (tomstd)
Re: RSA/PK Question ("Trevor L. Jackson, III")
getting easy primes ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Attack on SC6a (sci.crypt cipher)
Date: Sat, 27 May 2000 08:51:18 -0700
Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
news:8goo7m$km8$[EMAIL PROTECTED]...
>
> tomstd <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > From his paper:
> >
> > One round of SC6a is as follows:
> >
> > in1 = a ^ c
> > in2 = b ^ d
> > (out1, out2) = f(in1, in2)
> > a = a ^ out2
> > b = b ^ out1
> > c = c ^ out2
> > d = d ^ out1
> > swap (b, c)
> > --
> >
> > Well if I can find pairs such that a ^ c = a' ^ c' then I can
> > run a difference thru his F function, and have a zero out with a
> > probability of zero. There are 2^16 ways to get this difference
> > too.
> >
> > His 'swap(b, c)' won't fix it either because (b, d) have a zero
> > difference anyways (you change the (a, c) input and keep (b, d)
> > the same).
> >
> > So this difference should go thru all rounds with prob=1.
> >
> > I conclude (if I got it right) his cipher is broken.
> To make this observation work, assume the same differential on all four
> words. That is, you start with a differential (x,x,x,x), for some x. Or,
> to write it out explicitly:
>
> a^a' = x b^b' = x c^c' = x d^d' = x
>
> Then, if you go through a round, you get an output differential of
(x,x,x,x)
> with probability 1.
>
> Now, this implies that if
> Encrypt( a, b, c, d ) = ( e, f, g, h ),
> then for all x:
> Encrypt( a^x, b^x, c^x, d^x ) = ( e^x, f^x, g^x, h^x )
>
> Now, this is certainly is a certficational weakness, and if the attacker
has
> one plaintext-ciphertext pair, this gives him 2**32-1 more "for free". It
> is difficult to see how to turn observation into a key-recovery attack.
Spoke too soon. I ignored the whitening and the PHT transforms at the front
and the back. My observation holds true only for the core rounds. However,
the whitening/PHT transformations does not eliminate the certificational
weakness and allows for a partial key-recovery attack.
The certificational weakness: suppose we start out with a differential
(0,X,0,0) where X == 0x80000000. This differential goes through
pre-whitening unchanged with probability 1. After the PHT transform, it
becomes the differential (X, X, X, X) with probability 1. As above, it goes
through the core rounds unaffected with probability 1. After the second set
of PHT transforms, it becomes the differential (0,X,0,0) with probability 1,
and after post-whitening, you get the output differential (0,X,0,0) with
probability 1.
Now, the key recovery attack -- we'll try to recover the pre and
postwhitening keys. Suppose you give the cipher the differential (0,Y,0,0),
where Y = 0x40000000. Then, (according to a quick program I wrote) it will
present the differential (Y,Y,Y,Y) to the core round only if the bit 30 of
each word after the whitening is one of:
( 0, 0, 0, 0 ) with differential Y on b
( 0, 0, 1, 0 ) with differential X+Y on b
( 0, 1, 1, 0 ) with differential X+Y on b
( 1, 0, 0, 1 ) with differential Y on b
If it isn't one of these four settings, it will present an uneven
differential to the core, which should output an essentially random
differential.
The post-PHT/whitening phase has insufficient avalanche to disguise a
(Y,Y,Y,Y) differential to the core. Sending a small series of well-chosen
differentials, and seeing which falls into one of the four categories, and
which doesn't, should allow us to deduce the value of bit 30 of the
pre-whitening keys. Once we have that, we can move on to work on bit 29 in
a similar manner.
Obtaining the postwhitening keys should be similar -- if the core outputs a
differential (Y,Y,Y,Y), we can look to see how to propogates through the
post-whitening, and deduce those key bits.
I have not examined the key scheduling, and so I cannot say how deducing
bits 0-30 of the pre/post whitening (this attack doesn't give you bit 31)
helps you gain the rest of the key.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (TheGame)
Subject: Best crypto if encrypted AND plain text are known (and small) ?
Date: Sat, 27 May 2000 15:56:48 GMT
Hi,
Sorry for this basic question, but I'm wondering what the best algorithm
would be to encrypt and decrypt a user name (e.g. 'fred'). The goal would
be to give 'fred' his encrypted username as a cookie, and to be able to
get back the original username 'fred' when decrypting the cookie.
Obviously, it should not be possible for anyone else to claim to be 'fred',
even by having thousands of plaintext and encrypted usernames to
try and figure out the key...
Any recommendations - preferably already implemented as a Perl module ?
Thanks for your advice,
TheGame.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Comments requested: One way function blast()
Date: Sat, 27 May 2000 15:55:52 GMT
In article <[EMAIL PROTECTED]>,
Andru Luvisi <[EMAIL PROTECTED]> wrote:
>
> What follows is a 32 bit -> 32 bit one way function I've been working
> on. It is based upon a block cipher with a 4 bit key and a 2 bit
> block, which is run Davies-Meyer style to form a hash function. Two
> bits of the 32 bit value are modified each time.
>
> Regarding the 2 bit block cipher:
> There are 24 possible permutations of the numbers 0 through 3.
> Deciding that having some permutations be unreachable is better than
> having some be more likely than others, I opted to use a 4 bit key to
> pick from among 16 combinations, rather than a 5 bit key to pick from
> among 24. I chose to discard the permutations which were rotations of
> { 0, 1, 2, 3 } and { 3, 2, 1, 0}. The remaining permutations have the
> nice property that given a random key, every output is equally likely
> for every input.
>
> Here is the source code for blast(). Comments requested:
>
I'm sorry, it's terrible. to break this,
follow the following procedure, written
in "pseudo C":
For all possible 4-bit initialization vectors:
do this:
{
For(i=0; i<Number of 2-bit message blocks;i++)
{
Seach for the 2-bits that will give the
correct hash value for the message block M_i.
You now have the message block M-i.
}
}
Now just choose the message from among the 256
messages you have that seems to make sense.
You now also have the initialization vector.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 27 May 2000 13:09:51 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Clive Tooth wrote:
> Trevor L. Jackson, III wrote in message <[EMAIL PROTECTED]>...
>
> >Clive Tooth wrote:
> >
> >> "Trevor L. Jackson, III" wrote:
> >>
> >> > Guy Macon wrote:
> >> >
> >> > > In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >> > >
> >> > > >I understand the Nth hexit of pi, irrespective of the value of N, to
> be
> >> > > >calculable using the equation derived by Borwein, Borwein and
> Plouffe.
> >> > > >The 400 billionth hexit of pi has been thus calculated.
> >> > >
> >> > > Really?!? (not questioning you, just suprised). Does the time to
> compute
> >> > > the answer get larger as N gets larger? Linearaly? Exponentialy?
> >> >
> >> > Since the formula is based upon N, it's implementation grows as the log
> of N.
> >>
> >> No.
> >
> >Interesting.
> >
> >> The time required to calculate the Nth _hex_ digit of pi by these
> >> non-memory-intensive methods is at most O(N*(log(N))^O(1)).
> >
> >A simplistic implementation in multi-precision arithmetic requires only a
> few MP multiplies
> >and an MP division to produce a term of the series. Since the MP
> operations are O(log N)
> >your estimate of the overall work implies that O(N) terms of the series are
> required to
> >produce a digit.
> >
> >Why is that? (I thought the number of terms was bounded by a small number)
>
> O(N) terms _are_ required. I did attempt an explanation of this at the end
> of my post that you quoted, but let me give an example.
>
> Let S = sigma(k=0, +infinity)[1/(16^k*(100k+7))]
>
> (The well-known "nth hex digit of pi" identity is the sum of 4 things
> similar to that.)
>
> So, S is some well-defined real number. Suppose we want to know its 11th,
> 12th and 13th hexadecimal digits. These hex digits are the first three hex
> digits of the number S*16^10.
>
> S = sigma(k=0, +infinity)[1/(16^k*(100k+7))]
> So
> 16^10*S = sigma(k=0, +infinity)[16^(10-k)/(100k+7)]
> = 16^10/7 + 16^9/107 + ... + 16^2/807 + 16^1/907 + 16^0/1007 + ...
>
> So, we just need the fractional part of each term.
>
> Set T to 0.
>
> Work out 16^10 mod 7 (using single precision integer arithmetic), divide the
> answer by 7 using ordinary floating point arithmetic, add the result to T.
>
> Work out 16^9 mod 107, divide the answer by 107, add the result to T.
>
> And so on.
>
> Go on until the quantity we are adding to T is less than 16^-3 (a few more
> terms may be required). In general we will need to take a few more than N
> terms (about 14 in this case).
>
> Finally, take the fractional part of T, multiply by 16^3, convert this to
> hex, and we have hex digits 11, 12 and 13 of S.
I now understand the derivation of your O( N log N ) estimate. Thanks.
However, I was convinced that there was a series sum that eliminated the bulk of
the trailing fractions by collecting terms of like denominators, leaving O( log
N ) uncollected terms. I haven't been able to find it again, so it may be from
a different problem. I'll keep looking.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another sci.crypt Cipher
Date: Sat, 27 May 2000 16:55:43 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8gnnmv$dma$[EMAIL PROTECTED]>, matthew_fisher@my-
> deja.com wrote:
> >In article <[EMAIL PROTECTED]>,
> > tomstd <[EMAIL PROTECTED]> wrote:
> >> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> >> (Mark Wooding) wrote:
> >....
> >
> >A nice attack. I had trouble reproducing it, though.
> >....
> >
> >> If I were to implement this on reduce rounds (for the fun of
> >> it), would I just take a plaintext (A,B) and (A,B xor
> 00010000)
> >> and look for the output difference of (A xor 00030000, B)
> after
> >> 3 or 4 rounds? I am not clear on this part.
> >>
> >> BTWx2 Thanks for the info, I really want to learn from this.
> >> BTWx3 I designed this cipher so I could break it. So I am not
> >> disappointed it was broken, just that I didn't do it first.
> >>
> >> Tom
> >
> >Tom,
> >
> >Here is even a better attack, I believe. The code is at the
> end, make
> >sure you reduce the rounds to 6!
> >
> >The differential is 00 00 00 0c -> 00 00 00 0c 4/256 for box 0.
> >
> >I noticed that all of the entries in sbox 0 ended in 0,4,8 or
> C. I
> >though it might be possible to get a truncated differential of
> the
> >form 00 00 00 xx -> 00 00 00 xx. Sure enough 0x0c does just
> that.
>
> I copied your source code onto of my ref source code and
>
> http://www.tomstdenis.com/tc1mf.c
>
> Is the result. I don't see your "trait" for both words even
> after 2 rounds. I do see the 0x0000000c in the first word, but
> it's gone after 4 rounds...
>
> Maybe I did it wrong?
>
Tom,
A slight mistake. Here is the output by round. You sample has ROUNDS
set to 8. So the
// this is four six rounds, should be about 2^24
if(((p[0]^p1[0]) == 0x00000000L) // 0000000
&& ((p[1]^p1[1]) == 0x0000000CL))
count2++; /* just a counter */
must be
// this is for eight rounds, should be about 2^30
if(((p[0]^p1[0]) == 0x0000000CL) // 0000000C
&& ((p[1]^p1[1]) == 0x0000000CL))
count2++; /* just a counter */
R p1 p0
0 0 c prob = 1
1 c 0 2^-6
2 c c 2^-6
3 0 c 1
4 c 0 2^-6 <-- output of the fourth round
5 c c 2^-6
6 0 c 1 <-- output of the sixth round
7 c 0 2^-6
8 c c 2^-6 <-- output of the eight round
9 0 c 1
A c 0 2^-6
B c c 2^-6
C 0 c 1
D c 0 2^-6
E c c 2^-6
F 0 c 1
c 0 cipher text
I liked you enhancements BTW.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 27 May 2000 11:12:21 -0500
From: No User <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Klaus Daehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Besides the fact that EE is crossposting and posting off topic, I
> wound up downloading their product before this debate started, and
> (so far) have nothing bad to say.
Yes I think this needed saying.
EE seems a excellent product and it's important to remember that even when
EE Support in this group is really pissing people off, and it really is,
EE. It's time you stuck to what you do best, writing software.
See how irritating repetition is?
--
Irritating Poster #2
------------------------------
Date: Sat, 27 May 2000 13:23:20 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Even his (Spencer's) conclusion is suspect. Peer review of the hardware is
necessary as demonstrated, but it is not sufficient due to the possibility of
features hidden in the tools that process the hardware design. I'm specifically
referring to capabilities such as the compromise of the Unix login command that
was hidden inside the C compiler.
It may be harder to recognize a DES or 3DES core that it is to recognize login.c,
but it isn't hard enough to make it impossible in practice. If the crypto core
exists in a library of such designs and the library was distributed with the
hardware design tools it would not even be difficult.
Jonathan Thornburg wrote:
> Someone (who if I've unwrapped the nested quoting correctly might have
> been Mark Wooding) wrote:
> >> Yes, but the point is that, in theory, DES is completely deterministic.
> >> If you have a DES chip, you can feed known keys and plaintexts in it,
> >> and verify that you get the right answers against some other known and
> >> trusted implementation. You can even give it `trick questions' every
> >> now and then while it's in production use, checking its results, to make
> >> sure it's not randomly deciding to emit leaked key material instead of
> >> giving the right answers every now and then. I'd hope that most serious
> >> users of black-box cryptography hardware or software did something like
> >> this.
>
> In article <[EMAIL PROTECTED]>,
> David Hopwood <[EMAIL PROTECTED]> replied:
> >Testing isn't sufficient. Consider:
> >
> > DES'[K](P) = DES[K](P), if P != backdoor
> > = K, if P == backdoor
> >
> >Then with a single chosen plaintext, the key is revealed. Assuming the
> >backdoor plaintext is chosen randomly, no amount of testing that takes
> >less than 2^63 expected work will find it.
>
> David is of course quite right. For a nice illustration of the same
> point, permit me to repost again, the following (highly amusing as well
> as factually correct) message by Henry Spencer from the Linux-IPsec
> mailing list:
>
> ## http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
> _________________________________________________________________
>
> [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread
> Index]
>
> Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
> _________________________________________________________________
>
> * To: Linux IPsec <[EMAIL PROTECTED]>
> * Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
> protected 100Mbit Ethernet
> * From: Henry Spencer <[EMAIL PROTECTED]>
> * From: [EMAIL PROTECTED]
> * Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
> * In-Reply-To: <[EMAIL PROTECTED]>
> * Reply-To: [EMAIL PROTECTED]
> * Sender: [EMAIL PROTECTED]
> _________________________________________________________________
>
> William H Geiger writes:
> > I don't know if you still follow the CP list but we have
> > been having a long debate on the trustworthiness of Intel
> > hardware, especially their RNG...
>
> At first I thought this was pretty much a non-issue here. The problem
> with the RNG is that it's so hard to decide whether its output is "really"
> random. But 3DES is a deterministic transform which can be tested against
> other implementations, so you can easily establish whether the chip is
> really doing 3DES or not.
>
> Alas, then I got to thinking. Suppose one built a 3DES accelerator chip
> so that, if and only if:
>
> (a) the chip is doing near-continuous encryptions at high speed, and
> (b) the keys are changing every packet or two, and
> (c) the chip detects -- via a simple mechanism like a little hash table --
> a key which has appeared before, recently, and
> (d) this key has not been marked "compromised" in the hash table, and
> (e) an internal 16-bit packet counter is all-1s,
>
> then
>
> (!) mark the key compromised in the hash table, XOR the key with the
> string "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!", prefix it with a
> random-looking constant bit pattern, and sprinkle the resulting bits into
> the encrypted data, in a haphazard but deterministic pattern.
>
> This is, of course, an encryption error. But rules (a)-(e) make it
> essentially irreproducible, so it won't happen a second time (and will be
> quite difficult to reproduce even in a test setup). Almost certainly it
> will get written off as a random error, and the affected packet will be
> re-processed correctly and re-sent, and all will be well.
>
> Except that an eavesdropper on the high-speed wire just looks for the
> constant bit pattern in the right places in a packet, and (almost) every
> time he sees it, he's nabbed an encryption key.
>
> There's no limit to the complexity that can be added -- especially if
> you're willing to consider active wiretapping, with the chip going into
> this mode only if it sees (say) an ICMP ping with the right data in it --
> to defeat attempts to find this sort of thing on the test bench.
>
> I fear I agree with William; nothing short of peer review of the hardware
> design makes such a device trustworthy.
>
> Henry Spencer
> [EMAIL PROTECTED]
> ([EMAIL PROTECTED])
>
> -
> This is the [EMAIL PROTECTED] mailing list. It is a
> restrict-Post filtered version of [EMAIL PROTECTED]
>
> --
> -- Jonathan Thornburg <[EMAIL PROTECTED]>
> http://www.thp.univie.ac.at/~jthorn/home.html
> Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
> Seen on usenet:
> Q: "If we're not supposed to eat animals, why are they made of meat?"
> A: "If we're not supposed to eat people, why are they made of meat?"
------------------------------
Date: Sat, 27 May 2000 13:25:23 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: looking for an 8-byte long output hashing function
Boris Kazak wrote:
> Dear Jean-Luc:
> Just take the 16-byte hash function and XOR together the right
> and left halves of the output.
... or throw away 12 of 20 bytes.
------------------------------
From: Joe@Joe's.bar&grill.org
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: Sat, 27 May 2000 17:38:32 +0100
On Sat, 27 May 2000 11:12:21 -0500, No User <[EMAIL PROTECTED]>
wrote:
>Klaus Daehne wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Besides the fact that EE is crossposting and posting off topic, I
>> wound up downloading their product before this debate started, and
>> (so far) have nothing bad to say.
>
>Yes I think this needed saying.
>
>EE seems a excellent product and it's important to remember that even when
>EE Support in this group is really pissing people off, and it really is,
>EE. It's time you stuck to what you do best, writing software.
>
>See how irritating repetition is?
And exactly how are they to defend themselves against the constant
barrage of lies regarding their software? If they do not defend
themselves, the lies will become truth in the minds of most.
Make no mistake about it -- some people are out to deliberately
destroy this product. EE is not merely indulging themselves in the
art of spamming. I think they are fighting for their corporate life.
I bought it awhile back and use it everyday. I think it's one the
most indispensable pieces of software I own.
Did it ever occur to you that maybe some of EE's chief detractors wear
badges?lll
-- Joe -
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 27 May 2000 10:37:55 -0700
In article <8goumb$6qa$[EMAIL PROTECTED]>, matthew_fisher@my-
deja.com wrote:
>Tom,
>
>A slight mistake. Here is the output by round. You sample has
ROUNDS
>set to 8. So the
>
>// this is four six rounds, should be about 2^24
>if(((p[0]^p1[0]) == 0x00000000L) // 0000000
>&& ((p[1]^p1[1]) == 0x0000000CL))
>count2++; /* just a counter */
>
>must be
>
>// this is for eight rounds, should be about 2^30
>if(((p[0]^p1[0]) == 0x0000000CL) // 0000000C
>&& ((p[1]^p1[1]) == 0x0000000CL))
>count2++; /* just a counter */
>
Um ok.
> R p1 p0
> 0 0 c prob = 1
> 1 c 0 2^-6
> 2 c c 2^-6
> 3 0 c 1
> 4 c 0 2^-6 <-- output of the fourth round
> 5 c c 2^-6
> 6 0 c 1 <-- output of the sixth round
> 7 c 0 2^-6
> 8 c c 2^-6 <-- output of the eight round
> 9 0 c 1
> A c 0 2^-6
> B c c 2^-6
> C 0 c 1
> D c 0 2^-6
> E c c 2^-6
> F 0 c 1
> c 0 cipher text
>
>
>I liked you enhancements BTW.
What enhancements ? I just cleaned up the code.
BTW how did you find those differentials anyways? That is why I
made this cipher. I want to learn how to spot them in less-then-
obvious cases.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Sat, 27 May 2000 13:50:53 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
tomstd wrote:
> In article <[EMAIL PROTECTED]>, "Trevor L. Jackson,
> III" <[EMAIL PROTECTED]> wrote:
> >
> >
> >Bob Silverman wrote:
> >
> >> In article <[EMAIL PROTECTED]>,
> >> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> >> > In article <[EMAIL PROTECTED]>,
> >> > [EMAIL PROTECTED] says...
> >> >
> >>
> >> > For example, if you want some information to remain secure
> for at
> >> > least the next 50 years, you'd _better_ not depend on an
> RSA key of
> >> > 768 bits, even though that's (AFAIK) unbreakable at the
> present time.
> >> > In 50 years, an average hand-held calculator is likely to
> have more
> >> > than enough resources to break a 768-bit key.
> >>
> >> Typical inane sci.crypt technobabble.
> >>
> >> I will give you a hint: Think about the *power* requirements
> to drive
> >> a processor that fast. Think about the power needed to
> refresh
> >> a terabyte of memory.....
> >
> >This _is_ worth thinking about. Remember that in 1900 NYC was
> supposed to be
> >covered in horse dung 100' deep by 1950, and everyone in the
> city was going to
> >be working as telephone operators by 1930. Remember that IBM
> projected a
> >worldwide market for computers of six units (and they were
> right -- then).
> >
> >Remember when another RSA spokesperson addressed the strength
> of their cipher
> >by saying it would take "40 quadrillion years" and it didn't
> even last 40
> >years.
>
> I think he was being a bit precautious then.
>
> >Remember Somebody's Law (Clarke?) to the effect that when an
> authority in a
> >field states that something is possible, he's nearly always
> correct, but when
> >he states that something is impossible, he's nearly always
> wrong.
> >
>
> I can't sprout wings, and it's impossible for me to sprout
> wings. I would love to be wrong on that one.
>
> >To address the question posed in detail, there is _no_ lower
> limit on the
> >amount of energy required to perform a calculation. So the
> power requirements
> >are completely irrelevant to the theoretical question of
> computation rates far
> >in the future.
>
> There is an *upper* limit. You can't for example run thru an
> entire 256 bit counter once, no matter what you do, there is not
> enough energy in the universe. So it's possible for example to
> use 256 bit symmetric keys and have "provable" security
> (assuming the cipher is made of "provable" parts which is
> another story).
You are mixing energy and time. There's plenty of energy to run the counter,
but there's not enough time to run it at less than fantastic speeds. The
shortest interval I'm aware of is the time it takes light to cross the distance
enclosing a sub-atomic particle. If there's a computation speed floor it's
something like that. There can't be a computation energy floor because of
reversibility.
>
>
> So if the NFS will take 2^256 steps to factor a n-bit composite,
> then it's provably secure, unless a new NFS or Sieve comes
> along, which is possible but not very likely.
>
> >As for terrabyte memories, I have it on good authority (cirra
> 1975) that they
> >are impossible because the ionization due to radioactive
> contamination of the
> >substrate and the carrier will raise the error rate
> unacceptably high as the
> >amount of charge in each cell drops below 5e5 electrons per
> bit. But they
> >didn't use ECC widely, and didn't have access to low radiation
> substrates and
> >carriers then. Remember?
>
> Yea the problem is the memory has to be tightly coupled, so you
> can use the memory of a million computers. You need one
> computer (with many processors) with a huge amount of ram.
>
> >-- Babble on, Bob
>
> While I do think he is speaking for RSA alot, I would like to
> also believe he is a person of science and he knows what he is
> doing.
I would like to believe that as well. But I can't always. Sometimes facts
interfere with my preferences.
------------------------------
From: [EMAIL PROTECTED]
Subject: getting easy primes
Date: Sat, 27 May 2000 17:41:30 GMT
just wanted to let the community know that numbers in following series
have surprisingly dense ratio of primes to compounds.
41, 43, 47, 53, 61, 71, 83, 97 ........
this series has nothing but prims until square of 41, that is 1681. and
still great much density of primes countinues indefinitely.
Naveed Yaseen
[EMAIL PROTECTED]
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
******************************
