Edit: Update - I am researching how to implement AES with authentication in an efficient way for this project. If you have the time I'd appreciate your skill in finding the best implementation for this FOSS project.

Could you folks review and comment on the encryption code I just posted on Codeplex? The intent is to use this as a foundation for encrypting Azure Table properties and prevent any unauthorized MSFT employee from casually browsing or editing my data. It's a working sample that should use any public private key pair on your local system. Just make sure you set permissions on your private key correctly.

For Azure Table, I want to encrypt each and every property below (including rowkey and partitionkey) using a symmetric key.

public class ContactDataModel :TableServiceEntity
    public ContactDataModel(string partitionKey, string rowKey)
        : base(partitionKey, rowKey)

    public ContactDataModel(): this(Guid.NewGuid().ToString(), String.Empty)

    public string Name { get; set; }
    public string Address { get; set; }

    // Used to rotate keys, while allowing old data to still be read
    public int EncryptionVersion {get;set;}

I intend to store the encrypted version of the symmetric key, and the nonencrypted IV on Azure Table storage. The overall design assumes that an encrypted symmetric key renders all other encrypted table data useless, even if the IV is available.

The symmetric key is encrypted with a RSA key that is securely delivered to my Azure Role instance.

Known issues:

I do know that I'm missing a seed in my symmetric encryption. How would I implement this from a Crypto perspective?

  • I'm noticing that the way the encoding/decoding was done is ugly, so I'm thinking it would be better to just use byte[] for everything and only handle base64 outside of the crypto calls.
    – Steve
    Commented May 11, 2011 at 21:50
  • Too late at night for me to dig into it right now, I'll try tomorrow... But in the meantime, if you're on .NET 4, why use RijndaelManaged, instead of AesManaged?
    – AviD
    Commented May 11, 2011 at 22:21
  • @AviD - Great point... Will revise once I find some samples to go off of. I'll Google tomorrow and will revise Commented May 11, 2011 at 22:29

1 Answer 1


I suggest you take a look at the thread on Lessons learned and misconceptions regarding encryption and cryptology. If I'm reading your code right, it looks like this code makes at least one mistake listed there. (e.g., use of encryption without authentication) Please review that page carefully to make sure you're avoiding the mistakes documented there.

More seriously, it may not be a good idea to design your own encryption format. Rather than re-inventing the wheel (insecurely), I recommend you use an existing well-vetted scheme, like GPG or PGP, for encrypting data. Most crypto libraries are intended for someone who is already very knowledgeable about crypto design; if you aren't super-knowledgeable about design of cryptographic schemes, then crypto libraries may lead you astray, because the primitives they provide are too low-level. You have to know a lot to combine those primitives properly into a fully secure scheme.

By the way, I find reading code a painful and inefficient way to review a cryptographic design. I suggest that, if you would like external review from volunteers, you should take the time to craft a specification of the encryption format, in a standard cryptographic/mathematical notation. Roughly speaking, the specification should define the format in enough detail that someone else could independently implement it an interoperable implementation, without any knowledge of C# and without any C#-specific stuff. Such a specification should specify the exact algorithms in use. For instance, it might say to encrypt a message M to the ciphertext C as C = (X, AES-CMAC(K1, X)), where X = AES-CBC(K0, M), or something like that. If you have to design your own encryption format, that's the level of abstraction which is probably most appropriate for analyzing it. But best of all is to avoid designing your own encryption format, and thereby avoid the need for such analysis.

  • Authentication for data in transport is done by use of the Azure-Table authentication keys. Data at rest is protected by Microsoft's internal access controls. The threat model is to obfuscate the data at rest, where the x509 certificate within the certificate store is the only trusted way of handling encryption. I'd be open to GPG or PGP if it worked that way... Commented May 12, 2011 at 14:35
  • 1
    That lessons learned post is great ;) You inspired me to ask another question: security.stackexchange.com/questions/3761/… Commented May 12, 2011 at 14:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .