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
>
>
