4 ms·
I think the bigger problem is that the crypto primitives we have available do not behave like lego blocks. For example, encryption is useless without authentica
by ufo 11y ago
I think the bigger problem is that the crypto primitives we have available do not behave like lego blocks. For example, encryption is useless without authentication on top of it but the API will still let you use AES in CBC mode without authenticating afterwards.
If you use a higher-level crypto API like libsodium/NaCl then you can treat functions like lego blocks just fine.
- sarciszewski 11y agoAye. I think cryptography escapes most developers. Especially most PHP developers. I've been talking in #php.security on Freenode with ircmaxell and a few others about making a pluggable high-level PHP library that abstracts all the lego blocks away and just gives a sane interface. (Note: This is mostly ircmaxell's idea, I just offered a draft for the API layout.) For example: $c = new \Crypto\Symmetric('openssl:cipher=aes-128;mode=cbc;hash=sha256'); $k = $c->generateKey(); $cipher = $c->encrypt("Some message", $k); Omitting any of these parameters (e.g. just passing 'openssl:') should have sane, opinionated defaults that prioritize security. Developers will NOT be allowed to use ECB mode. The idea is that it should support multiple "drivers" (openssl, libsodium, possibly a begrudging mcrypt inclusion). PDO : databases :: this idea : cryptography The roadmap looks like this: 1. a PHP implementation/PoC 2. a PECL extension 3. a RFC and pull request to make it part of the PHP 7.1 core We already have password_hash() and password_verify(), there's no reason we can't abstract a typical use-case away from the average PHP developer and prevent them from implementing it themselves, horribly.