” If we use standard encryption algorithms, the message size will be increased tremendously to hundreds of bytes“——你的依据是什么？（以及什么是standard encryption algorithms）。

AES是一种相当标准的加密算法，它得到了例如ESP32 的支持，ESP32是一种使用非常广泛的电路板。

这个页面说

大多数对称密码处理比单个字节大得多的数据块（例如，AES-128，一次处理 16 个字节）。因此，如果文件不是块大小的倍数，则需要填充末尾以填充完整块。有一些方法（例如“密文窃取”）可以在不使加密文件大于原始文件的情况下执行此操作，但只需添加几个字节的填充通常更简单。

因此，您可能会担心消息大小 < 16 字节。

如果是这样，您必须问自己是否不能缓冲您的数据并在您有 16 个字节时发送它。

BLE 安全性的基本介绍说

BLE 克服这一问题的方法是使用 AES-CCM 密码术对正在传输的数据进行加密。

所以你可能不需要在芯片上加密，除非你正在缓冲数据（或想要双重加密）。

如果您能准确定义您发送的数据大小、频率以及时间敏感度（您可以缓冲它），这将对我们有所帮助？

如果您使用 BLE 5，则最大化 BLE 吞吐量第 3 部分：数据长度扩展 (DLE)可能会有所帮助。引用...

DLE 是添加到链路层的一项功能，它允许数据通道协议数据单元 (PDU) 有效载荷字段从默认的 27 字节增加到最多 251 字节

总之，我认为 BLE 5 可以解决您的问题。你怎么认为？

如果您为应用程序选择了正确的标准加密算法，则不必增加消息大小。您可以在 LoRaWAN 协议中检查它是如何完成的，并将相同的方法应用于您想要的任何 PHY 协议、LoRa、FSK 或任何其他类型的调制。

LoRaWAN 在 CTR 模式下使用 AES 进行加密，并且该模式不会增加任何开销（如果有效载荷为 1 个字节，则加密的有效载荷为 1 个字节）。对于身份验证，LoRaWAN 使用 CMAC 生成 4 字节签名。除了资源最有限的应用程序外，这可能是所有应用程序都可以接受的开销。所有这些密码系统都基于对称密钥。为避免常见攻击，使用长期秘密对称密钥（特定于每个设备）来生成会话密钥，这些密钥在链路两端以安全方式协商。

对于 BLE，如果您希望智能手机能够理解心率数据（该值是标准 BLE 配置文件的一部分），您别无选择，只能遵循 BLE 标准并使用协议中内置的安全性.