briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:28Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/372Clean up Introduction Session States when removing contact2018-06-12T11:32:28ZTorsten GroteClean up Introduction Session States when removing contactCurrently, when a contact is removed, any existing sessions will be aborted, but no session state messages are deleted from the local group.
Currently, when a contact is removed, any existing sessions will be aborted, but no session state messages are deleted from the local group.
Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/373Slow Contact list2018-06-12T11:32:28ZErnir ErlingssonSlow Contact listSamsung Galaxy Note 4 (fast device) is taking 4-5 seconds to load the Contact list the first time, with 8+ contacts with a couple of days worth of conversations.Samsung Galaxy Note 4 (fast device) is taking 4-5 seconds to load the Contact list the first time, with 8+ contacts with a couple of days worth of conversations.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/374Add Forum Avatars to Available Forums List2018-06-12T11:32:28ZTorsten GroteAdd Forum Avatars to Available Forums ListAs soon as !172 and !178 have both been merged, the forum avatars should also be added to the Available Forums List.
As soon as !172 and !178 have both been merged, the forum avatars should also be added to the Available Forums List.
Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/375Extract ForumFactory from ForumManager2018-06-12T11:32:28ZakwizgranExtract ForumFactory from ForumManagerThe code for creating forums in ForumManager is used by ForumSharingManager and also needed by InviteeEngine. Extract it into its own class.The code for creating forums in ForumManager is used by ForumSharingManager and also needed by InviteeEngine. Extract it into its own class.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/378Replace BDF data structures with classes in forum sharing client2018-06-12T11:32:28ZakwizgranReplace BDF data structures with classes in forum sharing clientThe forum sharing client uses BdfDictionary and BdfList for its internal data structures, rather than just for serialisation. This tends to push type checking from compile time to run time. Create classes to represent the protocol messag...The forum sharing client uses BdfDictionary and BdfList for its internal data structures, rather than just for serialisation. This tends to push type checking from compile time to run time. Create classes to represent the protocol messages and other internal state.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/380Standard UI pattern for handling background errors2018-06-12T11:32:27ZakwizgranStandard UI pattern for handling background errorsVarious bits of the UI handle errors in background tasks in different ways - for example, by showing a toast, finishing the activity, or just logging the error. Come up with a standard pattern and apply it consistently, except where ther...Various bits of the UI handle errors in background tasks in different ways - for example, by showing a toast, finishing the activity, or just logging the error. Come up with a standard pattern and apply it consistently, except where there's a reason for making an exception.https://code.briarproject.org/briar/briar/-/issues/381Extract dependencies from messages in validation hook2018-06-12T11:32:27ZakwizgranExtract dependencies from messages in validation hookThe validation hook should return a list of dependencies to the validation manager.The validation hook should return a list of dependencies to the validation manager.Milestone DTorsten GroteTorsten Grote