5 ms·

Doing your own encryption does clearly not exclude also using other encryption. Or is implementing AES already not anymore doing your own encryption, because AE

by madez 9y ago

Doing your own encryption does clearly not exclude also using other encryption. Or is implementing AES already not anymore doing your own encryption, because AES wasn't invented by you? You _always_ use work of others. Doing your own crypto can be used as way to safeguard against unknown vulnerabilities in the tools you would use otherwise. If the recommended library is safe, then fine, you are good to go. How do we know it is safe? My idea above is a way to increase the safety margin in a way that is orthogonal to the increase of the key space of the recommended tool. That sounds like a very good thing to me.

dsacco 9y ago
I'm sorry, I don't understand what you're trying to say. Can you clarify? What I am trying to say is that you gain nothing by, say, implementing your own encryption algorithm, using it on a plaintext, then encrypting the resulting ciphertext with a known good implementation of a known good algorithm like AES. That is how I interpreted your previous comment. So - you don't gain anything from that, if that's what you meant. If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot, and there are plenty of open source implementations that you can inspect if you don't trust the code. Finally, if you distrust the design of a known good algorithm, you're out of luck, because (again) you're almost certainly not going to come up with something better. If you do, by all means use it, but it's simply not likely whatsoever. And again: you're not increasing the safety margin by double encrypting, unless you know both algorithms and implementations are solid. And even if they both are, the safety margin improvement will be negligible compared to the decrease in performance.
- jmulho 9y ago
  > "If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot" I've never understood this argument. Encryption algorithms are deterministic. If you implement a known good algorithm on your own, and it gets the same outputs given the same inputs, then you are highly unlikely to shoot yourself in the foot. This is not what people are talking about when they warn not to roll your own crypto.
  - bascule 9y ago
    Just because an AES implementation matches the test vectors does not make it correct or safe. Here is an excellent visual depiction of several different AES implementations, many of which do not run in constant time: https://cr.yp.to/mac/variability1.html https://cr.yp.to/mac/variability1.html Implementing AES with variable time secret-dependent operations can leak the key. There are much bigger and more terrifying subtleties to implementing crypto correctly than simply matching the test vectors.
    - dsacco 9y ago
      To briefly expand on this (good) comment: In cryptography, the output of an algorithm is far less important than how that output was generated (with very precise specificity). Crypto code requires far more heavy lifting in the "how" of the output than other software does. This is not intuitive, because ordinarily there are several ways to do things and you can compare on output, and it's probably fine to develop something in a functional but unorthodox way (minus performance consequences, maybe). As the parent comment here mentions, there are extremely bad consequences to subtle mistakes in how the algorithm and its implementation arrives at the output, even if the output is correct. If Alice sends Bob an encrypted message and the custom crypto provides an incorrect output, Bob can't decrypt the message. But if Alice sends Bob an encrypted message with the correct output generated in an unsafe way, there are many ways by which the secret key could theoretically be recovered, which is far worse than Bob not being able to read the message in the first place.
    - jmulho 9y ago
      > "Just because an AES implementation matches the test vectors does not make it correct or safe." Actually, this does make it correct. Whether or not it is safe depends on the application. For example, I sent my friend Bob some cyphertext that I calculated by hand with a pencil and paper using the AES algorithm. I sent it via my trusted courier Eve. It took four hours for me to do the calculation. At the last minute I started to second guess my math so I double checked it against a respected crypto library. It was fine, so I handed it off to Eve. I am pretty sure that in this application my choice to calculate the answer by hand was exactly as safe as if I had just used the library. In fact, I am so sure (given that the answers were identical), that just as Eve was walking out the door, enroute to Bob, I pulled her close and whispered in her ear: "Eve, be very careful with this cyphertext, it took me four hours to create it."
monsieurbanana 9y ago
That's far from what I'd call "doing crypto as a side-hobby".

by madez 9y ago

dsacco 9y ago

I'm sorry, I don't understand what you're trying to say. Can you clarify? What I am trying to say is that you gain nothing by, say, implementing your own encryption algorithm, using it on a plaintext, then encrypting the resulting ciphertext with a known good implementation of a known good algorithm like AES. That is how I interpreted your previous comment. So - you don't gain anything from that, if that's what you meant. If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot, and there are plenty of open source implementations that you can inspect if you don't trust the code. Finally, if you distrust the design of a known good algorithm, you're out of luck, because (again) you're almost certainly not going to come up with something better. If you do, by all means use it, but it's simply not likely whatsoever. And again: you're not increasing the safety margin by double encrypting, unless you know both algorithms and implementations are solid. And even if they both are, the safety margin improvement will be negligible compared to the decrease in performance.

jmulho 9y ago
> "If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot" I've never understood this argument. Encryption algorithms are deterministic. If you implement a known good algorithm on your own, and it gets the same outputs given the same inputs, then you are highly unlikely to shoot yourself in the foot. This is not what people are talking about when they warn not to roll your own crypto.
- bascule 9y ago
  Just because an AES implementation matches the test vectors does not make it correct or safe. Here is an excellent visual depiction of several different AES implementations, many of which do not run in constant time: https://cr.yp.to/mac/variability1.html https://cr.yp.to/mac/variability1.html Implementing AES with variable time secret-dependent operations can leak the key. There are much bigger and more terrifying subtleties to implementing crypto correctly than simply matching the test vectors.
  - dsacco 9y ago
    To briefly expand on this (good) comment: In cryptography, the output of an algorithm is far less important than how that output was generated (with very precise specificity). Crypto code requires far more heavy lifting in the "how" of the output than other software does. This is not intuitive, because ordinarily there are several ways to do things and you can compare on output, and it's probably fine to develop something in a functional but unorthodox way (minus performance consequences, maybe). As the parent comment here mentions, there are extremely bad consequences to subtle mistakes in how the algorithm and its implementation arrives at the output, even if the output is correct. If Alice sends Bob an encrypted message and the custom crypto provides an incorrect output, Bob can't decrypt the message. But if Alice sends Bob an encrypted message with the correct output generated in an unsafe way, there are many ways by which the secret key could theoretically be recovered, which is far worse than Bob not being able to read the message in the first place.
  - jmulho 9y ago
    > "Just because an AES implementation matches the test vectors does not make it correct or safe." Actually, this does make it correct. Whether or not it is safe depends on the application. For example, I sent my friend Bob some cyphertext that I calculated by hand with a pencil and paper using the AES algorithm. I sent it via my trusted courier Eve. It took four hours for me to do the calculation. At the last minute I started to second guess my math so I double checked it against a respected crypto library. It was fine, so I handed it off to Eve. I am pretty sure that in this application my choice to calculate the answer by hand was exactly as safe as if I had just used the library. In fact, I am so sure (given that the answers were identical), that just as Eve was walking out the door, enroute to Bob, I pulled her close and whispered in her ear: "Eve, be very careful with this cyphertext, it took me four hours to create it."

monsieurbanana 9y ago

That's far from what I'd call "doing crypto as a side-hobby".