我们要求客户说，如果有人访问数据库，所有包含个人信息的数据都应加密，这样当他们选择呼叫时，他们就不应该以明文形式看到任何内容。现在这对于Strings来说不是什么问题，但是对于bytearrays呢？ （可能非常巨大（几百英镑））
当您进行选择呼叫时，无论如何都会出现乱码。是否有可能黑客以某种方式读取字节并获取敏感信息而不知道它所映射的对象的结构如何？
因为如果是这种情况，那么我想我们应该加密这些字节，即使它们可能非常大。 （我猜测添加加密会让它们更大）
答案 0 :(得分：2)
这似乎是一种为大量工作提供额外安全性的方法，更不用说使用加密数据调试查询的额外麻烦了！
如果目标是保护数据库中的数据，我建议整体加密数据库，并使用身份验证和访问控制来确保仅向您的程序提供数据，并且不会进行未经授权的访问。如果数据库落入坏人手中，在这个系统下，邪恶的恶棍必须弄清楚用户名/密码或用于验证合法用户获取访问权限的其他凭据。通常这意味着要么强力搜索，要么对您的代码进行逆向工程（如果凭证存储在您的程序中 - 这不是一个好主意。）
如果您逐行加密数据库中的所有数据，以便加密程序，它仍然必须由您的程序解密。通过逆向工程代码可以找到密钥。
因此，我希望您看到，加密每个返回的结果集将很难实现，但不比使用现成的解决方案（数据库文件加密和身份验证/访问控制）更安全。
编辑：我写这篇文章时考虑到了本地数据库，因为OP谈到了攻击者获取数据库的问题。另一方面，如果您使用物理上安全的远程数据库服务器，则使用传输层加密的协议，例如： HTTPS将为您提供所需的内容。中间的攻击者无法理解程序和数据库之间的数据。它也是透明的 - 您的数据访问代码根本不需要更改。
答案 1 :(得分：1)
首先，加密通常不会增加大小，除了可能加密算法的块大小的下一个倍数（例如，128位边界）。
第二，是的，如果数据保持清晰，攻击者可能很快就能理解它的相当一部分。
第三，所有这一切的大问题（与大多数密码学一样）是密钥存储和分发。在某些点，您必须解密数据，并且（通常）最简单的攻击形式是找到检索该密钥的方法。您的两个主要选择是要求用户输入密钥，或者使用某种受保护的存储（例如，智能卡）来存储密钥，并在客户端计算机上使用智能卡读卡器。
根据您使用的数据库，它可能能够为您处理大量此类数据。公平的数字具有某种行级甚至列级加密，以帮助符合隐私要求（例如美国的萨班斯 - 奥克斯利法案）。