Hasin Hayder has recently posted a tutorial to his blog showing how to use the Zend_Crypt_Rsa library for encrypting/decrytping data in a Zend Framework application.

Public/private key based encryption is very popular because of the strength it sets in encryption, specially above 1024 bits. Now there are external library to encrypt data using RSA encryption like RSA in phpclasses.org - the fun is we were also using this library in one of our ZF based project. But last week I've found that there is a hidden gem in the Library/Zend/Crypt folder (Zend_Crypt_Rsa) which can do the same thing using openssl library.

He couldn't find much in the way of documentation for the component, so he wrote up how to use it in three easy steps:

• Create your RSA public/private key using ssh-keygen
• Encrypt data using your public key
• Decrypt the cipher

The Zend_Crypt_Rsa makes it simple to encrypt/decrypt the data, just taking in a passphrase, a path to the RSA key file and the message contents.

In this new post to his blog Sameer Borate looks at a method he's come up with to encrypt files uploaded into your application with the help of the Zend_Filter component of the Zend Framework.

As earlier I'd encountered Zends wonderful Zend_Filter class, I decided to go with it and use the Zend_Filter_Encrypt and Zend_Filter_Decrypt to accomplish the work. The Zend_Filter component provides a set of common useful data filters, among which are the encryption filters. Although my project was not developed in Zend, I could easily integrate the required classes in the code. Note that Zend has a great upload library, Zend_File_Transfer, that lets you easily manage file uploading and also encryption, but as I already had the upload code tested, I decided to just add the encryption part.

He includes the step-by-step process to get everything you need and which files you'll need to have included from the framework to make things work. He includes code for both encrypting and decrypting the file information as well as hints on selecting an algorithm and a random initialization vector. You can download the complete source if you want to jump right in.

Evert Pot has a quick new post to his blog today talking about how to push encrypted information into a cookie for storage.

There have been a couple of approaches I've been considering [to replace sessions being stored in the database], one of which is simply storing all the information in a browser cookie. First I want to make clear I don't necessarily condone this. The reason I'm writing this post, is because I'm hoping for some more community feedback. Is this a really bad idea? I would love to know.

He includes some code to make it happen - a class that uses the hash_hmac function and a SHA1 encryption type (along with a salt) to convert the information into a string that can be (relatively) safely stored in a cookie. Be sure to read the comments for more opinions on the method.

On NETTUTS.com today there's a new post by Dustin Blake with a few simple tips and helpful techniques to locking down and protecting your website with some simple PHP scripts.

One crucial part of PHP development practice is always keeping in mind that security is not something you can simply buy off the shelf at your local convenient store. Ensuring the security of your web applications is a process, which over time, needs to be constantly evaluated, monitored, and hardened.

He shows a few methods you can use to secure things - generating random values, making random passwords to give to your users, creating salted passwords, obfuscation and an overview of cryptography in PHP. Complete source code is included.

On the NETTUTS.com site there's a new tutorial posted looking at creating a "crypter" class in PHP - a handy class to make encryption and decryption of data simpler.

Think about what we might need a class like this for? We want to encrypt important data with a password for security reasons. We also want, as already mentioned, to be able to decrypt that data when necessary. Why should you use symmetric algorithms? It's easy; when you're offering a password sent via email or something like that, you need the password to be sent in plaintext. The hash algorithms are not reversible. Once you have hashed a string you can't decipher the original text from the hash.

He lays out his basic class with three methods - the constructor that sets up the key and algorithm and the encrypt and decrypt functions. These use to mcrypt functions to handle the heavy lifting.

The Zend Developer Zone has a new tutorial posted today showing how to use the open source encryption tool GnuPG from inside PHP.

While GnuPG works very well as a standalone tool, it also plays very well with PHP. This integration is possible due to PHP's ext/gnupg extension, which provides a flexible and powerful API to access GnuPG functions for encryption, decryption, message signing and verification, and key maintenance. And your mission (should you choose to accept it) will be to accompany me over the next few pages, while I give you a crash course in this API, showing you how easy it is to integrate these functions into your next PHP application.

The tutorial walks you through some of the basic concepts behind the "lock and key" GnuPG implements and how to get the extension installed so you can follow along. His examples range from a basic encryption of a string out to a full encrypt/decrypt example, how to sign information with a key and even a method for sending an encrypted message.

Andreas Gohr has a general overview of hashing in a new post to his blog:

Every good programmer knows, that passwords should never be stored in clear text. Instead a one way hash (or digest) should be used. This way user passwords are not at risk in case of an intrusion.

He points out the multiple ways that PHP offers for both simple hashing (like md5 or sha1) and the true encryption types (like ssha, apr1 and crypt). He shows how they work in the DokuWiki application via a call to auth_cryptPassword to make it and db_get_hash/auth_verifyPassword to check against it.

Harry Fuecks came across a need in his development work to bridge a gap between a PHP script and some Java work he'd done. He found the way that fit his situation the best - the encryption of the data on the PHP side via OpenSSL.

Needed a mechanism to be able to pass chunks of data securely from PHP to Java [...] One solution might be something "from scratch" involving mcrypt or PHP libraries like Crypt_RSA. [...] Another approach is GnuPG, either via the command line as discussed in this tutorial or via the GnuPG extension from PECL.

Option 3 is using OpenSSL and PHP's openssl_seal() function. SSL is normally used for encrypting networked communication between peers but that's not all it can do. [...] What's more - and perhaps the biggest win - it also allows us to re-use existing SSL certificates.

He uses the openssl_seal functionality on top of the EVP encrypted envelope on the certificate to handle the encrypt/decrypt of the data. Both the PHP code and Java code (and execution example) are included in the post.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.

On PHPBuilder.com today, there's a new tutorial that talks about a method to securing data sent via GET requests in your application.

In this article I'm going to show you how you can use PHP to encode your data for transit. Most importantly, it will be done in a way that makes the data decodable, and therefore much more usable, by the receiving page.

They talk about some of the advantages to encryption before getting into how it actually works. Their example script is separated out into three PHP files - the main part of the script, a single-use script that, in turn, creates the third file, include file for the encode/decode functions. With the structure defined, they move on to the code - the generation of the file with the large multi-dimensional array and the two functions to encode and decode the information.