基本高性能数据真实性答案

【问题标题】：Basic high performance data authenticity基本高性能数据真实性
【发布时间】：2012-04-02 16:23:04
【问题描述】：

（我不是母语人士，在术语方面可能不正确。对此感到抱歉。）

我正在通过无线电在 AVR 微控制器之间传输数据以供个人使用，并希望客户证明传输数据的真实性，因为它来自授权客户之一。这意味着我不需要不可否认性，并且能够预定义共享密钥。我对不同的方法进行了一些研究，发现我需要一些帮助来选择最符合我要求的方法。

请理解，我不需要最高安全性。我只是想防止潜在的脚本小孩邻居在几个小时内闯入。如果从今天开始使用普通消费者装备需要几周的时间，我会没事的。

我发送的消息非常小（不超过 30 个字节，负载只有几个字节），频率不超过 30 条消息/分钟。

一个用例是运动检测器通过无线方式向处理单元发送消息，然后处理单元通过无线方式向电灯开关发送另一条消息。请不要专注于运输。这个问题只针对数据真实性。

我在闪存和 RAM 非常有限的 20 MHz AVR 微控制器上运行客户端/服务器软件（C 语言）。因此，我正在寻找一种代码大小和 RAM 利用率小，同时仍提供高数据速率的解决方案。

我使用 MD5 实现 (C) 从 20 字节数据创建散列进行了一些性能测试，发现它可能太慢了。我知道 MD5 实现本身并不能解决这个要求。我进行测试只是为了评估哈希性能。

感谢cmets

【问题讨论】：

我正在考虑使用 HMAC，但不确定使用什么哈希函数。
您是否对任何客户端也能够创建有效消息感到满意，或者您是否需要客户端能够验证消息但不创建它们？
@Nick：感谢您的评论。你指的是不可否认性吗？我不需要它（如问题中所述）。
不，我问的是是否也可以允许验证者创建有效消息，或者他们是否应该只能进行验证。如果验证者能够发布消息是可以的，那么 HMAC 就可以正常工作。如果没有，您将需要公钥加密。
@Nick：我明白这就是不可否认性 (http://en.wikipedia.org/wiki/Non-repudiation#Non-repudiation_in_digital_security

【解决方案1】：

我会使用 128 位 AES 对消息进行签名。这是一个已经为 AVR 实现此功能的优秀资源，其中包含大小和周期计数的完整文档，包括权衡大小/速度的不同版本。 http://avrcryptolib.das-labor.org/trac/wiki/AES

【讨论】：

感谢您的评论。您能解释一下如何使用 AES 对消息进行签名（签名可能不是最好的术语。签名需要不对称加密）？您将如何使用您提到的实现来创建 MAC？
@Netzoss，你是对的。我的意思是使用 AES 生成 MAC。发送方使用密钥计算 MAC 并将其附加到有效负载。接收方使用密钥计算 MAC 并与收到的内容进行比较。您还需要添加一个增加的随机数/序列号以防止重放攻击。这是 AES MAC cr.yp.to/mac.html 的示例
如果不需要，请不要使用非标准化密码术。我会认真建议您改用 AESCMAC。找到参考实现的机会也更好，甚至自己创建它（当然使用 AES）并针对官方 NIST 测试向量进行测试（在这种情况下是根据经验）都不会太难。见here
当然，您可能比尊敬的 Bernstein 先生的算法做得更差，但仍然 :)
似乎 AES-CCM 可以解决问题。从对身份验证部分的第一次测试开始，它似乎足够快。我将实现完整的 AES-CCM，并让您知道它是否足够好。

【解决方案2】：

如果您对妥协感到满意，请计算消息有效负载的 CRC-32 或 CRC-64，并在末尾附加一个密钥（有效负载，而不是 CRC 校验和）。两端可以使用相同的密钥执行此操作以获得相同的结果。不确定它的确切可破解性，但肯定不是零。

【讨论】：

谢谢迈克尔。我想这种方法很容易受到一些攻击，所以我不知道它是否满足在几天内无法破解的要求，提供常规消费设备。
+1 提到了这种方法，这绝对是高性能。安全性确实很低：对于 CRC-32，只有大约 40 亿个值可以进行暴力破解——在当前的 PC 硬件上，没有什么是无法在几秒钟内完成的。值得注意的是：“密钥”不必比 CRC 值长，即 32 位或 64 位，因为更长的密钥根本不会增加安全性。