The custom is that the first word names the function group (yes, I know
old functions do not follow it, but this is new one). Unless we're going
to introduce a group of functions called secure_, random_ is a natural
choice.
This reminds me of the other problem. There is no one crypto lib that
is in good shape or really covers what's needed. The Cryptography lib
for Python has the right idea with it's backend interfaces:
http://is.gd/kUztPc There's a lot else I like about that lib, like
putting all the primitives under a member named "hazmat".
The problems with mcrypt have been discussed.
The limitations of OpenSSL became apparent when I researched what a
shim on OpenSSL could manage: http://is.gd/jHtafh tl;dr The coverage
is so poor I wouldn't bother trying. If you're using AES/CBC you're
OK and it's not worth messing around with a shim. I'm not sure
there's anything else OpenSSL supports that I want anything to do
with. Besides, people are understandably scared of OpenSSL.
libgcrypt does at least have a maintainer but it's poor Werner Koch
who is so destitute he lives on charity raised on Kickstarter and has
his work cut out just trying to deal with GPG: http://is.gd/cbHCYO
Botan has a nice array of features and is well documented but is
otherwise a mystery to me.
Python Cryptography uses also Apple's CommonCrypto but it doesn't
add very much, is limited to OS X and comes with Apple's open
source license.
I thought I'd share what I learned while working on it. And,
fwiw, Yii excises Mcrypt in 2.0.3.
Hi,
libgcrypt does at least have a maintainer but it's poor
Werner Koch who is so destitute he lives on charity raised
on Kickstarter and has his work cut out just trying to deal
with GPG: http://is.gd/cbHCYO
Wow. Just WOW.
Are you jealous that thousands of people consider Werner Koch's work
valuable and therefore support him building the financial ground to pay
full-time maintainers for a software that millions use without even
knowing (HINT: package signatures) or are you just a jerk?
Unbelievable.
Stefan Esser
Hi,
libgcrypt does at least have a maintainer but it's poor
Werner Koch who is so destitute he lives on charity raised
on Kickstarter and has his work cut out just trying to deal
with GPG: http://is.gd/cbHCYOWow. Just WOW.
Are you jealous that thousands of people consider Werner Koch's work
valuable and therefore support him building the financial ground to pay
full-time maintainers for a software that millions use without even
knowing (HINT: package signatures) or are you just a jerk?Unbelievable.
Stefan Esser
Woah, hold on there Stefan. I think you may have misinterpreted
something here. Toms words definitely don't have any negative feeling
to them, if anything I got the feeling of sympathy, and the "poor
maintainer" might have to quit one day unless he gets more funding!
Please remember that now is just impossible to use AES-GCM with the current
OpenSSL extension API, there is no way to get/set the authentication tag.
With AES-GCM you already get a MAC for free, that should be the default
operation mode.
https://bugs.php.net/bug.php?id=67304
On 26 February 2015 at 16:07, Stefan Esser stefan.esser@sektioneins.de
wrote:Hi,
libgcrypt does at least have a maintainer but it's poor
Werner Koch who is so destitute he lives on charity raised
on Kickstarter and has his work cut out just trying to deal
with GPG: http://is.gd/cbHCYOWow. Just WOW.
Are you jealous that thousands of people consider Werner Koch's work
valuable and therefore support him building the financial ground to pay
full-time maintainers for a software that millions use without even
knowing (HINT: package signatures) or are you just a jerk?Unbelievable.
Stefan Esser
Woah, hold on there Stefan. I think you may have misinterpreted
something here. Toms words definitely don't have any negative feeling
to them, if anything I got the feeling of sympathy, and the "poor
maintainer" might have to quit one day unless he gets more funding!
Hi,
libgcrypt does at least have a maintainer but it's poor
Werner Koch who is so destitute he lives on charity raised
on Kickstarter and has his work cut out just trying to deal
with GPG: http://is.gd/cbHCYOWow. Just WOW.
Are you jealous that thousands of people consider Werner Koch's work
valuable and therefore support him building the financial ground to pay
full-time maintainers for a software that millions use without even
knowing (HINT: package signatures) or are you just a jerk?
Hi Stefan,
I don't know why you think these are the only interpretations of
what I wrote. I believe my description is factual and says nothing
about my opinions regarding Werner or his work. If you would like to
know what I think, rather than jump to your own conclusions, you may
ask and I will tell you.
Tom
Hi,
libgcrypt does at least have a maintainer but it's poor
Werner Koch who is so destitute he lives on charity raised
on Kickstarter and has his work cut out just trying to deal
with GPG: http://is.gd/cbHCYOWow. Just WOW.
Are you jealous that thousands of people consider Werner Koch's work
valuable and therefore support him building the financial ground to pay
full-time maintainers for a software that millions use without even
knowing (HINT: package signatures) or are you just a jerk?Hi Stefan,
I don't know why you think these are the only interpretations of
what I wrote. I believe my description is factual and says nothing
about my opinions regarding Werner or his work. If you would like to
know what I think, rather than jump to your own conclusions, you may
ask and I will tell you.
It is possible to read your paragraph both ways, and i have picked up on
the same interpretation as Stefan. Glad you meant it the other way.
Tom
The custom is that the first word names the function group (yes, I know
old functions do not follow it, but this is new one). Unless we're going
to introduce a group of functions called secure_, random_ is a natural
choice.This reminds me of the other problem. There is no one crypto lib that
is in good shape or really covers what's needed.
The problems with mcrypt have been discussed.
The limitations of OpenSSL became apparent
Agree 100%.
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.
Leigh and all,
The custom is that the first word names the function group (yes, I know
old functions do not follow it, but this is new one). Unless we're going
to introduce a group of functions called secure_, random_ is a natural
choice.This reminds me of the other problem. There is no one crypto lib that
is in good shape or really covers what's needed.The problems with mcrypt have been discussed.
The limitations of OpenSSL became apparent
Agree 100%.
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.
One thing I'd like to make clear: I do not intend to target 7 with
this functionality (possibly 7.1 or later). I'd rather build a POC and
play with it for a bit. So while I do want to discuss it, I just
wanted to set expectations properly.
Anthony
One thing I'd like to make clear: I do not intend to target 7 with
this functionality (possibly 7.1 or later). I'd rather build a POC and
play with it for a bit. So while I do want to discuss it, I just
wanted to set expectations properly.
Agreed. Not 7.0.
I just think it's time to start thinking about what to do. POC would
be real swell, of course.