5 ms·

Hey, like you I decided to dive into cryptography coming from a different background. Although this quote is not directly related to your problem it can be safe

by msl09 9y ago

Hey, like you I decided to dive into cryptography coming from a different background. Although this quote is not directly related to your problem it can be safely applied to it: "Almost certainly you will get the urge to invent new cryptographic algorithms, and will believe that they are unbreakable. Don't resist the urge; this is one of the fun parts. But resist the belief; almost certainly your creations will be breakable, and almost certainly no one will spend the time breaking them for you. You can break them yourself as you get better."[1] The problem that Schneier is referring to is that doing a careful analysis (that is required if you want to use your crypto in production) is tedious, time consuming, and requires expertise in the area to know most blank spots of the algorithms (heck a single one is hard enough). That's why he recommends you to be have enough experience breaking many algorithms before you make any serious claim about your the safety of your crypto. So all in all it's great that you got the interest in the area, there is a lot of work needed in OSS. But be very careful about claiming that your lib is ready for production. What you got is a bunch of volunteers to glance at your code. Few cryptographers (if any) will seriously try to break it. [1] https://www.schneier.com/crypto-gram/archives/1999/1015.html#SoYouWanttobeaCryptographer https://www.schneier.com/crypto-gram/archives/1999/1015.html...

Piskvorrr 9y ago
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.
    - 9y ago
- 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.

by msl09 9y ago

Piskvorrr 9y ago

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.
  - 9y ago
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.