briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:28Zhttps://code.briarproject.org/briar/briar/-/issues/371Don't allow SessionId re-use in IntroductionClient2018-06-12T11:32:28ZTorsten GroteDon't allow SessionId re-use in IntroductionClientWhen an introducee received a message with type `TYPE_REQUEST` that re-uses an old `SessionId`, the introducee treats this as a new introduction.
Check for this to happen and if so, delete message without processing it.
Also add a test.When an introducee received a message with type `TYPE_REQUEST` that re-uses an old `SessionId`, the introducee treats this as a new introduction.
Check for this to happen and if so, delete message without processing it.
Also add a test.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/370Nav Drawer Activity doesn't remember selected Fragment2018-06-12T11:32:28ZTorsten GroteNav Drawer Activity doesn't remember selected Fragment1. Open Forums
2. Rotate your device
3. Observe how you suddenly see the contact list1. Open Forums
2. Rotate your device
3. Observe how you suddenly see the contact listMilestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/367Replace invitation codes with list of discovered devices2018-06-12T11:32:28ZakwizgranReplace invitation codes with list of discovered devicesWhen using the Bluetooth method of adding contacts, testers found the similarity between invitation codes and confirmation codes confusing. The workflow could be simplified by picking the contact's device from a list of discovered device...When using the Bluetooth method of adding contacts, testers found the similarity between invitation codes and confirmation codes confusing. The workflow could be simplified by picking the contact's device from a list of discovered devices, then exchanging confirmation codes.
Related to #33.https://code.briarproject.org/briar/briar/-/issues/366Protocol spec for contact exchange protocol2018-06-12T11:32:28ZakwizgranProtocol spec for contact exchange protocolRelated to #365.Related to #365.https://code.briarproject.org/briar/briar/-/issues/365Reuse contact exchange protocol for Bluetooth and QR codes2018-06-12T11:32:28ZakwizgranReuse contact exchange protocol for Bluetooth and QR codesRelated to #256.Related to #256.Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/364Introduction responses should be signed2018-06-12T11:32:28ZakwizgranIntroduction responses should be signedIn the direct contact protocol, the parties don't directly sign the identity public keys, transport properties or timestamps. Instead, each party signs a nonce derived from the key exchange protocol's master key. This provides a degree o...In the direct contact protocol, the parties don't directly sign the identity public keys, transport properties or timestamps. Instead, each party signs a nonce derived from the key exchange protocol's master key. This provides a degree of deniability: the remote party obtains a fresh signature from the local party, but can't prove to a third party without help from the local party that the signature included input from the remote party, and thus that the local and remote parties are contacts.
If we directly sign the identity public keys, transport properties and timestamps in the introduction protocol, we'll lose deniability for introduced contacts. Cryptographic deniability isn't one of our design goals, so that's acceptable. But I'd like to explore whether a similar construction to the direct contact protocol would work here.
Subtask of #256.
# Description of protocol
The format of the response message is unchanged. Two fields are added to the ack message: a signature and a MAC.
Immediately before the local introducee sends her ack (which may happen either when she receives the remote introducee's response or when she makes her own decision, whichever happens later), she derives a master key from the ephemeral shared secret. Two nonces and a MAC key are derived from the master key. The local introducee signs one of the nonces and calculates a MAC over her own identity public key, ephemeral public key, transport properties and timestamp. The local introducee includes the signature and MAC in her ack.
On receiving the remote introducee's ack, the local introducee verifies the signature and MAC.
# Security goals
The local introducee doesn't know whether each piece of information received from the introducer originates from the remote introducee or has been replaced by the introducer, i.e. whether the introducer is carrying out a man-in-the-middle attack. The introduction protocol doesn't aim to detect or prevent man-in-the-middle attacks. We only aim to establish that if the remote identity public key is not replaced then the remote ephemeral public key, transport properties and timestamp are not replaced either. Later, when the local introducee verifies that the remote identity public key belongs to a particular person, she can also be sure that the remote ephemeral public key, transport properties and timestamp originated from that person.
# Security argument
We assume that signatures reveal what was signed, so the introducer learns the nonces.
The master key is only known to the local introducee and whoever knows the remote ephemeral private key.
The master key includes input from the local party, so it is fresh, i.e. it has not been replayed.
Verifying the signature proves that the originator of the signature knows the corresponding identity private key: the master key is fresh, so the nonce is fresh, so the signature is fresh.
Replacing the signature would require replacing the identity public key, and vice versa.
Replacing the ephemeral public key would require replacing the MAC, and vice versa.
Replacing the ephemeral public key would produce a different nonce, and would therefore require replacing the signature (but not vice versa).
Replacing the transport properties or timestamp would require replacing the MAC (but not vice versa).
So if the introducer doesn't replace the identity public key, she can't replace the signature, so she can't replace the ephemeral public key, so she can't replace the MAC, so she can't replace the transport properties or timestamp.
# Authenticating negative responses
Negative responses are not authenticated, so the introducer can falsely claim that the remote introducee declined. This is consistent with what we show in the UI, i.e. "Alice says that Bob declined the introduction".
If we want to authenticate negative responses in future, we'll have to add extend the protocol as follows:
* Response message includes an ephemeral public key regardless of whether the response is accept or decline
* Ack message is sent regardless of whether the response is accept or decline
* If the response is accept, the MAC is calculated over the response, identity public key, ephemeral public key, transport properties and timestamp
* If the response is decline, the MAC is calculated over the response, identity public key and ephemeral public key
Milestone BTorsten GroteTorsten Grote2016-08-31https://code.briarproject.org/briar/briar/-/issues/363Tester received notification while message screen was open2018-06-12T11:32:28ZakwizgranTester received notification while message screen was openA tester received a notification while the message screen was open.A tester received a notification while the message screen was open.Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/360Feedback for introducer when introduction request is sent2018-06-12T11:32:28ZakwizgranFeedback for introducer when introduction request is sentA tester tried to repeat the introduction because he didn't get immediate feedback. We already show the introduction request as an outgoing system message in the conversation, but perhaps we can make the feedback clearer.A tester tried to repeat the introduction because he didn't get immediate feedback. We already show the introduction request as an outgoing system message in the conversation, but perhaps we can make the feedback clearer.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/359Introduction message can be overlooked2018-06-12T11:32:28ZakwizgranIntroduction message can be overlookedTesters tended to overlook the introduction message from the introducer, which was displayed at the same time as the system message notifying them of the introduction. A possible solution would be to combine the messages.Testers tended to overlook the introduction message from the introducer, which was displayed at the same time as the system message notifying them of the introduction. A possible solution would be to combine the messages.Milestone Bhttps://code.briarproject.org/briar/briar/-/issues/358Testers did not understand introductions2018-06-12T11:32:28ZakwizgranTesters did not understand introductionsThe testing report says that the feature could be explained better.The testing report says that the feature could be explained better.Milestone Ehttps://code.briarproject.org/briar/briar/-/issues/357Introduction feature is not very visible2018-06-12T11:32:28ZakwizgranIntroduction feature is not very visibleTesters could not easily discover the introduction feature.Testers could not easily discover the introduction feature.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/356Make it clearer who will be introduced2018-06-12T11:32:28ZakwizgranMake it clearer who will be introducedA tester asked for the ability to cancel an introduction if he had chosen the wrong contacts.A tester asked for the ability to cancel an introduction if he had chosen the wrong contacts.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/355Keyboard closes when private message is sent2018-06-12T11:32:28ZakwizgranKeyboard closes when private message is sentA tester complained that he had to open the keyboard again for each new message.A tester complained that he had to open the keyboard again for each new message.Milestone Cakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/354Layout improvements for private message composition2018-06-12T11:32:28ZakwizgranLayout improvements for private message compositionThe testing report says that the send icon is too big and the text has too little padding.The testing report says that the send icon is too big and the text has too little padding.Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/353Tester expected enter button to send private message2018-06-12T11:32:28ZakwizgranTester expected enter button to send private messageA tester tried to send a private message via the enter button and wondered why it didn't send. The message was no longer visible because the text entry was limited to a single line and pressing enter had created a new line.
Investigat...A tester tried to send a private message via the enter button and wondered why it didn't send. The message was no longer visible because the text entry was limited to a single line and pressing enter had created a new line.
Investigate how other messaging apps handle this. Does enter send the message, or do they start a new line and expand the text entry?https://code.briarproject.org/briar/briar/-/issues/352Conversation screen has too much padding2018-06-12T11:32:29ZakwizgranConversation screen has too much paddingTesters reported that the speech bubbles in the conversation screen have too much padding, not enough of the conversation is visible.Testers reported that the speech bubbles in the conversation screen have too much padding, not enough of the conversation is visible.Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/350Contact list still showed unread message after message had been read2018-06-12T11:32:29ZakwizgranContact list still showed unread message after message had been readA tester got an unread message notification, switched directly to the converstion, read the message, switched to the contact screen, and there was still an unread message indicator next to the contact's name.
This may be a race condit...A tester got an unread message notification, switched directly to the converstion, read the message, switched to the contact screen, and there was still an unread message indicator next to the contact's name.
This may be a race condition between messages being marked as read and the contact list loading the message headers.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/347Show progress indicator while loading QR code2018-06-12T11:32:29ZakwizgranShow progress indicator while loading QR codehttps://code.briarproject.org/briar/briar/-/issues/345Identity selector when adding contacts is confusing2018-06-12T11:32:29ZakwizgranIdentity selector when adding contacts is confusingTesters found the identity selector confusing when adding contacts.Testers found the identity selector confusing when adding contacts.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/344Tester could not find contact screen2018-06-12T11:32:29ZakwizgranTester could not find contact screenA tester could not find the contact screen when he was already there. The contact list was empty, but the "No contacts" empty state message should have been visible, and the window title should have been "Contacts". I'm not sure what we ...A tester could not find the contact screen when he was already there. The contact list was empty, but the "No contacts" empty state message should have been visible, and the window title should have been "Contacts". I'm not sure what we can do to make this clearer.
Related to #327.Milestone D