如何保障小数据的数据安全？
How Do You Ensure Data Security of Small Data?
我的问题：
确保小数据数据安全的最佳方法是什么？下面我提出了一个关于对称和非对称加密的问题。我很好奇是否有一种方法可以对小数据进行非对称加密，相当于某种 "salting" 以真正确保安全？如果是这样，您如何选择 "salt" 并正确实施？ 或者有更好的方法来处理这个问题吗？
我的担忧的解释：
在加密具有 "bulk" 的内容时，在我看来，非对称加密方法非常安全。我担心的是我是否有一小部分数据，比如数据库中的信用卡号、密码或社会保险号。然后被加密的数据是固定长度和表示的。也就是说，黑客可以尝试使用 public 密钥加密每个可能的社会安全号码（10^9 排列）并将其与存储在数据库中的值进行比较。一旦找到匹配项，他们就会知道真实数字。可以对其他数据类型进行类似的攻击。因此，我决定避免对称方法，例如 mysql 的 AES_ENCRYPT() 内置函数，但现在我也在质疑非对称方法。
我们如何正确保护小数据？
加盐通常用于哈希算法，但我需要能够在之后取回数据。我想也许有一些 "base bulk text"，然后将敏感数据附加到末尾。对该连接进行加密。解密将通过解密然后剥离 "base bulk text" 来反转过程。如果黑客可以找出基本的批量文本，那么我看不出这将如何增加任何额外的安全性。
选择其他数据作为加密的一部分，以帮助充当从数据库中其他字段派生的盐值（或这些字段的散列值，或它们的组合会产生相同的问题）也似乎是这样很脆弱。由于黑客可以 运行 通过类似于上述攻击的组合来尝试执行更智能的 "brute force" 形式。话虽如此，我不确定如何正确保护小数据，我的谷歌也没有帮助我。
保证小数据安全的最佳方法是什么？
非对称加密最适用于在双方之间传输加密数据。例如，您有一个接受信用卡号并需要将它们传输到服务器进行处理的移动应用程序。您希望 public 应用程序（本质上是不安全的）能够加密数据，并且只有您应该能够在您的安全环境中对其进行解密。
存储是完全不同的事情。您不会与不安全的一方进行任何交流，您是唯一处理数据的人。如果每个人都破坏了你的存储，你不想给每个人一个解密的方法，你想让事情变得尽可能困难。使用对称算法进行存储，并包含一个唯一的初始化向量，每个加密值作为存储被破坏时的解密障碍。
PCI-DSS 要求您使用强密码术，其定义如下。
At the time of publication, examples of industry-tested and accepted standards and algorithms for minimum encryption strength include AES (128 bits and higher), TDES (minimum triple-lengthkeys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher). See NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.
除此之外，他们主要关注密钥管理，这是有充分理由的。破坏您的存储空间并没有真正有办法解密您的数据那么有用，因此请确保您的对称密钥得到正确管理并符合他们的要求。
我在加密短信的时候，在加密前加了一个比较长的随机盐。 编辑其他人建议将盐添加到有效负载。
因此，例如，如果我对假信用卡号码进行加密 4242 4242 4242 4242。我实际加密的是
tOH_AN2oi4MkLC3lmxxRWaNqh6--m42424242424242424
第一次，
iQe5xOZPIMjVWfrDDip244ZGhCy2U142424242424242424
第二次，以此类推
这种随机加盐会严重阻碍您描述的查找 table 方法。许多操作系统提供高质量随机数源，例如 *nix /dev/rand 和 Windows' RNGCryptoServiceProvider 模块。
没有纵深防御和PCI数据安全认证，这样持有支付卡数据还是不行的。
编辑：一些加密方案将这种加盐处理作为其正常功能的一部分。
如果您使用 RSA public 密钥加密，则无需对小数据进行加盐。使用 OAEP 填充。填充引入了等效的随机盐。尝试一下：使用相同的 RSA public 密钥对信用卡号进行两次加密，使用 OAEP 填充，然后查看结果。您将看到两个不同的值，与随机数据无法区分。
如果您使用 AES 对称密钥进行加密，则可以为每个数据使用一个随机 IV，并将 IV 明文存储，publicly，紧挨着密文。尝试使用 AES CBC 模式对信用号进行两次加密，例如，每次使用唯一的 16 字节（加密强度高）IV。你会看到两个不同的密文。现在，假设一个 16 字节的 AES 密钥，尝试暴力破解这两个输出，而不使用任何密钥知识。仅使用密文和 16 字节 IV，并尝试发现信用卡号。
编辑：这超出了问题的范围，但由于我在评论中提到它，如果客户端可以向您发送任意密文来解密（"decrypt this credit card info"），您不能让客户端看到任何解密时的填充错误与解密时的任何其他错误之间的区别。查找 "padding oracle".
如果您需要使用对称密钥算法对数据进行加密，AES 是一个不错的选择。使用诸如CBC和随机IV之类的模式，这将确保加密相同的数据会产生不同的输出。
添加 PKCS#7 née PKCS#5 用于填充。
如果数据中存在真正的价值，请聘请加密领域专家来帮助设计和后期验证。
还有一个名为 Format-preserving encryption 的研究领域，旨在帮助遗留系统维护 column-width 和数据类型（即使经过加密，社会安全号码也是 9 位数字等） ，同时允许对值进行安全加密。通过这种方式，可以在遗留系统的低级别创建加密，而不会破坏它上面依赖于特定数据格式的所有层。
它有时被称为“small-space 加密”，论文 How to Encipher Messages on a Small Domain 也解释了这个想法
Deterministic Encryption and the Thorp Shuffle 介绍了主题并介绍了作者设计的特定算法。维基百科文章提到了许多其他具有类似目的的算法。
如果您更喜欢有关该主题的视频说明，请参阅 The Mix-and-Cut Shuffle: Small Domain Encryption Secure Against N Queries Crypto 2013 的演讲。它包括详细说明几种算法如何工作的图形以及对此类设计安全性的一些早期研究。
我的问题：
确保小数据数据安全的最佳方法是什么？下面我提出了一个关于对称和非对称加密的问题。我很好奇是否有一种方法可以对小数据进行非对称加密，相当于某种 "salting" 以真正确保安全？如果是这样，您如何选择 "salt" 并正确实施？ 或者有更好的方法来处理这个问题吗？
我的担忧的解释：
在加密具有 "bulk" 的内容时，在我看来，非对称加密方法非常安全。我担心的是我是否有一小部分数据，比如数据库中的信用卡号、密码或社会保险号。然后被加密的数据是固定长度和表示的。也就是说，黑客可以尝试使用 public 密钥加密每个可能的社会安全号码（10^9 排列）并将其与存储在数据库中的值进行比较。一旦找到匹配项，他们就会知道真实数字。可以对其他数据类型进行类似的攻击。因此，我决定避免对称方法，例如 mysql 的 AES_ENCRYPT() 内置函数，但现在我也在质疑非对称方法。
我们如何正确保护小数据？
加盐通常用于哈希算法，但我需要能够在之后取回数据。我想也许有一些 "base bulk text"，然后将敏感数据附加到末尾。对该连接进行加密。解密将通过解密然后剥离 "base bulk text" 来反转过程。如果黑客可以找出基本的批量文本，那么我看不出这将如何增加任何额外的安全性。
选择其他数据作为加密的一部分，以帮助充当从数据库中其他字段派生的盐值（或这些字段的散列值，或它们的组合会产生相同的问题）也似乎是这样很脆弱。由于黑客可以 运行 通过类似于上述攻击的组合来尝试执行更智能的 "brute force" 形式。话虽如此，我不确定如何正确保护小数据，我的谷歌也没有帮助我。
保证小数据安全的最佳方法是什么？
非对称加密最适用于在双方之间传输加密数据。例如，您有一个接受信用卡号并需要将它们传输到服务器进行处理的移动应用程序。您希望 public 应用程序（本质上是不安全的）能够加密数据，并且只有您应该能够在您的安全环境中对其进行解密。
存储是完全不同的事情。您不会与不安全的一方进行任何交流，您是唯一处理数据的人。如果每个人都破坏了你的存储，你不想给每个人一个解密的方法，你想让事情变得尽可能困难。使用对称算法进行存储，并包含一个唯一的初始化向量，每个加密值作为存储被破坏时的解密障碍。
PCI-DSS 要求您使用强密码术，其定义如下。
At the time of publication, examples of industry-tested and accepted standards and algorithms for minimum encryption strength include AES (128 bits and higher), TDES (minimum triple-lengthkeys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher). See NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.
除此之外，他们主要关注密钥管理，这是有充分理由的。破坏您的存储空间并没有真正有办法解密您的数据那么有用，因此请确保您的对称密钥得到正确管理并符合他们的要求。
我在加密短信的时候，在加密前加了一个比较长的随机盐。 编辑其他人建议将盐添加到有效负载。
因此，例如，如果我对假信用卡号码进行加密 4242 4242 4242 4242。我实际加密的是
tOH_AN2oi4MkLC3lmxxRWaNqh6--m42424242424242424
第一次，
iQe5xOZPIMjVWfrDDip244ZGhCy2U142424242424242424
第二次，以此类推
这种随机加盐会严重阻碍您描述的查找 table 方法。许多操作系统提供高质量随机数源，例如 *nix /dev/rand 和 Windows' RNGCryptoServiceProvider 模块。
没有纵深防御和PCI数据安全认证，这样持有支付卡数据还是不行的。
编辑：一些加密方案将这种加盐处理作为其正常功能的一部分。
如果您使用 RSA public 密钥加密，则无需对小数据进行加盐。使用 OAEP 填充。填充引入了等效的随机盐。尝试一下：使用相同的 RSA public 密钥对信用卡号进行两次加密，使用 OAEP 填充，然后查看结果。您将看到两个不同的值，与随机数据无法区分。
如果您使用 AES 对称密钥进行加密，则可以为每个数据使用一个随机 IV，并将 IV 明文存储，publicly，紧挨着密文。尝试使用 AES CBC 模式对信用号进行两次加密，例如，每次使用唯一的 16 字节（加密强度高）IV。你会看到两个不同的密文。现在，假设一个 16 字节的 AES 密钥，尝试暴力破解这两个输出，而不使用任何密钥知识。仅使用密文和 16 字节 IV，并尝试发现信用卡号。
编辑：这超出了问题的范围，但由于我在评论中提到它，如果客户端可以向您发送任意密文来解密（"decrypt this credit card info"），您不能让客户端看到任何解密时的填充错误与解密时的任何其他错误之间的区别。查找 "padding oracle".
如果您需要使用对称密钥算法对数据进行加密，AES 是一个不错的选择。使用诸如CBC和随机IV之类的模式，这将确保加密相同的数据会产生不同的输出。
添加 PKCS#7 née PKCS#5 用于填充。
如果数据中存在真正的价值，请聘请加密领域专家来帮助设计和后期验证。
还有一个名为 Format-preserving encryption 的研究领域，旨在帮助遗留系统维护 column-width 和数据类型（即使经过加密，社会安全号码也是 9 位数字等） ，同时允许对值进行安全加密。通过这种方式，可以在遗留系统的低级别创建加密，而不会破坏它上面依赖于特定数据格式的所有层。
它有时被称为“small-space 加密”，论文 How to Encipher Messages on a Small Domain 也解释了这个想法 Deterministic Encryption and the Thorp Shuffle 介绍了主题并介绍了作者设计的特定算法。维基百科文章提到了许多其他具有类似目的的算法。
如果您更喜欢有关该主题的视频说明，请参阅 The Mix-and-Cut Shuffle: Small Domain Encryption Secure Against N Queries Crypto 2013 的演讲。它包括详细说明几种算法如何工作的图形以及对此类设计安全性的一些早期研究。