
Show HN: Halite – A simple libsodium wrapper for PHP projects - CiPHPerCoder
https://github.com/paragonie/halite
======
ejcx
Just wanted to give OP, CiPHPerCoder, a shoutout.

His work is all really high quality and he works very hard. Halite is great
for the PHP crypto crowd (if you are unfortunate enough to be in that
crowd...it is small). Really high quality project.

------
CiPHPerCoder
Hi HN,

I've been working on this project for a year now, and looking to push for a
version 3 release before 2016 is over.

Halite takes a lot of guesswork out of cryptography. You don't even need to
know what a nonce is to use it successfully.

I'd like to get more feedback from other developers if possible.

~~~
e12e
Looks nice on the surface. The only thing that leaps out at me from the
readme, is the lack of a suggested way to store/recover the salt? Ideally I'd
see a function that takes a "password" and some "plaintext" \- generates a
salt from an OS provided source, an IV (if applicable) and returns a package
of the cipher-text along with the salt (and IV).

I suppose there might be instances where the cipher-text without the salt
might be useful -- but I can't immediately think of any. Keeping the salt
"semi-secret" is akin to using a two-key system: the password the user knows,
and the salt that the server knows -- but it strikes me as a brittle way of
doing things, and provides unclear promises wrt. availability etc (can the
user always recover the data, only remembering the password?).

One could of course _construct_ such a function on top of the primitives
provided here - but I think it would make a lot of sense to provide something
along the lines of:

    
    
      * sym_enc(password, plaintext) >
         -> returns "box" autogenerated-salt|ciphertext
         -> possibly with a version header, indicating
            KDF (&enc algo) used (could just be a magic
            number)
        Should obviously use an AEAD mode
    
     * syn_dec(password, box)
        -> retrieves key by getting KDF, salt from
           box, regenerating key
        -> and returns decrypted plaintext
    

There's nothing wrong with exposing the KDF-functions I suppose, but it feels
like it's aiming a bit low, in close proximity to ones feet.

~~~
CiPHPerCoder
> The only thing that leaps out at me from the readme, is the lack of a
> suggested way to store/recover the salt? Ideally I'd see a function that
> takes a "password" and some "plaintext" \- generates a salt from an OS
> provided source, an IV (if applicable) and returns a package of the cipher-
> text along with the salt (and IV).

Generally you want to just do this once:

    
    
        $key = KeyFactory::generateEncryptionKey();
        KeyFactory::save($key, '/path/outside/webroot');
    

And from then on:

    
    
        $key = KeyFactory::loadEncryptionKey('/path/outside/webroot');
    

Encryption typically never touches a password (although you can derive one
from a password and salt if you so choose). The normal way of doing things is
to just use a random key.

(My takeaway is: the README for v3 probably needs work to make this more
clear.)

Thanks for the feedback! :)

~~~
e12e
Right. Still, after your last edit, the last section (the example with a
password derived key) -- still stands out from the rest of the otherwise
excellent readme -- in that it's not actually a usable example. I mean the
code (appears to) _work_ \- but it's not an actually usable example like the
others. Because it leaves a lot of questions up in the air (or worse, for an
untrained eye, it might lead to implementing "one-way" encryption, if real
data is encrypted, and the salt thrown away...).

------
Bino
[https://wiki.php.net/rfc/libsodium](https://wiki.php.net/rfc/libsodium)

------
b34r
There's also a BitTorrent client by the same name, if anyone thought this
sounded familiar.

------
akie
This looks really great, but I have to ask: why only support for PHP 7+? Is
there any plan to support PHP 5.x? With only PHP 7+ it's more or less unusable
in the large majority of current PHP projects or in common PHP hosting
environments.

~~~
CiPHPerCoder
We actually have a blog post for this exact question.

[https://paragonie.com/blog/2016/04/go-php-7-our-
commitment-m...](https://paragonie.com/blog/2016/04/go-php-7-our-commitment-
maintaining-our-open-source-projects)

The short of it:

* PHP 7 allowed us a combination of type safety and brevity that makes it much easier to reason about the security of Halite in a way that PHP 5 does not.

* There is a very bad habit in the PHP community, led by WordPress, to provide _very legacy_ support (i.e. PHP 5.2.4 in 2016). For that reason, we're going against the grain focusing on PHP 7 only. If people want to use any of our new open source libraries, they need to make the decision to upgrade now.

