On 27 February 2015 at 21:14, Tom Worster <f...@thefsb.org> wrote: > 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.
There are countless applications/services that will do things "their own way", and the odds of them using the same structure as any generic implementation is going to be hit and miss. I guess it would have been better if I had said "doesn't give any room for flexibility" > 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... Feeling pretty pessimistic on this one. Each camp is going to feel that they know best and push for their own way. If we could get a mandate from a group of established and respected cryptographers, maybe :) > 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(). I hear you. http://marc.info/?l=php-internals&m=142365688004941&w=2 Count the number of replies :( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
