After all, if the standard implementations work, it doesn't matter if you mess up your own crypto implementation, because the standard implementation is unbreakable.
This sounds like obviously good advice but it actually isn't, if your implementation is vulnerable to timing attacks and is used as the first layer, it can potentially reveal (parts of) your plaintext. Vulnerabilities like this is exactly why "don't roll your own crypto" is good advice
if your implementation.. is used as the first layer...
Don't you have this backward? The inner-most (first) layer would be the unverified roll-your-own, the outer layer would be standard. Outer layers are the first to be penetrated to get to the plaintext, not the inner layers... I'm intuiting as a non-crypto guy so please correct me if wrong.
The point of a timing attack is that some operations take different amounts of time depending on the plaintext and/or key. Depending on the attack in question and your access to the system, this potentially lets you draw conclusions about what was encrypted by observing how quickly the system responds to various requests.
If the custom algorithm is an outer layer, it only processes data that has already been encrypted by another presumably strong algorithm. Even if there's a timing attack, breaking the outer layer can't help you unless you can also break the well-studied inner layer. If the custom algorithm sees the actual plaintext directly, the timing attack can let you straight to the original message, no matter how strong any of your outer layers are.
Indeed, if the home-made RSA algorithm is the outer layer, and someone manages to break it, then we're back to the status quo. And the status quo is unbreakable encryption, right?
On the other hand, if the home-made RSA algorithm is part of the inner layer, how is it different than any of the other poorly designed code that we use in the user facing side of encryption? If an API call goes through 100,000 lines of business logic, and the result gets encrypted and sent as an API response, that's okay, it happens billions of times per day. In terms of security, what does it matter if a few of those 100,000 lines are a home-made RSA implementation?
For example, if the outer algorithm takes a fixed amount of time and the inner algorithm takes longer for certain messages then by looking at the total time taken you can determine the content.
Comments
This sounds like obviously good advice but it actually isn't, if your implementation is vulnerable to timing attacks and is used as the first layer, it can potentially reveal (parts of) your plaintext. Vulnerabilities like this is exactly why "don't roll your own crypto" is good advice
Don't you have this backward? The inner-most (first) layer would be the unverified roll-your-own, the outer layer would be standard. Outer layers are the first to be penetrated to get to the plaintext, not the inner layers... I'm intuiting as a non-crypto guy so please correct me if wrong.
The point of a timing attack is that some operations take different amounts of time depending on the plaintext and/or key. Depending on the attack in question and your access to the system, this potentially lets you draw conclusions about what was encrypted by observing how quickly the system responds to various requests.
If the custom algorithm is an outer layer, it only processes data that has already been encrypted by another presumably strong algorithm. Even if there's a timing attack, breaking the outer layer can't help you unless you can also break the well-studied inner layer. If the custom algorithm sees the actual plaintext directly, the timing attack can let you straight to the original message, no matter how strong any of your outer layers are.
Indeed, if the home-made RSA algorithm is the outer layer, and someone manages to break it, then we're back to the status quo. And the status quo is unbreakable encryption, right?
On the other hand, if the home-made RSA algorithm is part of the inner layer, how is it different than any of the other poorly designed code that we use in the user facing side of encryption? If an API call goes through 100,000 lines of business logic, and the result gets encrypted and sent as an API response, that's okay, it happens billions of times per day. In terms of security, what does it matter if a few of those 100,000 lines are a home-made RSA implementation?
For example, if the outer algorithm takes a fixed amount of time and the inner algorithm takes longer for certain messages then by looking at the total time taken you can determine the content.
Ah okay, this is obvious now, ty