CODEWITHSUNDEEP
c#aes
coffeeak
coffeeak

Reputation: 3120

AES Key Management advice

I need some advice on a school project I am working on. I am making an AES app for encrypting data in some files. Now these files can be accessed by many people.

For the AES key, I was thinking of using RFC2898DeriveBytes to get an encryption key from a passphrase. MSDN has some good tutorial on how to use it. Now, my problem is Where and how to store that key?

I wanted to store the key in a file in a flash drive, but if there are many users, then how to write the key to many flash drives at the same time? (A computer can have only a limited number of ports). Also, lets say I have a new user who should have access rights to some file, how do I write the key to his flash drive?

Upvotes: 2

Views: 960

Answers (3)

Maarten Bodewes
Maarten Bodewes

Reputation: 93948

You cannot store the key; you would have to tell the user what the key is. The RFC2898DeriveBytes is useless if you simply store the output. If you need a random key, use a well seeded random number generator instead.

Normally you would encrypt a random data key with the key that is generated from the users password. Then use the data key to encrypt the data. This way you can encrypt a file for multiple users; just encrypt the same key with those of the users (generated with the PBKDF2 function in RFC2898DeriveBytes) as you do now.

Make sure you use a different salt for each time that a user enters his/her password. It's also strongly recommended to prepend a random IV to the data file, and to use authenticated mode encryption or a (H)MAC.

Upvotes: 2

Kevin
Kevin

Reputation: 704

It really depends on the goal of your application.

  1. If the intent is to encrypt the data such that any user of your applicaiton can access it, then it is more appropriate to embed the key (or, even safer, data from which to derive the key) in the application itself.

  2. If access is to be restricted on a per user basis, then the key (or data from which to derive the key) will need to be stored on a per user basis (so that it is only available to authorized users).

A couple tips on using embedded security data:

  • break the data up into pieces that can be pulled from various places within the application. Use a custom algorithm to assemble the data.

  • it is much safer to embed data from which to derive your key than to embed the key itself. If a hacker uses a binary editor and finds your key intact in the application, it will be much easier to decrypt the files. If the same hacker finds the data from which to derive the key, he still must determine the algorithm you've used to derive the key from that data before it would be usable.

Upvotes: 3

Eric Petroelje
Eric Petroelje

Reputation: 60498

Personally I wouldn't store the key anywhere - just require them to enter the password and generate the key on-demand.

Upvotes: 0

Related Questions