The Encrypt Data API protects data privacy by scrambling clear data into an unintelligible form, OPM, QC3ENCDT; ILE, Qc3EncryptData
Simplified RC4 or AES Encryption by Bob Cozzi
In the last issue, I reported on a few of the new OS/400 encryption APIs: Qc3CalculateHash, Qc3EncryptData, and Qc3DecryptData.
Calling one of these APIs requires careful interpretation of the API's parameter list. The parameter lists consist of various data structures and formatting codes that can be somewhat vexing to say the least. Unless it's for performance reasons, I can't understand why IBM continues to publish APIs that require such complex parameters. Even I find them confusing, and I've been working with OS/400 APIs since before the first ones were even announced.
To help simplify matters, I've written two subprocedures that accept data as input (along with the encryption key/password) and return the data encrypted or decrypted, depending on which subprocedure you call
APIs by Example: AES Encryption to Actual Field Length
By: Carsten Flensburg
I've discussed and demonstrated the Cryptographic Services APIs in past issues of this newsletter. The encryption examples that I presented have all used the Advanced Encryption Standard (AES) algorithm, which offers a current, strong, and well-performing encryption method that has been adopted as an encryption standard by the U.S. government. If you have followed those examples, you know that AES encryption is a block cipher and that the ciphertext produced by AES therefore always is an exact multiple of the block size applied to the cryptographic process. The block size specified for the AES algorithm is 16 bytes, although the Cryptographic Services APIs' implementation of AES offers 24 and 32 bytes block sizes as well.
For some purposes and situations, the block-size determined length of the ciphertext could be regarded as an inconvenience. In today's APIs by Example, I explain a method for handling data not a multiple of the block length
More Encrypting Data on as400 to follow...