1

I'm writing a program that can encrypt a file using AES cfb128 (using Openssl and C++).

The scenario of the program is this:

  • Person A visits computer, encrypts a file they make, takes away a key (on USB stick?)
  • Person B visits computer and is unable to decrypt encrypted file
  • Person A comes back and decrypts the file using their key

My question is I have an encryption key and initialization vector that I must set for the AES encryption. I plan on randomly generating numbers for one and using a hardware ID for the other. Also the person could choose to encrypt multiple files.

So how would I do this?
Can I make the encryption key the hardwareID and the init vector a sequence of random bits?

If the same hardwareID and init vector are used to encrypt multiple files per machine, is this unsecure given that an attacker will not have the init vector but may have the encryption key? Should the encryption key be the random bit instead and the hardware key be the init vector?

Or should both the encryption key and init vector be random and unknown to the attacker? And if so, is it secure to encrypt multiple files using the same 2 unknown keys?

Mo Beigi
  • 255
  • 1
  • 4
  • 9

1 Answers1

3

You can use your HardwareID as basis for the encryption key. If the ID provides enough entropy it'll work. However, if anyone can somehow obtain the ID (which might be quite easy to do) one can decrypt the file.

For CFB-Mode the IV must indeed be unpredictable (but need not be secret), so random is just fine, but DO NOT REUSE AN IV.

Encryption large amounts of data with the same key and different IVs is just fine and no problem at all.

However, I want to propose some improvements for the security level.

  1. Don't use CFB-Mode but EAX/CCM/GCM-Mode, as they are authenticated and hence you've authentication "for free" without any further worries.
  2. As replacement for the Hardware-ID based Key I'd suggest either storing the key (plain - not recommended) on the USB-Stick, or only use a password (+ scrypt) or store the key encrypted (AES-GCM+scrypt) on a stick.
  3. You might want to consider generating a key for each file you encrypt and storing this key (+IV) as a "header" for the encrypted file. The header would be decrypted using the secret key (from USB / from password / from USB+password)
SEJPM
  • 46,697
  • 9
  • 103
  • 214