Cryptography-Digest Digest #855, Volume #9 Fri, 9 Jul 99 00:13:03 EDT
Contents:
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Netiquette Question ("karl malbrain")
Re: Summary of 2 threads on legal ways of exporting strong crypto (Isaac)
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Is Stenography legal? ([EMAIL PROTECTED])
Re: Is Stenography legal? ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Stream Cipher != PRNG (Nicol So)
Re: Possible Extension for Block Ciphers (Nicol So)
AES question ("King")
Re: Why this simmetric algorithm is not good? (AllanW)
Re: Possible Extension for Block Ciphers ([EMAIL PROTECTED])
One additional comment on "A Thought or a Quarter" ("rosi")
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 09 Jul 1999 01:08:13 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> Rubbish. The compiler will more than likely produce the same
> code in both cases. All you achieve by doing this is unreadable
> code.
>
Get Micro-C from www.dunfield.com and tell me that. Not all people
have access to high end compilers (although I must admit Micro-C is
quite good). For low end cpus you want to code the other way (keep
things in accumulator). I am speaking from my experience (with various
MCUs such as the 68hc11).
> > return state[x = ni[++x]] += state[y = ni[++y]];
> >
>
> Code like this would be sent back to you for a rewrite by
> many companys.
Well it would actually read
/* this table is used to avoid the branch required to force a loop back
when incrementing the counter &/
int ni[] = { 0, 1, ..., 54, 0 };
/* update state and return next pseudo-random word */
unsigned long step(void)
{
return state[x = ni[x + 1]] += state[y = ni[y + 1]];
}
Which is quite followable, and highly optimized (for c code). It
requires no branches, keeps something in the accumulator and is rather
compact. The only expense is the table (which is a tradeoff).
pseudo-code is allowed to be messy, as long as it has purpose and is
explainable. I realize at first it looks messy but it is optimized
code.
btw this is OT big time (can we say private email? :))
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Netiquette Question
Date: Thu, 8 Jul 1999 18:32:56 -0700
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In general, if I recieve a message by E-mail containing information
> related to a posting that I feel ... (snipped)
Yes, you've outlined exactly what I do, as I've found that personal E-MAILS
in response to threads are usually just mis-pressed buttons, and all ERRORS
should be corrected by whomever notices them with capability, in general.
As to the predicate, feel, you may as well leave that out -- just do the
process all the time, the same way every time.
Karl M
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: 9 Jul 1999 01:42:11 GMT
On Wed, 07 Jul 1999 12:52:42 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>Your argument relies upon case law (actually lack thereof). That's a
>shaky foundation. It only takes one fire-breathing US Attorney out to
>make a name for himself to invalidate it.
>
>Their argument would be something of the form: The printed text is not
>source code. It is an encoded form of software designed for machines
>rather than humans. Like object ocode or a bar code, it has to be
>processed (by a machine) to be useful as executable software. But it is
>clearly (he'd say) not source code.
>
I see your point. In this case things are not so clear cut. I'd expect
the counter argument to be that the resulting decoding step yields
source code and not object or executable code, and therefore the book
was simply a non human readable vehicle for exporting source code in
printed format. Although the regs leave wriggle room to change in the
future, they do express the idea that ability to read the source code
from a book via OCR or other technology is not currently relevant. Human
readability also is irrelevant.
Still I could see this case getting in front of a judge. Perhaps it's
not a slam dunk win for the defense.
>BTW, the explicit provision in ITAR/EAR regs _are_ based on first
>amendment grounds. Without those provisions the whole set of regs would
>be invalid because they would be an impermissible infringement on first
>amendment rights (publishing is "speech").
This argument is similar to one I've hacked out in the past with other
posters. In my opinion, the provision is insufficient to make the
regs valid, but I'll agree that the infringement of first amendment
rights is more clear if even printed source code is banned. So far
I think district court judges are evenly split in their rulings
on pretty much this exact point.
Isaac
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 09 Jul 1999 01:43:37 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> > Tom St Denis's code is not a good example.
>
> You are not perfect and I will prove it.
Of course I'm not perfect. I expect to be a
better programmer next year than I am today. I
jumped on your sloppy and incorrect code because
you used it as an example when giving advice on
programming.
| > > x = (x + 1) & 255
| > > y = y + state[x]
| > > ---
| > > Can be written as
| > > ---
| > > y += state[x = (x + 1) & 255]
> > But definitely not as
> >
> > y += state[x++];
> >
> > which is what Tom used in his C++ code. If the
> > increment of x were a separate statement, it would
> > not matter that it's a post-increment where RC4
> > requires a pre-increment. Tom's also assuming
> > (without comment) that unsigned char holds only the
> > values 0 through 255. ANSI/ISO C requires it to
> > hold at least that range of values.
>
> Well this has the same effect as long as chars are 8-bits. It will
use
> x then increment it (which is what you have todo) then add the
state[x]
> to y. That's RC4 for you.
I re-included your "can be re-written" above, so we
can see that
y += state[x++];
does _not_ have the same effect. You post-increment
where RC4 requires a pre-increment.
> You can always use an extra '&255' if you are not sure, but that makes
> the code slightly longer and slower.
You are making groundless assumptions. The extra
operation is trivial to optimize away. The choice
between correct in all cases and faster in some
cases is not a close call.
> Plus almost every platform I have
> worked on uses 8-bit chars. It's kinda a standard (people associate
> chars with ASCII or bytes...)
I recommend ANSI/ISO C - it's not just "kinda" a
standard. If you must make assumptions beyond the
standard, you should at least document them.
Perhaps with something like:
#include <limits.h>
#if UCHAR_MAX != 255
#error "Code requires ..."
#endif
> > Tom has now given us two implementations of the
> > simple RC4 algorithm, both of them wrong. He had
> > an example implementation code to work from, so it
> > seems that both bugs were the result of his
> > attempts at optimization.
>
> RC4 is hard to get wrong. I don't see what's
> wrong with my code except
> for the explitcit use of char=8bits...
>
> Here is my understanding of RC4:
>
> y = (y + Sx) mod 256
> x = (x + 1) mod 256
> swap(Sx, Sy)
> z = (Sx + Sy) mod 256
> return Sz
So you want to change RC4 to conform to your code?
Why did you change the order of the assignments to
x and y?
[...]
> I made the 'assumption' that '++x' can be optimized, maybe I shouldn't
> have. By removing the '++x' and replacing it with 'x + 1' ALL
> compilers will optimize it by not forcing a second store...
Your assumptions are groundless. Code first for
correctness, then clarity. Profile before you
optimize.
[...]
> > Nonsense. Static storage and the heap are at least
> > as bad as the stack.
>
> Well normally stack usage is harder to track.
I suppose you could say it's harder to track than
static storage, but both are trivial. Heap is the
only tracking challenge.
> All you have todo is
> memset the round keys when you are done.
Irrelevant. Obviously that works for stack, heap
or static.
> Most people would not know
> how to clear 4KB of stack space... (well it's not hard but most don't
> think of it), in fact there is no ANSI standard way to clear stack
> space...
The only reason "most people" would not know is
that most people never program in C. Don't project
your own misunderstandings onto other C programmers.
Stack storage is not in any way harder to clear than
heap, and programs are less likely to lose track of
it.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Wed, 07 Jul 1999 20:48:06 -0400
From: [EMAIL PROTECTED]
Subject: Re: Is Stenography legal?
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Government is not reason. Government is force. -- George Washington
> >
>
> Here is a relevant question. How many u.s citizens actually want
> crypto control? It seems people are in favor of envelops on snail
> mail, why would they be against crypto on email? Do these same people
> want the government to read their letters to grandma?
>
> Hmm, it seems that most governments (espescially canadian and us) have
> a hard time trying to figure out what the people really want.
>
> In that A&E special they said about 75% of all u.s citizens believe in
> gun control, yet their is still no functional laws about it.
Sorry, but there are over 20,000 guns laws on the US books. Students of
self defense are now counseled that it is impossible to keep track, much
less follow all of the silliness passed in the name of "control".
PLease check your facts before you assert such incongruous statements.
This is
> ot, but it's kinda the reverse of the crypto situation.
>
> One last question, how does controlling export of crypto technology or
> it's use stop a criminal from using it? Really I mean if a criminal
> can program in C they can write their OWN programs to use a relatively
> strong algorithm. It's not productive.
>
> Anyways my two cents. I just thought it's interesting their is no laws
> against stengagraphy (spelling?) but there are against cryptography...
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Stenography legal?
Date: Fri, 09 Jul 1999 02:03:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Sorry, but there are over 20,000 guns laws on the US books. Students
of
> self defense are now counseled that it is impossible to keep track,
much
> less follow all of the silliness passed in the name of "control".
> PLease check your facts before you assert such incongruous statements.
>
Look Mr. NRA your gun polish is getting to your head. this is OT so
drop the subject.
BTW, do you remember why the NRA was started? Didn't think so.
BTWx2, What is the second admendment?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 09 Jul 1999 02:01:13 GMT
In article <7m3k47$t4o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > > Tom St Denis's code is not a good example.
> >
> > You are not perfect and I will prove it.
>
> Of course I'm not perfect. I expect to be a
> better programmer next year than I am today. I
> jumped on your sloppy and incorrect code because
> you used it as an example when giving advice on
> programming.
>
Then shut the fuck up.
> I re-included your "can be re-written" above, so we
> can see that
> y += state[x++];
> does _not_ have the same effect. You post-increment
> where RC4 requires a pre-increment.
It matters not when concerning security issues. Although you are
correct in saying it's not RC4 (although this slight variation is just
as secure).
> > You can always use an extra '&255' if you are not sure, but that
makes
> > the code slightly longer and slower.
>
> You are making groundless assumptions. The extra
> operation is trivial to optimize away. The choice
> between correct in all cases and faster in some
> cases is not a close call.
If I put a &255 the compiler CAN NOT optimize it away. It has to be
done. So tell me how this is faster? I chose to assume char = 8bits
because the platforms I have access to and the platforms I have used
(including HPs) use char=8bit.
> So you want to change RC4 to conform to your code?
> Why did you change the order of the assignments to
> x and y?
Because I must have made a mistake. It happends you know. Instead of
jumping on me like the elitist shit head you are, you could have just
pointed it out as wrong. I am open to suggestions. In fact I will
update my code to make these reflections (including the &255).
> Your assumptions are groundless. Code first for
> correctness, then clarity. Profile before you
> optimize.
Hmm trivial stuff like char=8bit is a simple optimization that I do a
lot of times....
> I suppose you could say it's harder to track than
> static storage, but both are trivial. Heap is the
> only tracking challenge.
Hmm? I am talking about local variables such as temps for RSA
encryption or temps for PRNGs...
>
> > All you have todo is
> > memset the round keys when you are done.
>
> Irrelevant. Obviously that works for stack, heap
> or static.
There is no ANSI standard for clearing the stack. And if you tell me
just do this
func()
{
int array[10000];
memset(array, 0,sizeof(array));
}
to clear stack that is wrong as well. There is no standard way to
clear the stack.
> The only reason "most people" would not know is
> that most people never program in C. Don't project
> your own misunderstandings onto other C programmers.
> Stack storage is not in any way harder to clear than
> heap, and programs are less likely to lose track of
> it.
Heap is normally easy to track. As long as there is no virtual memory,
the pointer you hold should be valid (point to real memory). All you
have todo is memset before you free. Not really hard.
BTW you don't have to be pushy to get changes. I realize that I made a
mistake with the RC4 in my code and I will change it. But jumping
on 'it's sloppy' is rather mean. I am trying to do something
productive for this group (and for myself). It's people like you that
give a bad name to cryptography in general.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 09 Jul 1999 02:05:59 GMT
In article <7m3gvq$85b$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > You can always use an extra '&255' if you are not sure, but that
makes
> > the code slightly longer and slower. Plus almost every platform I
have
> > worked on uses 8-bit chars. It's kinda a standard (people associate
> > chars with ASCII or bytes...)
>
> You're in for a fun surprise when you start writing in Java...
Most java code is so sloppy that this is the least of your worries.
I don't think Java is 'strict' enough to be a lang. Besides 'C' is
more usefull. Anyways this is OT. I write programs for PCs and
char=8bit so it works for me.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Stream Cipher != PRNG
Date: Thu, 08 Jul 1999 22:43:44 -0400
[EMAIL PROTECTED] wrote:
>
> In a private email I was told that stream ciphers and PRNGs are
> completely different beasts. Am I missing something? I always thought
> Stream ciphers were PRNGs which are difficult to solve (i.e
> intractable).
In my opinion, the essence of stream ciphers is statefulness.
Pseudorandom number generators can be used in combination with a
combiner function to construct stream ciphers, but this common
construction does not cover the full generality of stream ciphers. An
obvious limitation of this framework is that the cipher's state has no
dependency on the plaintext stream.
Nicol
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Possible Extension for Block Ciphers
Date: Thu, 08 Jul 1999 22:26:53 -0400
[EMAIL PROTECTED] wrote:
>
> [Description of a method of randomizing block cipher by filling
> some of the plaintext bits with a counter or pseudorandom value,
> deleted]
This idea is so obvious that I expect most people interested in
cryptography will have come up with it independently at some point. The
drawback of the scheme is that it is not an efficient way of injecting
randomness into an otherwise deterministic cipher. There are (much)
better ways.
Nicol
------------------------------
From: "King" <[EMAIL PROTECTED]>
Subject: AES question
Date: Thu, 8 Jul 1999 22:08:49 -0500
Hi, can anyone tell me how many and when AES submissions have been broken as
of today? I tried to find the information but part of NIST web site was
down. Thanks!
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 09 Jul 1999 02:46:09 GMT
[EMAIL PROTECTED] wrote:
> Most compilers can optimize lines of code if they are companded.
Somehow when I learned about computers they forgot to teach
me about "companded lines of code."
BUT: Compilers that I am familiar with (I wouldn't dare talk
about "most compilers" because I haven't even heard of most
compilers) break down the code into simple logical steps
long before any optimization, so that (for instance in C or
C++) optimizing
x = (x+1) & 255;
y = y + state[x];
is exactly as efficient (no more, no less) than
y += state[x=(x+1)&255];
because the simple logical steps for either one of these
are something roughly equivalent to this:
read x
add 1
and 255
store x
add <address of state>
read indirect
add y
store y
Optimization occurs both during and after these steps have
been turned into machine code. But note that there is no
longer any way to detect end-of-source-line without examining
debugging information. Thus it makes NO difference if these
steps were originally one line of code or twenty.
> Take a look a my PRNG C++ file, you will notice that the
> stepping of the PRNGs look like
>
> ---
> return state[x = ni[++x]] += state[y = ni[++y]];
> ---
I hope not; this is invalid C++. You have used ++ to increment
x and y and you have also assigned a value to x and to y. This
engenders "undefined behavior" which means that the compiler
can generate any code that it likes. Note that the fact that
your version works on one or more compilers is not proof that
the code is correct.
The C++ compiler can generate code that formats your hard disk
the first time that it is run; as unlikely as this sounds, this
would not disqualify it as a conforming C++ compiler. It could
also generate code that happens to do whatever it is you
expected the code to do -- but it would be foolish to count on
this happening in every version of every compiler. The FAQ for
comp.lang.C++ has a good explanation of this concept.
You probably meant to do this:
return state[x=ni[1+x]] += state[y=ni[1+y]];
BTW I just compiled this on MSVC 6 and examined the assembly
code. Then I compiled this with "assume no aliasing" optimization:
x = ni[1+x];
y = ni[1+y];
return state[x] += state[y];
and the assembly code was amazingly similar. Try it yourself!
> Everything should be in the accumulator as required (i.e MCU
> friendly).
Wouldn't that be compiler-dependant? Some computers don't even
have an accumulator. That seems like a very sweeping statement
without even a disclaimer such as "for most compilers I have
ever used".
> Most compilers can optimize code like this better
> then if it were done in 3 or so lines...
Are you guessing? If you have tried it, I would like to know
which compiler(s) you are talking about. In my experience, this
rarely makes any difference at all. Even when it does generate
a different code sequence, it would be an inconsequential
change; for instance, it might generate the same instructions
in a different order, or it might use a different register.
In these hypothetical situations, the code would generally be
exactly the same size and would execute at exactly the same
speed.
> For security reasons you want to avoid putting round keys
> on stack (i.e auto/locals). This is not algorithm related
> but implementation related.
Are you suggesting that an attacker might be executing a
program in the same time and memory space that the encryption
program is running? If so, there's very little you can do
about it anyway, wouldn't you agree? If not, then what
possible difference could it make if data is on the stack or
in some other section of memory?
Thanks for teaching me all about "companded code."
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Possible Extension for Block Ciphers
Date: Fri, 09 Jul 1999 03:39:24 GMT
In article <[EMAIL PROTECTED]>,
Nicol So <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > [Description of a method of randomizing block cipher by filling
> > some of the plaintext bits with a counter or pseudorandom value,
> > deleted]
>
> This idea is so obvious that I expect most people interested in
> cryptography will have come up with it independently at some point.
The
> drawback of the scheme is that it is not an efficient way of injecting
> randomness into an otherwise deterministic cipher. There are (much)
> better ways.
The obvious goal is to have key and time dependant permutations of a
subset input. Stream ciphers for example are time based. This might
have some merit.
If the counter is private (possibly encrypted per message based on
another time/key permutation ) it a) makes chosen plaintext attacks
very limited (you only get control of a subset of the total block) and
b) makes the permutations semi non-fixed (i.e it's not fixed for the
entire key...)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: One additional comment on "A Thought or a Quarter"
Date: Thu, 8 Jul 1999 23:06:24 -0400
Hi,
I just read a few posts and think that I may need to make it more
explicit concerning OWF and trapdoor OWF. I would like to stress
that I am not to critique on anybody. I just want to make sure that
'my free style', though should be clear, did not confuse people.
There are definitions on those which are fine IF one uses them
consistently and uses them to mean exactly the same thing consistently.
If you find difficulty, by any chance, please try using mine. :)
The reason of using my definition is clear when I did jokingly using
un-encore-temp. I think it is better to mean exactly what the words
mean, or as closely as possible. Everybody knows what a function
is. What does 'one-way' convey? One-way. (And no alternate route or
going whatever direction is of interest in that regard)
Now, non-repudiation and encryption/decryption are different things.
In non-repudiation, it is desired to be hard for an adversary to find ANY
x (except perhaps THE x) such that f(x)=y for some y of interest. In
encryption/decryption, such is not required. The former is a hard (actually
one of the hardest) posed by the adversary. In the second, the adversary
can be given a hard nut to crack. In short, in the latter, the adversary is
not
to find an x, but THE x.
I think it is a bit of a narrow view on things when we fix on one mold
of invertible function. More precisely for cryptography, the inverse
need not be a function. It is in the case where decryption is not unique
that gives rise to the chance of forcing the adversary to answer the NO
part of the question.
Back to the existence of OWF. It is obvious by my definition that they
do exist. (Otherwise we get nice contradictions). Another thing is that
even when one-one, it still depends on the underlying problem, IMO. Let
me be a bit concrete here. Given a specially designed set of high density,
to the decryptor the subset sum solution can be unique. However, due to
the high density, lattice reduction is faced with overwhelming numbers
of short vectors. In effect, the (subset sum) solutions are many. Of course,
in such cases (i.e. one-one) a 'solution' corresponding to a short vector
can be verified to be a wrong one, yet before getting this thing (call it
certificate), the verification can not be executed. Finding an x is no good;
finding THE x is what matters. I do not see how the difficulty can be
easily
overcome unless perhaps subset sum problem exhibits other
charateristics to be exploited.
Finally, as OWF's (by my def) do exist (I said OWF not trapdoor OWF),
we can use them "freely" with a guarantee that anything protected by
them "won't" reduce the original security we have.
Hope I did not confuse more.
Thanks
--- (My Signature)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Fri, 09 Jul 1999 03:00:27 GMT
In article <7m3npf$uc8$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
> read x
> add 1
> and 255
> store x
> add <address of state>
> read indirect
> add y
> store y
Yeah this is true, but sometimes they perform the extra load.
Generally it is the same.
> You probably meant to do this:
>
> return state[x=ni[1+x]] += state[y=ni[1+y]];
>
> BTW I just compiled this on MSVC 6 and examined the assembly
> code. Then I compiled this with "assume no aliasing" optimization:
>
> x = ni[1+x];
> y = ni[1+y];
> return state[x] += state[y];
>
> and the assembly code was amazingly similar. Try it yourself!
I will. But I try to compand the code to make it optimal on as many
compiler as possible. The ++x was wrong, it should have been 'x+1'
because the assign is not required.
> > Everything should be in the accumulator as required (i.e MCU
> > friendly).
>
> Wouldn't that be compiler-dependant? Some computers don't even
> have an accumulator. That seems like a very sweeping statement
> without even a disclaimer such as "for most compilers I have
> ever used".
Not really Micro-C works on about 10 CPUs and in all of them (including
the x86) companded lines compile better. In Turbo C it's not so bad,
and in DJGPP it really doesn't matter. but if you can optimize for all
why not? (it should not be slower at least).
> > Most compilers can optimize code like this better
> > then if it were done in 3 or so lines...
>
> Are you guessing? If you have tried it, I would like to know
> which compiler(s) you are talking about. In my experience, this
> rarely makes any difference at all. Even when it does generate
> a different code sequence, it would be an inconsequential
> change; for instance, it might generate the same instructions
> in a different order, or it might use a different register.
> In these hypothetical situations, the code would generally be
> exactly the same size and would execute at exactly the same
> speed.
Talking from experience with Micro-C. I should not have said this
because Micro-C is not 'most compilers'. sorry about the confusion.
> Are you suggesting that an attacker might be executing a
> program in the same time and memory space that the encryption
> program is running? If so, there's very little you can do
> about it anyway, wouldn't you agree? If not, then what
> possible difference could it make if data is on the stack or
> in some other section of memory?
Normally virtual memory is the only big problem. memset the round keys
(sboxes or whatever the cipher uses) is generally easy in linear memory
modes...
> Thanks for teaching me all about "companded code."
Your quite welcomed. Seems to me that I am the only one who favors
it....
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
