Re: assymetric encryption functions based on OpenSSL

From: Date: Mon, 13 Nov 2000 21:01:20 +0000
Subject: Re: assymetric encryption functions based on OpenSSL
References: 1 2 3 4 5 6  Groups: php.dev 
Request: Send a blank email to php-dev+get-38007@lists.php.net to get a copy of this message
At 09:37 PM 11/13/00 +0100, Stig Venaas wrote:
On Mon, Nov 13, 2000 at 10:23:02PM +0200, Andi Gutmans wrote: I took a look at the two samples. It looks as if the whole business could be abstracted a bit more but I am no expert on OpenSSL so I'm not sure. Two issues which should probably be debated: a) Should we require the user to mess with fopen(), fclose() as part of the API. I'll look into this. b) Do we need them to mess with the read_x509 part. I could avoid it, but it might be interesting to add functions that work with certificates, so that function might be needed. Also, the public key might not come from a certificate, so it should be possible to give a public key as argument. I could perhaps allow for both certificates and keys as arguments, but that might be confusing too. I'm open for suggestions here, I'll allow for both if people think it's a good idea. c) How is the API handled if the x509 is not in a file but comes from a database as a string? That's a really good question, I would like to be able to retrieve certificates on the fly from an LDAP server, so I would like to be able to use a string. The problem is that all the OpenSSL functions I've found expect to be passed a file descriptor or a socket. I'm not saying the current API is wrong but I think it needs a review just to make sure that we can make it as easy as possible on the end user. The current examples aren't that simple (i.e. PHP simple). Yes, I tend to agree, will fix a) soon, and maybe b). c) I would like to fix, but I'm not so sure how. Thanks for the comments,
Well as you've noticed my comments are based on hunches as I haven't had time to study the OpenSSL library. Maybe you (and the rest of the list) can come up with a few possibilities and we can then discuss them. As you know lots of functions in PHP aren't their C parallel. The reason is to save a lot of hassle for the coder and allow people to very quickly get things working without having to mess around with too much low-level understanding of how things actually work. Example, the function copy() (ok that's a simple example but still it portrays what I mean as the user doesn't need to do two open()'s and read()/write()'s himself). No matter how we go on this extension we have to keep this in mind. And as I think this extension is a great contribution and will be used by many I think we should work on getting it right from the beginning *even* if it means postponing the final look of the extension by a couple of days in order to leave time for discussion. OK I'm off to sleep now. Night, Andi --- Andi Gutmans <andi@zend.com> http://www.zend.com/

« previous php.dev (#38007) next »