Re:A Formal Security Analysis of the Signal Messaging Protoc...
by motohagiography on Saturday May 19, 2018 @10:41AM
(#17108061)
Great paper, there goes my weekend.
Initial impression is that theoretical place to look for attacks on an implementation would be simultaneously against the derivation components in the KDFs, (const0, 1), which appear to be the basis for iterating the chain keys to gen msg keys (other than the hmac of the previous one) - and on the derivation of a chains root key from (I think) the contents of that initial 3DH key agreement. If I were sabotaging an implementation, I would probably examine the impact of reducing the entropy of these components.
Even then, you would have to precompute chains of message keys for each sender/recipient combination.
Using the previous key HMAC in the KDF to increment message and chain is a really nice touch as it removes the dependency on a static counter or a universal GF counter seed across all client instances.
Whether these intuitions are correct or not, what the protocol effectively does (very well) is force an attacker to target an individual users device to get message cleartext, as even if an implementor made a bunch of mistakes, the diversity of keys across senders and recipients makes passive mass surveillance impractical.
IMHO, the most economical "mass," attack against it would be to identify its messages on the wire, then auto-exploit the endpoint devices, install screen grabbing spyware, and harvest that data. Hardly passive or scaleably undetectable.
Initial impression is that theoretical place to look for attacks on an implementation would be simultaneously against the derivation components in the KDFs, (const0, 1), which appear to be the basis for iterating the chain keys to gen msg keys (other than the hmac of the previous one) - and on the derivation of a chains root key from (I think) the contents of that initial 3DH key agreement. If I were sabotaging an implementation, I would probably examine the impact of reducing the entropy of these components.
Even then, you would have to precompute chains of message keys for each sender/recipient combination.
Using the previous key HMAC in the KDF to increment message and chain is a really nice touch as it removes the dependency on a static counter or a universal GF counter seed across all client instances.
Whether these intuitions are correct or not, what the protocol effectively does (very well) is force an attacker to target an individual users device to get message cleartext, as even if an implementor made a bunch of mistakes, the diversity of keys across senders and recipients makes passive mass surveillance impractical.
IMHO, the most economical "mass," attack against it would be to identify its messages on the wire, then auto-exploit the endpoint devices, install screen grabbing spyware, and harvest that data. Hardly passive or scaleably undetectable.
Nice.