基于Azure表安全的C#密码技术的同行评测

Question

编辑:更新-我正在研究如何在这个项目中以有效的方式使用身份验证来实现AES。如果你有时间，我会感谢你的技能，为这个自由和开放源码软件项目找到最佳的实现。

您能回顾一下Codeplex上的我刚发的加密代码并发表评论吗？其目的是将其用作加密Azure表属性的基础，并防止任何未经授权的MSFT员工随意浏览或编辑我的数据。这是一个工作样例，应该在本地系统上使用任何公共私钥对。只需确保正确设置私钥的权限即可。

对于Azure表，我希望使用对称密钥加密下面的每个属性(包括行密钥和分区密钥)。

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;}
}

我打算在Azure表存储中存储对称密钥的加密版本和未加密的IV。总体设计假设，即使IV可用，加密的对称密钥也会使所有其他加密表数据变得无用。

对称密钥使用安全地传递到我的Azure角色实例密钥加密。

已知问题：

我知道我在对称加密中丢失了一个种子。我将如何从密码的角度来实现这一点？

Answer 1

我建议你看看关于加密和密码学的经验教训和误解上的帖子。如果我正确地阅读了您的代码，看起来这段代码至少犯了一个错误。(例如，在没有认证的情况下使用加密)请仔细检查该页面，以确保您正在避免那里记录的错误。

更严重的是，设计自己的加密格式可能不是个好主意。与其重新发明轮子(不安全)，我建议您使用现有的经过良好审查的方案，如GPG或PGP，用于加密数据。大多数密码库都是为那些已经对密码设计非常了解的人准备的；如果你对密码方案的设计不太了解，那么密码库可能会导致你误入歧途，因为它们提供的原语太低了。要正确地将这些原语组合成一个完全安全的方案，您必须了解很多知识。

顺便说一句，我发现阅读代码是一种痛苦和低效的方法来检查密码设计。我建议，如果您希望志愿者进行外部审查，您应该花时间用标准的加密/数学表示法来编写加密格式的规范。粗略地说，规范应该定义足够详细的格式，使其他人可以独立地实现它--一个可互操作的实现，而不需要任何C#知识，也不需要任何特定于C的东西。这样的规范应该指定使用中的精确算法。例如，它可能会说将消息M加密到密文C为C= (X，AES-CMAC(K1，X))，其中X= AES-CBC(K0，M)，或类似的内容。如果您必须设计自己的加密格式，那么这就是最适合分析它的抽象级别。但最重要的是避免设计自己的加密格式，从而避免需要进行这样的分析。