For more context: we have historically required the crypto instructions because
1. We make heavy use of sha256 in blobfs, where such content-hashing is on the critical path of loading all binaries, and we believe that in the absence of hardware acceleration, product owners will likely find that their performance requirements are difficult to attain and may seek to resolve those issues by compromising core security invariants, which we do not wish to encourage
2. For protecting mutable storage, both reads and writes go through AES-XTS, either in zxcrypt or fxfs-crypt. For similar reasons, we want AES instructions to be accelerated, so that protection of user data is not something that we are motivated to compromise for performance reasons.
3. In any product, we expect to do TLS for a variety of purposes (software updates, time sync, communications with servers, etc.), and don't want poor TLS performance to be a reason that people are later motivated to avoid TLS/use weak ciphersuites/etc.
Since we do not want product owners to be motivated to disable fairly fundamental security features of the system, we have endeavored to ensure that the hardware baseline is likely to adequately support performance requirements, including through the requirement of the ARM crypto instructions on such boards.
Why wouldn't they catch this before they started work on porting this device to Fuchsia? Why isn't this a problem with the existing OS (Android? ChromeOS?)?
Perhaps they didn’t think the impact was going to be as bad as it was and it turned out it just wasn’t possible to meet their standards as they had hoped w/o requiring crypto hardware.
Or, perhaps, they simply changed their minimum security standards and had to raise requirements as a result.
Security people very often underestimate the performance impact of encryption (especially on embedded devices), so the former would not be surprising to me. Without acceleration, AES hurts and is incredibly hard to implement without opening up side-channel attacks. SHA is also very slow without acceleration. Both have simple, more modern alternatives that are a lot faster on embedded (ChaCha and Blake2 respectively).
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.
Fyi, blake3 was released in 2019 and should probably be used over blake2 unless you have some strong reason not to. It's basically a reimplementation of blake2 with performance tweaks.
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.
Blake vs. Nist is irrelevant to the performance debate, because no matter what you do, they're both going to go approximately the same speed. The debate is why hardcore 256+ bit crypto is needed at all by the operating system primitives on a simple device living in my home, when doing that goes literally 30x slower than using something like crc32 or xxhash. Not to mention that if you're pushing for hard crypto merkle tree stuff, you'd be a fool to do it without things like ecc ram too. Since cosmic rays will blow up your data structures. So you're not just making embedded go slow. You're making it less reliable too. Just to wield ironclad remote control of people's personal possessions.
Is the extra 100 bits of security on your cryptography standard what's actually going to stop them?
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.
Third parties who want to exploit the relationship between Google and its users are certainly not users. I don't think it's productive to question their intentions. The better question to be asking here is how or why we allowed our homes to become yet another front in the war between Google and its adversaries. Their business model doesn't jive with third amendment culture. I reject any world in which guests within my home have a legitimate need for their own military grade encryption. That is not the future I'm rooting for.
Someone who feels comfortable letting a tech company control a microphone in their home (and by proxy all the agencies that company is obligated by law to serve) probably isn't too concerned about the local neighborhood prankster getting in on the action too. I think the great fear they have is that someone will come along and install a daemon on that speaker which charges them rent.
> Not to mention that if you're pushing for hard crypto merkle tree stuff, you'd be a fool to do it without things like ecc ram too. Since cosmic rays will blow up your data structures. So you're not just making embedded go slow. You're making it less reliable too. Just to wield ironclad remote control of people's personal possessions.
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?
> 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.
That’s not a big deal on a multi-core 1ghz processor. Much bigger deal on a single core 200mhz microcontroller that doesn’t have branch prediction or any of those fun optimizations.
I know you're pointing at the general class of hardware performance enhancements including branch prediction, hardware prefetching, superscaler execution, pipelining, etc. But out of all of them, if you get a speedup for any advanced branch prediction beyond just always assuming branches are taken then I'd be very worried your cryptographic algorithm is broken.
This is just speculation that they didn't catch this before.
Maybe they weren't yet decided on lowering their security stance for these specific devices to one similar to the existing OS or skipping these devices. Maybe management was pushing for them to find a solution either way. We can speculate in a lot of different ways.
For more context: we have historically required the crypto instructions because
1. We make heavy use of sha256 in blobfs, where such content-hashing is on the critical path of loading all binaries, and we believe that in the absence of hardware acceleration, product owners will likely find that their performance requirements are difficult to attain and may seek to resolve those issues by compromising core security invariants, which we do not wish to encourage
2. For protecting mutable storage, both reads and writes go through AES-XTS, either in zxcrypt or fxfs-crypt. For similar reasons, we want AES instructions to be accelerated, so that protection of user data is not something that we are motivated to compromise for performance reasons.
3. In any product, we expect to do TLS for a variety of purposes (software updates, time sync, communications with servers, etc.), and don't want poor TLS performance to be a reason that people are later motivated to avoid TLS/use weak ciphersuites/etc.
Since we do not want product owners to be motivated to disable fairly fundamental security features of the system, we have endeavored to ensure that the hardware baseline is likely to adequately support performance requirements, including through the requirement of the ARM crypto instructions on such boards.
-- https://fuchsia-review.googlesource.com/c/fuchsia/+/808670?t... marking the relevant CPU as not supporting crypto instructions.