我正在开发一个应用程序，其中应用程序跟踪用户位置，将它们写入文件并定期将文件发送到服务器（在此示例中每小时）。然后，人们将解密并从服务器读取数据。
我正在使用带有 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 key exchange。“错误”的答案是手机生成密钥，然后将其发送到服务器，因为任何可以拦截加密文件的人也可以拦截密钥。
您应该考虑使用公钥密码术来加密发送到服务器的文件。这样，手机只需要知道服务器的公钥，不需要保密。