# Should an AES byte key generated with OpenSSL be converted to hex?

I am generating a key & iv with Ruby's OpenSSL wrapper for an AES CBC 256 setup:

cipher = OpenSSL::Cipher::Cipher.new('aes-256-cbc')
key = cipher.random_key
iv = cipher.random_iv


I am then storing the generated key / iv in blob columns in the database. When trying to display the key or iv it looks something similar to this:

×>×=ñ±8i·ÊahJ[  }öú­Ç{xÎÝ¿


My question is:

should the key & iv which seem to be random bytes be converted to hex with an SHA function before using and storing into the DB?

Is it safer this way for storage / use or can they be used just as they are generated in byte form?

UPDATE:

Looks like I was mistaken on my terminology and use of SHA.

Revised question: Is a random byte key from OpenSSL just as random and secure if I convert it to hex via unpack('H*')

Any help is appreciated.

Thanks!

-
:-o SHA does not convert to hex. I think you should revisit your sources. You can convert to hex with any of the utilities Ruby gives you for that. Apart from that storing secret keys in the DB, doesn't seem a good idea. –  izaera Mar 19 at 17:31
Revised the question, I was mistaken on hashing and hex conversion. –  mrmanman Mar 19 at 17:45
Are you storing the key and IV in the database alongside the data being encrypted? That seems like folly. Also, if available in your version of OpenSSL, you should strongly consider using an authenticated cipher such as AES-128-GCM, which prevents tampering with ciphertexts. –  Stephen Touset Mar 19 at 18:03
Sometimes, the status-quo of Layer 8 is intriguingly scary. Let me comment your question in 3 parts: (1) unpack('H*') converts hex to bytes, not the other way around as you're describing… you need pack to to that, (2) depending on how you implement/use it, the hex version will not be as secure as the byte version, and (3) you should not be storing keys and encrypted data next to each other… in fact, if you do that, you could as well simply store it plaintext to spare an attacker the effort of copy-and-pasting the keys. –  e-sushi Mar 19 at 21:18
@e-shusi: Can you elaborate (2) a little more? I can't see why storing something as hex may be different than storing it as binary. Sounds to me like saying that "Spanish is less secure than English" ;-). –  izaera Mar 21 at 8:01

This is an answer to your revised question, although it doesn't seem to make any more sense:

Hex is just another way to represent your data. It is neither more nor less secure than the binary representation or any other representation. Its all about convenience when dealing with this numbers.

As humans we tend to operate with data encoded in the decimal system. Computers on the other hand operate with binary data. However, the problem with binary data is that it tends to get quite long and error prone when you as a human have to deal with it. It is much more easy for us to remember or copy 46 rather than 0b101110.

The hex representation is a a good compromise, because:

• A single character encodes four bits, therefore making it shorter than the appropriate binary representation.

• It is quite easy for humans to handle. Basically everyone is used to 0-9 and A-F.

• Is is really easy to convert data from binary into hex and vice versa.

• It can be represented in ASCII without any problems. Random binary data on the other hand looks like complete gibberish and gets messy because of different encodings and such.

Yet, at the end of the day it is all representing the same information.

-
Thank you, that answers my question –  mrmanman Mar 19 at 17:57
Keep in mind that while it's perfectly okay to store the key and IV as hex strings, AES as an algorithm operates on bytes and not hex strings. So you will need to reverse the process and decode from hex back to bytes before using the key and iv. –  Stephen Touset Mar 19 at 18:01