PHP Becomes First Programming Language To Add 'Modern' Cryptography Library In Its Core (bleepingcomputer.com)

An anonymous reader writes from a report via BleepingComputer: The PHP team has unanimously voted to integrate the Libsodium library in the PHP core, and by doing so, becoming the first programming language to support a modern cryptography library by default. Developers approved a proposal with a vote of 37 to 0 and decided that Libsodium will be added to the upcoming PHP 7.2 release that will be launched towards the end of 2017. Scott Arciszewski, the cryptography expert who made the proposal, says that by supporting modern crypto in the PHP core, the PHP team will force the WordPress team to implement better security in its CMS, something they avoided until now. Additionally, it will allow PHP and CMS developers to add advanced cryptography features to their apps that run on shared hosting providers, where until now they weren't able to install custom PHP extensions to support modern cryptography. Other reasons on why he made the proposal are detailed here. Arciszewski also says that PHP is actually "the first" programming language to support a "modern" cryptography library in its core, despite Erlang and Go including similar libraries, which he claims are not as powerful and up-to-date as PHP's upcoming Libsodium implementation.

Comments

Oh please

[Anonymous Coward]

Any language where the default equality comparison operator is *true* given two string-type variables with values "0E54321" and "0E12345" is not a cryptographically secure language. In fact there is a nonzero chance of the default equality operator returning true between two different MD5 or SHA256 hashes if they happen to fall into a hexadecimal form that is all digits except for one E or F.

Anyone who claims that PHP is somehow more secure as a language because it has added *new optional library calls* without doing anything about the fundamental language defects is demented.

Re:Oh please

[Vairon]

PHP has a comparison operator === that evaluates if the two things it is comparing are equal and of the same type.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo 'equal'; } else { echo 'not equal'; } "
not equal

Without ===, variable type conversion can cause a string containing numbers to be converted to an integer. See these links for details:

http://php.net/manual/en/langu...
http://php.net/manual/en/langu...

Re:Oh please

[Lisandro]

Except for objects, where a === b is true only if a and b are the same object. Such a beautifully designed language.

Re:Oh please

[Dogtanian]

Any language where the default equality comparison operator is *true* given two string-type variables with values "0E54321" and "0E12345" is not a cryptographically secure language. In fact there is a nonzero chance of the default equality operator returning true between two different MD5 or SHA256 hashes if they happen to fall into a hexadecimal form that is all digits except for one E or F.

Technically, that (in itself) doesn't necessarily mean that the built-in cryptography nor the language itself are inherently insecure. In theory, that is, provided you understand the language and use it correctly.

And that's the problem. Because in practice, PHP's design philosophy of trying to be clever- often too clever by half- when it comes to comparisons, equality, automatic coercion, data types, etc. etc. too often gives unpredictable and unexpected results from people who weren't aware of that behaviour.

You absolutely do *not* want any risk of this happening when you're designing a system that has to be secure. You want boringly explicit and utterly predictable data and type handling.

My prediction is that far, *far* more security holes will be down to bugs caused by unforeseen subtle aspects- i.e. pitfalls- of PHP's type handling and equality behaviour (etc.) in the apps using it rather than bugs in the cryptographic module itself.

PHP being a language more favoured by inexperienced users, this is likely to be made far worse. Expect lots of newbies with misplaced confidence designing what they think are "secure" apps that are in fact full of holes- either because they've misused or misunderstood the cryptographic module, or because they've overlooked some basic aspect of computer security elsewhere (e.g. failure to parse input securely) that makes the use of cryptography irrelevant.

And those are the sorts of mistakes newbies would make when using any language- with PHP's language design issues on top of that, it has the potential to be far worse.

So, yeah. I trust that the module will be secure. The main problems- I guarantee- will be caused by caused by overlooked (or not known about) aspects of PHP's too-clever-by-half data handling (in client apps using it) leading to exploitable holes, and by the fact that too many of PHP's newbie-skewing userbase will overconfidently assume it makes their apps foolproof while using it incorrectly and ignoring security holes elsewhere that make it redundant.

Re:Oh please

[Lisandro]

Oh, how i wish i was: https://developers.slashdot.or...

Re:Oh please

[fahrbot-bot]

PHP has a comparison operator === that evaluates if the two things it is comparing are equal and of the same type.

The next version will support "====" for things are really, *really* equal.

Re: Oh please

[Edgewize]

Or more relevantly, I think this is what the original poster was referring to:
https://www.whitehatsec.com/bl...

Here are some examples of PHP doing mind boggling things with md5 and sha1 hashes.

https://3v4l.org/tT4l8

Re:Oh please

[Lisandro]

I think you meant s = 'H'; there....

But again, this is to be expected. C is a low level language without memory management; PHP is neither. There is no sane reason why it is supposed to segfault (according to the developers, "infinite recursion crashes") and i'm not aware of any other high level language which does the same. How hard is to add a recursion counter?

Re:Oh please

[gweihir]

It is a sign of very junior and inexperienced language designers with very big egos. And no concept of personal responsibility.

Writing good code is hard enough with good tools.

Re:Oh please

[gweihir]

It is a poor craftsman that uses shoddy tools in the first place. Selecting good tools is a core skill for any craftsman. Those that do not have it will never amount to anything.

Re:Oh please

[TheRaven64]

The type of "hello world" is const char *, so your compiler should warn that you're dropping the const in an implicit cast (and if you're a sensible person and compile with -Werror, then your compiler will reject the code). You can get the behaviour that you want with:

const char s[] = "hello world";

This will copy the contents of the string literal into a mutable array. If you write this at the global scope, the copy will be done at compile time, so you'll end up with the string in the data section, not the rodata section (if you do it in a variable with automatic storage, you'll get a copy every time the variable comes into scope). Putting constant strings in the rodata section is important for optimisation, because it allows them to be coalesced. If you write "hello world" in two place, then you'll end up with a single string in the rodata section. With some linkers, if you also write "world" somewhere else, then you'll just get two pointers into the same string (this is also one of the reasons that C uses null-terminated strings: you can't do this with Pascal strings, and it saved a useful amount of memory on the PDP-11). Once you're sharing the string, it becomes a really bad idea to allow someone to modify it, because that modification will then become visible in a different bit of code.

SubjectsSuck

[aardvarkjoe]

Arciszewski also says that PHP is actually "the first" programming language to support a "modern" cryptography library in its core, despite Erlang and Go including similar libraries, which he claims are not as powerful and up-to-date as PHP's upcoming Libsodium implementation.

So it's the first to support a modern cryptography library, as long as you define "modern" to mean "the one that we're using."

It's easy to be first to do something if you place enough arbitrary restrictions on what that something is.

Re:SubjectsSuck

[NotInHere]

"Modern" is for CS people like "Alternative facts" is for politicians.

Re:SubjectsSuck

[MightyMartian]

I don't even understand the point of the claim. So the interpreter has a baked-in crypto library? And how is that different than simply #including a crypto library, which has the added bonus that you can pick any number of crypto libraries.

Re:SubjectsSuck

[Chuck Chunder]

What are the best alternatives to NACL for cryptographic primitives?

I think the point is "first" is a weird word to use when you are talking about "modern" as "modern" changes with time.

OpenSSL or mcrypt or whatever else you might point to were "modern" when they were "first" used, even if they aren't "modern" any more.

"Only" might be a better choice if you are talking about the current time.

Re:SubjectsSuck

[Anonymous Coward]

Libsodium is an extended fork of Daniel J. Bernstein's original NaCl project (not to be confused with Google Native Client), which is a cryptography library developed with the overarching aim of simplifying (and improving the implementation-level safety of) the practical use of strong cryptographic constructs. The "big idea" behind NaCl was to abstract away many of the low-level choices and technical details associated with various cryptographic primitives in favor of more "generic" interfaces, utilizing implementations of algorithms that are widely deemed strong and safe behind the scenes. Thus, the potential for human error via misuse or misunderstanding of various primitives would ideally be reduced, and overall security posture could be improved for many applications, without every developer needing to spend years becoming a cryptography expert. For additional background on NaCl, you might reference the following paper: The security impact of a new cryptographic library. Like its predecessor, libsodium is freely licensed, and developers are encouraged to embed and distribute the library along with their projects.

Hope this helps. -PCP

Re: SubjectsSuck

[Sledgy]

It's different in that if a vulnerability is discovered in the underlaying library an new release of PHP is required to fix it. Note you will need to convince the hosting provider/infrastructure team to test and deploy the latest release. This is the reason the cryptography library for Python (and requests) don't want to be made part of the core so they can be agile and respond quickly to security problems.

So they'll be the first to do it wrong?

[OverlordQ]

I'll stick to every other language that has had libsodium bindings for a while now.

Re:So they'll be the first to do it wrong?

[c]

I'll stick to every other language that has had libsodium bindings for a while now.

I'm just waiting for them to release the libsodium bindings for C...

libsodium is a C library

[adam.voss]

For those who don't know, libsodium is a C library that PHP will be utilizing. It is not a PHP library.

Too little... too late...

[__aaclcg7560]

I got tired of script kiddies banging down my PHP/MySQL servers. I'm using Pelican (Python) to convert my websites into static websites. With nothing to hack, script kiddies go away.

Re:Too little... too late...

[__aaclcg7560]

How do you edit your Pelican-powered website while away from your home PC? Skiddies can hack through that.

I don't allow outside access to my file server at home. From my file server I can make whatever changes needed to the website, run pelican to generate the static files, and rsync the output directory to the hosting server. Since I don't use PHP or MySQL, the script kiddies have no attack vector into my website.

Re:Too little... too late...

[__aaclcg7560]

If you get an idea for an update while away from home, particularly for an extended period, what do you do with that idea?

I write it down in my dead tree notebook.

BULLSHIT!

[allo]

BULLSHIT! BULLSHIT! BULLSHIT!

PHP is one of the programming languages, which load all stuff into the core (which can be quite a disadvantage), but other languages use a library by a single include. So what?
And even php has it into a .so file, which can be loaded, but isn't required to be used. So the "core" is relative as well. Actually its a bundled module.

Perhaps instead of building everything and .....

[aix tom]

.... a kitchen sink into the core, they could have instead done a *sane* way to include additional modules.

Perl and Python for example have no problem loading user-specific or script-specific modules, not like the "system wide or nothing" approach of PHP. ( which of course doesn't work with shared hosting. )

Other languages did this first

[MobyDisk]

I remember when Java was the first language to do this. Shortly after that, C# was the first language to do this. Now PHP is the first language to do this. So who will be the next one to do it first?

Gotta love PHP ...

[Qbertino]

I'm smiling while I read this.

Every single bit of this news is sooo PHP and one of the reasons this awkward mess of a PL is so successful.

They find something new or something they need and bolt it on. Just like that. End of story. A vote on the core team, a little coding and *BAM* PHP has a new inner API function with what has to be the most over-the-top all-out-PHP-style name for an inner API function ever - sodium_crypto_box_keypair_from_secretkey_and_publickey($ecdh_secret, $ecdh_public); (seriously, this is no joke).

Totally LOL. Takes the cake for inner function names ten times over, even by PHP standards, which is quite a stunt. And right away PHP has up-to-date hard crypto that even a simpleton can use.

You have to hand it to the PHP crew - they actually get shit done, no matter what. :-)

Monte beat PHP by a year!

[MostAwesomeDude]

My beloved Monte https://monte.rtfd.org/ beat PHP to this by a wide stretch. While it's true that PHP is a big established language, that doesn't mean that they get to claim sudden leaps in innovation which didn't happen. I've tweeted at the author of the blog post https://twitter.com/corbinsimpson/status/834175224736157696 with timestamped commits from the Monte codebase.

So, you're embedding libsoduim...

[Lisandro]

...which effectively prevents me from updating it. Great choice for a security library guys.

Would you prefer an interpreted crypto library?

[tepples]

And how is that different than simply #including a crypto library, which has the added bonus that you can pick any number of crypto libraries.

I can see three ways to proceed:

A built-in crypto library This runs at full speed and is available by default to the shared hosting customer. An add-on crypto library compiled to native code and distributed as a PHP extension This runs at full speed but requires the shared hosting customer to convince the hosting provider to install it. An add-on crypto library written in pure PHP This is available by default to the shared hosting customer but can run unacceptably slowly due to interpreter overhead.

The crypto is the easy part of this

[thogard]

The cryptography algorithms are the easy part. The vary hard part is protecting keys so I hope someone provides plenty of examples of how to do that properly. I hope they don't go down the Java route of showing how to use the functions without proper key management.

And it'll be a shitshow because of course it is

[Just Some Guy]

Sneak preview of the API:

crypto_really_encode(plaintext, algorithm); // Simplest
crypto_really_encode(plaintext, mode, algorithm); // Next arg goes in the middle
crypto_really_encode(block_size, plaintext, algorithm, mode); // Switch it up yo lol

...where AES will somehow be a valid value for both mode and algorithm (which will silently override to "NULL" if plaintext starts with a zero or the letter "p").