# [RFC] Libsodium - Discussion

- Thread: https://externals.io/message/93663
- Original archive: https://news-web.php.net/php.internals/93663
- Started by Scott Arciszewski on 2016-06-01T07:49:01+00:00
- Messages: 39
- RFC: Libsodium (Implemented (PHP 7.2)) — https://externals.io/rfc/libsodium.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/93663.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #93663 — Scott Arciszewski — 2016-06-01T07:49:01+00:00

URL: https://externals.io/message/93663#93663

Hi PHP Internals Team,

Let's begin discussing the prospect of adding libsodium as a core extension
in PHP 7.1. I've updated the RFC to explain why this would be a good idea
and the benefits it offers.

https://wiki.php.net/rfc/libsodium

If the subsequent discussion goes smoothly, I would like to open voting on
June 15.

Together, let's make PHP cryptography so safe that it becomes boring.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com

---

## #93664 — Julien Pauli — 2016-06-01T08:41:36+00:00

URL: https://externals.io/message/93663#93664 · In reply to: #93663

> Hi PHP Internals Team,
>
> Let's begin discussing the prospect of adding libsodium as a core extension
> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
> and the benefits it offers.
>
> https://wiki.php.net/rfc/libsodium
>
> If the subsequent discussion goes smoothly, I would like to open voting on
> June 15.
>
> Together, let's make PHP cryptography so safe that it becomes boring.

I wouldnt use such a sentence talking about security.


But I'm obviously +1 for such a movement, that will make PHP better
and have better crypto in PHP and finally get rid of mcrypt :-p


Julien.Pauli

---

## #93665 — Remi Collet — 2016-06-01T08:57:07+00:00

URL: https://externals.io/message/93663#93665 · In reply to: #93663

Le 01/06/2016 à 09:49, Scott Arciszewski a écrit :
> Hi PHP Internals Team,
> 
> Let's begin discussing the prospect of adding libsodium as a core extension
> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
> and the benefits it offers.
> 
> https://wiki.php.net/rfc/libsodium

Please state about the extension name in the RFC.

I will be -1 for "libsodium" (as libsodium is confusing on Linux and
raise various issues)

I will be +1 for "sodium"


Remi.

---

## #93668 — Marco Pivetta — 2016-06-01T10:48:00+00:00

URL: https://externals.io/message/93663#93668 · In reply to: #93663

Hey Scott,



> Hi PHP Internals Team,
>
> Let's begin discussing the prospect of adding libsodium as a core extension
> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
> and the benefits it offers.
>
> https://wiki.php.net/rfc/libsodium
>
> If the subsequent discussion goes smoothly, I would like to open voting on
> June 15.
>
> Together, let's make PHP cryptography so safe that it becomes boring.
>

First, thanks for providing better alternatives to crypto in PHP!

I also agree with Remi on naming: let's avoid calling the extension
`libsodium`.

I have some concerns that are just about code quality, not about
functionality. Consider that I didn't look at the underlying library (and I
really care little about it, from a consumer perspective).

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

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #93674 — Scott Arciszewski — 2016-06-01T13:45:04+00:00

URL: https://externals.io/message/93663#93674 · In reply to: #93668

> Hey Scott,
>
> 
>
> > […]
>
> First, thanks for providing better alternatives to crypto in PHP!
>
> I also agree with Remi on naming: let's avoid calling the extension
> `libsodium`.
>
> I have some concerns that are just about code quality, not about
> functionality. Consider that I didn't look at the underlying library (and I
> really care little about it, from a consumer perspective).
>
>  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.
>  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?
>
> Cheers,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
​I'd love to just keep the namespace personally
​ (
Ke
​eping \Sodium\foo() and \SODIUM\FOO means code I've written today will
work in 7.1 for non-PECL users
​, and less work we thrust on Frank Denis)​
​
but it was previously expressed that doing so violates the coding standard.
​ Changing to sodium_* would mean less bikeshedding and automatic "No"
votes.

As for the function names, that's what they were called in NaCl.
https://nacl.cr.yp.to/secretbox.html

I believe randombytes_buf() was named in a similar spirit to OpenBSD's
arc4random_buf().

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>​

---

## #93675 — Marco Pivetta — 2016-06-01T13:46:45+00:00

URL: https://externals.io/message/93663#93675 · In reply to: #93674

> 
>
> > […]
> ​I'd love to just keep the namespace personally
> ​ (
> Ke
> ​eping \Sodium\foo() and \SODIUM\FOO means code I've written today will
> work in 7.1 for non-PECL users
> ​, and less work we thrust on Frank Denis)​
> ​
> but it was previously expressed that doing so violates the coding standard.
> ​ Changing to sodium_* would mean less bikeshedding and automatic "No"
> votes.
>

Weird... I guess we could add a subsection to the vote?


> As for the function names, that's what they were called in NaCl.
> https://nacl.cr.yp.to/secretbox.html
>
> I believe randombytes_buf() was named in a similar spirit to OpenBSD's
> arc4random_buf().
>

Yeh, that is software archaeology though, not software design ;-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #93676 — Scott Arciszewski — 2016-06-01T13:53:01+00:00

URL: https://externals.io/message/93663#93676 · In reply to: #93675

> 
>
> > […]
>
> Weird... I guess we could add a subsection to the vote?
>
>
> > […]
>
> Yeh, that is software archaeology though, not software design ;-)
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Strictly speaking,
​ our​
 `random_bytes()`​
​ is every bit good enough without \Sodium\randombytes_buf(), for the PHP
use case. We might be able to trim some redundant features (however, unless
we make all the PHP encoding functions cache-timing-safe, will insist on
keeping \Sodium\bin2hex and \Sodium\hex2bin).

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/

---

## #93677 — Scott Arciszewski — 2016-06-01T14:11:14+00:00

URL: https://externals.io/message/93663#93677 · In reply to: #93675

> 
>
> > […]
>
> Weird... I guess we could add a subsection to the vote?
>
>
> > […]
>
> Yeh, that is software archaeology though, not software design ;-)
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

​I've added "proposed voting choices".

  1. Adopt libsodium?
  2. ...as-is? (Otherwise, prefix ahoy!)

This is precisely the sort of thing that should be voted on rather than
bikeshedded. :)

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>​

---

## #93681 — Fleshgrinder — 2016-06-01T17:26:27+00:00

URL: https://externals.io/message/93663#93681 · In reply to: #93668

> I also agree with Remi on naming: let's avoid calling the extension
> `libsodium`.
> 

I agree here too.


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


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

  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. :)

-- 
Richard "Fleshgrinder" Fussenegger

---

## #93685 — Scott Arciszewski — 2016-06-01T17:53:13+00:00

URL: https://externals.io/message/93663#93685 · In reply to: #93681

> 
>
> > […]
>
> I agree here too.
>
> 
> > […]
> instance,
> > […]
> the
> > […]
>
> I agree here too but read on.
>
> 
> > […]
> more
> > […]
>
> 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. :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
​Well, for what it's worth, I did write https://github.com/paragonie/halite
​ as a high-level abstraction.

The goal of this RFC is to get the lower-level functionality (which is
still, I promise, a high-level cryptography API) available.​


Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>​

---

## #93686 — Fleshgrinder — 2016-06-01T17:58:10+00:00

URL: https://externals.io/message/93663#93686 · In reply to: #93685

> ​Well, for what it's worth, I did write https://github.com/paragonie/halite
> ​ as a high-level abstraction.
> 

This looks over engineered too me, no offense!


> The goal of this RFC is to get the lower-level functionality (which is
> still, I promise, a high-level cryptography API) available.​
> 

I see that, no worries, I know other libraries. :)

procedural !== low-level

-- 
Richard "Fleshgrinder" Fussenegger

---

## #93691 — Niklas Keller — 2016-06-01T19:25:12+00:00

URL: https://externals.io/message/93663#93691 · In reply to: #93681

Fleshgrinder <php@fleshgrinder.com> schrieb am Mi., 1. Juni 2016 19:26:

> 
>
> > […]
>
> I agree here too.
>
> 
> > […]
> instance,
> > […]
> the
> > […]
>
> I agree here too but read on.
>
> 
> > […]
> more
> > […]
>
> 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

---

## #93692 — Ronald Chmara — 2016-06-01T19:46:02+00:00

URL: https://externals.io/message/93663#93692 · In reply to: #93681

> 
> > […]
> 
> > […]
> I agree here too but read on.
>
> 
> > […]
> 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

Hi. https://github.com/php/php-src/commit/aa203477bc24b1fadc16d65533c1749162260592
was my commit, put together as a result of discussions on this list
(and sidebars). I can try to speak to it from memory.

> Note that it also encourages this weird C style naming with
> abbreviations, hence, I would be open for discussing it.

It was 2000, 16 years ago.

WRT: "C style naming": C style PHP, *was* a big part of the PHP
adoption base in 2000. No objects. No inheritance. No classes. No
namespaces. Folks were also coming to PHP from ColdFusion, from Perl,
from JavaScript, and bringing their language conventions with them.
Without many guide rails, there was a weird mix of CreaTive_nameing
(and spelling). Conventions like verbnoun, Noun_Verb,
parent_Verb_noun, Parent(Noun())....(and most imaginiable
permutations) were sprinkled throughout the code, throughout
documentation, throughout the community... and one of the earliest
public complaints about PHP was about about inconsitent function
naming. The goal was to bend the curve, over the years, to bring some
order and consistency, not just to internal function naming (as in
this case), but to the entire PHP ecosystem. Thus, the standards about
parent naming, about underscores and....

...Abbreviation: In 2000, most PHP code was typed, manually, No IDE
completion, no built-in syntax checking, no code generators, every
single keystoke was a human hammering away in emacs/vi, BBedit,
Notepad (etc.), and longer function names tended to decrease code
quality (due to increased human error potential), and take up valuable
screen space (800x600 pixels on emergency terminals, though a nice
developer setup could have had 1024x768 pixels on a screen, all *at
the same time*.)  Coding houses still had rules like "maximum of 80
characters per line", to encourage brevity. Abbreviation in this
environment made for more compact code, with less typing errors, but
came with the costs of inconsistent abbreviations, and decreased
readability.

In 2016, using an editor with built in syntax highlighting,
auto-completion, while at coding desks measuring in thousands of
pixels across multiple screens, it seems a bit dated, but when
debugging text files with vi on a spare monochrome terminal session,
late night over a modem at 3,600 Kbps, those things mattered a great
deal. For folks who are still using modems, terminals, and updating
their PHP on 800 pixel screens, I imagine they might still matter.

-Ronabop

---

## #93719 — Pierre Joye — 2016-06-02T14:30:11+00:00

URL: https://externals.io/message/93663#93719 · In reply to: #93663

hi Scott,


> Hi PHP Internals Team,
>
> Let's begin discussing the prospect of adding libsodium as a core extension
> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
> and the benefits it offers.
>
> https://wiki.php.net/rfc/libsodium
>
> If the subsequent discussion goes smoothly, I would like to open voting on
> June 15.
>
> Together, let's make PHP cryptography so safe that it becomes boring.

Good work and very good choice for the backend library.

I am overall in favor of having this extension in the core. However a
couple of things are sub optimal or not ideal (in no special order):


- \Sodium\library_version_major() \Sodium\library_version_minor() and
\Sodium\version_string() should be constants

For  \Sodium\version_string(), the name is not consistent as it refers
to the library version not the extension version ("Returns a string
identifier of the current version of the sodium library installed.")
(edit: used would better represent what is actually happening)


- memzero, memcmp, hex2bin

I am not totally convinced that memzero and maybe memcmp names are
good nor they should be there. Both would be very useful as operator
on variables. Given the simplicity of the implementations, it could be
very useful in many other areas in case this ext is not installed

For hex2bin, the optional parameter could be added to the existing
functions. As this function does not require crypto safe
implementation (and does not need from an implementation), we should
have them as part of the engine instead.


- buf and other abbreviations should be better. I think we had a
discussion some time ago about how to provide interfaces for non C
developers.

- compare should be string_compare, or it could be confusing about
what it can compare, especially in code review while checking crypt
code, where many other types come into the game



Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #93720 — Fleshgrinder — 2016-06-02T16:59:47+00:00

URL: https://externals.io/message/93663#93720 · In reply to: #93692

> Hi. https://github.com/php/php-src/commit/aa203477bc24b1fadc16d65533c1749162260592
> was my commit, put together as a result of discussions on this list
> (and sidebars). I can try to speak to it from memory.
> 
> > […]
> 
> It was 2000, 16 years ago.
> 
> WRT: "C style naming": C style PHP, *was* a big part of the PHP
> adoption base in 2000. No objects. No inheritance. No classes. No
> namespaces. Folks were also coming to PHP from ColdFusion, from Perl,
> from JavaScript, and bringing their language conventions with them.
> Without many guide rails, there was a weird mix of CreaTive_nameing
> (and spelling). Conventions like verbnoun, Noun_Verb,
> parent_Verb_noun, Parent(Noun())....(and most imaginiable
> permutations) were sprinkled throughout the code, throughout
> documentation, throughout the community... and one of the earliest
> public complaints about PHP was about about inconsitent function
> naming. The goal was to bend the curve, over the years, to bring some
> order and consistency, not just to internal function naming (as in
> this case), but to the entire PHP ecosystem. Thus, the standards about
> parent naming, about underscores and....
> 
> ...Abbreviation: In 2000, most PHP code was typed, manually, No IDE
> completion, no built-in syntax checking, no code generators, every
> single keystoke was a human hammering away in emacs/vi, BBedit,
> Notepad (etc.), and longer function names tended to decrease code
> quality (due to increased human error potential), and take up valuable
> screen space (800x600 pixels on emergency terminals, though a nice
> developer setup could have had 1024x768 pixels on a screen, all *at
> the same time*.)  Coding houses still had rules like "maximum of 80
> characters per line", to encourage brevity. Abbreviation in this
> environment made for more compact code, with less typing errors, but
> came with the costs of inconsistent abbreviations, and decreased
> readability.
> 
> In 2016, using an editor with built in syntax highlighting,
> auto-completion, while at coding desks measuring in thousands of
> pixels across multiple screens, it seems a bit dated, but when
> debugging text files with vi on a spare monochrome terminal session,
> late night over a modem at 3,600 Kbps, those things mattered a great
> deal. For folks who are still using modems, terminals, and updating
> their PHP on 800 pixel screens, I imagine they might still matter.
> 
> -Ronabop
> 

This is a nice story but it simply is not true at all. You refer to the
beginnings of the 21st century as if it was the 1970/80s.

Steve McConnell: Code Complete, Second Edition

>
> Make names of routines as long as necessary
>
> Research shows that the optimum average length for a variable name is
> 9 to 15 characters. Routines tend to be more complicated than
> variables, and good names for them tend to be longer. Michael Rees of
> the University of Southampton thinks that an average of 20 to 35
> characters is a good nominal length (Rees 1982). An average length of
> 15 to 20 characters is probably more realistic, but clear names that
> happened to be longer would be fine.
>

>
> A study by W. J. Hansen found that longer names are better for rarely
> used variables or global variables and shorter names are better for
> local variables or loop variables (Shneiderman 1980). Short names are
> subject to many problems, however, and some careful programmers avoid
> them altogether as a matter of defensive-programming policy.
>

The first edition of the book contains these passages as well, it was
released in 1993 and the years of the studies are already in the quotes.

I know that there are many valid reasons for short names as well as
appropriate and I know that there are certain domains where long names
are not even possible or make no sense in the first place.[1] However,
PHP is a high level programming language that does not suffer from such
limitations. The only relation to C is the fact that PHP's underlying
engine is in C. Users of PHP are not familiar with C and very often not
familiar with any programming language other than the ones for the web
(e.g. JavaScript).

From our own source:

  zend_rsrc_list_get_rsrc_type()

How is that more readable or faster to type than any of the following
who are human readable and much clearer?

  zend_typeof_resource()
  zend_resource_type()
  zend_get_resource_type()

[1] http://programmers.stackexchange.com/questions/162698

-- 
Richard "Fleshgrinder" Fussenegger

---

## #93723 — Fleshgrinder — 2016-06-02T17:36:59+00:00

URL: https://externals.io/message/93663#93723 · In reply to: #93691

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

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.

  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()`?

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

---

## #93727 — Niklas Keller — 2016-06-02T18:10:30+00:00

URL: https://externals.io/message/93663#93727 · In reply to: #93723

2016-06-02 19:36 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:

> 
> > […]
>
> 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

---

## #93734 — Scott Arciszewski — 2016-06-02T21:34:07+00:00

URL: https://externals.io/message/93663#93734 · In reply to: #93727

> 2016-06-02 19:36 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:
>
> > […]
>
> Yes, sure.
>
>
> > […]
>
> 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.
>
>
> > […]
>
> Yes, and thus I think it shouldn't be exposed to userland.
>
>
> > […]
>
​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/>​

---

## #93738 — bjorn.x.larsson@telia.com — 2016-06-03T09:19:41+00:00

URL: https://externals.io/message/93663#93738 · In reply to: #93720

Den 2016-06-02 kl. 18:59, skrev Fleshgrinder:
> 
> > […]
> This is a nice story but it simply is not true at all. You refer to the
> beginnings of the 21st century as if it was the 1970/80s.
>
> Steve McConnell: Code Complete, Second Edition
>
> > […]
> The first edition of the book contains these passages as well, it was
> released in 1993 and the years of the studies are already in the quotes.
>
> I know that there are many valid reasons for short names as well as
> appropriate and I know that there are certain domains where long names
> are not even possible or make no sense in the first place.[1] However,
> PHP is a high level programming language that does not suffer from such
> limitations. The only relation to C is the fact that PHP's underlying
> engine is in C. Users of PHP are not familiar with C and very often not
> familiar with any programming language other than the ones for the web
> (e.g. JavaScript).
>
>  From our own source:
>
>    zend_rsrc_list_get_rsrc_type()
>
> How is that more readable or faster to type than any of the following
> who are human readable and much clearer?
>
>    zend_typeof_resource()
>    zend_resource_type()
>    zend_get_resource_type()
>
> [1] http://programmers.stackexchange.com/questions/162698
>
One could add that not all development / debugging is done through
an advanced IDE. Logging in to production server with SSH ending up
with a terminal window, only having Emacs or Vi at your disposal is
still valid today.

Regards //Björn Larsson

---

## #93747 — Marco Pivetta — 2016-06-03T13:50:05+00:00

URL: https://externals.io/message/93663#93747 · In reply to: #93738

> One could add that not all development / debugging is done through
> an advanced IDE. Logging in to production server with SSH ending up
> with a terminal window, only having Emacs or Vi at your disposal is
> still valid today.
>

s/valid/inconsiderate

You do this sort of stuff to quickly check something, not for developing.
Not on a staging/prod environment for sure.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #93788 — Stanislav Malyshev — 2016-06-04T22:15:26+00:00

URL: https://externals.io/message/93663#93788 · In reply to: #93663

Hi!

> Let's begin discussing the prospect of adding libsodium as a core extension
> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
> and the benefits it offers.
> 
> https://wiki.php.net/rfc/libsodium
> 
> If the subsequent discussion goes smoothly, I would like to open voting on
> June 15.

Some notes based on the docs in https://paragonie.com/book/pecl-libsodium:
TLDR: I think the idea of having something like this in core is very
nice, but I think it needs some tweaks in order to be a solution we can
recommend as core module.

- I would appreciate deeper namespacing. It is rarely that you would use
all sub-modules (such as encryption, both symmetric and asymmetric,
password hashing, decryption, random, etc.) in the same piece of code.
So if I could just "use Sodium\Crypto;" and then use short names it
would be much nicer than having to spell out the whole story.

- Also, I'm not sure why functions like
crypto_aead_chacha20poly1305_encrypt() exist. Shouldn't algorythm be a
parameter to encryption function and not function name? Putting
parameter into function names makes it much harder to be flexible and
configurable. Or, if there's only one, then why not just call it
 `encrypt()` and state the fixed algorithm in the docs?

- The function names in general are kind of all over the place. I.e., to
get a random, you get:
- for string: _buf
- for ranged (I assume unsigned?) integer: _uniform
- for 16-bit unsigned integer: _random16
If you can notice a pattern here, I can't. Also, I don't see why you
have a function for 16-bit int but not for 8-bit or 32-bit. Additionally
weird that _uniform gets int, but has limit different from PHP int.

- Naming/namespacing of constant-time function should make it clear they
are there because they are constant time, not just because somebody
wanted to reimplement bin2hex. It's also unclear why we need memcmp as
separate function from `hash_equals()`.
Also, I'm still not convinced bin2hex in PHP even has a timing problem.
I haven't seen anything but vague generic theoretising in this regard.
Same with hex2bin (in fact, even more since hex2bin doesn't even have
index lookups).

- What exactly memzero does in PHP? Looks like it accepts argument
by-ref, which means if you do something like:

function foo($secret_key) {
// do stuff with key
memzero($secret_key);
}

and then:

$key = get_key(); foo($key);

then $key still has the key. So I'm not sure how that all memory wiping
is still working in practice. I mean, it may work with random keys that
you generate, use once and immediately destroy, but in any other
scenario it's just wasting time. Even with random keys it's iffy since
it assumes your RNG state is either not in memory or is protected.
E.g. in the example at
https://paragonie.com/book/pecl-libsodium/read/09-recipes.md#encrypted-cookies
keys are meticulously erased, but since they are all deterministically
derived from $this->key (and cookie name which is public) which stays in
memory, what exactly is the point?

- increment() needs clearer explanation what it does (e.g. does it
accept any string? What exactly does it do to that string?) and also it
seems to be it would be nicer to just return the value. Or at least have
this option - mutation in place is not always what you want.

- Why version functions are functions and not constants?

- Names like "secretbox" are weird to me - what exactly is "secretbox" -
is it encryption? Decryption? hashing? Is it symmetric or asymmetric? It
would be nicer to use established and more clear terminology. Same with
other names - e.g. crypto_auth - what it does? Does it check the message
for authenticity or generates the signature for somebody else to check?
Turns out the latter, but it's not clear from the name.

- Same with crypto_box() - actually it differs from crypto_secretbox()
by... try to guess what. You would never guess. The former is
asymmetric, the latter is symmetric.

- It's not clear why keypair parameter is string - if it's two keys, how
it is one string? Also, why you need a keypair to encrypt-decrypt if
you'd use only one key in each case (public or private)? What you do if
you only have public key - how would you decrypt a message? Can you
decrypt a message at all if you don't have secret key - and if so, how?

- crypto_box_keypair_from_secretkey_and_publickey seems to use secret
and public key from different people, so the result is not what is
usually called a key pair (set of public+private keys belonging to one
user) - in fact, I don't know what the result is. Could you explain?

- After looking into crypto_sign_open I understands that it separates
the message from attached signature and verifies the signature. But it's
a bit confusing as it doesn't actually open anything.

- It is unclear why you need different functions to generate encryption
keypair and signing keypair.

- The API never seems to either document or allow any choice of the
algorithms. While it can be a boon for simplicity, I do not see how such
code could be made to interoperate with code in other languages and
other systems. I mean, I can generate the signature easily, but how
would I check such signature in, say, Python or Java? The docs give no
clue. It's OK to support only one algorithm if it's considered superior
(though what the users would do if it turns out not to be the case?) but
at least it should be thoroughly documented.

- If crypto_pwhash_str highly recommends using provided constants, why
not make these parameters optional with defaults being recommended
constants?

- crypto_pwhash_scryptsalsa208sha256 looks awfully specific (and long).
Is that the only algorithm supported? If yes, do we need to spell it out
in the name (and not the docs)? If not, why it's not a parameter?

- Is there any support for importing/exporting keys in any of the
established formats? Is the library inter-operable with any of the
existing key/data interchange formats?

- Function names like crypto_sign_ed25519_sk_to_curve25519 seem to not
be very usable to common people. The docs says "Transform crypto_sign
key into crypto_box key" - maybe the name should reflect it?
Names like crypto_stream_xor have a similar problem - what it does is
encrypts stream with a key, according to docs. Looks like it uses XOR
for it, but is it the most important part for the user or the fact it
encrypts? Maybe it should be crypto_stream_encrypt or something? Also,
does it really do just XOR? Because XOR is not really the best idea to
do even if you don't care about authenticity - due to trivial chosen
plaintext attack. Probably it does more than mere XOR, but then I'm not
sure what exactly.

- Why one would use crypto_scalarmult? That looks like a random piece of
low level API without clear indication why it exists.

- What is the difference between crypto_stream and randombytes_buf? Both
seem to produce a random string of given length. I assume crypto_stream
does more but the docs do not explain.

- For crypto_kx, it is not clear what exactly this function does and why
the same parameter is passed twice in different places. I mean, if you
know the details of how DH key exchange works, it may make sense, but if
we want to make it simple for the common user, it needs some better
explanations and maybe better parameters.

- Names like CRYPTO_PWHASH_SCRYPTSALSA208SHA256_OPSLIMIT_INTERACTIVE
look very painful. Yes, people have IDEs and copy-paste, but imaging to
have to type it just once over ssh connection in vim, where copy-paste
is not working. Can't we have something more concise and put the rest in
the docs?

This came out longer than I expected (hopefully somebody made this far?)
and more disorganised, so I provide a quick summary:
- Need better naming, both namespaces and functions
- Need better docs explaining what the functions do and why

The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
build a secure web application." I fully agree with this goal. I however
feel that current implementation, while making admirable progress
towards this goal, still needs some work to actually achieve it.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #93789 — Stanislav Malyshev — 2016-06-04T22:25:07+00:00

URL: https://externals.io/message/93663#93789 · In reply to: #93723

Hi!

> For instance nonce arguments ...
> 
>   $nonce = randombytes_buf(CRYPTO_SECRETBOX_NONCEBYTES);
>   crypto_secretbox(...

Speaking of which, what about just passing null there (or make it
optional) that would make the function generate a new random nonce of
suitable size? It's BTW would be very annoying to watch each time to use
nonce of the suitable size and would produce a lot of bugs. Not talking
about having to type CRYPTO_AEAD_CHACHA20POLY1305_IETF_NPUBBYTES and
distinguish it from CRYPTO_AEAD_CHACHA20POLY1305_NPUBBYTES.

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

We don't really need the uniform part if we don't have the non-uniform
one. If the only one we get is uniform, and it's the one we actually
want, we should not spell it out in the name - we should name it
something like random_int or random_range or random_between and explain
in the docs that yes, it's the  uniform one and it's the only you get
because uniform is awesome.

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

Hear, hear!

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #93795 — Pierre Joye — 2016-06-05T06:20:35+00:00

URL: https://externals.io/message/93663#93795 · In reply to: #93788

>

> The stated goal is "You shouldn't need a Ph.D in Applied Cryptography to
> build a secure web application." I fully agree with this goal. I however
> feel that current implementation, while making admirable progress
> towards this goal, still needs some work to actually achieve it.

I fully agree with you. As much as I think we need something like that, I
think these are stopping points.

I would very interested to hear from Scott about these questions and the
low level nature of the APIs make it not as friendly or future proof as it
could.

Cheers
Pierre

---

## #93798 — Fleshgrinder — 2016-06-05T07:28:51+00:00

URL: https://externals.io/message/93663#93798 · In reply to: #93789

> We don't really need the uniform part if we don't have the non-uniform
> one. If the only one we get is uniform, and it's the one we actually
> want, we should not spell it out in the name - we should name it
> something like random_int or random_range or random_between and explain
> in the docs that yes, it's the  uniform one and it's the only you get
> because uniform is awesome.
> 

https://secure.php.net/function.random-int

Is it uniform? That shouldn't be too hard to find out and the result
might be again that we actually don't need this new function at all.

-- 
Richard "Fleshgrinder" Fussenegger

---

## #93797 — Scott Arciszewski — 2016-06-05T07:46:02+00:00

URL: https://externals.io/message/93663#93797 · In reply to: #93795

>
> 
> > […]
>
> > […]
>
> I fully agree with you. As much as I think we need something like that, I
> think these are stopping points.
>
> I would very interested to hear from Scott about these questions and the
> low level nature of the APIs make it not as friendly or future proof as it
> could.
>
> Cheers
> Pierre
>

Hi Pierre,

My position on the low level nature of libsodium's APIs is as follows:
​That sounds like a call to action for https://wiki.php.net/rfc/php71-crypto
rather than a point of concern for adopting libsodium.​

Compare the following two snippets which accomplish the same "goal"
(anonymous public-key encryption).

    <?php
    /**
     * OpenSSL -- since the Diffie Hellman features in ext/openssl kind
     * of suck, I'm going to use RSA to encrypt the AES key using the
     * recipient's public key.
     */

    ## ENCRYPTION ##

    $message = 'Prime Numbers Rock!';
    $publicKey = openssl_pkey_get_public('file://path/to/public_key.pem');

    $aesKey = random_bytes(32);
    // Basically a poor-man's HKDF by just using HMAC
        $keyE = hash_hmac('sha256', 'Encryption Key', $aesKey, true);
        $keyA = hash_hmac('sha256', 'Authentication Key', $aesKey, true);

    $iv = random_bytes(16);
    $ciphertext = openssl_encrypt($message, 'aes-256-ctr', $keyE,
OPENSSL_RAW_DATA, $iv);
    $mac = hash_hmac('sha256', $iv . $ciphertext, $keyA, true);

    $combined = $mac . $iv . $ciphertext;
    $rsaCipher = '';
    openssl_public_encrypt($aesKey, $rsaCipher, $publicKey,
OPENSSL_PKCS1_OAEP_PADDING);
    $sendMe = $rsaCipher . $combined;

    ## DECRYPTION ##

    $privateKey = openssl_pkey_get_public('file://path/to/private_key.pem');
    $rsaPart = mb_substr($sendMe, 0, 256, '8bit'); // Assuming 2048-bit RSA
    $aesPart = mb_substr($sendMe, 256, null, '8bit');
    $mac = mb_substr($aesPart, 0, 32, '8bit');
    $iv = mb_substr($aesPart, 32, 16, '8bit');
    $cipher = mb_substr($aesPart, 48, null, '8bit');

    openssl_private_decrypt($rsaPart, $aesKey, $privateKey,
OPENSSL_PKCS1_OAEP_PADDING);
    $keyE = hash_hmac('sha256', 'Encryption Key', $aesKey, true);
    $keyA = hash_hmac('sha256', 'Authentication Key', $aesKey, true);

    $calc = hash_hmac('sha256', $iv . $cipher, $keyA, true);
    if (!hash_equals($calc, $mac)) {
        throw new Exception('MAC validation failure');
    }

    $decrypted = openssl_decrypt($cipher, 'aes-256-ctr', $keyE,
OPENSSL_RAW_DATA, $iv);
    var_dump($decrypted); // string(19) "Prime Numbers Rock!"

​Can you count the foot-bullets in that snippet that you'd need to be a
cryptography engineer to successfully avoid?

Demo: https://3v4l.org/nYVPf

Here's a congruent implementation in libsodium:​

​    <?php
    /**
     * Libsodium
     */

    ## ENCRYPTION ##

    $message = 'Prime Numbers Rock!';
    $bob_public_key = "... populate here ...";
    ​
    $nonce = random_bytes(24);
    $sendMe = \Sodium\crypto_box_seal($message, $bob_public_key);

​    ## DECRYPTION ##​

​    ​$bob_kp = "... populate here ...";
    $decrypted = \Sodium\crypto_box_seal_open($sendMe, $bob_kp);
    var_dump($decrypted); // string(19) "Prime Numbers Rock!"

(No demo available, as 3v4l doesn't have ext/sodium installed.)

​Libsodium already ​knocks it out of the park compared to OpenSSL and
Mcrypt. If we want to talk about a higher-level abstraction-- such as
what's provided by paragonie/EasyRSA + defuse/php-encryption or
paragonie/halite-- I wholeheartedly endorse that discussion. But I don't
think we should try to solve that problem with this particular RFC.

In closing, I don't disagree that a simple crypto API is a good goal to
have. I just think the ideal you're discussing is:

A. Out of scope, and
B. Kind of belittling to how much of an improvement libsodium is to what we
already have.

Further reading: http://framework.zend.com/security/advisory/ZF2015-10

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
​

---

Next page: https://externals.io/message/93663.md?page=2