On 10/31/2014 09:56 PM, David Leon Gil wrote: > -- They present an unknown key-share attack on TextSecure; this is > rather serious, to say the least.
I'm not so sure. One party claiming another's fingerprint is a minor but general issue with fingerprints almost everywhere they are used. It affects SSH, OTR, PGP, etc. They describe a scenario where Bart wants to trick his friend Milhouse. Bart knows that Milhouse is going to invite him to his party. So Bart changes his own published public identity key to Nelson's public identity key. Then when Milhouse sends the invite to Bart, Bart can take the message (which he can't decrypt, but assumes is the invite) and forward it to Nelson (while somehow spoofing Milhouse's source address). Now Nelson thinks he was invited to the party (Bart hopes the message content doesn't read: "Hey Bart,..."). The attack would require that the server is colluding with Bart. The paper recommends hashing addresses into the MAC. We were actually the ones to suggest that to them, but there are philosophical limits on how effective that can be. Bart could claim that his number changed (to Nelson's number) at the same time that he claims his identity key has changed. For that matter, if I meet you in person for the first time, you can even claim someone else's name as your own, in addition to their phone number and fingerprint. So including logical addresses in the MAC helps with some cases, but one could always construct cases where it doesn't. The two-phase QR code thing they propose doesn't work for offline verification (people putting fingerprints on business cards, email sigs, etc) or remote verification (people reading fingerprints over the phone). It also feels pretty cumbersome. Right now, preserving those types of verification feels more valuable to us than compromising on them to stop a somewhat esoteric UKS. > Rather puzzling, however: 1. They > claim that HMAC(key=constant, message=secret) is not provably a PRF. What's more puzzling is that we're not doing that. We do HMAC(key=secret, message=constant). It could be that I'm missing something. I'll email them and get them to show me the code, but I suspect they made a mistake in their analysis. > 2. They also claim that the security of truncated > SHA2-256, as used in TextSecure tags, is unknown. Since this is extremely common practice, is approved by NIST, and is approved in the HMAC RFC, I think we're in good shape. > More concerning re > tags: TextSecure is only using an 8 byte tag. 64-bit authenticity is > plainly insufficient. I dunno. Sure 16 or 32 bytes would be better, but we're dealing with a world of really extreme size constraints where another 8 bytes is a *lot*. In the context of how this tag is specifically used for TextSecure messages (where there is no oracle), I'd like to hear more about where you see a practical attack. - moxie -- http://www.thoughtcrime.org _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
