4 ms·
This is a good example of what can go wrong when you try to use too much cryptography. When designing a protocol/application, you should first try to do it wit
by agwa 7y ago
This is a good example of what can go wrong when you try to use too much cryptography. When designing a protocol/application, you should first try to do it without crypto, then with hashes/symmetric crypto, and only as a last resort public key crypto (e.g. signatures, RSA), since the more crypto you use the more things can go wrong.
Here, ACME was using signatures for its challenges when it could have gotten by with no crypto at all (just putting the account ID and CA name in the challenge would have been secure, and easy to analyze) and got tripped up by a counter-intuitive property of signatures (signatures do not uniquely identify a person).
- snarf21 7y agoThese things are hard to get perfect and attackers generally have more resources. I have a question though: wouldn't encrypting the data in .well-known/acme-challenge/some_file with a LE public key (this can be loaded out of band to prevent MitM) prevent this signature attack?
- agwa 7y agoMaybe. But why would you try that when you can just not use signatures, which were the wrong tool in the first place? My point is that you usually need less crypto, not more. Trying to fix fundamental problems by tacking on more crypto might make a protocol more secure, but it definitely will make the protocol harder to analyze, which makes it harder to find problems.