Andy,
I took a look at and modified rc4_enc.c I do not know how to upload the new version
for test. Therefore I'm sending it to you for
your purusal and I'll ask you to forward it to the proper people after you've had a
look at it.
Please advise me of the procedures involved - I'm very new to this.
The mods should result in a trivial increase in size and speed should be unaffected.
I've been unable to test it of course since I haven't yet set up a development version.
On Thu, 30 Sep 1999 18:30:17 +0200, Andy Polyakov wrote:
>> I wouldn't do it like that. You are executing a function call
>You've mentioned "a function to detect" yourself, haven't you:-)
>> and all that is requrired is a simple test.
>Of course! In real life you would *inline* whatever the function does.
>>
>> I'd do it something like this probably:
>>
>> static union endian
>> { int i;
>> char little;
>> } is_endian;
>>
>> Then in an initializationb routine:
>>
>> is_endian.i = 1
>But if you declare it const and initialize it at compile time instead,
>then the compiler gets a chance to at least generate correct branch
>prediction flag and in the best case even eliminate none-relevant code
>fragment along with the branch itself:-)
>
>Now back to your previous letter:
>> So all I'll need are the names of a couple affected functions.
>As I already mentioned it's 32-bit block message digests, i.e. MD5, SHA*
>and RIPEMD160, and updated RC4 (first available in 19990927 snapshot).
>Affected functions are HASH_UPDATE in ./crypto/md32_common.h and RC4 in
>./crypto/rc4/rc4_enc.c. Note that HASH_UPDATE itself is endian-neutral!
>As well as HASH_BLOCK_DATA_ORDER and HASH_BLOCK_HOST_ORDER! #ifdef
>[LB]_ENDIAN appears earlier when you "alias"
>HASH_BLOCK_DATA_ORDER_ALIGNED to HASH_BLOCK_HOST_ORDER whenever host
>happens to be of the same endianness as input data. It's (as already
>mentioned) done for performance sake. But I have to admit that in this
>case (message digests) it's perfectly possible to implement check for
>endiannes at run-time without sacrificing performance *or* space. In RC4
>case you *have to* make the code *substantially* bigger if you want to
>keep performance. Fortunately RC4 is rather compact and extra 1.5
>kilobyte (of machine code and only if compiler fails to eliminate it:-)
>won't harm anybody... I'll look into the whole thing...
>> I'll need the current sourse tree
>Which is always available at ftp://ftp.openssl.org/snapshot/.
>
>Andy.
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>Development Mailing List [EMAIL PROTECTED]
>Automated List Manager [EMAIL PROTECTED]
RC4_ENC1.C
ENDIAN.H
