On Sat, Nov 1, 2014 at 8:24 AM, Moxie Marlinspike <[email protected]> wrote:
> > > 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. > Yup. The implementation code does indeed indicate that the paper got that aspect of the ratchet incorrectly. For any potential future person who happens to benefit from this line of inquiry: https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/ChainKey.java https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/ratchet/RootKey.java https://github.com/WhisperSystems/libaxolotl-android/blob/0f7d0db039a60e8d1a9fb8748ed9262e0ffc7a58/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java Nadim > > > 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 >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
