Tips and Techniques: Encrypting Text

[MCWebsite.Staff]

** This thread discusses the article: Tips and Techniques: Encrypting Text **
** This thread discusses the Content article: Tips and Techniques: Encrypting Text **
0

[matt.haas@thomson.com]

Tips and Techniques: Encrypting Text

** This thread discusses the article: Tips and Techniques: Encrypting Text **
I just read this article and one thing that wasn't mentioned was using salt values when encrypting. For example, if I encrypt first names (like Bob or Matt) using AES and don't use a salt value, the cipher text is always going to be the same. It's still better than just storing clear text but it does open you up to dictionary attacks on the password. By adding a salt value (which is ideally a secure random number like the one generated by CIPHER's Psuedo Random Number generator), you end up with different cipher text for the same clear text which makes it much more difficult to perform dictionary attacks. The trick with using a salt value is that you need to know what it is when you decrypt the data. Typically, this means storing it with the cipher text in a set position (or pattern) so it can be retrieved later. One other consideration with encryption is that it can make cross system (or even cross language) communication more difficult since the cipher text is actually a binary format. Using credit cards for an example, if I encrypt the credit card number and then send it off to a Java or .Net program for processing, they will not be able to decrypt it and get a meaningful value since they'll end up with EBCDIC characters. Also, the built in encryption routines in Java and .Net expect the data to be padded before encryption which CIPHER does not do (or at least I wasn't able to figure out how to do it at V5R1). These were all issues that I had to deal with on my first encryption project. Here's how we resolved it using 128-bit AES: - Convert data to Unicode (.Net and Java are already Unicode so those systems don't do this step) - Pad (we use PKCS5 padding) - Salt - Encrypt (we used CIPHER on the iWhatever IBM calls it this week) Decryption is the reverse of these steps. Also, RC4 is a poor choice for encryption (easy to hack and easy to implement in ways that make it really easy to hack) and depending upon your requirements, may not even be allowed. It's usually safe (export issues aside) to use 3DES with a large key value or 128-bit or higher AES (AES is prefered over 3DES) and since those choices are as easy to implement, there's just not a good reason to use RC4. Additionally, block ciphers typically perform better than byte at a time ciphers and AES in particular is very fast. Matt

[lrmorgan]

Tips and Techniques: Encrypting Text

** This thread discusses the article: Tips and Techniques: Encrypting Text **
This would be wonderful if it could do triple des or one of the newer methods that are acceptable to auditors these days. It would be nice if all we had tro do is call a program and pass a couple of perameters. I agree that the Qc3 parameters are quite complicated and it took me quite some time to get the encryption to work. I would love it if someone would come up with an easier method to do some of the newer methods of encryption.