我会敦促你重新审视你的前提。如果两个端点上都有一个应用程序，那么您选择算法的标准无效：应用程序将处理加密/解密，而不是用户。在这种情况下，公钥加密可能会提供更好的安全性；例如，它可以启用首次使用时信任（类似 SSH）的密钥管理。另外，我建议您首先考虑威胁模型。第一个问题不应该是，我使用什么加密算法？您的第一个问题应该是，我要防御哪些威胁？

如果必须对 SMS 文本使用对称加密，CBC 模式下的 AES 与密文窃取是一个合理的选择。如果要加密的消息不是 16 字节的偶数倍，则密文窃取将避免浪费。你仍然需要一个 IV，它会占用一些空间。为了节省空间，您可以发送一个计数器，并将计数器的 AES 加密用作您的 IV。

如果有任何方法可以避免通过 SMS 传输密文，请避免使用它。160 个字符非常有限。您可以通过 Internet 传输消息吗？

如果您可以避免通过 SMS 进行隧道传输，您可以探索应用程序拥有自己的私钥/公钥并为每个联系人维护一个公钥的模型。联系新人时，应用程序会发送自己的公钥，从对方那里接收公钥，记住该公钥，然后发送使用该公钥加密的消息。这当然容易受到中间人攻击，但可能更容易使用。

如果您尝试使用多种品牌和型号，那根本行不通——尽管许多智能手机允许第三方软件通过互联网网关发送 SMS 消息，但除了最开放的手机操作系统之外，其他所有操作系统都不允许允许第 3 方软件处理传入的 SMS 消息。

但是，如果我们忽略不可能，128 AES 应该可以正常工作。这会给你一个不大于明文的密文；其中 8 个可以放入 140 字节的 SMS 中。使用 SMS 的字符编码，这意味着您仍然有 146 个字符的消息。

由于您指定了对称加密，我很乐意将密钥分配问题留给您！

您将需要使用 AES 或 AES+RSA 的组合。现在是 160 个字符的问题。实际上可用的有效载荷只有 140 字节。在手机中（GSM 或 CDMA）；140 个可用字节被编码为 7 位编码，因此允许将 160 个字符放入 140 个字节中。

现在既然短信是渠道，而且要加密，通讯方式就不能再是短信，而是二进制信息。对于 UDH（用户数据头），二进制消息将占用额外的 7 个字节。所以你可以操作的字符数只有 133 个。

我认为如果您使用的是短信渠道，那么您需要一个两端的APP。您可以使用基于端口的消息传递；使用它，消息将直接由最终应用程序而不是本机收件箱处理。

SMS通道的优点之一是存储转发协议，意味着对方收到消息的机会很高，问题是延迟和有效负载限制。使用应用程序级分段，您也可以发送长消息。

SMS 通道的另一个优点是，在双向通信中，将确认真正的受信方仅参与消息传递。A 可以在向 C 发送 SMS 时冒充 B；但是当 C 响应时，它总是只会去 A。因此，使用 2 路协商，您可以构建用于相互通信的密钥生成和共享算法。