briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-06-12T11:32:26Zhttps://code.briarproject.org/briar/briar/-/issues/429Explain that QR codes can not be scanned remotely2018-06-12T11:32:26ZTorsten GroteExplain that QR codes can not be scanned remotelyAlmost all people that I showed Briar to asked my to post my QR code into another chat app or to go into a WebRTC room to show my QR code in a webcam. Everytime I need to explain that this won't work, so it would be nice if it would some...Almost all people that I showed Briar to asked my to post my QR code into another chat app or to go into a WebRTC room to show my QR code in a webcam. Everytime I need to explain that this won't work, so it would be nice if it would somehow be clear from the app.Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/117Add contacts via QR codes2018-06-12T11:32:38ZakwizgranAdd contacts via QR codesMilestone Bhttps://code.briarproject.org/briar/briar/-/issues/618BdfDictionary should have a defined iteration order2018-06-12T11:32:20ZakwizgranBdfDictionary should have a defined iteration orderThe iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialis...The iterators for BdfDictionary's keys, values and entries should return their elements in a defined order. Currently BdfDictionary uses the iterators inherited from Hashtable, which have no defined order, so deserialising and reserialising a dictionary may produce output that's different from the input. This will be a problem whenever we want to hash or sign data that contains dictionaries.Milestone Bakwizgranakwizgranhttps://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/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/295Handle Declined Introductions2018-06-12T11:32:31ZTorsten GroteHandle Declined IntroductionsAt the moment, introducees are not informed about the other's response. When both accept, they get a notification about that.
However, when Alice declines first, Bob's backend gets the response, so it knows that the protocol has compl...At the moment, introducees are not informed about the other's response. When both accept, they get a notification about that.
However, when Alice declines first, Bob's backend gets the response, so it knows that the protocol has completed. In this case, Bob's response will not be forwarded to Alice whether positive or negative.
This violates our principle that information available in the backend should also be shown to the user so that the user understands what information she's potentially exposing to other users, who may be using different frontends.
So I essentially see two options to solve this:
1. Show **all** responses to the user
2. Do not forward negative responses to the introducees
The first option poses some UX challenge as it is not clear how the response of a contact we do not yet have should be shown. It is also an open question whether responses should always be forwarded. This would require introducing additional protocol states.
The second option would be less work to implement. The only problem is that the session of the introducee who was declined would forever stay "open" (if she accepts herself) and wait for a response that never comes. Since we are not deleting sessions anyway, that would be fine.Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/294Reject introduction requests that introduce an identity to itself2018-06-12T11:32:31ZakwizgranReject introduction requests that introduce an identity to itselfMilestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/284Don't allow accepting an introduction of two identities belonging to the same...2018-06-12T11:32:31ZTorsten GroteDon't allow accepting an introduction of two identities belonging to the same contactThe first user has identity H, the second user S1 and S2. H and S1 are contacts; H and S2 are contacts.
The first user introduces S1 to S2. For some inexplicable reason, the second user accepts the introduction to herself, so she ends...The first user has identity H, the second user S1 and S2. H and S1 are contacts; H and S2 are contacts.
The first user introduces S1 to S2. For some inexplicable reason, the second user accepts the introduction to herself, so she ends up with her own identities on her contact list: S1 as a contact of S2, and S2 as a contact of S1.
So far this isn't necessarily a bug, although it's probably a bad idea.
The bug is that when the second user touches S1 or S2 on the contact list, the introduction with S1 *and* S2 is always shown.Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/279Contact can't be removed if introduction client's local group doesn't exist2018-06-12T11:32:31ZakwizgranContact can't be removed if introduction client's local group doesn't existWhile testing the introduction UI, I tried to remove an old contact. The "Contact deleted" toast was shown but the contact wasn't removed because the introduction manager's RemoveContactHook threw an exception:
```
04-01 12:35:57.843...While testing the introduction UI, I tried to remove an old contact. The "Contact deleted" toast was shown but the contact wasn't removed because the introduction manager's RemoveContactHook threw an exception:
```
04-01 12:35:57.843 1951-8113/org.briarproject W/ConversationActivity: org.briarproject.api.db.NoSuchGroupException
org.briarproject.api.db.NoSuchGroupException
at org.briarproject.db.DatabaseComponentImpl.getMessageMetadata(DatabaseComponentImpl.java:412)
at org.briarproject.clients.ClientHelperImpl.getMessageMetadataAsDictionary(ClientHelperImpl.java:193)
at org.briarproject.introduction.IntroductionManagerImpl.removingContact(IntroductionManagerImpl.java:157)
at org.briarproject.contact.ContactManagerImpl.removeContact(ContactManagerImpl.java:152)
at org.briarproject.contact.ContactManagerImpl.removeContact(ContactManagerImpl.java:109)
at org.briarproject.android.contact.ConversationActivity$14.run(ConversationActivity.java:481)
at org.briarproject.android.BriarActivity$4.run(BriarActivity.java:154)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
```Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/278Improve BQP UI2018-06-12T11:32:31Zstr4dImprove BQP UIContinuation of the discussion in #117.Continuation of the discussion in #117.Milestone Bhttps://code.briarproject.org/briar/briar/-/issues/276Introduction Client Tests2018-06-12T11:32:31ZTorsten GroteIntroduction Client TestsMilestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/272MessageQueue deleted messages2018-06-12T11:32:31ZTorsten GroteMessageQueue deleted messagesAlice is receiving a message via the MessageQueue:
```
03-21 18:03:19.825 I/MessageQueueManagerImpl: Received message with position 5, expecting 5
03-21 18:03:19.825 I/MessageQueueManagerImpl: Message is in order, delivering
```
Th...Alice is receiving a message via the MessageQueue:
```
03-21 18:03:19.825 I/MessageQueueManagerImpl: Received message with position 5, expecting 5
03-21 18:03:19.825 I/MessageQueueManagerImpl: Message is in order, delivering
```
Then a new message is sent by Bob:
```
03-21 18:05:35.971 I/MessageQueueManagerImpl: Sending message with position 6
```
But Alice does not get the message, because the MessageQueue is deleting it:
```
03-21 18:05:36.605 I/MessageQueueManagerImpl: Received message with position 5, expecting 6
03-21 18:05:36.605 W/MessageQueueManagerImpl: Deleting message with duplicate position
```
Bob sends another message:
```
03-21 18:05:50.484 I/MessageQueueManagerImpl: Sending message with position 7
```
This time, Alice gets it, but it still comes in with the wrong position.
```
03-21 18:05:50.775 I/MessageQueueManagerImpl: Received message with position 6, expecting 6
03-21 18:05:50.775 I/MessageQueueManagerImpl: Message is in order, delivering
```Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/269Race condition between adding contacts and adding transports2018-06-12T11:32:32ZakwizgranRace condition between adding contacts and adding transports`KeyManagerImpl#addContact()` runs synchronously whereas `KeyManagerImpl#addTransport()` runs asynchronously. If a transport is added and then a contact is added immediately afterwards, it's possible for the contact not to get any transp...`KeyManagerImpl#addContact()` runs synchronously whereas `KeyManagerImpl#addTransport()` runs asynchronously. If a transport is added and then a contact is added immediately afterwards, it's possible for the contact not to get any transport keys.
This is very unlikely to affect real users because transports are added early in the startup process, but it's causing SimplexTransportIntegrationTest to fail intermittently, and should be fixed anyway on principle.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/266Message queues2018-06-12T11:32:32ZakwizgranMessage queuesWrite a generic one-to-one message queue implementation that clients can use to exchange ordered messages with a contact.Write a generic one-to-one message queue implementation that clients can use to exchange ordered messages with a contact.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/256Verify and bind long-term public keys when adding contacts2018-06-12T11:32:32ZakwizgranVerify and bind long-term public keys when adding contactsDesign a protocol for verifying and binding long-term public keys when adding contacts directly or via introductions.
The current Bluetooth protocol does this by generating two nonces from the ephemeral shared secret - each party sign...Design a protocol for verifying and binding long-term public keys when adding contacts directly or via introductions.
The current Bluetooth protocol does this by generating two nonces from the ephemeral shared secret - each party signs one of the nonces. We could use a similar approach for the new protocols, or an approach based on triple Diffie-Hellman.
Identities already have long-term signature keys but they don't have long-term DH keys, so if we use 3DH we either need to be sure it's safe to reuse the signature keys as DH keys, or we need to extend the identity object with a long-term DH key, signed with the long-term signature key. This has the disadvantage of committing us to a DH primitive for the long term.
Using signatures would make the key exchange undeniable, but it's debatable whether that matters in practice.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/254Crash when keys are rotated2018-06-12T11:32:32ZakwizgranCrash when keys are rotatedThis crash happens when leaving a test phone to do nothing (see https://code.briarproject.org/akwizgran/briar/merge_requests/74#note_2358):
```
java.lang.IllegalStateException: TimerTask is scheduled already
at...This crash happens when leaving a test phone to do nothing (see https://code.briarproject.org/akwizgran/briar/merge_requests/74#note_2358):
```
java.lang.IllegalStateException: TimerTask is scheduled already
at java.util.Timer.scheduleImpl(Timer.java:569)
at java.util.Timer.schedule(Timer.java:456)
at org.briarproject.system.SystemTimer.schedule(SystemTimer.java:21)
at org.briarproject.transport.TransportKeyManager.run(TransportKeyManager.java:260)
at java.util.Timer$TimerImpl.run(Timer.java:284)
```
Looks like the issue is that TransportKeyManager re-schedules the same TimerTask instance (i.e. itself) and the Timer impl doesn't allow that. TransportKeyManager's TimerTask implementation should be broken out into a private class so a different instance can be scheduled each time.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/253Show Introduction and Responses in UI2018-06-12T11:32:32ZTorsten GroteShow Introduction and Responses in UICurrently, the introduction client shows the introductions and the responses to them only in system notifications. See [the related wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient#draft-of-user-interface...Currently, the introduction client shows the introductions and the responses to them only in system notifications. See [the related wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient#draft-of-user-interface) for how it is done at the moment.
If the user signs out of Briar before responding via the notification, the notification will be removed leaving the user with no way to respond and the invitation protocol in limbo forever. Therefore, the received introductions should be shown somewhere else in the UI as long as they are not responded to.
Very similar to that are invitations to participate in a forum where there's also a message the user needs to respond to and that needs to be visually presented to the user in some way. That functionality is tracked in #121.
Other related tickets are [Show new messages/forum posts on dashboard](#42) and [Show recent activity on the dashboard](#88) which focus on the Dashboard which does not exist anymore. It has been proposed to show introductions/invitations in the navigation drawer in the appropriate section, so either Contacts or Forums.
There, the number of unread messages could also be shown. Later other notifications might be needed e.g. for Blogs or RSS feed reader. So a unified UI concept would be welcome.
Subtask of #118.Milestone Bhttps://code.briarproject.org/briar/briar/-/issues/252New polling logic for LAN2018-06-12T11:32:32ZakwizgranNew polling logic for LANSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/251New polling logic for Bluetooth2018-06-12T11:32:32ZakwizgranNew polling logic for BluetoothSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/250New polling logic for Tor2018-06-12T11:32:32ZakwizgranNew polling logic for TorSubtask of #116.Subtask of #116.Milestone Bakwizgranakwizgran