Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93681
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.87 cause and error)
Reply-To: internals@lists.php.net
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
 <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>,
 Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <295c09d5-01af-1528-8e61-00dc6ee6c69e@fleshgrinder.com>
Date: Wed, 1 Jun 2016 19:26:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="dQqtvcUISKFaqbqUsBT9cDg2NfR5vk5RV"
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: php@fleshgrinder.com (Fleshgrinder)

--dQqtvcUISKFaqbqUsBT9cDg2NfR5vk5RV
Content-Type: multipart/mixed; boundary="jVpGmmI2LktnnD8M0oA3Jt6s4o5dl0jMF"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Marco Pivetta <ocramius@gmail.com>,
 Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <295c09d5-01af-1528-8e61-00dc6ee6c69e@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
 <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
In-Reply-To: <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>

--jVpGmmI2LktnnD8M0oA3Jt6s4o5dl0jMF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/1/2016 12:48 PM, Marco Pivetta wrote:

> I also agree with Remi on naming: let's avoid calling the extension
> `libsodium`.
>=20

I agree here too.

On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>  1. is there a particular reason why abbreviations are used? For instan=
ce,
> why `sodium_randombytes_buf()` instead of `sodium_random_bytes_buffer()=
`?
>  2. from a naming perspective, I'd expect `sodium_randombytes_buf()` to=

> give me a buffer of random bytes (probably as a stream), but it returns=
 the
> actual string of random bytes. Again: confusing naming
>  3. can we avoid using "themed" naming? For example, instead of
> `sodium_crypto_secretbox()`, it would be best to express what it actual=
ly
> does, like `sodium_encrypt_and_sign()`. While the naming may be emergin=
g
> from lower layers, I still (like I did with other RFCs) disagree with
> inheriting confusing naming. This will just cause users to look up the
> naming up when reading or writing code, and ultimately add up to silly
> bugs. I can already foresee that people will use the API incorrectly ju=
st
> because of the naming.
>

I agree here too but read on.

On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>  4. can't we just keep it namespaced under `Sodium`, instead of adding =
more
> stuff to the root level namespace? Does anyone have a reference to the
> coding standards that would cause the rename?
>=20

I was the person who brought this up because it is not desired according
to the existing CODING STANDARD:

https://github.com/php/php-src/blob/master/CODING_STANDARDS

Note that it also encourages this weird C style naming with
abbreviations, hence, I would be open for discussing it. That being
said, I am not a friend of putting procedural functions into namespaces
and prefer the establish prefix approach.

That being said, I see many opportunities here to create very nice
classes that enable dependency injection, single validation, and of
course I am +1000 for namespaces here. It would also help a lot to get
some of those extremely weird names out of the window.

  namespace Sodium;

  interface SodiumException extends \Throwable {}

  class SignatureException
    extends \UnexpectedValueException
    implements SodiumException {}

  class DetachedSignature {

    public function __construct(string $detached_signature);

    public function __toString(): string;

    public function verify(string $message, PublicKey $public): bool;

  }

  class SignedMessage {

    public function __construct(string $signed_message);

    public function __toString(): string;

    public function getSignature(): DetachedSignature;

  }

  interface Key {

  }

  class PrivateKey implements Key {

    public function sign(string $message): SignedMessage;

  }

  class PublicKey implements Key {

    public function verify(SignedMessage $message): bool;

  }

  class KeyPair {

    public function __construct(PrivateKey $private, PublicKey $public);

    public static function generate(): KeyPair;

    public function getPrivate(): PrivateKey;

    public function getPublic(): PublicKey;

  }

This is of course an attempt of writing up some classes after looking at
the API for literally 5 minutes but I think it illustrated the
potential. It is also going to increase the security by a huge margin
because a private key suddenly has to be an instance of a PrivateKey and
not some arbitrary string that needs to be revalidated all the time.

The same software design principles apply as always and the current API
might be nice for C but it is definitely not for PHP in my opinion.

Of course I offer my help to find and define such an API if you guys are
interested in creating one. :)

--=20
Richard "Fleshgrinder" Fussenegger


--jVpGmmI2LktnnD8M0oA3Jt6s4o5dl0jMF--

--dQqtvcUISKFaqbqUsBT9cDg2NfR5vk5RV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXTxrIAAoJEOKkKcqFPVVr/30P/iMXGz3UjNUQ485DRbk0XEoH
oyKQl9hs5G6XRUDK9G8yyDyoc9La/MQXqzAxkVTTfYgvtpHsj9FRJZ7q/j1akdE5
uPyhFg8a83BCLzRb86aeBqoBgliWa6sr703zwroH3XptDnlg8Z22EECRfnWm4wrw
S/Dwv66mRuhTCFmSLQoNIZAHojkUNwcmgKh8UBGdsKJOH5fAYui8asNdmRXVc2Dw
p9K+2Eys7yKJF6+WP61n0onpPgq2qDX76keNLyFj/+N3pcRX+5HqYYjrEVORnA6C
/fdKb1oant+JuYqjV2gpB9e0g3RFQRhVuKajFeEpvVRz/mkygpm/vFcju3Txva5l
MWGvS3VdZ50djbzKNIsv2OFjRRBIKQp89H/XsFKixMDF6tH/GYNFTgwvar4Eum/R
tdmSJ/n2NeSgmuiS20wSRATYACaHmGALvYL73bvw+23OVEYD6F+J8JpqdVgl9CLq
583U87m0OUCLE2hBmkoOjEtciK+TN74N6tTqeaSGcWOgWrvgQ/4XKJAZDDNUcnB0
bh6YnHdjoJ9pni6GE2iptdisYKvkhS0jjs/bBwsbD8mxuGyqdIIlgMWzbSWmjzYF
GSKf7Vo6ocwlY0g9BDtRzql7S/8JigrEcqqP1vu+4yy9+606ZatH7J6XIFasAJCH
JtyitTvWr2OHENx2AnEd
=3fx+
-----END PGP SIGNATURE-----

--dQqtvcUISKFaqbqUsBT9cDg2NfR5vk5RV--