我正在尝试是否可以使用CRC32作为固件空中更新的完整性检查机制，或者是否应该使用MD5等哈希算法？
我的情况：
该平台是STM32F091RC(512KB闪存，32KB RAM(，它没有用于MD5或其他哈希算法的硬件/外围设备。它确实提供了CRC32外围设备。固件下载将具有100KB范围内的确切已知长度，并将通过蜂窝数据网络(LTE-Cat M1和2G(进行传输。我不担心故意篡改，只担心由于噪音等原因导致的传输错误。所有传输都将使用TCP作为传输协议。据我所知，蜂窝数据包和它们封装的TCP数据包都有自己的数据包级CRC。TCP数据包是CRC16，用于不大于1500B的数据包，我相信蜂窝数据包更小，并且有自己的CRC(不确定CRC大小(。因此，已经进行了两组CRC检查，并对坏分组进行了必要的重传。
CRC32将更易于实现，并且具有更小/无占地面积。我假设MD5将提供更高级别的完整性保证(如果这是正确的术语的话！(，但要以复杂性和占地面积为代价(它也可能更慢，但这不是真正的问题，因为这些下载只是偶尔发生的(。
我读了很多文章(关于堆栈溢出和其他方面(，但在从CRC32切换到MD5或类似的哈希算法之前，我仍然不清楚应该应用什么传输大小限制？一个帖子有：
编辑：看看维基百科上关于CRC和Lott答案的页面，我们有：小于64字节：8位CRC小于16K字节：16位CRC小于512M字节：32位CRC
因此，基于以上内容，我认为CRC32会很好，但我的舒适度不高，因为这是我发现的唯一一个具有这些类型数字的作品。
对我应该做什么——CRC32或MD5/类似的哈希算法的任何观点都很感兴趣？
由于您不关心故意篡改，因此不需要MD5。还有其他比32位长的、速度快得多的非加密哈希可以使用。
你所需要弄清楚的是，你认为可以接受的假阳性概率是多少。也就是说，当事实上存在错误时，完整性检查错误地指示良好数据包的概率。取该概率的以2为底的对数的负数。你的散列中至少需要那么多比特。