加密小消息(BLE信标)-小熵对称

Question

我想加密蓝牙信标数据。我在想，如果明文中的熵很小，那么钥匙就更容易猜测了吗？最大数据长度为31字节。

数据的一个例子(填充结构)：在序列单调增加的情况下，所有其他测量值在读数之间都有很小的变化(假设25.00 -> 25.01 -> 25.02 -> 25.00)

const uint8_t id;
uint32_t sequence;
int16_t batteryV;
float32 measuredTemperature;
float32 internalTemperature;
float32 atm-pressure;
float32 ambient-Light;

这清楚地表明了使用AES-CTR的模式，但我不知道这是否重要。是吗？

编辑:删除无用的显示。

额外注意事项:不使用nonce，因为-所有31个字节都需要用于发送数据。CTR仅仅是因为它是一个流-绝对向其他算法思想开放。

我想问题是，有一个明确的模式。这是否会削弱加密到“为什么还要麻烦”的地步呢？

Answer 1

显然，它是使用AES-CTR与固定IV，这减少为异或与常量位串(一个看起来是随机的观察者没有键)。这个位串是恒定的，这大大削弱了加密，就在‘为什么麻烦’点旁边。举几个问题：

• 一个知道一个明文/密文对的人可以破译所有其他的密文。
• 两个明文中一个字段的相同值可以从密文中检测到。
• 字段变化缓慢(在这里，大部分)，并且可以很容易地猜出近似值，只能从密文中解密。

如果真正的sequence单调增加且从不循环或重置‡，那么有一个简单的解决方案:不要加密sequence，并将其用作AES-CTR加密的最重要的比特(将IV的低阶比特设置为某些常数，例如，全部为零)。

如果sequence可以重复，仍然有使用格式保持加密的非常安全的解决方案；我们有有关这方面的问题。我们可以用随机数据填充31字节中任何未使用的字段，用31字节分组密码加密，例如使用AES构建的6轮Feistel密码。在这种情况下，最好的对手可以做到(没有键)是认识到两个明文是完全相同的(包括随机场)。

‡啊，讨厌的电池换了！

Answer 2

根据以下问题下的评论，我的回答似乎是正确的。

由于每条水平线都是CTR加密BLE广告的一个流，而且每个CTR流(跨行)的IV/ your是固定的，所以当然会有模式给出几乎不变的读数。

忽略你不清楚的显示，考虑到输入中几乎没有熵，而且像温度这样的东西显然是可以猜测的，这在某种意义上很可能是弱的。

我想知道你的加密功能是否有问题。尝试几种不同的模式，看看模式是否仍然存在。