Cryptography-Digest Digest #978, Volume #8 Wed, 27 Jan 99 12:13:05 EST
Contents:
Re: Unicity, DES Unicity and Open-Keys (Mok-Kong Shen)
Re: Why isn't RC4 used as a hash function? (Paul Crowley)
Re: Foiling 56-bit export limitations: example with 70-bit DES (Patrick Juola)
Re: steganography algorithm (Mok-Kong Shen)
Re: Metaphysics Of Randomness (Alan DeKok)
Re: hardRandNumbGen (Mok-Kong Shen)
Re: My comments on Intel's Processor ID Number (robert)
Re: Random numbers from a sound card? (Mok-Kong Shen)
Re: hardRandNumbGen (Patrick Juola)
Re: Sanity check on authentication protocol (Paul Onions)
Re: hardRandNumbGen (R. Knauer)
Re: lexical analysis problem.... (Terje Mathisen)
Re: Random numbers from a sound card? (R. Knauer)
Re: hardRandNumbGen (Mok-Kong Shen)
Re: Who will win in AES contest ?? (Robert Harley)
Re: My comments on Intel's Processor ID Number (John Savard)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Bruce Barnett)
Re: hardRandNumbGen (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Wed, 27 Jan 1999 14:44:56 +0100
[EMAIL PROTECTED] wrote:
>
>
> For special protocols, in high-security applications, the "magic numbers" can
> also be implicit or encoded with a random seed in each use. However, the
> encoded data itself may betray its presence by its very structure, size,
> range, randomness, redundancy, etc. This is a problem in identification and,
> as given in [Ger98], "to identify is to look for connections" -- not just to
> look for an identity connection with a set of "magic numbers". For further
> discussion on this topic and a practical example please see [Ger99], Section
> 4.
I look forward to be able to study the forthcoming version of your
paper, though I am not yet quite sure that the task of identification
or analysis of compression (if appropriately done for cryptography)
is as straightforward as your text above apparently suggests.
M. K. Shen
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Why isn't RC4 used as a hash function?
Date: 25 Jan 1999 19:32:21 -0000
"Glynne Casteel" <[EMAIL PROTECTED]> writes:
> Is there anything obviously wrong with treating a document as an extremely
> long key and using RC4 as a hash function? That is, repeatedly re-key RC4
> with 256 byte chunks of your document (perhaps iterating thru a few cycles
> between chunks). It seems like you would end up with RC4 in some state
> determined by the document that you fed to it. This would also have the
> benefit of producing a flexible hash size, i.e. if you need a 128 bit hash
> value make 16 calls to the RC4 generator, if you need 240 bits make 30 calls
> to RC4.
It depends what you mean by "hash function". I think that building a
collision-free message digest function with RC4 would be very
difficult, but ISTM that a MAC might be possible. I'd key the RC4
state using the MAC secret, feed it the document whole, discard the
results of 512 further iterations, and then use output from the
generator as the MAC output.
Maybe you could try and build a message digest by, say, feeding it
each 1k chunk of the document thrice, but I think it would be both
slower and less secure than, say, SHA-1.
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: 27 Jan 1999 08:46:08 -0500
In article <78m55c$4cd$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
[snip]
>Please visit the full paper at http://www.mcg.org.br/unicity.htm
>
>This specific section was also changed, to make it easier to understand. The
>new relevant part is:
>
>Consider a hypothetical M-DES Standard (hereafter, M-DES) which would specify
>a total of 2M pre-defined and publicly known 64-bit different blocks of data,
>for various choices of M = 0, 1, ... Now, when Bob wants to send a message to
>Alice, he needs to negotiate a M-DES cipher with Alice, which includes a
>56-bit secret-key [Note-1] and a publicly defined value for M, say M = 14.
>The value of M is chosen by Bob according to his security needs [Note-2], and
>accepted (or not) by Alice. To use M-DES, Bob would privately choose one
>64-bit "key" at will (from the public list of 2^14 "keys") and then
>repeatedly use this choice to XOR-encode one by one each of all 64-bit DES
>ciphertext blocks which are calculated with the 56-bit secret-key he shares
>with Alice -- without disclosing his choice (i.e., anyone else would ignore
>the choice). Thus, Bob's choice is an "unknown key" to anyone else, including
>Alice -- providing open ignorance.
Interesting idea. On the other hand, all it really seems to do
is to slow down Alice's ability to communicate to exactly the
same degree that it slows down Mike's ability to read her communications.
So the work factor -- i.e. the ratio between Alice's time to decrypt
and Mike's -- is unchanged.
Comments?
-kitten
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: steganography algorithm
Date: Wed, 27 Jan 1999 15:19:26 +0100
Steven H. McCown wrote:
>
> For some good overviews, see:
>
> http://www.jjtc.com/Steganography/
I have just obtained an URL of an interesting paper on steganography
by R. J. Anderson and F. A. P. Petitcolas:
http://www.cl.cam.ac.uk/~fapp2/papers/jsac98-limsteg/JSAC98-LimSteg.html
M. K. Shen
------------------------------
From: aland@!spam.striker.ottawa.on.ca (Alan DeKok)
Subject: Re: Metaphysics Of Randomness
Date: 27 Jan 1999 09:36:42 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 26 Jan 1999 19:07:21 -0500, aland@!spam.striker.ottawa.on.ca (Alan
>DeKok) wrote:
>
>> I want random numbers to be so secure that even *I* won't be able to
>>predict their behaviour once my application reaches a customers site;
>>even knowing the algorithm and guessing all initial conditions.
>
>If your PRNG is seeded, there will only be 2^K possible outputs, which
>is far short of the 2^N ciphers possible from a message of length N.
Yes. The same argument applies to encryption algorithms. A key of
size K yields cipher text of size N. Yet the key may be found by
searching over K, not N. (Even NOT knowing the clear text M.)
>The only way to get true security is to generate one of 2^N possible
>keys. But that requires a seed that is N in length - so why not just
>use it instead of the PRNG output?
I'm not sure what you're getting at here. I'm using a PRNG because
I can't ship real random numbers around. That's why I can't use a
seed of size N, and that's why cryptographically secure PRNG's were
invented.
For my applications, I try to keep N near K, and to re-seed when
N >> K. That seems reasonable, considering the practical limitations.
Alan DeKok.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 15:38:29 +0100
R. Knauer wrote:
> A TRNG is a physical device that is capable of generating all possible
> sequences of a given finite length equiprobably. If you understand
> that, then you will understand crypto-grade randomness - and, as
> another poster pointed out yesterday, you will also understand
> cryptography.
Excellent! Then tell me HOW to get such a physical device that
PROVABLY is capable of generating all possible sequences of a given
finite length equiprobalbly.
Secondly, your equiprobability is not at all sufficient. If
the said given finite length is 2, is a physical divice outputting
0001101100011011..... a TRNG?????
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (robert)
Subject: Re: My comments on Intel's Processor ID Number
Date: 27 Jan 1999 15:44:04 +0100
[EMAIL PROTECTED] (Bruce Schneier):
>I wrote a column on Intel's Processor ID number for ZDNet.
Two interesting stories appeared on news.com regarding the Pentium III:
- http://www.news.com/News/Item/0,4,31374,00.html
"Intel will ship its forthcoming Pentium III processor with a
controversial security feature turned off by default. The company
announced the change today after two privacy groups called for a
boycott of Intel products."
- http://www.news.com/News/Item/0,4,31482,00.html?st.ne.fd.gif.e
"An Arizona state legislator next week will introduce a bill that
seeks to ban the sale or manufacture of Pentium III processors in the
state because of complaints that a security feature in the chips could
threaten personal privacy."
I think Intel, wanting to show the world it's technological dominance, made
quite a mistake by including a processor ID number on the list of 'new,
hot and amazing features' list of the PIII, especially in this day and age
where people are quite aware of (and are opposing!) what's being done with
their personal information (think about spam (snail-)mail, for instance).
If Intel would not have made big news of this 'feature', I wonder if we
would actually find out about this at all, which troubles me. Even with
the feature turned off I don't think I would want to buy myself a PIII,
and with me probably alot of other people. My guess will be that Intel
will (have to) remove the ID portion of the PIII before it goes mainstream.
robert
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 14:56:34 +0100
R. Knauer wrote:
>
> Nothing we humans build is Perfect, but we are able to build things
> that are very damn close to Perfect. We can build TRNGs that are
> perfect enough to send messages which would take more energy to
> analyze than is available in the Universe.
>
> How much more Perfect do you want, even in a practical sense?
I am not against having something ideal and perfect as a standard
for approximation (to be strived at in practice) or for pedagogical
purpose. But to say there IS (in the sence of EXISTS) something
perfect can be misleading.
>
> >because OTP presuppose (absolutely) true randomness
> >and there is no way of determining that in practice.
>
> Sure there is. Just look at how the numbers are being generated. That
> will tell you if they are random.
To 'just look' is certainly not ensuring (compare watching a
magician pulling rabits out of his hat). We have to ascertain
how 'random' the sequence we get really is. And that's one of
the real and big problem for the practice.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 27 Jan 1999 09:51:46 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
>
>> A TRNG is a physical device that is capable of generating all possible
>> sequences of a given finite length equiprobably. If you understand
>> that, then you will understand crypto-grade randomness - and, as
>> another poster pointed out yesterday, you will also understand
>> cryptography.
>
>Excellent! Then tell me HOW to get such a physical device that
>PROVABLY is capable of generating all possible sequences of a given
>finite length equiprobalbly.
You can't. Tell me how you can build a plane that will *provably*
fly equally stably in any direction.
>Secondly, your equiprobability is not at all sufficient. If
>the said given finite length is 2, is a physical divice outputting
>0001101100011011..... a TRNG?????
You can't tell. You've framed the question such that it's
unanswerable due to insufficient information :
There is a coffee cup on the southeast corner of my desk. If
it is approximately 1/3 full, what is written on the outside
of the cup?
What kind of mileage does a blue car get?
However, the fact that you've asked a dumb question doesn't mean that
the concepts aren't useful -- both paint color and mileage are
important in describing and evaluating cars. But they're not connected
the way you think they are.
The fact that you're repeatedly asking the same dumb question does,
however, suggest that you're not really interested in the answer.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Paul Onions)
Subject: Re: Sanity check on authentication protocol
Date: Wed, 27 Jan 1999 14:49:19 GMT
On 27 Jan 1999 07:42:38 +0200, Antti Huima <[EMAIL PROTECTED]>
wrote:
>As I mentioned earlier, the protocol needs anyway to use strong MACs.
>Perhaps they can cover R_C true. However, the DoS attack point is not
>very interesting because you can as well just scramble the encrypted
>data.
OK, the way I stated it wasn't very interesting. But the details of
the protocol are important. The following is more interesting:-
Suppose the protocol allows an adversary impersonating the client (or
server) to (partially) complete the handshake, causing the
shared-secret to be updated. So that when the legitimate parties try
to communicate they find they cannot. This is a Denial-of-Service
attack whereby the adversary does not have to be online and actively
altering the messages of his target. Indeed, he would be able to
perform a "batch-job" attack on a whole network of users all at once,
severely damaging the functionality of their network for a substantial
amount of time after the actual attack.
Of course, as you point out, the protocol should be designed using
MACs to withstand such attacks. But, as they say, the devil is in the
details!
Paul(o)
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 14:54:25 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jan 1999 08:37:36 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>You *can't* evaluate a random number generator based only on the
>statistical properties of the stream it produces.
I fully agree for finite sequences, but as I mention in the thread
entitled "Metaphysics of Randomness", statistical tests presumably do
apply to infinite sequences. But then, an infinite sequence contains
all the details about the generation process, so that makes sense.
On an earlier occasion I asked if the Bayesian attack could be used to
characterize crypto-grade random numbers. If I gave you a large number
of ciphers of substantial length based on some unknown key generation
procedure, you tried the Bayesian attack on them and they "leaked" no
significant amount of information, then you would probably conclude
that the pads were most likely generated by a TRNG, even if I had used
some other method like a well-hashed stream cipher. Then I went on to
ask if such a "Bayesian Test" for vulnerability could be used to
produce confidence limits on the security of subsequent ciphers
produced by that encryption method.
Assuming that you could use such a Bayesian Test to characterize
randomness, how does that differ from statistical tests for
randomness? If you were to take the combined keys for all the ciphers
used in the Bayesian Test and concatenate them to one very large
number for statistical testing, we know that does not tell us if the
number is random - otherwise statistical testing could be used to
characterize randomness.
But why should applying the Bayesian Test to presumably random numbers
be any different? (I think I know why - one is a statistical test, the
other is a probability survey.)
Can you or anyone else please comment on this.
Bob Knauer
"An honest man can feel no pleasure in the exercise of power over
his fellow citizens."
--Thomas Jefferson
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: lexical analysis problem....
Date: Wed, 27 Jan 1999 15:51:35 +0100
[EMAIL PROTECTED] wrote:
>
> I'm looking for a quick way of finding all words whose letters add up to 111.
>
> Each letter in the english alphabet is allocated the value of its respective
> position in the alpahabet (i.e. A =1, B=2, C=3 and so on).
[snip]
> So my problem - how to find all permutations of words between 5 and 15 letters
> long that add up to 111. A brute force algorithm would take far to long since
> 26^15 calculations and comparisons would need to be performed. An idea I had
> was building a table of letters representations ie.
Much quicker:
Start with a dictionary:
For each word in the dictionary, if it is at least 5 letters long, do a
simple table lookup for each letter and sum.
int lettersum(char *word) // Only 'A'-'Z','a'-'z' in input!
{
int sum = 0, c;
do {
c = *word++;
sum += c & 0x1f;
} while (c);
return sum;
}
The algorithm above would take about 3 cycles/character, so with less
than 1M words in your dictionary, with an average length of (guess) 7
letters, it would take you far less than a second to check them all.
OTOH, if you are looking for an algorithm to generate all possible
characters strings that would add up to 111 according to that formula
and don't care about actual words, then you have a completely different
problem!
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 15:02:36 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 14:56:34 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>But to say there IS (in the sense of EXISTS) something
>perfect can be misleading.
Does a Perfect Circle EXIST?
If you say is does, is that misleading?
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 16:06:40 +0100
Terry Ritter wrote:
>
> So how are we to trust a software state-machine RNG to produce our
> unpredictable values? One way is to use a well-known cryptographic
> hash or cipher to protect the original values. Another way is to
> measure molecular-level events which are "known" to be unpredictable.
I like however to associate that "known" with some degree of
subjectivity (unless that "known" can be shown to be the same as
"proved"). So I would say that the decision I referred to is not
entirely free from subjectivity.
> >And if additionally
> >I don't know which sequence I get is from software and which is from
> >hardware? (Compare the Turing test.) How does the origin of the
> >sequence affect the workload of the analyst,
>
> Note that the goal of the analysis is to "break" (be able to predict)
> the generator. That obviously depends upon the generator.
In another follow-up I described more precisely the difficult
situation of a user who has to choose among two given sequences
without additional information as to the sources. I don't think
that a choice based on objective criteria alone is (always) possible.
>
> The way generators are broken is through a detailed analysis of the
> generation process, which may involve statistical support. But, on
> their own, statistical tests are simply uninformed about the structure
> of the generator, and so cannot test correlations to the construction.
> But it is precisely the construction which we seek to break.
But the generator may under circumstances not be exactly known,
namely if its design (its structure etc.) depends on a number of
parameters not known to the analyst. Brute-forcing these may be
imfeasible if there is a combinatorial explosion.
M. K. Shen
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Date: 26 Jan 1999 17:25:07 +0100
Serge Vaudenay wrote:
>People says DFC has not enough rounds, which is why it is faster. Then
>increase it from 8 to 12 rounds, and it will be as fast as the popular
>ones!
[EMAIL PROTECTED] () replied:
>i missed something... a dfc with 12 rounds is not faster on 64b cpu and
>looses its speed advantage.
I think Serge's remark was somewhat tongue-in-cheek! Twelve rounds
would probably be a bit excessive for DFC.
Presumably we want a code which is:
1. Possible on the low end.
2. Fast on the high end.
3. SECURE!!!
1. Low end.
Everybody seems to agree that on the low end are smart cards for which
we need something that can get by with at most a few hundred bytes of RAM.
Just a few messages ago, Paul Crowley ruled out DFC and others
claiming that they required "at least 195 bytes", whereas the DFC Web
page links to a several-month-old paper describing an implementation
in 100 bytes. Being too hasty and getting facts wrong sure won't help
us make a good choice!
Note also that Gemplus (a major smart-card company) is involved in DFC
so it appears that those who know the low-end well think highly of
this particular candidate.
2. High end.
Here there seems to be some disagreement. Should the high end be the
latest x86 chip? Or the latest Alpha? Or some unknown processor that
will be popular in 2010? The conclusions are quite different
depending on which you choose.
Many people have x86 machines, obviously, and NIST suggested testing
on a 200 Mhz Pentium Pro. However some appear far too willing to
dismiss out-of-hand all but the very fastest on that particular chip
with the particular implementations they have at hand.
My machine is an Alpha (the outgoing 21164 generation) so for
me DFC is the fastest candidate. Amongst the serious contenders it
is fastest by quite a bit.
My personal opinion on this is that more effort should go into
implementations on diverse types of processor. Bruce has done a very
careful implementation on Pentium Pro, and even posted here recently
to announce shaving 2 cycles off per round, but what about Alpha?
Perhaps Twofish could be sped up there. Likewise for other codes.
I've implemented DFC myself on Alpha but am incapable of doing a good
job on x86. Some guys at ENS did an implementation that takes about
750 cycles. I did one on ARM that takes about 750 cycles too, yet ARM
is a very simple in-order single-issue RISC chip. Surely a Pentium
Pro could beat it easily! I wouldn't be surprised if 20 or 200 cycles
could be knocked off by a top-notch x86 programmer. Where's Terje
Mathisen when you need him? =:-)
3. Security.
Don't overlook that security is more important than anything else!
Imagine if some variant of DES had been chosen that was faster on the
chip-du-jour in 1975 but got broken in 1985? The whole AES landscape
would be very different.
A few candidates are easily ruled out but it would be a mistake to
assume that the rest are all equal.
For now, the various AES teams are involved in guerilla warfare,
trying every avenue to criticize the others. Read carefully and
separate the wheat from the chaff. When Bruce Schneier and colleagues
comment on 32-bit performance they criticize DFC as "The modular
multiply does a nice job of diffusing bits, but hurts performance
significantly." They're praising it with faint criticism!
At heart I'm a bit of a speed-demon but mostly a mathematician. There
are some fast candidates, but that's not enough. There's plenty of
advocacy going on, but much of it doesn't really matter. There are
guys with good reputations involved. I respect that. But the
clincher is:
WHAT CAN YOU PROVE? WHAT IS HARD, COLD FACT?
And what's just heuristics, conjectures and such like?
Heuristics and conjectures are important, especially in cryptography,
but pale in comparison to the others. Take a step back from just DES
and look at what lies behind cryptographic methods that have stood out
since the seventies: you will surely have in mind things like
factoring, discrete logarithms, exponentiation, finite fields and so
on. When mathematics is brought to bear it really does a good job.
I would argue that DES was the end of an era: an era when cryptography
meant pushing bits around in some complicated fashion, getting smart
people to try to crack the resulting code and declaring it safe when
they fail. This process produced DES and DES succeeded. But I think
there was a large amount of luck involved.
The filtering process is of course necessary but it is not sufficient.
Twenty to twenty-five years ago, cryptography came out into the open
and nothing has been done the same since, save doomed attempts like
Clipper, until now that is. The AES process seems to be swamped by
candidates going back to the old way, submitted by people apparently
blinded by DES's lucky success.
If that's what is wanted then go with triple-DES!
Take a look at the serious candidates from a mathematical point of
view. There are a lot of similarities: Feistel this, XOR that...
But one stands out. One says: hey guys here's a proof that
such-and-such attack can't work, nor this other attack nor some entire
classes of attacks. And they're not "straw-man" attacks that are
being held at bay either, they're genuinely useful against some other
codes. You may have missed the crucial word so I'll repeat it: proof.
Now you may be wondering why I'm laying down a strong argument which
happens to favour DFC. Maybe the designers are friends of mine?
No: I just met them for the first time a few days ago. Maybe its some
primitive nationalism, after all I'm posting from France. No: I'm Irish.
I'm defending DFC because it melds the best of the old DES era and the
new mathematical one; because it has gone through the AES process to
date with as much distinction as the other good candidates, withstood
attempts to break it, and because on top of that it is backed up by
guarantees, when all the others have to offer is rhetoric.
So forget all the business with "candidate A is bla% slower/faster than
candidate B on processor X, but on Y mumble mumble".
None are perfect. But one comes with proof. The others don't.
WHAT ARE YOU PEOPLE THINKING?
=:-)
Bye,
Rob.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: My comments on Intel's Processor ID Number
Date: Wed, 27 Jan 1999 16:16:59 GMT
[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>I wrote a column on Intel's Processor ID number for ZDNet. You can
>read it at:
>http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
However, according to claims I've read about the Intel processor ID
number, it will include a digital signature by Intel. So the validity
of a processor ID number can be checked.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: Bruce Barnett <[EMAIL PROTECTED]>
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: 27 Jan 1999 09:50:58 -0500
[EMAIL PROTECTED] (Fabrice Noilhan) writes:
> This was experienced for the DFC algorithm very recently. DEC's cc was
> faster than an assembly code. The reason is that this assembly-coded
> program was optimized for the 21064 and the compiler was good enough to
> do optimizations on the 21164. So, C code was faster than assembly code
> on the 21164 (on account of new instructions and different pairing).
In my days, we didn't need no stinkin' optimizin' C compiler. We
optimized the C code like REAL PROGRAMMERS - by tweaking the source
code. :-)
Okay - I'll stop waving my cane around. :-)
Seriously now...
I have seen minor changes in the source produce large improvements in
the executable speed. Heck, long ago, you could make major speed
imnprovements in Fortran by changing the nesting of two for-loops in a
two-dimensional array. Many Fortran programmers were ignorant of the
big penalty hit this can cause. Disclaimer: I haven't used Fortran in
more than 15 years.
Someone who is familiar with C and ASM can do similar changes in the C
code to improve the ASM code that is generated.
I remember someone showing some tight ASM code, bragging about
it. They also said no C compiler could match it. Someone else then
wrote the equivalent C code that was VERY CLOSE to the organization
and therefore speed of the ASM code. This was very different from the
original C code. This technique doesn't generate optimized code for
every architecture. A bigendian system may need different tweaking
than a smallendian system, for instance. Same goes with indexing
inside loops, etc. Also - some loops may have the same number of
instructions, but one form may be efficiently cached, while others may
not.
My suggesting is to
Write it in C
Optimize it in ASM by hand-tuning the instructions.
Re-write the C to generate code as similar to the ASM as
possible.
Compare the two versions.
As for Java - I guess someone has to be very familiar with the
performance of the virtual machine, including the cost of each virtual
instruction, etc.
--
Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 16:12:44 +0100
Patrick Juola wrote:
>
> The fact that you're repeatedly asking the same dumb question does,
> however, suggest that you're not really interested in the answer.
The origninal purpose is evidently: Since there can't be an good
answer, one can't claim hardware sequences are always to be preferred
to software sequences.
M. K. Shen
------------------------------
** 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
******************************
