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). * Code specifically for 32-bit ARM prior to ARMv6. Last time ARMv5 was discussed, there were some devices (maybe some dlink NAS, I don't quite remember?) that could run free software and featured an old ARMv5 processor. Is that still relevant? * 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. * 32-bit sparc. I think this hardware is long obsolete. * 64-bit sparc. This is a borderline case. Current assembly code (dating from 2005) still gives up to 30% AES speedup, benchmarked on a friend's "T2" sparc machine. If there's interest, there's potential for larger gains on more recent "T4" processors which features crypto instructions. But I'd consider it a rather obscure hardware, e.g., not well supported (natively, or with packaged cross compilers) by debian, which makes testing a bit cumbersome. I do have access to a few machines via the gccfarm, though. Opinions welcome, in particular, if there's something on this list that you'd really like to see not deleted. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
