This is a discussion on Re: OpenSSH PKCS#11merge - openssh ; Hello, On 1/9/08, Peter Stuge wrote: > Cool! Have you made any research on pkcs#11 in OpenBSD? I asked > around in #openbsd on freenode some time ago but noone there had > heard any strong opinions either for or ...
On 1/9/08, Peter Stuge
> Cool! Have you made any research on pkcs#11 in OpenBSD? I asked
> around in #openbsd on freenode some time ago but noone there had
> heard any strong opinions either for or against it.
PKCS#11 is just an interface... I don't think people should be against it...
> OpenBSD has support for hardware crypto, but that's all in the kernel
> and I suppose applications all use whatever native API:s there are,
> which then may or may not be accelerated.
True. This is the problem with people reinvent the wheel.
> Might be interesting to check out. OpenVPN supposedly can make use of
> the hw crypto acceleration. I don't know at all about the scope of
> OBSD hw crypto support. Perhaps a p11 wrapper for the OBSD native API
> would be useful.
OpenVPN uses OpenSSL engines to accelerate the symmetric operations...
The asymmetric operations can be performed using PKCS#11.
The problem is that OpenSSL as OpenBSD and others (Linux) choose to
define its own proprietary interface to cryptography module, so both
applications and cryptographic modules, must support its interface.
Because the lack of standardization in Open Source communities,
introducing external (software or hardware) accelerators or devices is
a complex task. Most developers choose to drop the idea.
PKCS#11 is far than being ideal... But at least it something many agree on.
> I could not resist looking at the code a bit.
Thank you for your help!
> _pkcs11_ssh_pin_prompt() does not check for snprintf() failure, which
> means that uninitialized memory may be passed to read_passphrase()
> and at least in theory this is a buffer overflow vulnerability.
BTW: Looking at other parts of OpenSSH, there are many snprintfs without this...
> Also, there is a possible memory leak, since passphrase is not always
> xfree()d; if the read passphrase is empty or longer than the max pin
BTW: When in terminal mode, there is no way to differentiate between
user enter empty passphrase or wish to cancel... I expected that
D will do the trick.
> In _pkcs11_convert_to_ssh_key(), the choice of local variable names
> make the code rather unreadable. It's not good to have one parameter
> called key and a variable called _key. Please try to find better
> names for all similar instances.
Fixed to internal_XXXX.
> I really like where this is going though.
That's is great!
Released another version:
This time I also added man updates.
openssh-unix-dev mailing list