3 ms·

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

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.
  - londons_explore 3y ago
    Turns out most bit flips in non-crypto systems simply have no effect. 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.
    - jacquesm 3y ago
      A bitflip in a config datastructure changing 0x00000001 to 0x00000000 - whatever impact you want to imagine.
      - pclmulqdq 3y ago
        1 in 32 is good odds to me.
        jacquesm 3y ago
        if (launch) { do_launch(); } else { printf("this is just a test...\n"); }
- jefftk 3y ago
  > 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 A device with a microphone and network connection? You don't think people would be excited to hack that?
  - jart 3y ago
    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.
  - jacquesm 3y ago
    I would be just as concerned - if not more - about Google having access to such a device as I am about some random hacker.
  - pclmulqdq 3y ago
    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.
    - jart 3y ago
      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.

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.
- londons_explore 3y ago
  Turns out most bit flips in non-crypto systems simply have no effect. 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.
  - jacquesm 3y ago
    A bitflip in a config datastructure changing 0x00000001 to 0x00000000 - whatever impact you want to imagine.
    - pclmulqdq 3y ago
      1 in 32 is good odds to me.
      - jacquesm 3y ago
        if (launch) { do_launch(); } else { printf("this is just a test...\n"); }
jefftk 3y ago
> 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 A device with a microphone and network connection? You don't think people would be excited to hack that?
- jart 3y ago
  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.
- jacquesm 3y ago
  I would be just as concerned - if not more - about Google having access to such a device as I am about some random hacker.
- pclmulqdq 3y ago
  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.
  - jart 3y ago
    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.