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