The plot thickens: It turns out that HKDF does in fact advocate using the salt as the HMAC key. https://tools.ietf.org/html/rfc5869
So libaxolotl is indeed following the HKDF spec, it's the spec itself that does things strangely. Confusing, but I guess there must be some kind of explanation or proof. I'll keep looking. On Wed, Apr 8, 2015 at 11:33 AM, Nadim Kobeissi <[email protected]> wrote: > Wait, hold on! Scratch what I said, it appears that the paper is correct: > HKDF appears to be defined incorrectly in libaxolotl. > > If you take a look at > `libaxolotl-android/java/src/main/java/org/whispersystems/libaxolotl/kdf/HKDF.java`, > specifically the `extract` method: > > > - Line 52 appears to indeed be initializing an HMAC-SHA256 object > using "salt" as the key. > - Line 53 appears to indeed be MACing the key material as the message. > > What was initially confusing was that the order of arguments being passed > to `deriveSecrets` (a pair of wrapper methods for `extract`) does appear to > be correct. But the actual `extract` method does things incorrectly it > seems. > > Correct me if I'm mistaken, but the paper does indeed appear to be correct > in defining libaxolotl's HKDF. Perhaps this should be fixed? > > > On Tue, Apr 7, 2015 at 5:50 PM, Nadim Kobeissi <[email protected]> > wrote: > >> 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
