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/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/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/276Introduction Client Tests2018-06-12T11:32:31ZTorsten GroteIntroduction Client TestsMilestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/223Unable to add contacts via Bluetooth with Android 62018-06-12T11:32:34ZTorsten GroteUnable to add contacts via Bluetooth with Android 6Apparently, you need the `ACCESS_COARSE_LOCATION` permission to use Bluetooth on Android 6. So we need to ask the user to grant this permission before contacts can be added via Bluetooth.
To quote from the [issue report](https://code....Apparently, you need the `ACCESS_COARSE_LOCATION` permission to use Bluetooth on Android 6. So we need to ask the user to grant this permission before contacts can be added via Bluetooth.
To quote from the [issue report](https://code.google.com/p/android/issues/detail?id=189090):
> To access the hardware identifiers of nearby external devices via Bluetooth and Wi-Fi scans, your app
> must now have the `ACCESS_FINE_LOCATION` or `ACCESS_COARSE_LOCATION` permissions
This is a sub-issue of #158.Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/211PanicKit Response: Uninstall Briar2018-06-12T11:32:34ZTorsten GrotePanicKit Response: Uninstall BriarIt is possible to not only purge all data, but also to install Briar completely, so that there are no (obvious) clues that it was installed and used at all.
Uninstalling should be added as another configurable Panic Response.It is possible to not only purge all data, but also to install Briar completely, so that there are no (obvious) clues that it was installed and used at all.
Uninstalling should be added as another configurable Panic Response.Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/195Notification about private messages should go away when viewing messages2018-06-12T11:32:35ZTorsten GroteNotification about private messages should go away when viewing messagesWhen viewing the private messages, the notification about these private messages should automatically be dismissed.When viewing the private messages, the notification about these private messages should automatically be dismissed.Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/184Disabling Bluetooth adapter on UI thread violates Strict Mode2018-06-12T11:32:35ZakwizgranDisabling Bluetooth adapter on UI thread violates Strict ModeOn the Galaxy Nexus (Android 4.3), BluetoothAdapter#disable() results in a disk write, which violates strict mode. Maybe we should run the enable() and disable() calls on the AndroidExecutor?
```
12-17 12:19:33.868 29626-29626/org.br...On the Galaxy Nexus (Android 4.3), BluetoothAdapter#disable() results in a disk write, which violates strict mode. Maybe we should run the enable() and disable() calls on the AndroidExecutor?
```
12-17 12:19:33.868 29626-29626/org.briarproject D/StrictMode: StrictMode policy violation; ~duration=319 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=287 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1097)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId(SQLiteConnection.java:779)
at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId(SQLiteSession.java:788)
at android.database.sqlite.SQLiteStatement.executeInsert(SQLiteStatement.java:86)
at android.database.sqlite.SQLiteDatabase.insertWithOnConflict(SQLiteDatabase.java:1469)
at android.database.sqlite.SQLiteDatabase.insert(SQLiteDatabase.java:1339)
at com.android.providers.settings.SettingsProvider.insertForUser(SettingsProvider.java:914)
at com.android.providers.settings.SettingsProvider.callFromPackage(SettingsProvider.java:634)
at android.content.ContentProvider$Transport.call(ContentProvider.java:279)
at android.provider.Settings$NameValueCache.putStringForUser(Settings.java:818)
at android.provider.Settings$Global.putStringForUser(Settings.java:5529)
at android.provider.Settings$Global.putString(Settings.java:5519)
at android.provider.Settings$Global.putInt(Settings.java:5607)
at com.android.server.BluetoothManagerService.persistBluetoothSetting(BluetoothManagerService.java:255)
at com.android.server.BluetoothManagerService.disable(BluetoothManagerService.java:439)
at android.bluetooth.IBluetoothManager$Stub.onTransact(IBluetoothManager.java:116)
at android.os.Binder.execTransact(Binder.java:388)
at dalvik.system.NativeStart.run(Native Method)
# via Binder call with stack:
android.os.StrictMode$LogStackTrace
at android.os.StrictMode.readAndHandleBinderCallViolations(StrictMode.java:1687)
at android.os.Parcel.readExceptionCode(Parcel.java:1413)
at android.os.Parcel.readException(Parcel.java:1382)
at android.bluetooth.IBluetoothManager$Stub$Proxy.disable(IBluetoothManager.java:286)
at android.bluetooth.BluetoothAdapter.disable(BluetoothAdapter.java:550)
at org.briarproject.android.SettingsActivity.onClick(SettingsActivity.java:297)
at android.view.View.performClick(View.java:4240)
at android.view.View$PerformClick.run(View.java:17721)
at android.os.Handler.handleCallback(Handler.java:730)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5103)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:737)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
at dalvik.system.NativeStart.main(Native Method)
```Milestone BTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/118Introduce contacts to each other2018-04-16T16:24:37ZakwizgranIntroduce contacts to each otherThe protocol for doing this will be a BSP client.The protocol for doing this will be a BSP client.Milestone BTorsten GroteTorsten Grote