3 ms·
There are a few claims made here which I'd like to see clarified. In the spirit of transparency, let me declare upfront that I use Signal but I am not affiliate
by throwawaymath 8y ago
There are a few claims made here which I'd like to see clarified. In the spirit of transparency, let me declare upfront that I use Signal but I am not affiliated with them, and I don't really have a dog in the race here. I'll reference the published NCC security review[1] for this comment. Overall I'm happy to see a published cryptographic review of this protocol.
First, under "The Full Security Picture" heading in this article, it's claimed that forward secrecy is supported via time-based exploding messages. Pages 19 and 20 of the NCC report explain that, "The default chat protocol does not allow for forward secrecy since the same keys can retain indefinitely on a users device." So forward secrecy is not assured by default under this chat protocol, is that correct?
The NCC report goes on to say that, "Exploding messages introduce mechanisms for message deletion and forward secrecy; however, it is not clear to the user that keys and messages could remain on their device beyond the period specified during message creation." I interpret this to mean that there is a way to assure forward secrecy - which is exploding messages - but you're not making that explicit in this announcement. This seems a little disingenuous to me because in your FAQ, the first answer criticizes Whatsapp for compromising forward secrecy using the backup feature, but you don't have forward secrecy enabled by default in your chat protocol.
Likewise, this announcement makes a point of mentioning how other apps require you to trust the server due to resets, and why trusting the server is bad. But page 20 of the NCC report explains that, "While the default Chat encryption protocol does provide for message confidentiality and integrity, it does not provide for security in the face of device and server compromise, as keys and ciphertext are stored for a potentially indefinite period of time." So is it correct to say that unless users specifically enable exploding messages for their conversation (which is not the default), they actually do need to trust the server?
There are also a few drawbacks to the ephemeral messaging scheme NCC found that I think should be explicitly disclosed, because they don't require too much technical detail:
1. There is no deniable authentication on the default chat protocol. While exploding messages provide deniable authentication, this property fails in a group with more than 100 participants. It's fair to question whether that's a realistic place to expect deniable authentication, but it should probably be called out.
2. Exploding messages are based on the local client's system clock. Therefore it's possible for an exploding message to be indefinitely retained on another device by e.g. manipulating the local time.
___________________
1. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...
- maxtaco 8y agoKeybase affiliate here. Correct: forward secrecy isn't on by default. We think there's a trade-off here. With forward secrecy, your old messages won't be visible on a new device, but users want this since Slack (and others) make it seem natural. However, you can opt-in to forward security on a per-message or per-conversation basis. The report says "device and server compromise." Decryption keys never leave the user's client. What they mean is if: (1) the server's stored data is compromised; (2) your phone is also compromised; and (3) the messages weren't marked ephemeral; then the attacker might be able to read past messages, even if the user tried to delete them (i.e., did Keybase really delete the ciphertexts?). This line of reasoning is correct and one of the primary motivations for key ratchets. I don't think the report is claiming that users need to trust Keybase's server in general. They do need to trust Keybase to delete messages that are marked deleted, which would mitigate the attack above if conditions 1 through 3 are met.
- lilyball 8y agoMy issue with Keybase's exploding messages is they're time-based exploding. I wish there was an option to do forward-secrecy messages where the message is visible indefinitely to current devices, but not visible to future devices.
- throwawaymath 8y agoThank you for clarifying that, especially the second point. Looks like I was misunderstanding the report then.
- maxtaco 8y agoThank you for taking the time to read the report!