I'll look into it shortly and for now I'd like to thank you for your
submission.
1. RC4 implementation.
Original submission is at http://cvs.openssl.org/chngview?cn=14248, and
my adaptation at http://cvs.openssl.org/chngview?cn=14249. Most notably
I've eliminated need for key->x=1 in RC4_set_key, as it's important to
us that C and assembler versions of RC4 are perfectly interchangeable.
Secondly I have eliminated remaining byte-order dependency [look for
RC4_BIG_ENDIAN]. The code has been tested on Linux and HP-UX and
compiles on Win64. There're other small changes listed at the latter URL.
2. MD5 implementation.
There seem to be misconception about md5_*_[host|data]_order.
md5_*_host_order is called with input in host byte-order, i.e.
big-endian on big-endian and little-endian on little-endian. This means
that endianess switch can't take place in md5_*_host_order function. In
other words the switch belongs in md5_*_data_order function. Which in
turn means that yes, it's appropriate to implement one. I already did
this [tested on Linux and HP-UX], but didn't commit the code yet, as I
have one remaining issue, namely HP-UX assembler failing to compile it
[see "common comments" below]. I'll commit when I resolve the issue.
BTW, you also make wrong assumptions about the moment when endianess
switch is appropriate. It has to take place *after* you pick A,B,C,D and
*prior* you write them back, not vice versa.
Once again. I *already* have MD5 working on both Linux and HP-UX and the
code will be committed shortly.
3. DES implementation.
I'd rather not:-( The point is that we always have to weight performance
gain against complexity inherent to assembler implementation, and 20-30%
improvement is exactly where the line is drawn. Yes, I know that one can
find assembler code in OpenSSL which gives less gain, most notably
md5-sparcv9.S. But nobody says that I don't regret this by now. At least
I can assure that if/when it fails, it will be just excluded, instead of
being fixed. On a side note, speaking of 64-bit alignment of key
schedule with long long dummy. I'd recommend double, as long long is not
as portable as one expects:-)
4. Endian-neutral AES mentioned in your TODO list.
It would require AES_set_[encrypt|decrypt]_key implemented in assembler,
because key schedule has to be maintained in big-endian order [but not
amount of rounds?]. Then we also have to think about cache-timing
attack. I already have sketched some code mitigating this kind of attack
[similar to one found in x86 implementation, where only CBC mode is
"protected"], so I'd say let's cooperate on this in order to avoid
duplicate effort.
5. Endian-neutral SHA mentioned in your TODO list.
Performance difference would be just few percents. I don't think it
worth the effort...
Common comments.
Usage of LP64 macro to guard usage of addp4. HP-UX in 32-bit mode is the
only platform using addp4, therefore it's more than appropriate to write
"#if defined(_HPUX_SOURCE) && !defined(_LP64)" and not just "#if
!defined(_LP64)" as you suggested, becuase the latter will have
undesired effect on for Win64 [and VMS?].
HP-UX assembler can't handle labels and assembler directives in long C
preprocessor macros expanded as single line. In RC4 case it was rather
easy to work around by spliting it to two, but in MD5 can one would have
to split to like 10, which is nothing but ridiculous. We have to ponder
about how to deal with this...
Feedback to OpenSSL. Timing for patch found at
http://www.hpl.hp.com/research/linux/crypto/ couldn't be worse. Most
notably quoted DEVRANDOM has emerged during beta-testing and was fixed
shortly after. Secondly, DES_INT [and alignment] could have made to
0.9.8, but now it has to wait till next release, because it affects
binary compatibility. As we already established it can be frustrating
experience to provide feedback to <openssl-dev> for unsubscribers [which
must be the explanation for bad timing], but it should be noted that
there *is* a way to provide such feedback as bug-fixes, improvements and
new code without having to subscribe, [email protected] to be
specific. Hoping for and appreciating cooperation:-)
Cheers. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
