briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-04-30T15:55:35Zhttps://code.briarproject.org/briar/briar/-/issues/37Optionally disable Tor when using mobile data2018-04-30T15:55:35ZakwizgranOptionally disable Tor when using mobile dataUsers may want to save bandwidth and battery by disabling Tor when they're using mobile data. We can detect this using the same events that we use to detect loss of connectivity.Users may want to save bandwidth and battery by disabling Tor when they're using mobile data. We can detect this using the same events that we use to detect loss of connectivity.Milestone ASantiago Torres-AriasSantiago Torres-Ariashttps://code.briarproject.org/briar/briar/-/issues/33Show breadcrumbs when adding a contact2018-06-12T11:32:40ZakwizgranShow breadcrumbs when adding a contactShow how many steps there are, and which is the current step.
Related Issue: #87Show how many steps there are, and which is the current step.
Related Issue: #87Milestone ATorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/24Raise minimum Java version to 62018-06-12T11:32:40ZakwizgranRaise minimum Java version to 6Upgrade H2 and any other libraries that were held back for Java 5 compatibility. Remove any workarounds for older APIs, such as `new IOException(e.toString())`.Upgrade H2 and any other libraries that were held back for Java 5 compatibility. Remove any workarounds for older APIs, such as `new IOException(e.toString())`.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/23Raise minimum Android version to 2.32018-06-12T11:32:40ZakwizgranRaise minimum Android version to 2.3Update the minSdkVersion to 9, remove any workarounds for older APIs. Wave goodbye to the Huawei U8110...Update the minSdkVersion to 9, remove any workarounds for older APIs. Wave goodbye to the Huawei U8110...Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/19KeyManagerImpl throws an error if the clock moves backwards2018-06-12T11:32:40ZakwizgranKeyManagerImpl throws an error if the clock moves backwardsWe need to handle this situation better, as some users adjust the clock rather than the timezone when travelling.We need to handle this situation better, as some users adjust the clock rather than the timezone when travelling.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/17Crash report activity is obscured2018-06-12T11:32:40ZakwizgranCrash report activity is obscuredAfter a crash (caused by KeyManagerImpl throwing an Error), the crash report activity is visible behind the Android crash dialog. But after dismissing the Android crash dialog, the crashed activity is restarted and immediately covered by...After a crash (caused by KeyManagerImpl throwing an Error), the crash report activity is visible behind the Android crash dialog. But after dismissing the Android crash dialog, the crashed activity is restarted and immediately covered by the password activity. After dismissing the password activity (two instances), the crash report activity is no longer there.
We may be able to fix this by changing the way we handle uncaught exceptions.Milestone Ahttps://code.briarproject.org/briar/briar/-/issues/7Crashes can create multiple instances of PasswordActivity2018-01-28T11:30:28ZakwizgranCrashes can create multiple instances of PasswordActivityAfter a crash, sometimes several instances of PasswordActivity appear on top of each other. This could be caused by the system relaunching a stack of activities, each of which spawns an instance of PasswordActivity. But the launch mode o...After a crash, sometimes several instances of PasswordActivity appear on top of each other. This could be caused by the system relaunching a stack of activities, each of which spawns an instance of PasswordActivity. But the launch mode of PasswordActivity should prevent multiple instances from being created.Milestone ATorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/5DB durability failures could cause key reuse2022-11-01T14:51:18ZakwizgranDB durability failures could cause key reuseIf an outgoing stream number is used and the database fails to store the updated stream counter durably, the stream number could be reused after restarting the app. That would mean the same key would be reused with the same IV, which wou...If an outgoing stream number is used and the database fails to store the updated stream counter durably, the stream number could be reused after restarting the app. That would mean the same key would be reused with the same IV, which would be very serious - the XOR of two GCM ciphertexts created with the same key and IV equals the XOR of the plaintexts, making the plaintexts guessable.
If this document is right, databases generally can't guarantee durability, even if they claim to:
http://www.h2database.com/html/advanced.html#durability_problems
We should use a fresh random IV for each stream to avoid reusing the same (key, IV) combination even if a stream number is reused.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/4TransportTagRecogniser makes alien calls while holding a lock2018-08-02T11:01:32ZakwizgranTransportTagRecogniser makes alien calls while holding a lockThis could cause deadlock. Refactor TagRecogniser and KeyManager so they don't need to hold locks while making alien calls.This could cause deadlock. Refactor TagRecogniser and KeyManager so they don't need to hold locks while making alien calls.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/3KeyManagerImpl makes alien calls while holding a lock2018-08-02T11:01:32ZakwizgranKeyManagerImpl makes alien calls while holding a lockThis could cause deadlock. Refactor TagRecogniser and KeyManager so they don't need to hold locks while making alien calls.This could cause deadlock. Refactor TagRecogniser and KeyManager so they don't need to hold locks while making alien calls.Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/1Migrate issues from Sourceforge2018-06-12T11:32:42ZakwizgranMigrate issues from Sourceforgehttp://sourceforge.net/p/briar/_list/tickets?source=navbarhttp://sourceforge.net/p/briar/_list/tickets?source=navbarMilestone Aakwizgranakwizgranhttps://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/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/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 B