On 2/26/15 11:12 AM, Leigh wrote:> On 26 February 2015 at 15:37, Tom Worster <f...@thefsb.org> wrote:
> I've spoken with Anthony and a couple of others about something in the > same vein as the new csprng functions. I think core needs a pair of > functions that handles the needs of the 99%. Those functions are. > > aes_encrypt(string $data, string $key): string > > aes_decrypt(string $data, string $key): string > > I have discussed this briefly with Anthony and Nikita, and we haven't > reached a consensus on whether AES-n would be determined by key-length > (adding complexity for the user), or whether $key should be > $passphrase and should have key-stretching performed (this would avoid > the case where people pass in hex for a key), in which case we would > default to AES-128. > > The default mode would be CTR > > An IV would be taken from the csprng random functions, and would be > prepended to the result. > > A strong MAC would be calculated and appended to the result. > > This doesn't leave any room for interoperability where things are done > differently, but it also doesn't leave any room for people to mess it > up. I think it's important that when it comes to crypto, we give > people the ability to "just get it right", without having to know > about why something is right or wrong. > > I welcome any thoughts on this. I agree with this direction and have a few comments. 1. You say it "doesn't leave any room for interoperability" but I'm not sure I agree. I invite you again to look at the Cryptography lib for Python. The Fernet protocol is published. It implements basically what you are describing above but with a couple of interesting extras: - protocol version number - timestamp, useful for receivers tracking for possible replay I don't see why we couldn't sponsor an effort to encourage adoption of this or some such interoperability protocol. Go to FIG, see if the Rails, Node and Django people are interested, and so fourth... 2. At this stage I think PHP should be thinking beyond AES. There are a number of arguments about phasing out AES that you can find online. Regardless of the merits of these arguments, the demand for newer ciphers is only going to increase. Meanwhile, it's going to be years before anything we discuss here now is mainstream in PHP and more years before that gets upgraded. So I think we may as well have a pluggable backend for algorithm implementations and a means for users to upgrade ciphers, perhaps by introducing new version numbers in the above mentioned protocol from time to time. That said, I'm not in favor of a function that lets users choose among lots of ciphers. I just want an easier way to evolve than introducing new functions, like, idk, threefish_encrypt(). 3. When we did this in the yii\base\Security component we choose to have separate methods for encryptByPassword() and encryptByKey(). The main advantages are: - it makes the API simpler and easier to explain - it encourages the developer to think about the difference - it gives us a soapbox to encourage people to avoid passwords when possible And I encourage PHP to do the same if you want to allow users to do either. Users will sometimes need to encrypt with a password so its best to make it hard to screw up. 4. We included a salt in the message for PBKDF2, and, just to keep the message format the same both ways, used one also for key-based encrypt. Tom Btw: owing to the volume on this list, I am not normally subscribed. I occasionally check activity using nntp but cannot seem to reply that way. In any case, if there's something you want me to see, please send it to my email address. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
