OpenSSH provides a --with-ssl-engine configure option to enable OpenSSL's hardware crypto support. The default is not to enable it. I don't see any reason not to enable it; it has no effect if no hardware crypto devices are available. I believe the default should be to enable it, and I even don't think it would be any loss to remove the configure option altogether (i.e. to always enable it). Ian
Created attachment 1454 [details] Patch to enable engine support by default This patch changes the behaviour of the configure script to enable OpenSSL support by default, and to disable it only if explicitly requested or if it is unavailable. Ian
I think the danger here is if you end up using contexts on your crypto hardware for (low-bandwidth) ssh sessions, rather that whatever you bought the hardware for (eg handling SSL). I would be interested in hearing from folks who have such hardware, though.
We have decided not to do this at this time due to the potential impact to some classes of hardware engines.
The motivating case for me is on machines with VIA CPUs with Padlock support (hardware implementations of a range of crypto functions including AES, SHA-1, SHA-256, random number generation and Montgomery multiplication). These are implemented on the CPU core and use the CPU's ordinary registers and memory for context. There's no advantage in doing things the slow way by using the CPU's regular instructions rather than these special-purpose ones. Given what you've pointed out about other classes of hardware engine, I guess I should file a new bug requesting some means of distinguishing classes of hardware engine?
(In reply to comment #4) > Given what you've pointed out about other classes of hardware engine, I > guess I should file a new bug requesting some means of distinguishing > classes of hardware engine? IMO the most sensible way to handle this is for libcrypto to automatically use the processor feature if appropriate (OpenBSD does this). Some Linux vendors ship different openssl packages for different processors (i386 vs i686, the latter making use of instructions not available on previous generations of processors). Anyway, I think it doesn't make sense to have every crypto-using application have to deal with this. Doing a bit of reading (http://marc.info/?l=openssl-dev&m=108903127031777&w=2) it looks like another option is to use openssl.cnf via its [engine_section] (see http://www.daemon-systems.org/man/openssl.cnf.5.html) Based on http://www.openssl.org/docs/crypto/OPENSSL_config.html, it looks like all we'd have to do is add a call of OPENSSL_config(NULL) to ssh, which I think would be reasonable (assuming it does what I think it does).
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.