0

我一直在对创建用于 .NET 应用程序的加密/解密类进行一些研究。我一次又一次地读到除了密码之外还需要一个盐。今天我遇到了一种只使用一个密码的加密/解密方法。此代码使用的加密方法是否有问题，因为它似乎没有使用盐？

Public Shared Function EncryptString(ByRef input As String, ByRef password As String) As String
  Dim RijndaelManagedObject As New RijndaelManaged
  Dim crypto As ICryptoTransform, MD5Obj As New MD5CryptoServiceProvider
  Dim EncryptedBytes As Byte()
  Dim HashedBytes As Byte() = New ASCIIEncoding().GetBytes(password)
  Dim PlainTextBytes As Byte() = New ASCIIEncoding().GetBytes(input)

  RijndaelManagedObject.BlockSize = 128
  RijndaelManagedObject.KeySize = 128
  RijndaelManagedObject.Mode = CipherMode.ECB
  RijndaelManagedObject.Padding = PaddingMode.Zeros
  RijndaelManagedObject.Key = MD5Obj.ComputeHash(HashedBytes)
  crypto = RijndaelManagedObject.CreateEncryptor()
  EncryptedBytes = crypto.TransformFinalBlock(PlainTextBytes, 0, PlainTextBytes.Length)

  If EncryptedBytes.Length > 0 Then
    Return Convert.ToBase64String(EncryptedBytes)
  Else
    Return String.Empty()
  End If
End Function
4

2 回答 2

3

这段代码有很多缺陷：

  1. 如果input或password不是 ASCII，则会发生无声降级。特别是非 asciiinput将无法正确解密。
  2. 你不使用很多迭代，这意味着如果真的很快就会暴力破解。
  3. 与密码散列相比，这里的盐缺乏更难解释，因为散列不是直接知道的。但是，如果您使用已知的开始块（这在许多文件头中很常见）加密文件，那么可以为这种格式构建一个彩虹表。但是，如果您只是尝试破解单个文件/哈希，那么彩虹表不会为您带来任何好处。只有当您需要破解以相同方式使用的许多不同密码时，它们才会受益。
  4. 不推荐使用 ECB 模式，因为它单独加密每个块。这使得 3) 的问题变得更糟，因为您只需要知道任何块的明文即可构建表。特别是最后一个块通常具有低熵。我希望每 16 组数据中只有 8 位熵。哎哟。
  5. 我不确定它是如何PaddingMode.Zeros工作的。但是可能无法去除填充，因为它的长度没有被编码。所以解密后你可能会有一些额外的 0 字节。

电子密码本 (ECB) 模式单独加密每个块。任何相同且在同一消息中的纯文本块，或者在使用相同密钥加密的不同消息中的任何纯文本块，都将被转换为相同的密文块。重要提示：不推荐使用此模式，因为它为多种安全漏洞打开了大门。如果要加密的明文包含大量重复，则密文一次破一个块是可行的。也可以使用块分析来确定加密密钥。此外，活跃的对手可以在不检测的情况下替换和交换单个块，这允许在不检测的情况下将块保存并插入到其他点的流中。

于 2011-04-12T21:45:16.620 回答
2

不，这没有什么问题。

加盐密码是为了在存储这些散列密码时防止彩虹表攻击。在这种情况下，密码被用于生成加密/解密密钥并且没有被存储。

于 2011-04-12T21:44:21.233 回答