| Summary: | OpenSSL engine support should be enabled by default | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Ian Lister <openssh-bugs> | ||||
| Component: | Build system | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | CLOSED WONTFIX | ||||||
| Severity: | enhancement | CC: | dtucker | ||||
| Priority: | P3 | ||||||
| Version: | 4.7p1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
|
Description
Ian Lister
2008-02-11 16:50:19 AEDT
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. |