On 7/08/22 01:17, Niels Möller wrote:
Hi,I'm considering deleting some assembly files for older architectures and older algorithms. They will still be supported via the corresponding C implementations, just (likely) slower. Why do that? I see two reasons: 1. Delete code that it's no longer easy to test, due to lack of hardware or easy to use cross compiler + emulator. 2. Remove code where the performance benefit isn't worth the extra complexity, e.g., to make it easier to rework the internal interfaces implemented by the assembly routines. Some candidates for removal: * All arcfour assembly. It used to be a fairly important algorithm thanks on its speed, but it's now considered to be of questionable security, and on most current architectures its performance isn't so impressive compared to salsa20, chacha and (where special hardware instructions are available) aes. * All md5 assembly. It seems questionable to have extra complexity to optimize legacy algorithms (even though hmac-md5 may still be unbroken, and on some architectures considerably faster than, e.g., sha256?). (On the other hand, I think it's still useful to aim for high sha1 performance).
FWIW, MD5 is still widely used for non-security purposes. Squid proxy relies on this Nettle implementation for high speed cache key hashing. We have attempted to move to SHA or AES hashes, but the performance is not sufficient to cope with network traffic at full speed.
* 32-bit x86. Unclear to me if there's any relevant hardware still using 32-bit x86 processors (or if it's still a thing to build and run 32-bit executables on 64-bit hardware). The current assembly code was written and tuned for processors that were great two decades ago, like AMD K7.
FWIW, Some still exist as legacy servers in small business and agricultural systems. I suggest looking at what the OS kernels you want to support are doing for this one - Linux at least is purging it.
* 64-bit sparc. This is a borderline case.
FYI, Debian apparently still has a sparc64 port. I have no idea how active it is though.
HTH Amos _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
