|
|
|
|
|
|
by Totient
4570 days ago
|
|
|
Smugness aside, I am actually concerned about this implementation and Telegram's response: > The rest looks like matters of taste as opposed to objective reasoning. Can you name an actual attack? The response to that is, "I shouldn't have to!" Anything that replaces a proven secure component with something that we haven't (yet) found an attack on is grounds for suspicion at the very least. SHA-1 isn't a MAC. It's not that hard to make it so (HMAC), but Telegram hasn't. > Again, we do not use MAC-then-encrypt. Our scheme is closer to MAC-and-encrypt with some essential modifications. Out of the three options: MAC then encrypt, encrypt then MAC, and MAC and encrypt, only encrypt then MAC is secure (http://cseweb.ucsd.edu/~mihir/papers/oem.pdf) I don't care if they've made "essential modifications", they're replacing a component that is provably secure, with one that may or may not be secure. |
|
|
"Assessing the security of software via the question "can we find any security flaws in it?" is like assessing the structure of a bridge by asking the question "has it collapsed yet?" -- it is the most important question, to be certain, but it also profoundly misses the point. Engineers design bridges with built-in safety margins in order to guard against unforeseen circumstances (unexpectedly high winds, corrosion causing joints to weaken, a traffic accident severing support cables, et cetera); secure software should likewise be designed to tolerate failures within individual components. Using a MAC to make sure that an attacker cannot exploit a bug (or a side channel) in encryption code is an example of this approach: If everything works as designed, this adds nothing to the security of the system; but in the real world where components fail, it can mean the difference between being compromised or not. The concept of "security in depth" is not new to network administrators; but it's time for software engineers to start applying the same engineering principles within individual applications as well."
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....