5 ms·

Show HN: Halite – A simple libsodium wrapper for PHP projects

43 points by CiPHPerCoder 10y ago

CiPHPerCoder 10y ago
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.
- deftnerd 10y ago
  Thanks for your hard work. I'll try to use it in some future projects
- e12e 10y ago
  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 10y ago
    > 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 10y ago
      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...).
ejcx 10y ago
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.
b34r 10y ago
There's also a BitTorrent client by the same name, if anyone thought this sounded familiar.
akie 10y ago
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 10y ago
  We actually have a blog post for this exact question. https://paragonie.com/blog/2016/04/go-php-7-our-commitment-maintaining-our-open-source-projects https://paragonie.com/blog/2016/04/go-php-7-our-commitment-m... 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.
Bino 10y ago
https://wiki.php.net/rfc/libsodium https://wiki.php.net/rfc/libsodium

43 points by CiPHPerCoder 10y ago

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.

deftnerd 10y ago
Thanks for your hard work. I'll try to use it in some future projects
e12e 10y ago
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 10y ago
  > 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 10y ago
    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...).

ejcx 10y ago

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.

b34r 10y ago

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

akie 10y ago

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 10y ago
We actually have a blog post for this exact question. https://paragonie.com/blog/2016/04/go-php-7-our-commitment-maintaining-our-open-source-projects https://paragonie.com/blog/2016/04/go-php-7-our-commitment-m... 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.

Bino 10y ago

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