0

我们的客户想给我们一个数据库。原始数据库有一个电话号码列。他不想给我们电话号码。不知何故，我不确定为什么 - 决定客户会给我们加密电话号码，并使用 128 位 AES 密钥加密。

我们会告诉客户哪个电话号码将出于某种目的而入围，但我们永远不会知道实际的电话号码是什么......我们只会知道加密的号码。

以下是我不明白的事情：

  1. 是否使用适合此目的的 128 位 AES 密钥加密？
  2. 客户端应该保留用于转换数字的 AES 密钥，还是客户端不应该保留密钥而是创建一个数据库，将原始数字与加密数字映射
  3. 应该使用相同的密钥来转换所有数字还是不同的
  4. 如果随机生成的密钥用于加密数字，两个电话号码的加密文本是否可能相同？
4

2 回答 2

5

IMO 这是错误的方法。与其对电话号码进行加密，否则您仍然有机会解密它（例如，因为有人泄露了密钥），客户端应该用一个指向带有真实电话号码的表的 ID 替换它们；当然，这个查找表留在他身边，你永远也得不到。

IE

原表：

Name   | Phone
-------+---------
Erich  | 555-4245
Max    | 1234-567

你得到：

Name   | Phone
-------+---------
Erich  | 1
Max    | 2

只有您的客户有：

ID | Phone
---+---------
1  | 555-4245
2  | 1234-567
于 2009-11-20T09:44:04.960 回答
1

按顺序解决您的疑虑：

  1. 可能是，也可能不是。实际上，您根本没有真正提到目的是什么：

    • 为什么需要加密？
    • 它受到谁的保护？
    • 数据的价值（或对您的责任，如果丢失）是什么？
    • 假设的攻击者的动机如何？
    • 对于安全性增益，什么样的性能损失是可以接受的？
    • 你有什么可用的硬件？
    • 谁对系统的各个部分有什么物理/逻辑访问权限？

    等等等等。在不了解情况的情况下，无法说这是否是一个合适的加密方案。（尽管它可能是一个可靠的选择）。

  2. 确定是客户自己决定的吗？不过，我会说，后一种情况似乎完全违背了加密的目的。
  3. 应该使用相同的密钥来转换所有数字，除非您喜欢使用各种密钥来尝试记住使用哪个密钥来解密哪些电话号码。如果安全系统设计得很好，这不会提供任何额外的安全性，只会令人头疼。
  4. 根据加密的定义，没有。它始终是一个可逆映射，这意味着不会丢失像散列一样的信息。因此，每个密文实例都有一个唯一的明文，该明文将对其进行加密（使用给定的密钥）。

虽然总而言之，这听起来不像是需要的。在我看来，有人一直在根据外表而不是技术优势做出决定——“我们用浏览器中使用的相同 128 位加密来加密你的电话号码”听起来不错，但它真的需要吗？

于 2009-11-20T09:43:18.687 回答