Cryptography-Digest Digest #561, Volume #12 Tue, 29 Aug 00 01:13:00 EDT
Contents:
Re: 4x4 s-boxes (Mack)
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Re: blowfish problem ("Bruce G. Stewart")
Re: Future computing power (Anthony Stephen Szopa)
Re: Future computing power (Anthony Stephen Szopa)
Re: Future computing power ("CMan")
Re: Future computing power (Anthony Stephen Szopa)
Re: Future computing power ("CMan")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 4x4 s-boxes
Date: 29 Aug 2000 04:10:27 GMT
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Mack) wrote:
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] (Mack) wrote:
>> >> >In article <[EMAIL PROTECTED]>,
>> >> > [EMAIL PROTECTED] (Mack) wrote:
>> >> >> Has anyone analyzed the number of s-boxes
>> >> >> that could be used for Serpent?
>> >> >>
>> >> >> more specifically, serpent s-boxes don't appear
>> >> >> to have particularly good avalanche characteristics.
>> >> >>
>> >> >> The criteria seem logic but is it possible that
>> >> >> the serpent s-boxes might have been chosen
>> >> >> using stricter criteria?
>> >> >
>> >> >My "serpent_sboxes" on my website are good candidates for
>replacement
>> >> >sboxes if needed.
>> >> >
>> >> >Tom
>> >> >--
>> >> >http://www.geocities.com/tomstdenis/
>> >> >
>> >>
>> >> I have looked at your program to produce s-boxes.
>> >>
>> >> My question is of a more general nature. ie. how many
>> >> s-boxes actually meet th Serpent criteria and could
>> >> we add additional criteria to the given ones that would
>> >> improve the characteristics without producing a null
>> >> set of s-boxes.
>> >>
>> >> for example. 4x4 s-boxes having the forward and
>> >> inverse both maximum non-linearity and meeting
>> >> sac are rare at best and non-existent at worst.
>> >> Does anyone know if such s-boxes exist?
>> >
>> >The sboxes I made have are completely non-linear i.e their "bent",
>they
>> >fullfil SAC and BIC to the order-3. Other then a DPmax of four they
>> >are perfect sboxes.
>> >
>> >Finding them is hard, it took about 8 hours of random searching with
>> >sboxgen. I am in the middle of making another set right now
>actually.
>> >
>> >Overall about 1 in 100 million are ok. This is really rough since I
>> >didn't keep track of the totals. This means about 1 in 2^27 are ok,
>> >and since there are only 2^44 possible sboxes, about 2^17 should
>exist.
>> >
>> >Tom
>> >
>>
>> It is relatively easy to find s-boxes that meet the SAC, BIC and non-
>linearity
>> requirements in the forward direction. there are only 1368 boolean
>functions
>> of four variables that meet the non-linearity requirement of 4 and
>SAC. There
>> are even less that meet the requirement of 6.
>
>I don't get the "requirement of 4". Generally you perform a WT or
>FWT. In my case I chose th WT and I get -4/4 which is the best you can
>get for a "bent" sbox.
>
You can also use the maximum hamming weight to a linear function
which is quicker to calculate. Extending this to an s-box is a bit
trickier but very useful.
bent is usually used to refer to functions which have non-linearity
which is maximum. They only occur on functions of 2n variables
and are not balanced. You appear to be refering to nearly bent
functions.
>> Note that for a permutation to be bent it is not bijective. I am
>interested in
>> Bijective 4x4 s-boxes with equally good properties in both directions.
>
>Actually any bijection function will have an inverse with the same
>linearnity. (this is really simple to prove too).
{3,13,6,14,2,0,15,12,1,5,10,7,4,11,8,9};
This is taken from Construction of DES-like S-boxes based on
Boolean functions satisfying the SAC by Kwangjo Kim.
Which are the S^2 s-boxes. This is line 2 of the S3-box.
The definition of non-linearity is the hamming distance
from the closest affine function. (Ruepple's criterion)
This has non-linearity of 4 and satisfies the SAC for
each of the boolean functions that are used to construct
it.
Its inverse
5 8 4 0 12 9 2 11 14 15 10 13 7 1 3 6
has nonlinearity of the constituent boolean functions
2 4 2 4
and none of the constituent functions satisfy the SAC.
So no the inverse does NOT have the same non-linearity.
proof by counter example
>
>> Have you found any s-boxes that are bijective (invertible) and
>> satisfy the nonlinearity of 4 and SAC in both directions?
>
>Yes, my serpent sboxes. They have a WT of -4/4 (doesn't matter which
>direction), a differntial xor-pair max of 4, fulfill SAC and BIC to
>order 3 (which means no set of 3 4x1 outputs can be linearly related
>via xor)
>
>> "Good S-boxes are easy to find" by Adams and Tavares
>> says that there are 60 sboxes that meet SAC, non-linearity,
>> and BIC and are bijective with both the box and its inverse
>> meeting these properties. They list three S-boxes but they aren't
>> the ones that meet these criteria.
>>
>> Does anyone actually have a list of the s-boxes?
>
>Um this is all wrong. There are 16! ~ 2^44 possible 4x4 sboxes, of
>which many are nonlinear and differentially secure. For example the
>following 1000 sboxes have a WT of -4/4, a DP max of 4. But they don't
>nessasarily follow SAC or BIC. At the end there are 50 sboxes that
>meet all of this in the forwards direction.
>
>Check out my sboxgen at http://www.geocities.com/tomstdenis/ for more
>info on making sboxes.
>
>/* 1000, 4 by 4 sbox(es) */
>const int sbox[1000][16] = {
> { 3, 7, 14, 1, 8, 2, 4, 12, 13, 11, 0, 9, 5, 6, 15, 10 },
> { 10, 15, 8, 4, 11, 5, 13, 1, 3, 6, 14, 12, 7, 9, 0, 2 },
> { 7, 4, 3, 11, 12, 5, 0, 13, 8, 6, 9, 14, 2, 1, 15, 10 },
> { 14, 8, 7, 6, 5, 10, 0, 4, 9, 15, 3, 11, 13, 1, 2, 12 },
> { 13, 2, 11, 6, 7, 5, 3, 4, 15, 8, 0, 1, 12, 9, 14, 10 },
> { 12, 6, 5, 7, 10, 9, 1, 15, 8, 13, 2, 4, 14, 0, 11, 3 },
> { 4, 7, 15, 8, 10, 2, 9, 13, 14, 3, 12, 6, 1, 0, 5, 11 },
> { 12, 13, 6, 3, 4, 0, 9, 11, 14, 1, 2, 8, 5, 10, 7, 15 },
> { 9, 6, 14, 10, 15, 12, 3, 8, 0, 5, 11, 2, 4, 1, 13, 7 },
> { 1, 12, 14, 5, 10, 11, 0, 7, 4, 15, 6, 3, 13, 9, 8, 2 },
> { 3, 9, 1, 13, 12, 15, 0, 6, 11, 10, 8, 5, 14, 4, 7, 2 },
> { 3, 12, 8, 10, 5, 9, 4, 14, 0, 11, 6, 1, 7, 13, 15, 2 },
> { 10, 8, 3, 1, 11, 5, 12, 13, 9, 7, 15, 6, 2, 14, 4, 0 },
> { 9, 15, 10, 5, 0, 1, 4, 7, 2, 3, 14, 12, 6, 11, 13, 8 },
> { 13, 6, 2, 11, 5, 4, 9, 7, 14, 0, 12, 1, 8, 10, 3, 15 },
> { 6, 0, 7, 11, 10, 15, 4, 9, 3, 8, 5, 1, 13, 2, 12, 14 },
> { 14, 9, 12, 11, 7, 5, 3, 10, 4, 13, 2, 0, 1, 15, 8, 6 },
> { 3, 1, 8, 12, 7, 4, 5, 2, 9, 6, 10, 13, 11, 0, 14, 15 },
> { 0, 13, 7, 15, 11, 1, 2, 5, 12, 6, 10, 4, 14, 3, 8, 9 },
> { 7, 10, 6, 0, 13, 12, 4, 15, 2, 1, 9, 3, 14, 5, 8, 11 },
> { 6, 10, 13, 14, 12, 3, 0, 11, 7, 5, 4, 9, 1, 2, 8, 15 },
> { 3, 13, 11, 10, 5, 8, 15, 6, 9, 0, 1, 4, 2, 7, 12, 14 },
> { 7, 11, 2, 13, 1, 8, 5, 12, 3, 15, 10, 0, 4, 6, 9, 14 },
> { 2, 14, 5, 13, 1, 4, 3, 6, 12, 8, 9, 15, 7, 0, 11, 10 },
> { 1, 11, 15, 5, 14, 9, 7, 2, 8, 12, 4, 10, 0, 3, 13, 6 },
> { 12, 1, 3, 13, 10, 11, 9, 15, 2, 7, 8, 5, 4, 14, 6, 0 },
> { 9, 2, 15, 3, 10, 8, 6, 1, 0, 11, 13, 5, 4, 12, 14, 7 },
> { 9, 1, 7, 13, 3, 11, 14, 8, 12, 0, 4, 6, 5, 2, 15, 10 },
> { 13, 15, 10, 0, 2, 9, 7, 12, 4, 8, 5, 11, 6, 3, 1, 14 },
> { 3, 5, 1, 14, 9, 0, 7, 10, 11, 8, 4, 12, 2, 15, 13, 6 },
> { 1, 4, 6, 14, 9, 3, 5, 7, 11, 10, 0, 8, 12, 15, 13, 2 },
> { 6, 5, 13, 7, 14, 12, 3, 10, 4, 11, 8, 15, 0, 1, 9, 2 },
><<snip>>
>
>better sboxes
>
>/* 50, 4 by 4 sbox(es) */
>const int sbox[50][16] = {
> { 14, 0, 1, 8, 15, 7, 11, 12, 6, 2, 4, 3, 10, 9, 13, 5 },
> { 12, 5, 3, 0, 8, 13, 4, 6, 9, 15, 11, 7, 2, 14, 1, 10 },
> { 2, 12, 1, 8, 7, 4, 3, 9, 14, 11, 6, 0, 5, 13, 10, 15 },
> { 10, 4, 1, 0, 6, 7, 8, 5, 14, 12, 3, 13, 9, 2, 11, 15 },
> { 9, 10, 1, 5, 14, 4, 13, 12, 8, 6, 11, 0, 3, 7, 15, 2 },
> { 9, 11, 4, 0, 13, 10, 14, 6, 7, 8, 5, 12, 15, 3, 2, 1 },
> { 5, 14, 8, 10, 0, 12, 11, 2, 13, 9, 15, 1, 4, 7, 3, 6 },
> { 5, 11, 9, 13, 7, 2, 6, 12, 8, 0, 10, 1, 3, 4, 14, 15 },
> { 5, 12, 13, 9, 0, 10, 7, 6, 14, 2, 11, 8, 4, 3, 15, 1 },
> { 2, 0, 1, 8, 11, 6, 7, 9, 5, 4, 13, 3, 10, 12, 14, 15 },
> { 6, 15, 7, 0, 4, 2, 1, 8, 9, 11, 5, 13, 14, 3, 12, 10 },
> { 0, 9, 4, 6, 5, 3, 2, 11, 7, 13, 15, 8, 12, 1, 14, 10 },
> { 15, 12, 13, 0, 7, 10, 1, 2, 9, 5, 4, 6, 8, 14, 11, 3 },
> { 3, 1, 5, 4, 14, 6, 7, 8, 0, 9, 11, 13, 10, 12, 2, 15 },
> { 5, 1, 12, 14, 13, 3, 9, 8, 0, 15, 6, 7, 11, 2, 10, 4 },
> { 0, 9, 2, 4, 8, 5, 13, 6, 10, 12, 14, 7, 11, 15, 1, 3 },
> { 8, 9, 3, 13, 14, 10, 12, 1, 2, 0, 6, 15, 11, 4, 7, 5 },
> { 5, 9, 4, 12, 14, 13, 1, 7, 0, 3, 6, 11, 10, 2, 8, 15 },
> { 15, 4, 9, 11, 7, 3, 13, 6, 14, 10, 12, 2, 8, 1, 5, 0 },
> { 15, 13, 11, 5, 4, 9, 14, 12, 3, 2, 8, 7, 1, 0, 6, 10 },
> { 1, 5, 7, 6, 4, 12, 13, 10, 0, 11, 9, 15, 2, 8, 14, 3 },
> { 14, 13, 10, 15, 7, 3, 4, 12, 0, 9, 11, 5, 2, 8, 6, 1 },
> { 3, 11, 13, 0, 1, 6, 5, 7, 10, 14, 15, 4, 2, 12, 8, 9 },
> { 10, 9, 0, 12, 3, 14, 4, 6, 2, 11, 15, 8, 7, 1, 13, 5 },
> { 3, 4, 14, 12, 0, 8, 2, 15, 5, 13, 6, 11, 10, 9, 7, 1 },
> { 5, 1, 14, 7, 2, 3, 4, 11, 12, 15, 8, 6, 0, 10, 9, 13 },
> { 6, 3, 15, 7, 14, 0, 13, 10, 11, 9, 1, 4, 12, 5, 8, 2 },
> { 3, 15, 11, 10, 9, 14, 5, 1, 0, 2, 7, 8, 4, 12, 6, 13 },
> { 5, 10, 2, 11, 9, 8, 1, 15, 4, 0, 12, 14, 3, 13, 6, 7 },
> { 9, 7, 6, 5, 8, 10, 2, 15, 4, 1, 12, 0, 3, 11, 14, 13 },
> { 11, 3, 5, 0, 13, 14, 12, 2, 8, 9, 1, 7, 6, 10, 4, 15 },
> { 4, 2, 7, 8, 13, 9, 1, 0, 12, 6, 10, 3, 14, 11, 15, 5 },
> { 5, 2, 12, 1, 14, 6, 8, 3, 13, 15, 9, 7, 0, 4, 11, 10 },
> { 12, 0, 4, 7, 9, 1, 6, 8, 3, 2, 5, 10, 13, 11, 15, 14 },
> { 8, 11, 10, 6, 0, 4, 12, 15, 13, 1, 14, 5, 9, 2, 3, 7 },
> { 11, 6, 5, 4, 15, 7, 13, 10, 9, 12, 14, 0, 8, 2, 1, 3 },
> { 5, 7, 0, 4, 12, 1, 6, 9, 3, 14, 10, 2, 13, 15, 11, 8 },
> { 12, 10, 15, 7, 13, 4, 2, 6, 14, 1, 11, 9, 0, 5, 8, 3 },
> { 10, 1, 14, 0, 4, 13, 15, 9, 3, 5, 2, 11, 6, 7, 8, 12 },
> { 4, 12, 7, 1, 5, 2, 15, 6, 9, 14, 0, 8, 3, 10, 13, 11 },
> { 12, 6, 0, 5, 14, 10, 13, 3, 7, 1, 8, 9, 15, 4, 11, 2 },
> { 10, 2, 6, 4, 14, 1, 7, 8, 3, 5, 9, 0, 12, 13, 15, 11 },
> { 11, 13, 9, 8, 2, 15, 6, 5, 12, 0, 1, 10, 14, 4, 7, 3 },
> { 1, 15, 4, 13, 3, 2, 12, 10, 5, 6, 11, 14, 9, 7, 8, 0 },
> { 4, 0, 1, 10, 5, 6, 12, 8, 3, 9, 11, 14, 15, 2, 13, 7 },
> { 12, 14, 9, 0, 13, 5, 2, 4, 7, 10, 15, 11, 1, 6, 3, 8 },
> { 7, 8, 0, 4, 15, 9, 2, 10, 11, 3, 1, 6, 14, 5, 12, 13 },
> { 3, 9, 10, 15, 5, 2, 13, 7, 1, 4, 14, 6, 8, 0, 11, 12 },
> { 10, 15, 14, 6, 7, 0, 13, 12, 9, 5, 4, 3, 11, 1, 8, 2 },
> { 11, 5, 1, 8, 15, 14, 3, 13, 9, 10, 4, 12, 0, 6, 2, 7 } };
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
>
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4x4 s-boxes
Date: Tue, 29 Aug 2000 04:07:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Mack) wrote:
> >> Has anyone analyzed the number of s-boxes
> >> that could be used for Serpent?
> >>
> >> more specifically, serpent s-boxes don't appear
> >> to have particularly good avalanche characteristics.
> >>
> >> The criteria seem logic but is it possible that
> >> the serpent s-boxes might have been chosen
> >> using stricter criteria?
> >
> >At http://www.geocities.com/tomstdenis/files/sboxes.c
> >
> >You can find about 10000 4x4 sboxes that have a DPmax of 4, a LPmax
of
> >4. They don't follow SAC/BIC in either direction.
> >
> >This just goes to show that your citation from CAST was wrong.
>
> citation from CAST????
>
> >
> >It's true however that the number of sboxes that follow SAC/BIC in
one
> >direction is quite a bit lower, and much lower in *both* direction.
> >
> >Tom
>
> I found an interesting correllation (at least to me).
> One of the criteria of the serpent s-boxes <APPEARS> to
> eliminate s-boxes satisfying the SAC. That is the
> criteria that no one bit input change results in a one
> bit output change. I may be wrong on this one,
> but from my observation all s-boxes that satisfy the
> SAC in both directions have a one bit output change
> for some one bit input change.
Perhaps, I am not sure off hand.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Bruce G. Stewart" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Tue, 29 Aug 2000 04:32:43 GMT
Eric Smith wrote:
>
> "Bruce G. Stewart" <[EMAIL PROTECTED]> writes:
> > Not so. It implies that converting an pointer to some type into a void*
> > then into an unsigned char* may be more than a trivial copy from
> > location to another.
>
> So you're saying that the C standard *requires* that a conforming
> implementation allow the programmer to cast a pointer from foo *
> to void *, then to char *, then back again, and wind up with the
> same pointer?
>
> I can't find anything in the standard which requires this. It seems
> to me that a conforming implementation that has different representations
> for foo * and char * could correctly handle converting from either of
> those to a void * simply by using the internal representation. In this
> case, the compiler could presumable correctly cast from foo * to char *,
> but if you went through an intermediate void *, the wrong thing would
> happen.
>
> Or does the standard somewhere require that void * have the same
> representation as char *?
Footnote 39 to 6.2.5.26 says, "The same representation and alignment
requirements are meant to imply interchangeability as arguments to
functions, return values from functions, and members of unions."
The round-about wording is probably to allow for tagged architectures
that might make the representations different in inconsequential ways.
The conversion part of the standard guarantees that a foo*, cast to a
void*, then back to an foo* will have it's original value. That is,
void* has the capacity to encode the value of any pointer to an object.
But there's no guarantee that casting a void* to foo* and back to void*
won't change the value for types other than chars.
"A pointer to an object or incomplete type may be converted to a pointer
to a different
object or incomplete type. If the resulting pointer is not correctly
aligned 57) for the
pointed-to type, the behavior is undefined. Otherwise, when converted
back again, the
result shall compare equal to the original pointer. When a pointer to an
object is
converted to a pointer to a character type, the result points to the
lowest addressed byte of
the object. Successive increments of the result, up to the size of the
object, yield pointers
to the remaining bytes of the object."
A hypothetical machine could, for example, provide addressing for some
objects that works like c subscripting, where the byte location of an
object is the number stored in the pointer times the size of the object.
In fact, a compiler on a plain byte addressed architecture might do that
to cut down on the amount of arithmetic need to do array accesses.
Cast-to-void in such a system could multiply the foo* by sizeof (foo).
The conversion from void* to char* could be trivial or not. When the
memcpy above is called, there would be this arithmetic involved in
converting the arguments from foo* to void*. Cast from void* to foo*
would divide the pointer by sizeof (foo).
What's required is that the foo* -> void* -> char* and foo* -> char*
both accomplish conversions that refer to the same location in storage.
Since you can't use void* for any kind of access, it really doesn't
matter what format void* has, so long as it can unambiguously represent
any objects address and the conversions work as required.
The memcpy implementation works fine because the conversion to void* is
implicit in the call, and it's defined to have the right properties to
make memcpy work, even if the bit-pattern in a foo* is different from
the bit-pattern of the foo* cast to void*.
/* assuming a pointer is the same size as a long and there are no hidden
bits to concern us */
int main(void)
{
union {
void *p;
long l;
} vu;
union {
long *p;
long l;
} lu1, lu2;
union {
char *p;
long l;
} cu;
long l;
vu.p = &l; /* void* */
lu1.p = &l;
/* vu.l not necessarily == lu1.l */
lu2.p = vu.p; /* from void * */
/* lu2.l == lu1.l */
cu.p = (char *)&l;
/* cu.l almost must == vu.l */
}
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Mon, 28 Aug 2000 21:45:01 -0700
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > While the fabulous quantum computing lies certainly yet
> > far in the future, it may be useful to know how fast the
> > conventional computing power at a single site could
> > augment in the days to come. A newspaper report says that
> > Compaq will build for the US ASCI program a processor
> > cluster capable of delivering 30 Teraflops next year. In
> > 2004 there will be a system delivering 100 Teraflops.
>
> First off what the heck is a flop? All I know is MIPS.
>
> Computer speed will really only affect the tractibilty of PK cracking
> not symmetric stuff. And even there bandwidth/memory is of more
> importance then speed anyways.
>
> If you take the trend of moores law, we can expect 4ghz computers
> sometime in 2002. With the current 400mhz bus (or let's say 800mhz
> bus) the cpu better have a large L1 cache.... :)
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
A "flop" is a floating point operation, I think.
Helps?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Mon, 28 Aug 2000 21:42:49 -0700
Ichinin wrote:
>
> Mok-Kong Shen wrote:
> <Snip>
>
> How about a 10 x 800Mhz Beowulf cluster for your "recreational
> purposes" ? :o)
>
> All you need are the basic components:
>
> What's needed for each node:
> - Processor
> - Fan
> - Systemboard
> - about 32 to 64 MByte memory (larger if you have $'s)
> - Boot system (CdRom/Harddrive or Floppy)
> - Some 100 MBit NIC
>
> Then you need:
> - an N-port 100Mbit Hub.
> - A storage box. (Customise or build)
> - A strong power outlet.
>
> Home supercomputing for practically nothing. I'd build
> one if i had some spare change.
>
> Regards,
> Glenn
I might give you some money if you can prove you can do it.
How much do you think you might need for the entire system?
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Mon, 28 Aug 2000 21:58:23 -0700
Don't forget Linux. You can have multiple copies of the operating system
running and be totally legal.
Remember, Linux can be rigged for diskless booting which can save a lot of
dollars on disk driveds(although these days disk drives are sort of a dime a
dozen - amazing. I bought that Apple II and ran it without a hard drive for
a long time. Gees. I wonder where the cost per gigaflop will finally
stabilize?
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Ichinin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mok-Kong Shen wrote:
> <Snip>
>
> How about a 10 x 800Mhz Beowulf cluster for your "recreational
> purposes" ? :o)
>
> All you need are the basic components:
>
> What's needed for each node:
> - Processor
> - Fan
> - Systemboard
> - about 32 to 64 MByte memory (larger if you have $'s)
> - Boot system (CdRom/Harddrive or Floppy)
> - Some 100 MBit NIC
>
> Then you need:
> - an N-port 100Mbit Hub.
> - A storage box. (Customise or build)
> - A strong power outlet.
>
> Home supercomputing for practically nothing. I'd build
> one if i had some spare change.
>
> Regards,
> Glenn
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Mon, 28 Aug 2000 21:48:45 -0700
[EMAIL PROTECTED] wrote:
>
> In article <8of50a$oc7$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >
> > Yes I am. Let's say you are interesting purely in graphics
> > manipulation. What is more usefull for you? flops/sec or dct/etc per
> > sec?
> >
>
> Benchmarks like SpecFP and SpecInt are far more involved than merely
> repeating a simple operation many times. If you are interested in
> scientific programming, the Spec benchmarks can give you some idea of
> the performance you might expect on standard codes. Of course, if you
> are interested in something else, by all means, use your own benchmarks
> on products. But don't expect everyone to use your benchmark too.
> Flops/sec are usually measured using a dense linear algebra routine
> like linpack (or its parallelized cousins). If you are interested in
> graphics manipulation, there are content creation benchmarks available,
> as well as 3d-rendering based application level tests.
>
> > At anyrate I think cycles per opcode, pipeline efficiency, cache
> > effectiveness and branch prediction effectiveness are more
> quantitative
> > things then how many times you can do fsqrt a second.
> >
>
> Your comment displays your lack of knowledge of how modern MPUs work.
> Cycles per opcode, pipeline depth, cache hit rates, and branch
> prediction success are only a very small part of the information needed
> to model a contemporary deeply pipelined, out-of-order, superscalar
> processor. Even if you generously throw in more information like
> instruction density, memory bandwidth, decoding width, functional
> units, and SIMD instructions, you have but a minute part of the overall
> picture that will allow you to judge performance. Many designs look
> good on paper (Itanium, ahem). Internal microarchitecture must be
> considered, as well as the intagibles like process technology and
> routing techniques.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Sounds like you got all that out in just one breath.
I would guess you could continue at length.
Yes?
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Mon, 28 Aug 2000 22:06:56 -0700
I don't agree at all if you are talking cryptography. CPU speed is THE
factor for most brute force applications that I can imagine. The cache
requirements are mild also. Perhaps you had a special application in mind
but the brute force search is usually highly parallel with almost no need
for high speed interprocess communication. You just dedicate a portion of
the keyspace to each processor and let her rip.
I'm sure someone will think of a mathematical operation that makes a liar
out of me but I just don't see the need for interprocessor bandwidth or
large cache memory for cryptography. There are MANY applications in other
fields like logic simulation where this is not the case of course.
We found that overclocked Celerons gave pretty spectacular performance in a
Beowulf cluster against MD5 - RC4.
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote in message news:8oeg9r$3q$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > While the fabulous quantum computing lies certainly yet
> > far in the future, it may be useful to know how fast the
> > conventional computing power at a single site could
> > augment in the days to come. A newspaper report says that
> > Compaq will build for the US ASCI program a processor
> > cluster capable of delivering 30 Teraflops next year. In
> > 2004 there will be a system delivering 100 Teraflops.
>
> First off what the heck is a flop? All I know is MIPS.
>
> Computer speed will really only affect the tractibilty of PK cracking
> not symmetric stuff. And even there bandwidth/memory is of more
> importance then speed anyways.
>
> If you take the trend of moores law, we can expect 4ghz computers
> sometime in 2002. With the current 400mhz bus (or let's say 800mhz
> bus) the cpu better have a large L1 cache.... :)
>
> Tom
>
>
> 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
******************************
