briar issueshttps://code.briarproject.org/briar/briar/-/issues2020-11-21T19:02:42Zhttps://code.briarproject.org/briar/briar/-/issues/362Connection indicators showed wrong information2020-11-21T19:02:42ZakwizgranConnection indicators showed wrong informationTesters reported that the connection indicators didn't correspond with whether their contacts were online or offline. This occurred with Bluetooth if multiple devices were in a small space.
May be related to the maximum number of device...Testers reported that the connection indicators didn't correspond with whether their contacts were online or offline. This occurred with Bluetooth if multiple devices were in a small space.
May be related to the maximum number of devices in a Bluetooth piconet, see #12.
We may be able to improve the situation by reducing the idle timeout for Bluetooth connections in order to detect failed connections more quickly.https://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/368Simplify Dagger providers2020-11-21T19:02:14ZakwizgranSimplify Dagger providersThe Dagger modules have a lot of methods like this:
```
@Provides
Foo provideFoo(Bar bar, Baz baz, Bam bam, Qux qux) {
return new FooImpl(bar, baz, bam, qux);
}
```
This can be simplified, making it easier to maintain:
```
@Provides
...The Dagger modules have a lot of methods like this:
```
@Provides
Foo provideFoo(Bar bar, Baz baz, Bam bam, Qux qux) {
return new FooImpl(bar, baz, bam, qux);
}
```
This can be simplified, making it easier to maintain:
```
@Provides
Foo provideFoo(FooImpl foo) {
return foo;
}
````https://code.briarproject.org/briar/briar/-/issues/369Remove UiCallback interface2018-06-11T10:16:35ZakwizgranRemove UiCallback interfaceThis interface is an ancient throwback. Plugins that need to call back into the UI should use specialised callback interfaces provided by their factories.This interface is an ancient throwback. Plugins that need to call back into the UI should use specialised callback interfaces provided by their factories.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/376Refactor clients based on ProtocolEngine2018-04-28T00:12:24ZakwizgranRefactor clients based on ProtocolEngineThe ProtocolEngine interface allows certain tasks to be performed in response to local actions and incoming messages: updating local state, sending messages, broadcasting events and deleting the incoming message. Clients based on Protoco...The ProtocolEngine interface allows certain tasks to be performed in response to local actions and incoming messages: updating local state, sending messages, broadcasting events and deleting the incoming message. Clients based on ProtocolEngine that need to perform other tasks are forced to store a task label in the local state, then retrieve it and perform the task outside the engine. This defeats the purpose of the engine interface, which is meant to encapsulate the protocol logic.
Alter or remove the ProtocolEngine interface so clients have the flexibility they need.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/377Replace BDF data structures with classes in introduction client2018-04-28T00:17:04ZakwizgranReplace BDF data structures with classes in introduction clientThe introduction 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 client's interna...The introduction 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 client's internal state.Android 1.0Torsten 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/379Safe publication audit2020-11-21T19:01:53ZakwizgranSafe publication auditAudit the codebase for safe publication issues:
* Allowing `this` to escape the constructor (including indirectly via non-static inner classes)
* Passing mutable objects between threads (including mutable collections)Audit the codebase for safe publication issues:
* Allowing `this` to escape the constructor (including indirectly via non-static inner classes)
* Passing mutable objects between threads (including mutable collections)https://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