briar issueshttps://code.briarproject.org/briar/briar/-/issues2018-03-29T12:53:22Zhttps://code.briarproject.org/briar/briar/-/issues/902Improve key binding in introduction protocol2018-03-29T12:53:22ZakwizgranImprove key binding in introduction protocolThe introduction protocol provides the following guarantees:
* Each introducee knows that the ephemeral and identity public keys she received are owned by the other introducee
* Each introducee knows that the ephemeral and identity p...The introduction protocol provides the following guarantees:
* Each introducee knows that the ephemeral and identity public keys she received are owned by the other introducee
* Each introducee knows that the ephemeral and identity public keys she received were used by the other introducee in the same run of the protocol - in other words it binds each introducee's ephemeral key pair to the same introducee's identity key pair and vice versa
* Each introducee knows that the ephemeral public key she received was used by the other introducee in the current run of the protocol - in other words it binds the introducees' ephemeral key pairs to each other
Unlike the contact exchange protocol, the introduction protocol does not verify the personal identity of the other introducee. The other introducee may be a persona presented by the introducer as part of a man-in-the-middle attack. However, the introduction protocol guarantees that if an introducee later verifies that a person owns the identity public key she received, that person also owns the ephemeral public key she received, and no man-in-the-middle attack took place.
To achieve this, each introducee uses her identity key pair to sign a nonce derived from the ephemeral shared secret, and authenticates her identity key pair using a symmetric key derived from the ephemeral shared secret.
Each introducee knows that the nonce she received is fresh, as it depends on her own ephemeral key pair, so the nonce itself proves that the other introducee owns the ephemeral public key received by the first introducee, while the signature proves that the other introducee owns the identity public key received by the first introducee.
The nonce is unique to this combination of ephemeral key pairs, so the signature represents a claim by the owner of the received identity public key that she took part in a protocol run involving both ephemeral key pairs. Authenticating the identity public key with a symmetric key derived from the ephemeral shared secret represents a claim by the owner of the received ephemeral public keys that she took part in a protocol run involving both ephemeral key pairs and the identity key pair.
As far as I can tell, this construction is secure and achieves what we need, but it's unnecessarily convoluted. The binding and proof of ownership that's achieved by signing nonces could be achieved more straightforwardly by signing public keys:
* Each introducee signs both introducees' ephemeral public keys and timestamps using her identity key pair
* Each introducee authenticates both introducees' identity public keys, ephemeral public keys and timestamps, using a symmetric key derived from the ephemeral shared secret
If we're not concerned with deniability, each introducee can sign both introducees' identity public keys, ephemeral public keys and timestamps. But as far as I can see, we get all the assurance we need without doing this.
Related to #901.Android 1.0https://code.briarproject.org/briar/briar/-/issues/857Introduction: No notification for contact established confirmation.2018-04-28T00:15:25ZMegaloxIntroduction: No notification for contact established confirmation.A introducted B to C. B accepted. Then C accepted. B did not receive a notification that C is now her contact.A introducted B to C. B accepted. Then C accepted. B did not receive a notification that C is now her contact.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/831Refactor BluetoothPlugin and DroidtoothPlugin to share common code2018-01-19T12:29:40ZakwizgranRefactor BluetoothPlugin and DroidtoothPlugin to share common codeMost of the logic in BluetoothPlugin and DroidtoothPlugin is identical. Refactor the common code into a shared superclass.Most of the logic in BluetoothPlugin and DroidtoothPlugin is identical. Refactor the common code into a shared superclass.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/703Create fake test data while using the app2017-10-10T09:16:00ZakwizgranCreate fake test data while using the appWhen testing the app it would be useful to be able to generate fake contacts, groups and messages quickly.
* Add a contact (saving the identity private key somewhere so we can create signed messages later)
* Add 100 private messages to/...When testing the app it would be useful to be able to generate fake contacts, groups and messages quickly.
* Add a contact (saving the identity private key somewhere so we can create signed messages later)
* Add 100 private messages to/from a fake contact
* Add 100 posts to a forum (nested replies from a mixture of throwaway fake identities, fake contacts and the user's own identity)
* Add 100 posts to a blog (comment chains from a mixture of throwaway fake identities, fake contacts and the user's own identity - these could be posted to the blogs of fake contacts or the user's own blog)
Alternatively, instead of creating the messages in batches, we could start a background service that generates them at random intervals until shutdown. That would also allow us to test notifications, UI updates, etc.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/617Protocol versioning2018-05-03T16:43:58ZakwizgranProtocol versioningAll protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.All protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/613Use metadata queries to look up introduction session state2018-04-28T00:17:21ZakwizgranUse metadata queries to look up introduction session stateSubtask of #376.Subtask of #376.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/594Implement Database Schema Update Mechanism2018-02-05T11:32:07ZTorsten GroteImplement Database Schema Update MechanismWhen the database schema changes in new versions, these changes should be applied to old versions of the schema.When the database schema changes in new versions, these changes should be applied to old versions of the schema.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/545Find out why DB lookups are so slow2018-03-29T12:29:31ZakwizgranFind out why DB lookups are so slowAsynchronously looking up small amounts of data from the database takes longer than it should, even when the same data has been looked up recently. Work out which part of the process is the bottleneck, and how much performance would be i...Asynchronously looking up small amounts of data from the database takes longer than it should, even when the same data has been looked up recently. Work out which part of the process is the bottleneck, and how much performance would be improved if we spent some time improving that part of the process.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/509Tapping QR code viewfinder should initiate auto focus2018-03-08T15:59:02ZakwizgranTapping QR code viewfinder should initiate auto focusFeedback from user testing:
> Almost anybody tried to tab the camera view finder to change the focus mode when it didn't scan immediately. People seem to be used to doing that with their regular camera. Maybe we could implement someth...Feedback from user testing:
> Almost anybody tried to tab the camera view finder to change the focus mode when it didn't scan immediately. People seem to be used to doing that with their regular camera. Maybe we could implement something similar to assist the scanning.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/482Store transport properties in metadata2017-12-15T15:04:27ZakwizgranStore transport properties in metadataStore the latest local and remote transport properties in metadata rather than iterating over all update messages whenever we need the latest properties.
Remote update messages can be deleted as soon as the properties have been extrac...Store the latest local and remote transport properties in metadata rather than iterating over all update messages whenever we need the latest properties.
Remote update messages can be deleted as soon as the properties have been extracted. When message receipt hooks have been implemented (#481), local update messages can be deleted as soon as the contact has received them.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/474Introduction protocol modifies state external to session2018-04-29T13:15:17ZakwizgranIntroduction protocol modifies state external to sessionSub-task of #456.Sub-task of #456.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/456Protocols Modify State External to Session2018-04-28T00:13:10ZTorsten GroteProtocols Modify State External to SessionThe fundamental issue is that the protocol modifies state that's external to the session. In the case of forum sharing, the external state is the list of forums and their visibility; in the case of introductions, it's the contact list. I...The fundamental issue is that the protocol modifies state that's external to the session. In the case of forum sharing, the external state is the list of forums and their visibility; in the case of introductions, it's the contact list. If multiple sessions can modify the same external state then we may have problems keeping the sessions consistent with the state and with each other.
When we first thought about sessions, I was thinking of the sequence of messages and the local state stored by the protocol - I didn't think about external state. That's also the reason the ProtocolEngine interface doesn't provide a way to update external state (#376). For any protocol that updates external state, such as the forum sharing and introduction protocols, we need to re-think what a session means.
I think we can solve this issue in the general case by saying that all sessions that affect the same external state must share the same session ID and local state. In other words, a single ongoing session per unit of external state. Then we need to design the state machine to allow for the fact that different parties may try to perform different operations within a given session, possibly at the same time. This will probably make the state machine more complex, but that's because the state machine now captures the possibility of multiple operations affecting the same state, whereas previously we just sort of crossed our fingers and hoped that didn't happen.
To put this in more concrete terms, the unit of external state for forum sharing is the visibility of a given forum to a given contact, so all sessions that affect the visibility of a given forum to a given contact should share the same session ID and local state. In particular, if a contact shares a forum with us and we simultaneously share the same forum with them, both sessions should use the same ID. When we receive their invitation we'll look up the session and discover that we're in the "invitation sent" state. We can then have a rule in the state machine that says what we should do if we receive an invitation in that state. For example, we might apply the Alice/Bob tie-breaker and ignore one of the invitations, or we might decide that we should react in the same way as if the contact had accepted our invitation. But the point is, the need to handle that situation is defined as part of the protocol.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/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/308Messages in MessageQueue are picked up by Clients2018-04-28T00:16:54ZTorsten GroteMessages in MessageQueue are picked up by ClientsA message that arrived out of order and is pending in the message queue could be picked up by `getIntroductionMessages()`.A message that arrived out of order and is pending in the message queue could be picked up by `getIntroductionMessages()`.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/237Create client for negotiating supported clients2018-04-29T16:28:05ZakwizgranCreate client for negotiating supported clientsIn future we'll add support for new clients (blogs, group messaging) and we'll need to know which contacts support those clients. Create a BSP client supported by all versions of Briar that syncs a list of supported clients with each con...In future we'll add support for new clients (blogs, group messaging) and we'll need to know which contacts support those clients. Create a BSP client supported by all versions of Briar that syncs a list of supported clients with each contact. The list should include a device ID for future multi-device support.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/236Migrate to Curve25519 and Ed255192018-02-16T18:19:21Zstr4dMigrate to Curve25519 and Ed25519See comments in #117.See comments in #117.Android 1.0https://code.briarproject.org/briar/briar/-/issues/108Set up offline build box2018-04-28T00:16:04ZakwizgranSet up offline build boxThe build box should be air-gapped as it will have access to the APK signing key, which can never be changed.The build box should be air-gapped as it will have access to the APK signing key, which can never be changed.Android 1.0akwizgranakwizgran