Encryption can be a complex beast of mathematical operations. In this video, we explore the evolution of modern cryptography and some of the basic underlying principles that it uses to keep data secure.

You can watch it in-page or head over to YouTube for the larger version. You can also follow his playlist to keep up with his future videos.

Does your framework of choice offer an easy way to perform data encryption? Maybe you have even utilized data encryption in some format. [...] It could not be much easier than that. It is hard to argue. But things won't stay as simple as this if you look at the meaning of "secure data encryption" a little bit closer. Usually people encrypt their data to make sure the data will stay safe. What does this actually mean? Simply put, it means your data stays secret as long as the secret key stays secret. No matter if an active attack is going on and the adversary can read your encrypted data.

He looks at why, by itself, encryption isn't that useful - it's only when its applied. He also covers some of the basic questions to ask when working with things like HMAC hashing and ciphertext malleability. He talks about random number/string generation for IVs, encryption keys and what you can do to help make your encryption more secure in its implementation.

At our company, we process a lot of requests on the leading gift cards and coupons websites in the world. The senior developers had a meeting in late October to discuss working on a solution to replicate the MySQL functions of AES_ENCRYPT and AES_DECRYPT in the language of PHP. This article centers on what was produced by senior developer Derek Woods and how to use it in your own applications.

He starts with a little bit of backstory - why to even bother using encryption, what AES encryption is and why you should probably avoid using the MySQL implementation of it in your apps. PHP's mcrypt functions don't return the same hashes as their MySQL counterparts (he includes the "why" of this) and includes some quick code to replicate the MySQL behavior. He also mentions some issues with the transformation, newlines and shows the source for their completed "aes_crypt" and "aes_decrypt" functions.

The other day I announced the release of my new password hashing library, PasswordLib. As I've come to expect, Reddit was full of interesting commentary on the topic. Some was good, some was bad and some surprised me. What surprised me was the insistence on a global salt (otherwise known as a "pepper"). So, I started thinking about it some more, and I figured I'd write a post on why I don't use peppers in my hashing algorithms (and why you may want to rethink it too).

He starts with an explanation of what a salt is (and isn't) to lead naturally into the idea of a "pepper", a single unique value that's used across an entire site/application for password encryption. He covers four flaws inherent with this method:

• There's no proof that using them increases your security.
• There are no publicly vetted hashing algorithms that accept a pepper as an argument.
• Using a block cipher instead of a pepper provides a stronger level of encryption and protection.
• The entire concept of a pepper is based around a flawed premise. [...] The flaw in that premise is that it's often not just your database that's leaked.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

Recently, an attacker hacked into my database and stole all the passwords and usernames stored there. Needless to say, I had to change everything and it cost me time and money. What made the crime easy for the attacker is that I never encrypted any of the passwords in the database. I've learned my lesson and now I'm passing along that wisdom with this article about encryption in PHP. Using some of the encryption techniques that PHP offers, you can safeguard your information in various ways.

He lays the foundation for the series by talking about three different kinds of encryption that can help you protect your data - one-way encryption, symmetric (using a key) and asymmetric (shared key locking).

In my situation, PayPal is only used to pay for orders - cart and order setup is done in our shop, so I do not want to have additional problems with users changing orders numbers, amount to be paid, etc. [...] Only PayPal knows how to decrypt it, because it uses public key encryption technology (you need to upload your certificate in PayPal account).

Some sample usage code is included as is a link to the class itself. His example takes a payment transaction including the item name, amount and currency type and sends it off to the PayPal servers in a connection protected by certificates.

It's been a while since I did some active ZF/PEAR component development. It's been one of those 6 month periods where time to commit was a rarity for a few reasons. So now that I'm back on the road, where to?

He sets his sights on the Zend_Crypt component and details some of the encryption methods it contains - HMAC, the Diffie-Hellman Key Agreement Protocol, a hashing wrapper and proposed support for a RSA public key cryptography. He mentions that a lot of this support is already in a beta package for PEAR.

What if you're using MD5 in your web application and want to switch over to another encryption method. It's actually not that hard and I plan to cover them in this multi-part tutorial (I know I planned on writing this months ago, but it's better late then never). In this first part I plan on going over updating the database structure and a 'pseudo-code' of what will need to be done.

As mentioned, he gives the outline (pseudo-code) of how the process will work - basically, creating an SHA1 hash of the MD5 and the username in a "newpassword" column added to your database.

In this increasingly virtual online world, you have to be careful to protect your data. Learn the basics of encoding and encrypting important bits of information, such as passwords, credit card numbers, and even entire messages. Get an overview of what it means to encrypt and decrypt information, as well as some practical examples involving passwords and other data, using PHP's built-in functionality.

They start off where any good encryption article should - with a primer in cyrptography. You can't understand the advanced without a good grasp on the basic. Using this knowledge, they start to work up their form, a simple username and password validation system.

They provide all of the code you'll need to build the form, and even intorduce you to the crypt() function. A bad use of this functionality is also illustrated. Of course, encryption is only half the fun, so they also include an example of decrypting the same information.