3 ms·

Security people very often underestimate the performance impact of encryption (especially on embedded devices), so the former would not be surprising to me. Wit

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.

mobilio 3y ago
Even Raspberry Pi (all of them!) doesn't have AES accelerated instructions.
- civilitty 3y ago
  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.
  - Symmetry 3y ago
    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.
eyegor 3y ago
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. https://github.com/BLAKE3-team/BLAKE3 https://github.com/BLAKE3-team/BLAKE3 If you need a non cryptographic hash, the xxhash family is crazy fast. https://github.com/Cyan4973/xxHash https://github.com/Cyan4973/xxHash
- im3w1l 3y ago
  What about "my library of choice doesn't support blake3 yet"? Is the improvement large enough to go out of your way to upgrade?
  - pclmulqdq 3y ago
    It's Google. Their library of choice supports whatever the hell they want.
    - im3w1l 3y ago
      I meant for other people
- necrophcodr 3y ago
  That reason could well be that the hardware doesn't support it, or that it is too slow. With that said, if the hardware cannot what is required, and SoM chips are required, then... Maybe better hardware should be used.
KirillPanov 3y ago
Cannot upvote enough. 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.
- jart 3y ago
  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.
  - petertodd 3y ago
    > 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?
    - deleted 3y ago
      [deleted]
    - pravus 3y ago
      > 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.
cumshitpiss 3y ago
[dead]

mobilio 3y ago

Even Raspberry Pi (all of them!) doesn't have AES accelerated instructions.

civilitty 3y ago
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.
- Symmetry 3y ago
  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.

eyegor 3y ago

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. https://github.com/BLAKE3-team/BLAKE3 https://github.com/BLAKE3-team/BLAKE3 If you need a non cryptographic hash, the xxhash family is crazy fast. https://github.com/Cyan4973/xxHash https://github.com/Cyan4973/xxHash

im3w1l 3y ago
What about "my library of choice doesn't support blake3 yet"? Is the improvement large enough to go out of your way to upgrade?
- pclmulqdq 3y ago
  It's Google. Their library of choice supports whatever the hell they want.
  - im3w1l 3y ago
    I meant for other people
necrophcodr 3y ago
That reason could well be that the hardware doesn't support it, or that it is too slow. With that said, if the hardware cannot what is required, and SoM chips are required, then... Maybe better hardware should be used.

KirillPanov 3y ago

Cannot upvote enough. 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.

jart 3y ago
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.
- petertodd 3y ago
  > 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?
  - deleted 3y ago
    [deleted]
  - pravus 3y ago
    > 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.

cumshitpiss 3y ago

[dead]