4 ms·

Note that the author is not inventing crypto algorithms, rather implementing them (although the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMH

Note that the author is not inventing crypto algorithms, rather implementing them (although the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line). Still a risky business, and tricky to get right, but several orders of magnitude safer than "hey, what if we just XORed everything with a random number? Unbreakable, eh?"

pkolaczk 9y ago
What's wrong with xoring with a stream of random numbers? Isn't it how stream ciphers work? Get a good cryptographic RNG, initialize it properly with a long enough key and you should be fine.
- baby 9y ago
  There's nothing wrong with that. You are right, that's how stream ciphers work.
- Piskvorrr 9y ago
  Thank you, that's my point exactly. Nothing wrong with what you wrote - but note the subtle difference between "XORing a stream of random numbers" (potentially viable, even unbreakable when using a OTP) and "XORing a random number" (essentially a Caesar cipher, kid-sister encryption).
  - thaumasiotes 9y ago
    > note the subtle difference between "XORing a stream of random numbers" (potentially viable, even unbreakable when using a OTP) and "XORing a random number" (essentially a Caesar cipher, kid-sister encryption) No, that's not a difference. A "stream of numbers" is just one very large number. What you're worrying about is how large the numbers are, not whether there's one or more than one.
    - dfox 9y ago
      Original point was certainly to point out the most common mistake of typical homegrown cryptosystems. Even programmers who know that XORing stuff with constant byte is not viable encryption can produce systems that do essentially the same thing (usually by XORing everything with RC4 output with long lived or even constant key)
- IncRnd 9y ago
  You're right about the theory, but you're also wrong about how to implement - which is the point of telling people not to roll their own crypto. What about reseeding or prediction resistance? How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Oops, the quantum random number generator card doesn't work anymore after adding that extra GPGPU to the system.
  - ramphastidae 9y ago
    > How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Sounds fascinating. Can you please tell us more?
    - the_stc 9y ago
      If you had a RNG that sampled some hardware noise but then you altered the environment by introducing extreme temperatures, maybe the RNG would end up with biased output. A simple example: you can use a camera as a good source of randomness, even taking a picture of a wall indoors. But if an attacker was able to flood that room with light and overwhelm your sensor, he could predict the image would be 100% white pixels or near to it and guess the random output. But the comment is exaggerating. Encryption algorithms do not handle the case of your entropy source being compromised. Good RNG algorithms like Yarrow try to mitigate this somewhat.
      - JohnStrange 9y ago
        Well, to be fair, a good implementation should throw some simple statistical sanity checks at RNG input during self-test and throw an error when it doesn't pass. Passing such tests doesn't indicate that the RNG is cryptographically secure, but failing them indicates that it is insecure.
      - pkolaczk 9y ago
        Even if you need a real entropy-based RNG, e.g. for key generation, you need to gather entropy once at the beginning to seed the RNG. Then running RNG does not need any more entropy, so your hairdryer trick won't work. A common myth I hear is that "entropy" gets "depleted" during RNG operation, but in fact it does not. You only need enough bits of entropy once at the beginning, equal to the internal RNG state length.
loup-vaillant 9y ago
> the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line It was a few months ago. Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew). It's not inventing crypto either: it's a straightforward application of what was done to Salsa20. The security reduction that worked for XSalsa20 (guaranteed secure if Salsa20 is secure) applies to XChacha20 as well.
- curun1r 9y ago
  > Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew). Do they really? What about timing attacks? Does all your code run in constant time? If not, there's a whole class of vulnerability that basically will only be found when experienced attackers have a chance to poke at it. Timing attacks are a great example of why "don't roll your own crypto" is sound advice. No amount of testing your library against a reference library will uncover them.
  - loup-vaillant 9y ago
    > Do they really? Absolutely: > […] However, XChaCha20 is currently not widely implemented outside the libsodium library, due to the absence of formal specification. https://download.libsodium.org/doc/advanced/xchacha20.html https://download.libsodium.org/doc/advanced/xchacha20.html Can't say for sure, but it look like they didn't have an independent implementation to compare to. Just like me a few months a go. --- > What about timing attacks? Monocypher is immune. First, the primitive were chosen precisely because they are easily immunised against timing attacks. Second, this is easily checked simply by looking at the source code: no secret-dependent branches, no secret-dependent indices, and that's about it. One doesn't need to be an expert to check that, a junior programmer could do it after being told what to look for.
shallot_router 9y ago
>XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line No pun intended?
- Piskvorrr 9y ago
  No pun intended, but it would have been a pretty good pun, had I noticed it before.

pkolaczk 9y ago

What's wrong with xoring with a stream of random numbers? Isn't it how stream ciphers work? Get a good cryptographic RNG, initialize it properly with a long enough key and you should be fine.

baby 9y ago
There's nothing wrong with that. You are right, that's how stream ciphers work.
Piskvorrr 9y ago
Thank you, that's my point exactly. Nothing wrong with what you wrote - but note the subtle difference between "XORing a stream of random numbers" (potentially viable, even unbreakable when using a OTP) and "XORing a random number" (essentially a Caesar cipher, kid-sister encryption).
- thaumasiotes 9y ago
  > note the subtle difference between "XORing a stream of random numbers" (potentially viable, even unbreakable when using a OTP) and "XORing a random number" (essentially a Caesar cipher, kid-sister encryption) No, that's not a difference. A "stream of numbers" is just one very large number. What you're worrying about is how large the numbers are, not whether there's one or more than one.
  - dfox 9y ago
    Original point was certainly to point out the most common mistake of typical homegrown cryptosystems. Even programmers who know that XORing stuff with constant byte is not viable encryption can produce systems that do essentially the same thing (usually by XORing everything with RC4 output with long lived or even constant key)
IncRnd 9y ago
You're right about the theory, but you're also wrong about how to implement - which is the point of telling people not to roll their own crypto. What about reseeding or prediction resistance? How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Oops, the quantum random number generator card doesn't work anymore after adding that extra GPGPU to the system.
- ramphastidae 9y ago
  > How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Sounds fascinating. Can you please tell us more?
  - the_stc 9y ago
    If you had a RNG that sampled some hardware noise but then you altered the environment by introducing extreme temperatures, maybe the RNG would end up with biased output. A simple example: you can use a camera as a good source of randomness, even taking a picture of a wall indoors. But if an attacker was able to flood that room with light and overwhelm your sensor, he could predict the image would be 100% white pixels or near to it and guess the random output. But the comment is exaggerating. Encryption algorithms do not handle the case of your entropy source being compromised. Good RNG algorithms like Yarrow try to mitigate this somewhat.
    - JohnStrange 9y ago
      Well, to be fair, a good implementation should throw some simple statistical sanity checks at RNG input during self-test and throw an error when it doesn't pass. Passing such tests doesn't indicate that the RNG is cryptographically secure, but failing them indicates that it is insecure.
    - pkolaczk 9y ago
      Even if you need a real entropy-based RNG, e.g. for key generation, you need to gather entropy once at the beginning to seed the RNG. Then running RNG does not need any more entropy, so your hairdryer trick won't work. A common myth I hear is that "entropy" gets "depleted" during RNG operation, but in fact it does not. You only need enough bits of entropy once at the beginning, equal to the internal RNG state length.

loup-vaillant 9y ago

> the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line It was a few months ago. Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew). It's not inventing crypto either: it's a straightforward application of what was done to Salsa20. The security reduction that worked for XSalsa20 (guaranteed secure if Salsa20 is secure) applies to XChacha20 as well.

curun1r 9y ago
> Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew). Do they really? What about timing attacks? Does all your code run in constant time? If not, there's a whole class of vulnerability that basically will only be found when experienced attackers have a chance to poke at it. Timing attacks are a great example of why "don't roll your own crypto" is sound advice. No amount of testing your library against a reference library will uncover them.
- loup-vaillant 9y ago
  > Do they really? Absolutely: > […] However, XChaCha20 is currently not widely implemented outside the libsodium library, due to the absence of formal specification. https://download.libsodium.org/doc/advanced/xchacha20.html https://download.libsodium.org/doc/advanced/xchacha20.html Can't say for sure, but it look like they didn't have an independent implementation to compare to. Just like me a few months a go. --- > What about timing attacks? Monocypher is immune. First, the primitive were chosen precisely because they are easily immunised against timing attacks. Second, this is easily checked simply by looking at the source code: no secret-dependent branches, no secret-dependent indices, and that's about it. One doesn't need to be an expert to check that, a junior programmer could do it after being told what to look for.

shallot_router 9y ago

>XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line No pun intended?

Piskvorrr 9y ago
No pun intended, but it would have been a pretty good pun, had I noticed it before.