5
$\begingroup$

I'm implementing (for learning purposes) a file encryptor, which uses the following method (from http://en.wikipedia.org/wiki/Encrypting_File_System). I have 3 kind of keys: RSA public/private, AES and a user key derived from a phrase.

  • encrypt the file with AES (I use OFB mode).
  • encrypt the AES key with RSA.
  • write the encrypted AES key to the file header
  • generate a user key
  • with the user key I encrypt the RSA private key and the IV too, then place them to a database file.
  • I also hash the original AES key and store it in the database

A database file structure looks like this:

size_t fileID;
byte rsaPrivateEncrypted[RSA_KEY_LEN];
byte aesIVEncrypted[AES_BLOCK_LEN];
byte aesKeyHash[HASH_LEN];

The key hash is used to validate the key, before decrypting the file check if the hashes are the same.

I've just read that there is still no implementation of a key wrap algorithm in Crypto++ library, so I use the method:

  • hash a user defined string (phrase) with MD5 (128 bit) - this will be the KEK
  • hash the hash again with MD5, this is the IV for KEK
  • encrypt the RSA private key and AES IV with them using AES

I've chosen MD5 because of its length fits AES' key/block size. (I know I could use the first n-bit of a longer hash too). I assume this way is pretty insecure, since I've read that there are special algorithm for this purpose (AESKW). What are the main drawbacks of this implementation? How can I make the key wrap/generation method more secure?

Also, in the wiki article, there is one more key:

  • FEK - KEK(RSA) - DPAPI - USER (hashed from PW).

What's the purpose of this key? As far as I understand, it is only used for decrypt the KEK. But the USER key could do this, since it is as secure as the USER key, no?

$\endgroup$
  • 1
    $\begingroup$ DPAPI has several purposes in Windows besides encrypting the RSA private key (to encrypt other secrets like WiFi passwords, and IE account passwords etc.); moreover the hash from the password is used only after thousands of iterations (and a random salt) provided by the DPAPI API. This slows down direct cracking attacks on the encrypted secret key, if the NTHash is not available, e.g. $\endgroup$ – Henno Brandsma Mar 1 '14 at 19:17
  • 1
    $\begingroup$ And, as an afterthought, DPAPI has a mechanism to avoid re-encryption of secrets (like RSA private keys) protected by it, when a user changes its password. This is an added benefit. $\endgroup$ – Henno Brandsma Mar 2 '14 at 15:25

Your Answer

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

Browse other questions tagged or ask your own question.