我需要使用AES-对称-字符串加密，然后与客户端共享加密的字符串。
他们知道密钥(我们已经通过电话进行了沟通(，他们应该能够破译加密的字符串。
然而，我发现的Java实现都需要与加密文档一起共享salt(或IV(。如果我每次都要发送salt，这就违背了只共享密文和对称密钥(在手头(的目的。
我是不是理解错了什么？有没有办法只共享密文和对称密钥？
加密中IV的目的是随机化。如果你使用ECB操作模式，它可能会泄露在同一密钥下加密的密文信息。看看著名的企鹅在维基百科的运作模式。
E(k,m) = E(k,m') iff m=m'
现代操作模式使用IV，作为TLS 1.3密码套件中的AES-GCM。
你应该把危险告诉大公司。我确信他们很容易适应你的情况。
注意：ECB模式只能是安全的，如果
- 您的数据总是不同的(没有模式(
- 您使用Diffie-Hellman密钥交换的密钥协议为每个加密生成一个新密钥，但情况并非如此
通常通过将IV附加到密文来共享IV。因此，最终您将发送一个Base64编码的字符串。
因此，如果您担心发送两个字段(一个IV和一个密文(而不是只发送一个字段会违反合同，请允许我向您保证，您只发送单个字段。解密逻辑知道如何从接收到的字符串中提取IV并在解密过程中使用它。
请注意，IV和密钥之间有一些关键区别：
- 密钥是秘密，IV不是
- 许多消息可以用相同的密钥加密，但IV对每个新消息都不同。密钥和IV的组合对于每条消息都必须是唯一的，IV也必须是随机的
因此，您不会以与密钥相同的方式共享IV。由于IV对每条消息都会更改，因此它实际上会附加密文以形成一个字符串，然后作为加密输出发送。因此，解密逻辑只将密钥和加密输出作为输入；它知道如何从加密输出中提取IV和密文。
在今天，如果有人需要使用AES加密某些东西，通常的选择是像GCM这样的经过身份验证的加密模式，它不仅提供了机密性，而且以安全的方式提供了完整性。
除非接收方(在您的情况下(严格指定AES的特定模式，否则默认选择将始终是带有GCM的AES。即使收件人提出的某种模式不是经过身份验证的加密模式，您也可以考虑向他们解释使用经过身份验证加密模式的好处。
您将在这里找到一个完整的java实现和详细的解释。
你可能还想把这篇文章和评论一起读，以便更好地理解它。