0
$\begingroup$

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!

|improve this question
$\endgroup$
  • 1
    $\begingroup$ :-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. $\endgroup$ – izaera Mar 19 '14 at 17:31
  • 1
    $\begingroup$ 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. $\endgroup$ – Stephen Touset Mar 19 '14 at 18:03
  • 1
    $\begingroup$ 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. $\endgroup$ – e-sushi Mar 19 '14 at 21:18
  • 1
    $\begingroup$ @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" ;-). $\endgroup$ – izaera Mar 21 '14 at 8:01
  • 1
    $\begingroup$ @izaera LOL – no, that's not what I meant. I said “depending on how you implement/use it” because using bytes is not a problem and storing hex values isn't a problem either… but if OP is planning to implement the whole thing while simply using hex values (as OP implies) instead of converting the hex values back to bytes, OP will end up using a limited char-range (0-9A-Z) instead of the expected (0x00-0xFF)… which will throw away a truckload of potential security. That's why I said it's important to have it implemented correctly… especially, since OP already mixed up pack() and unpack(). ;) $\endgroup$ – e-sushi Mar 30 '14 at 18:27
3
$\begingroup$

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.

|improve this answer
$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – Stephen Touset Mar 19 '14 at 18:01
2
$\begingroup$

The reason why you see this gibberish is that the key is random and simply interpreting it as a string of characters doesn't make sense and can lead to all kind of mistakes.

You should inform yourself about hashes! Once you hash something, you are not able to retrieve the original value, so I would guess you don't want to do that. Hashes are not about converting data into hex! Its just convenience that hash functions usually output hex strings, because they can be handled more easily.

What you might want to do, is to convert the key into its hex representation. Note, however, that this is something completely different than a hash function. I'm sure Ruby offers you means to do that.

Besides all of that: Why are you storing keys and IVs in a database? Obviously we don't know anything about your application, but this seems like a bad idea, especially with a lack of understanding for cryptographic fundamentals.

|improve this answer
$\endgroup$
  • $\begingroup$ Thanks for that information. So just to clarify I can convert the bytes into hex representation and the key still retains it's randomness and strength? Sorry if that's a stupid question, trying my best to wrap my head around this :) $\endgroup$ – mrmanman Mar 19 '14 at 17:36
  • $\begingroup$ The key is nothing magic: it's just an array of bytes. You can represent an array of bytes as hexadecimal numbers, as characters, as a list of decimal numbers, encode them in base64, ... If you write it as hex numbers somewhere, then you should read them as hex and convert them to bytes again. This link may help stackoverflow.com/questions/1393238/… $\endgroup$ – izaera Mar 20 '14 at 7:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.