3 ms·

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

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

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