briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:36Zhttps://code.briarproject.org/briar/briar/-/issues/160Improve .gitignore2018-06-12T11:32:36ZErnir ErlingssonImprove .gitignoreImprove the .gitignore to clean up the change-listImprove the .gitignore to clean up the change-listMilestone Ahttps://code.briarproject.org/briar/briar/-/issues/148Upgrade Tor to 0.2.7.52018-06-12T11:32:37ZakwizgranUpgrade Tor to 0.2.7.5Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/147Implement crypto_secretbox with Spongy Castle2018-06-12T11:32:37ZakwizgranImplement crypto_secretbox with Spongy CastleThis is a simple combination of XSalsa20 and Poly1305. Use libsodium or tweetnacl to generate test vectors.This is a simple combination of XSalsa20 and Poly1305. Use libsodium or tweetnacl to generate test vectors.Milestone Ahttps://code.briarproject.org/briar/briar/-/issues/146Upgrade Spongy Castle to 1.532018-06-12T11:32:37ZakwizgranUpgrade Spongy Castle to 1.53Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/114Establish initial contacts with partner organisation2018-06-12T11:32:38ZakwizgranEstablish initial contacts with partner organisationIdentify a partner organisation that could benefit from an app built on the Bramble protocol stack and establish initial contacts with a view to producing a roadmap for the application.Identify a partner organisation that could benefit from an app built on the Bramble protocol stack and establish initial contacts with a view to producing a roadmap for the application.Milestone Ahttps://code.briarproject.org/briar/briar/-/issues/112Separate data sync protocol (BSP) from clients2018-04-16T16:24:37ZakwizgranSeparate data sync protocol (BSP) from clientsThe current clients of the data sync protocol are:
* Transport properties
* Private messages
* Forums
The current clients of the data sync protocol are:
* Transport properties
* Private messages
* Forums
Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/111Implement new transport protocol (BTP2)2018-06-12T11:32:39ZakwizgranImplement new transport protocol (BTP2)Milestone Aakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/55Refactor KeyManager and TagRecogniser2018-06-12T11:32:40ZakwizgranRefactor KeyManager and TagRecogniserThese classes are tightly coupled but live in different packages. They both provide StreamContexts - KeyManager for outgoing streams and TagRecogniser for incoming streams. They both hold copies of temporary secrets.These classes are tightly coupled but live in different packages. They both provide StreamContexts - KeyManager for outgoing streams and TagRecogniser for incoming streams. They both hold copies of temporary secrets.Milestone Aakwizgranakwizgranhttps://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/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/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/276Introduction Client Tests2018-06-12T11:32:31ZTorsten GroteIntroduction Client TestsMilestone BTorsten GroteTorsten Grotehttps://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/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 Bakwizgranakwizgran