This week at RPG World in Las Vegas, nearly 200 attendees are upgrading their skills, learning new techniques, hearing about the direction of RPG and System i5, and connecting with their software vendors.

One of the sessions I'm teaching for the first time this morning is "Getting Started with Encryption." This session covers the basics of System i5 encryption—from the _CIPHER MI instruction, to packages that do encryption (such as RPG xTools), to the new "Qc3" APIs. (The 20+ encryption APIs all begin with "Qc3," so I refer to them collectively as "Qc3 APIs.")

Encryption today has come a long way. Long ago, the only way to do it on a midrange system was with a coprocessor. In addition, RSA got a stranglehold on encryption in 1977. Thank goodness a group of fine young hackers published the code behind RC4 encryption all over the Internet. As a result, newer, better encryption schemes were created. And IBM started to support these new schemes (or "algorithms") in software. At first, it was a bit confusing because if you didn't install the Licensed Program Product (LPP) for encryption, you could not do encryption. With IBM's pricing architecture where it is and most of IBM's marketing referring to chargeable products as "free," I have no idea if you actually have to pay for encryption in an itemized fashion or if the charge is consolidated in with the base licensed code/operating system. So I won't try to guide you in installing cryptographic support.

Until OS/400 V5R3, programmers had to rely on the _CIPHER MI instruction to perform encryption and hashing (also known as "message digest"). In V5R3, IBM introduced the Qc3 APIs, three of which stand out.

Qc3EncryptData

This API encrypts data using any of the following algorithms:

• DES—Data Encryption Standard
• TDES—Triple DES
• AES—Advanced Encryption Standard
• RSA—Written by Ron Rivest, Adi Shamir, and Len Adleman
• RCx—Includes RC2 (Rivest Cipher 2) and RC4 (Rivest Cipher 4)

Encrypting data with these APIs can be challenging, and of course, in keeping with tradition, IBM does not provide prototypes for Qc3 APIs in RPG IV syntax. Several (not all) are available via free download (as usual) from rpgiv.com/downloads.

Here is the prototype for the Qc3EncryptData API:

Qc3DecryptData

This API is used to decrypt data that has previously been encrypted. It uses the same algorithms as Qc3EncryptData.

The prototype for the Qc3DecryptData API follows:

Often, when data is being encrypted or decrypted, it's transferred between different systems. When this occurs, the coded character set ID (CCSID) of the data needs to be kept in sync. For example, if data is encrypted on a PC, it is probably in PC ASCII CCSID(819) or similar. If that encrypted data is sent to a System i5 and decrypted, the resulting information will not be correct. Instead, once the encrypted data is sent to the System i5, it should be decrypted and then translated to the job's CCSID. Likewise, data on the System i5 should be translated to PC ASCII and then encrypted.

Qc3CalculateHash

This API is used to create an MD-5 hash or one of four Secure Hash Algorithm (SHA) hashes (aka "message digest") for a given data set. A hash is used to validate data rather than encrypt it. The SHA algorithms supported are SHA-1, SHA-256, SHA-384, and SHA-512. Normally, you want to use MD-5 (the de facto standard) or SHA-512, which is much more secure than MD-5.

The SHA algorithms were designed by the U.S. government, but in spite of that, they are very secure.

The number following the SHA name (except for SHA-1) indicates the number of bits that are used to generate the hash. For example, SHA-256 produces a 32-byte (256-bit) hash, SHA-384 produces a 48-byte (384-bit) hash, and SHA-512 produces a 64-byte (512-bit) hash. SHA-1 produces a 20-byte (160-bit) hash and is considered the successor to MD-5, which produces a 128-bit (16-byte) hash.

One great application for a hash is password security. Storing passwords can be a security issue. Storing encrypted passwords can also be a security issue. Storing a hash for a password, rather than storing the password itself, can be a security benefit. For example:

1. Someone creates a new password.
2. Your program generates an MD-5 or SHA-1 hash for the password.
3. You store the hash but not the password.
4. Later, the user enters the password.
5. You generate a hash from the data entered.
6. The new hash is compared to the saved hash.
7. If they match, great. If not, sorry!

This way, even if someone steals the password file, he can't reverse-engineer the passwords. Of course, the higher the bit count, the more secure the hash.

Another application is to verify whether or not data has been modified. For example, suppose you add a 20-byte field to the end of a database file's record. In this field, you store an SHA-1 hash that is generated using the content of the record. If the content of the database is changed, when you generate the hash from that new data, it will not match the existing hash and you'll know someone or some program has changed the data. This is like having a much more powerful version of Modulus 11 to verify data integrity.

Of course, IBM doesn't provide the prototype for this API, so I've included here.

In the next issue, I'll illustrate subprocedure wrappers for these three APIs that simplify encryption, decryption, and hash creation.