Garrett D'Amore wrote: > Why are we using OpenSSL for this instead of PKCS#11? Is SunSSH already > using OpenSSL (without engine support)?
Yes it already uses the libcrypto from OpenSSL. > If all things were equal (and I'm not saying they are), I'd think direct > access to PKCS#11 would be preferable, since it would reduce layering > induced overhead, and might offer additional configuration options. It would but we can do this project now or the bigger project much later. > One of the PKCS#11 configuration options that might be really cool to > have, for example, would be support for PKCS#11 secure key management. > (I.e. allow me to store my private keys securely in a FIPS-140-2 > compliant crypto device such as SCA 6000.) It isn't clear to me that > this is easy (or feasible) with an OpenSSL layered approach. It is actually possible and Jan, myself and Ferenc have worked out how to do it. > It seems like this project is only offer the acceleration benefit for > hardware crypto, and not offering any key handling improvements, right? Correct that is what is is all about. The main focus is on the UltraSPARC T2 processor which is just an accelerator anyway - it has no hardware keystore. > Also, what are the "compatibility" concerns of the new configuration > file directive? What will happen to other open source implementations > of SSH when they see the same directive (such as when sharing a home > directory via NFS with Linux or FreeBSD systems)? We already have that problem. The workaround is to use the per system /etc/ssh/ssh_config. > Finally, might it not be a better choice to avoid hardcoding the notion > of OpenSSL into the configuration file syntax? Perhaps something more > generic, such as "UseHardwareOffload" or somesuch might be better, > especially if the software might one day be changed to use a different > crypto backend (such as PKCS#11.) This was on purpose because it is about using the OpenSSL engine. If we do a direct PKCS#11 interface in the future the configuration required will be more than just a boolean. Also if we switch to direct PKCS#11 then hardware vs software doesn't make much sense, what makes sense is which PKCS#11 slot/token is being used. -- Darren J Moffat
