微控制器上的 Ascii 字符串加密答案

【问题标题】：Ascii String Encryption on Microcontroller微控制器上的 Ascii 字符串加密
【发布时间】：2013-08-21 21:29:21
【问题描述】：

我一直在尝试在 IAR IDE 中用 C 语言在 Cortex M3 微控制器上实现 XTEA 加密，到目前为止，加密解密正在工作，但我面临一个问题，我必须编码 Ascii 字符串，但加密字符串有时在字符串数组中包含一个 0x00，不是作为空终止符，而是在中间某处，所以字符串函数不由于这个额外的 0x00 他们假设它的 Null Terminator 得到正确的字符串长度，问题是我必须通过 GPRS 传输这个字符串，并且后端也使用相同类型的 ASCII 字符串，只在最后期望 0x00，在固件中也是字符串传输的其余部分假设它是空终止，有没有办法用其他值替换加密字符串中的这个 0x00，以某种方式它也可以稍后在后端轻松复制，假设我将 0x01 添加到每个加密字符串数组，这可能会使一个 0xff 变为 0x00 ，有没有办法去掉这个 0x00 ，

或任何其他简单的 Ascii 字符串加密算法，可在微控制器上轻松实现，保证加密字符串中的非零值，后端人员坚持在系统中使用一些算法，AES 算法是否确保非零值？

【问题讨论】：

AES 和其他加密算法具有随机输出，因此 0x00 字节可能与任何其他字节一样。
停止将您的加密数据视为文本字符串 - 不是，您应该将其视为字节数组（长度前缀而不是空分隔）。
@NickJohnson 所说的是这个问题的真正答案。如果您相信您的加密数据是 ASCII，那么您将遇到严重的问题。

标签： c algorithm encryption embedded logic

【解决方案1】：

与其发明新的编码方案，不如考虑使用existing 编码方案。（您的文档会更容易。）

如果您的数据是ASCII，那么您只能使用 0 到 0x7F 的代码。 Base64 是最好的选择。

【讨论】：

我相信只有 0x00 字节存在问题，因此转义它会比 base64 更有效（假设字节 0x00 与其他字节具有相同的概率）。
@Maciej S OP 说“后端也使用相同类型的 ASCII 字符串，期望 0x00”。 ASCII 字符串仅使用代码 0-127。 OP 正在通过 XTEA 加密，其输出 unint32_t 可能转换为 0-255 的 4 字节组。因此，要么 OP 需要 ASCII 通信解决方案，要么 OP 误用“ASCII”。如果 OP 误用了“ASCII”，就会发出危险信号，我怀疑还有其他未说明的通信问题。归根结底，推荐行业标准是解决 OPs 问题的更好选择，无论是否明确。

【解决方案2】：

如果您不介意字符串增长一点，您可以在编码期间将 0x00 字节替换为 0x01 0x01 并将 0x01 字节替换为 0x01 0x02。

然后，您可以在解码期间将 0x01 0x01 替换为 0x00 并将 0x01 0x02 替换为 0x01。

例如：

0x04 0x00 0x05 0x01 在传输过程中会变成 0x04 0x01 0x01 0x05 0x01 0x02。

【讨论】：

通信协议经常使用this转义。

【解决方案3】：

您始终可以使用 base64 或其他编码方法，但我认为建议的 escaping0x00 更好。

【讨论】：