我正在开发一个应用程序，其中应用程序跟踪用户位置，将它们写入文件并定期将文件发送到服务器（在此示例中每小时）。然后，人们将解密并从服务器读取数据。
我正在使用带有 PBE 的 AES (first answer in this question)
但是，由于很多手机都会使用它，并且将为每个手机和每个文件发送操作生成新的 IVs。对我来说，将每个 IV 发送到服务器并将它们与服务器中的相应文件相关联似乎有点过头了。
我可以使用 不带 IV 的 AES，比如只使用密码吗？这是否违反 AES 的逻辑？ 我在密码学方面没有经验，你能告诉我一个克服“大量文件加密和解密”的方法吗？
提前致谢。
【问题讨论】：
标签： java android encryption cryptography aes
您需要问自己“我在保护自己免受什么伤害？”然后围绕它制定安全策略。我认为您使用了错误的工具来完成这项工作，并且不应该使用任何您不了解如何设置的加密，因为您可能会在此过程中造成重大安全漏洞。
以下是我能想到的几种情况，您想保护什么以及如何解决。
防止有人在数据传输到您的服务器时捕获数据并获取数据副本：
如果您只需要保护手机和服务器之间的信息，只需在您和服务器之间使用 SSL 连接。它很容易设置，很难搞砸。
保护服务器上的个人数据，以便在数据从服务器被盗时无法访问：。
为此，您需要加密服务器上的数据，因为它是“静止的”。最好的方法是使用对称密钥算法，因此它具有快速加密和解密，该算法的密钥应该通过只有客户端来保护（但如果客户端丢失了他们的密钥客户端，则无法恢复他们的数据，只有生成数据的设备才能解密它，所以没有“Web界面”。或者你必须以一种方式保护密钥，使数据库丢失不会允许攻击者解密数据（如@987654321 @)
保护手机上缓存的数据，这样如果有人拥有手机的 root 访问权限，他们就无法解密应用记录的过去数据：
为此，您只需使用对称密钥加密数据，然后使用应用程序的公钥加密对称密钥，然后删除应用程序上的对称密钥副本。使用这种方法，一旦删除了对称密钥，应用程序的用户就无法取回数据，因为唯一可以恢复对称密钥的人是您，您可以使用您的私钥解密数据的对称密钥.请注意，如果有人在应用程序运行时对其进行监控（无法阻止），这不会保护您，这只会保护在监控开始之前记录的数据。
我希望这对您有所帮助，并让您制作更安全的程序。
免责声明：当我说“无法解密”时，我的意思是如果不对密钥使用暴力攻击并尝试每个密钥，就无法解密。
【讨论】：
如果您在ECB mode 中加密，您可以使用没有 IV 的 AES，但这不是一个好主意。在 ECB 模式下，相同的明文总是加密成相同的密文，因此明文中的模式可以“显示”为密文中可识别的模式。不鼓励使用 ECB 模式。
为了避免ECB模式的问题，密码可以将明文的每个块与前一个块的加密结果组合在一起，即CBC mode。这可以防止明文中的模式在密文中被识别，因为相同的明文会根据它在流中的位置产生不同的密文。但是如果你将每个块与它之前的块组合在一起，你将 first 块与什么组合？这就是 IV 的用途。
将 IV 与密文一起发送并不是什么大问题。它很小，对于 AES 来说只有 16 个字节——传输几乎不会“过度杀伤”。将其视为加密文件的一部分。
不过，您的问题提出了一个与密钥管理相关的问题。 AES 是symmetric cipher，这意味着解密数据的人需要拥有与手机加密数据相同的密钥。如果您有很多手机都将 AES 加密数据发送到服务器，那么您必须跟踪很多不同的密钥。
（我假设每部手机使用不同的密钥，否则您将没有安全性。如果所有手机都使用相同的密钥进行加密，那么任何拥有您的应用程序的人都可以提取该密钥并使用它来解密来自其他人的数据人的电话。）
如果您使用TLS 向服务器发送数据，它会负责为每个连接生成一个临时加密密钥，并自动加密手机上的数据并在服务器上解密。您根本不必直接处理 AES。
但由于您是“手动”实施加密，您还必须手动实施密钥管理。服务器如何知道手机的密钥？ “正确”的答案是使用Diffie-Hellman key exchange。 “错误”的答案是手机生成密钥，然后将其发送到服务器，因为任何可以拦截加密文件的人也可以拦截密钥。
您应该考虑使用public-key cryptography 来加密发送到服务器的文件。这样，手机只需要知道服务器的公钥，不需要保密。
【讨论】：
没有。将随机生成的 IV 与有效负载一起发送。由于可预测的 IV，有一个 flaw discovered in TLS。不要犯同样的错误。
作为进一步的解释，发送两条具有相同密钥和相同IV的消息违反了semantic security的原则。每条消息都应该有一个唯一的 IV，它永远不会与密钥结合使用。
【讨论】：