On the Zend blog there's a new tutorial posted by Enrico Zimuel covering the use of libsodium in PHP 7.2 to provide stronger encryption for your data.

Recently, at ZendCon & OpenEnterprise 2018, I presented a session about the usage of Sodium in PHP 7.2. Here you can find the slides of this session.

Sodium is a powerful library for modern cryptography. It is a portable, cross-compilable, installable and packageable fork of NaCl, a famous cryptographic tool designed by Prof. D.J. Bernstein.

The tutorial begins with an outline of the Sodium encryption including the algorithms it can use and how it helps to prevent side-channel attacks. It then lists out some of the common use cases and provides a simple code sample showing how to use it to encrypt a simple message with a randomly generated key.

On the php[architect] site they've posted an article that appeared in their December 2017 issue, an article that introduces Libsodium (by Eric Mann), a new addition to PHP's "security toolbelt" for encryption.

By the time you read this, the PHP community should have introduced the world to the newest version of our favorite language. This latest version adds better support for type annotations, allows trailing commas in lists (just like JavaScript and other dynamic languages) and introduced several security improvements. The most notable security addition, however, is the introduction of the Sodium cryptographic library as a core extension.

In the article he covers the basics of the Sodium library (that libsodium is built on top of) and what makes it different from other encryption methods. He also talks about what's been done to support it on pre-PHP 7.2 versions including the sodium_compat polyfill library and the PECL extension for PHP 7.0+. Example code is included showing how to use this new functionality via native functions once support for it has been compiled in.

In a new post to the Paragon Initiative blog Scott Arciszewski has shared a helpful reference for those that might be a little confused by the naming and functions involved in the use of libsodium in PHP. In this quick reference he lists out each of the functions, what type they are and an example use case.

Last Friday at Day Camp 4 Developers, I presented a talk titled Cooking with Sodium in PHP 7.2, which was largely live-demoing the various cryptography features provided by libsodium. One of the questions I was asked by attendees was about knowing which feature to use to solve specific problems. This is the sort of problem that I suspect many people run into, so here's a quick reference table followed by a detailed explanation.

In the table below, all encryption modes utilize authenticated encryption.

Following the quick reference table he then gets into more detail on each of the functions, describing in depth what they're for and examples of how to most effectively use them.

On the SitePoint PHP blog today they've reposted an article that was originally posted on the ParagonIE blog about searching encrypted information in database fields from author Scott Arciszewski.

This question shows up from time to time in open source encryption libraries’ bug trackers. This was one of the “weird problems” covered in my talk at B-Sides Orlando (titled Building Defensible Solutions to Weird Problems), and we’ve previously dedicated a small section to it in one of our white papers.

You know how to search database fields, but the question is, How do we securely encrypt database fields but still use these fields in search queries?

Our secure solution is rather straightforward, but the path between most teams asking that question and discovering our straightforward solution is fraught with peril: bad designs, academic research projects, misleading marketing, and poor threat modeling.

They start off with some of the examples of bad ways to perform the searching of encrypted information, mostly around either using poor encryption levels or custom created encryption solutions. With those out of the way, the tutorial moves on to their recommended method: using an authenticated encryption scheme (libsodium) and blind indexing. The key to the method is to use a secondary column for the actual searching process, encrypting the value provided and running the search against that, not the encrypted value itself. The article then covers two questions that need to be asked before putting this method to use. The article ends with a method to enhance the previous searching to allow for "fuzzier" searching through the generation of some additional index values in a joined table.

In this post to the dev.to site Scott Arciszewski talks about a milestone in the PHP language, it being the first language to "add modern cryptography to its standard library" (PHP 7.2).

Last week, the voting phase closed on an RFC to add libsodium to PHP 7.2. The result was unanimous (37 in favor, 0 against).

When version 7.2 releases at the end of the year, PHP will be the first programming language to adopt modern cryptography in its standard library.

He goes on to talk about what "modern cryptography" is describing concepts like secure primitives and showing example of the high-level API the integration will provide. The post finishes out with a rebuttal against some of the nay-sayers around PHP and its reputation for security. They say that there's "no way PHP is more secure than " so Scott compares this libsodium addition to some of the features in other languages and where they're lacking in relation.

On the SitePoint PHP blog there's a new tutorial posted showing you how to use the Halite package to encrypt the contents of emails. The Halite library sits on top of the libsodium functionality to provide tested, hardened cryptographic results.

Cryptography is a complex matter. In fact, there is one golden rule: "Don’t implement cryptography yourself." The reason for this is that so many things can go wrong while implementing it, the slightest error can generate a vulnerability and if you look away, your precious data can be read by someone else.

[...] Some libraries out there implement cryptography primitives and operations, and leave a lot of decisions to the developer. [...] Nevertheless, there is one library that stands out from the rest for its simplicity and takes a lot of responsibility from the developer on the best practices, in addition to using the libsodium library. In this article we are going to explore Halite.

The tutorial then starts of helping you get the libsodium package installed on your system (assuming it's unix-based). They then start on the sample application - a basic "email" client able to send/receive messages between users. They set up RESTful endpoints to get the messages, use the Doctrine ORM for a database interface and show the use of the Halite Crypto class to encrypt/decrypt the message contents.

On the Paragon Initiative site there's a new post that promises a way to solve all of your cryptography problems in PHP with three simple steps.

Last year, we began developing Halite, a FOSS high-level wrapper for the PHP bindings to libsodium. We use Halite extensively in our own projects (including our upcoming CMS which has quite a few of its own innovative cryptography features baked-in).

As of version 2.1.0, we are confident that Halite solves all of the application-layer cryptography problems that most PHP developers face; and it does so in three easy steps. (For transport-layer cryptography, you should still use TLS, of course.)

Their three steps to effectively using Halite and libsodium in your application are:

• Step One: Managing Cryptography Keys
• Step Two: Encrypting or Authenticating with Halite
• Step Three: Decrypt or Verify

Each step comes with example code showing how to use the tool to accomplish it. There's also a few other problems that are solved by using the library including generating encrypted password hashes and whole file cryptography.

On the Paragon Initiative site they've posted a new tutorial sharing a method for creating "one login to rule them all" for your PHP-based applications. The goal is to make one system that can provides a single authentication point and secure credential storage.

Problem: You want to create a system whereby when a user authenticates to example.com, they're also automatically logged in at foo.com, bar.com, baz.com, and any other domains that you decide to add to the list at a later date. Okay, great, that seems straightforward, except there's a complication: The Same Origin Policy prevents you from getting/setting cookies on domains other than the one you control.

[...] Let's narrow it down a little bit further: Unlike a situation where e.g. "Login with Facebook" would be appropriate, you control all of the domains. They just happen to be different, so the Same Origin Policy kicks in. For simplicity, feel free to assume they're on the same server and application codebase, but you have a multi-site architecture in place where some of the sites have a different domain name.

Let's work around this limitation with as few moving parts as possible.

He then shoes how to use libsodium (via the Halite wrapper) to secure your credentials (passwords) and hooking it into a custom API endpoint that takes in a hex-encoded JSON string and a signature for the payload. He then expands this to provide "automatic login" handling making use of another endpoint to fetch an image to and log in the user by passing it the payload and signature values. He ends the post with a few security concerns around using this method and some things that it assumes are correct (and robust enough).

On the Paragon Initiative site they've posted a new article showing you how to safely store a password (in 2016) that discusses both the concepts around good password hashing and how to do it in several languages (including PHP).

The Problem: You want people to be able to create a unique user account, with a password, which they will use to access your application. How can you safely implement this feature?

He advises using libsodium for some of the best protection but points out that it's not widely supported yet. An alternative that is, however, is bcrypt (including PHP. He shows how to hash a password in:

• PHP
• Java
• C# (.NET)
• Ruby
• Python
• Node.js

Each of them is basically a one-line kind of change and doesn't require much effort on the developer's part to implement. He ends the post with a few FAQs around Argon2, PBKDF2 and why he's chosen to advise bcrypt over scrypt.

On the Paragon Initiative blog there's a post that suggests changing your thinking about security trade-offs, those concessions we make every day in the development choices we make around the security of our applications versus other concerns.

The theory goes: You cannot have perfect security against all possible threats all the time for free. Usually, we expect our applications to incur a cost (usually in terms of CPU, memory, or electricity usage) in order to be secure. It seems logically correct that, if you need more security, your cost must therefore be higher.

Fortunately, this is not always true! Sometimes, given a choice between two solutions, the more secure option costs less than the insecure one.

The article points out that what we think might be a "fair tradeoff" between two choices may only look as much on the surface. They give the example of random number generation and the speed involved in using the random functions versus the true CSPRNG in PHP 7 (or the compatibility library). The article also points out that even those in the security industry make these same kinds of decisions. Essentially they lesson they're trying to suggest is that trade offs in security are usually based on the wrong assumptions or a limited knowledge of the technologies offered.

And if you reach the point where you have to make a choice between a secure option and an insecure option that might be better by some other metric, make sure you actually document and measure this trade-off. You might find that the benefit of the insecure choice is negligible, and that you therefore should opt for security.