Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.220 cause and error)
MIME-Version: 1.0
In-Reply-To: <52b8417d-4d23-338c-0737-562ddc7476b5@fleshgrinder.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
	<CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
	<295c09d5-01af-1528-8e61-00dc6ee6c69e@fleshgrinder.com>
	<CANUQDCiV_GQD+zPSer5JUUJyP1Vg3ROo+-Bd=hLOSfvrLO2oPQ@mail.gmail.com>
	<52b8417d-4d23-338c-0737-562ddc7476b5@fleshgrinder.com>
Date: Thu, 2 Jun 2016 20:10:30 +0200
Message-ID: <CANUQDChp3L1ZcWp7YdHTZc9D5C7YfKsSni+kqMag2-t7Xgkx5w@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Cc: Scott Arciszewski <scott@paragonie.com>
Content-Type: multipart/alternative; boundary=047d7b4508e48a4ae005344f85de
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: me@kelunik.com (Niklas Keller)

--047d7b4508e48a4ae005344f85de
Content-Type: text/plain; charset=UTF-8

2016-06-02 19:36 GMT+02:00 Fleshgrinder <php@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
>
>

--047d7b4508e48a4ae005344f85de--