https://github.com/BLAKE3-team/BLAKE3
If you need a non cryptographic hash, the xxhash family is crazy fast.
With that said, if the hardware cannot what is required, and SoM chips are required, then... Maybe better hardware should be used.
This decision reeks of DJB-hating. A lot of NIST types really hate the fact that there are now first-class hashes and symmetric ciphers that perform well without crypto-specific accelerators. This makes bugdooring a lot harder. And then the same guy went and published a curve (Ed25519) whose implementation is nearly impossible to fuck up in ways that leak your secrets.
Lesson to be learned: don't piss off supergenius mathematicians.
Can you give me an example of how a bit-flip would blow up a cryptographic merkle tree, but not blow up a non-cryptographic file system?
Any bit changes anywhere in the merkle tree immediately destroy its ability to self-verify because the integrity is ruined. Basically the entire tree is dead because you can't add new nodes.
Non-cryptographic file systems? A bit-flip changes 1-bit in an isolated place. That one place is ruined but can be easily recovered with checksums or strategies like RAID parity. Detection is harder, though.
Either can be recovered at the block level, though.
I use merkel trees as a solution for a project at work and it has brittleness issues related to data integrity and we have to solution specifically around it.
A bitflip in an error handling path of a binary, where that error never happens - no user impact.
A bitflip in a bitmap image buffer - user doesn't notice one miscoloured pixel for 1 frame in an animation.
A bitflip in a config datastructure changing 0x00000001 to 0x00400001 - no impact because the whole number is treated as boolean anyway.
if (launch) {
do_launch();
}
else {
printf("this is just a test...\n");
}A device with a microphone and network connection? You don't think people would be excited to hack that?
In reality, most hacks are stopped by stupid stuff, like closing down ports and proper key management hygiene, not by using completely-brute-force-proof encryption standards. I'll make you a deal: do everything else on that compute-limited embedded device to a practically-uncrackable standard, then you can upgrade to 256 bit crypto. Some devices get there, but no consumer electronics.
Encrypting the filesystem on that specific device is also completely irrelevant to my security as a user - it has more to do with Google protecting itself from copies and users being able to add features.
Of course, they are also often unwilling to compromise on their chosen security practices to adapt to the situation, even if that just means switching to lightweight/embedded-friendly cryptography algorithms with similar security levels.