Ben Laurie wrote:
>
> Dr Stephen Henson wrote:
> >
> > >From time to time someone needs to pass a parameter to a passphrase
> > callback. For example the prompt for the password can be set to a
> > meaningful phrase or the passphrase itself could be set by this method.
> >
> > Currently this isn't directly possible and the only solutions are messy.
> >
> > IMHO it's about time this issue was resolved one way or the other.
> >
> > There are several possible solutions, some break existing code and
> > others might be considered a bit "naughty". But first a bit more info
> > about the way things are handled...
> >
> > All the passphrase callbacks are function pointers which look like:
> > int pem_password_cb(char *buf, int size, int rwflag);
> >
> > 'buf' is the buffer to write the passphrase to, 'size' is the maximum
> > length of the passphrase and 'rwflag' is set to '1' if the passphrase
> > should be verified by asking for it twice (e.g. when setting or changing
> > a passphrase as opposed to checking an existing one).
> >
> > They return the length of the password or a value <=0 to indicate an
> > error.
> >
> > Typically a callback is passed to a function like this:
> >
> > EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x, pem_password_cb *);
> >
> > OK enough backround. Here are a few possible solutions.
> >
> > 1. Just add an extra parameter. With this method the callback would
> > become:
> >
> > int pem_password_cb(char *buf, int size, int rwflag, void *arg);
> >
> > and would be called like this:
> >
> > EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x,
> > pem_password_cb *, void *arg);
> >
> > This main problem with this is anything existing code calling
> > PEM_read_PrivateKey() should choke with a compilation error. The fix is
> > trivial though: set the extra parameter to NULL and add an ignored
> > parameter in the callback (if used).
> >
> > This does at least have the advantage that it solves the problem and
> > catches any code using the "old way": that is everything at present.
> >
> > 2. Add a set of extra functions:
> >
> > EVP_PKEY *PEM_read_PrivateKey_ex(FILE *fp,EVP_PKEY **x,
> > pem_password_cb_ex *, void *arg);
> > int pem_password_cb_ex(char *buf, int size, int rwflag, void *arg);
> >
> > This might be considered overkill, would double the number of PEM
> > functions needed and have lots of PEM 'legacy' functions using the old
> > method that would have to stay. It would however retain compatability
> > with existing code.
> >
> > 3. Do something evil with the cb parameter...
> >
> > EVP_PKEY *PEM_read_PrivateKey(FILE *fp,EVP_PKEY **x, void *x);
> >
> > This has a companion "default callback":
> >
> > int default_pem_callback(void *x, char *buf, int size, int rwflag);
> >
> > This needs a bit more explanation. Any function calling
> > PEM_read_PrivateKey() in the "old way" will end up calling the
> > default_pem_callback() which retains the old behaviour: treating 'x' as
> > a passphrase callback in the "old way". Anything that wants to pass
> > parameters to the callback can replace the default_pem_callback() and
> > interpret the 'x' parameter in any appropriate way.
> >
> > This does however lose typechecking of the 'x' parameter and is a bit
> > awkward to use. Interpreting a void * as a function pointer might also
> > be a potential problem.
> >
> > This does however have the advantage that existing code will still work
> > and the neccessary functionality is available.
> >
> > Anyway thats three options, none of which IMHO is ideal. Any alternative
> > solutions or comments anyone?
>
> I think 3 is too disgusting to contemplate.
Yes I thought you'd like it :-)
> 1 is OK with me: we
> regularly break all existing code,
I don't think anyone has broken code to this degree yet. It will
probably end up breaking just about anything that reads in a private key
or several other kinds of PEM file.
> anyway (speaking of which, I tried to
> get demos/selfsign.c going the other day, but X509v3 support has changed
> so drastically I couldn't easily figure out how!).
Ugh. I didn't see that. It's using the old V3 pack stuff which is rather
horrible for things like bit strings. I'll fix it for the new code.
> If you are concerned
> about existing code, then I'd vote for 2, but I'm not hugely keen on the
> precedent or the bloat.
>
I'm not that concerned.
> The other possibility I can think of is to add an "extra data" pointer
> to EVP_PKEY instead.
>
Unfortunately this has to work with all PEM read/write functions not
just EVP_PKEY.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
