On Thu, Jun 2, 2016 at 2:10 PM, Niklas Keller <m...@kelunik.com> wrote:
> 2016-06-02 19:36 GMT+02:00 Fleshgrinder <p...@fleshgrinder.com>:
>
>> On 6/1/2016 9:25 PM, Niklas Keller wrote:
>> > Why does it directly extend throwable?
>> >
>> > Just a short node: the keys shouldn't be responsible for signing /
>> > verification.
>> >
>>
>> This was not a real proposal, I only wanted to illustrate the potential
>> for a nice OO implementation.
>>
>
> Yes, sure.
>
>
>> The goal is it to make crypto simpler for userland. Well, having
>> dedicated classes and everything type hinting against those makes it
>> very easy.
>>
>> For instance nonce arguments ...
>>
>> $nonce = randombytes_buf(CRYPTO_SECRETBOX_NONCEBYTES);
>> crypto_secretbox(...
>>
>> $message_nonce = randombytes_buf(CRYPTO_BOX_NONCEBYTES);
>> crypto_box(...
>>
>> $nonce = randombytes_buf(CRYPTO_AEAD_CHACHA20POLY1305_NPUBBYTES);
>> crypto_aead_chacha20poly1305_encrypt(...
>>
>> $nonce = randombytes_buf(CRYPTO_AEAD_CHACHA20POLY1305_IETF_NPUBBYTES);
>> crypto_aead_chacha20poly1305_ietf_encrypt(...
>>
>> $nonce = randombytes_buf(CRYPTO_AEAD_AES256GCM_NPUBBYTES);
>> crypto_aead_aes256gcm_encrypt(...
>>
>> ...
>>
>> This is not only super annoying, it also requires you to perform the
>> same fixtures all the time and allows users to make mistakes, e.g.
>> reusing the same nonce.
>>
>
> I agree, we should expose a higher level API. For nonces, a random value
> might even be bad, because of the birthday paradoxon. But it's probably
> best if the user doesn't even have to care about generating a nonce
> manually.
>
>
>> namespace Php\Sodium {
>>
>> class Nonce {
>>
>> function __construct(int $bytes);
>>
>> function __toString(): string;
>>
>> function getBytes(): int;
>>
>> }
>>
>> }
>>
>> namespace Php\Sodium\Asymmetric {
>>
>> class EncryptedMessage {
>>
>> function decrypt(PrivateKey $private_key): Message;
>>
>> function getNonce(): Nonce;
>>
>> }
>>
>> class Message {
>>
>> function __construct(string $plain_text);
>>
>> function encrypt(PublicKey $public_key): EncryptedMessage;
>>
>> }
>>
>> }
>>
>> Of course some of the provided stuff is not well suited for OO but those
>> could be implemented normally as procedural functions. However, I
>> question the names and the functionality of some. For instance:
>>
>> Isn't randombytes_buf() pretty much the same as random_bytes()?
>>
>
> Yes, and thus I think it shouldn't be exposed to userland.
>
>
>> randombytes_uniform() has a weird name that does not really tell what it
>> does. random_int_uniform() would be better and match the existing
>> random_int() function.
>>
>> Why does randombytes_random16() even exist? It does exactly the same as
>> randombytes_uniform(65536)?
>>
>> Again, I really like the goal but I don't think that the current
>> proposal meets it. I also understand the desire to have it in 7.1 but it
>> is the same problem as in every company: rushing is bad! Once released
>> we're done. We cannot remove it anymore, we cannot change it anymore, we
>> have to live with it. All because we wanted something better but too fast.
>>
>> Let's give it some time to come up with a simpler solution that
>> integrates nicely into existing PHP. Without confusion over functions
>> that are doing what already existing functions to. With classes that
>> encapsulate complicated stuff and make it hard to get things wrong.
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
>>
>
The birthday bound of a crypto_box or crypto_secretbox nonce, generated
from a CSPRNG, is 2^96 for one collision. If it's gonna happen, you've got
bigger things to worry about.
I should probably state clearly that the concept of an abstract pluggable
crypto API that supports OpenSSL and Libsodium isn't what I'm proposing
here. Just libsodium.
If I find time to write the pluggable crypto API, I will propose that next.
Unfortunately, that likely won't be until 7.2.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
