> On 2001-05-04 20:47:25, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> > Even though it is 4 functions, I think users will find it easier to
> > work with functions called openssl_public_encrypt,
> > openssl_private_decrypt etc. It also separates them from possible
> > symmetric enryption later on.
> 
> So are we looking at openssl_asym_public_encrypt() (or is the asym part
> redundant by implication?).

It is redundant for me, but I've got no idea what other people think.

> IMHO, I prefer to spell it out - especially to those new to openssl (I'm
> fairly new to it!) it helps to have things spelled out.  That way, you
> don't have to be an openssl hacker to benefit from the PHP interface.

I've used SSLeay back in 1996 once, and then a few weeks ago for my patch.
You don't need to be an openssl expert, but as with all cryptography you
should have some basic understanding before using it.

> > I think it's generally better to not alter arguments, better return it
> > this way. Is it good enough to report errors by returning an empty
> > string? I think so.
> 
> Can an empty string become an non-empty string when encrypted?
> If so, when we decrypt it, we will not be able to distinguish the
> correctly decrypted empty string from an error condition.

Not when encrypting, but if you encrypt an empty string and then decrypt it,
it will become the empty string again.

> We could return false (as is the convention), but then everyone would have
> to use === to check it correctly.
> 
> If an empty string is not a valid return result, then we are OK.

It's invalid on encryption, but valid on decryption.

Sascha


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to