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