Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93691
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.217 cause and error)
MIME-Version: 1.0
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
 <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com> <295c09d5-01af-1528-8e61-00dc6ee6c69e@fleshgrinder.com>
In-Reply-To: <295c09d5-01af-1528-8e61-00dc6ee6c69e@fleshgrinder.com>
Date: Wed, 01 Jun 2016 19:25:12 +0000
Message-ID: <CANUQDCiV_GQD+zPSer5JUUJyP1Vg3ROo+-Bd=hLOSfvrLO2oPQ@mail.gmail.com>
To: internals@lists.php.net, Marco Pivetta <ocramius@gmail.com>, 
	Scott Arciszewski <scott@paragonie.com>
Content-Type: multipart/alternative; boundary=001a11444ba25e073405343c73e7
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: me@kelunik.com (Niklas Keller)

--001a11444ba25e073405343c73e7
Content-Type: text/plain; charset=UTF-8

Fleshgrinder <php@fleshgrinder.com> schrieb am Mi., 1. Juni 2016 19:26:

> On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>
> > I also agree with Remi on naming: let's avoid calling the extension
> > `libsodium`.
> >
>
> 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
> instance,
> > 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 actually
> > does, like `sodium_encrypt_and_sign()`. While the naming may be emerging
> > 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 just
> > 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?
> >
>
> 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 {}
>

Why does it directly extend 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;
>
>   }
>

Just a short node: the keys shouldn't be responsible for signing /
verification.


>   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. :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

--001a11444ba25e073405343c73e7--