briar issueshttps://code.briarproject.org/briar/briar/-/issues2021-12-09T00:18:37Zhttps://code.briarproject.org/briar/briar/-/issues/187Implement I2P plugin2021-12-09T00:18:37Zstr4dImplement I2P plugin@akwizgran expressed a keen interest in this happening eventually. The basic idea is to add I2P as a transport, so that contacts can choose to communicate over I2P if they wish. It should be similar to the Tor plugin, and will probably b...@akwizgran expressed a keen interest in this happening eventually. The basic idea is to add I2P as a transport, so that contacts can choose to communicate over I2P if they wish. It should be similar to the Tor plugin, and will probably be easier to implement (because I2P has a native Java API).https://code.briarproject.org/briar/briar/-/issues/152Merge patches upstream2020-11-21T19:42:04ZakwizgranMerge patches upstreamDetermine which of the patches in the /patches dir should be merged upstream and contact the upstream developers.
Related: #25, #64, #115Determine which of the patches in the /patches dir should be merged upstream and contact the upstream developers.
Related: #25, #64, #115https://code.briarproject.org/briar/briar/-/issues/65Two-factor authentication2020-11-21T20:09:51ZakwizgranTwo-factor authenticationAdd optional two-factor authentication to the Android app via NFC -- to log in, the user must tap a particular NFC tag as well as entering their password. Data from the NFC tag is incorporated into the PBKDF. This prevents brute force pa...Add optional two-factor authentication to the Android app via NFC -- to log in, the user must tap a particular NFC tag as well as entering their password. Data from the NFC tag is incorporated into the PBKDF. This prevents brute force password cracking if the Android device is captured but the NFC tag is not.
NFC tags may be readable at long distances, so this won't prevent password cracking by an attacker who can read the NFC tag in advance.
This is weaker than 2FA protocols based on public keys, such as U2F, but those require a trusted server that can deny access to the account if the signature doesn't match.https://code.briarproject.org/briar/briar/-/issues/63Prevent tag length from being used for active probing2021-01-25T17:55:11ZakwizgranPrevent tag length from being used for active probingOn some transports it may be possible to use the fixed tag length to probe a transport endpoint to determine whether it's likely to be accepting BTP traffic: the endpoint will always accept (tag length - 1) random bytes but close the tra...On some transports it may be possible to use the fixed tag length to probe a transport endpoint to determine whether it's likely to be accepting BTP traffic: the endpoint will always accept (tag length - 1) random bytes but close the transport connection after (tag length) bytes.
It may be possible to address this by picking a random number for each incoming transport connection and reading that many bytes before deciding whether to accept the connection. The number could be anywhere between (tag length) and (tag length + stream header length). The number could be drawn from a distribution supplied by the TAP profile, allowing the distribution to be tailored to the transport.https://code.briarproject.org/briar/briar/-/issues/59Traffic analysis prevention layer2022-11-01T14:51:18ZakwizgranTraffic analysis prevention layerThe traffic analysis prevention (TAP) layer is responsible for preventing an observer from determining the volume and timing of data carried by a BTP stream.
What should the interfaces between BTP, TAP and the transport plugin look like...The traffic analysis prevention (TAP) layer is responsible for preventing an observer from determining the volume and timing of data carried by a BTP stream.
What should the interfaces between BTP, TAP and the transport plugin look like? Does the plugin need to be able to ask for a specific stream length, other than setting an upper bound? Are there any transports for which sending data as quickly as possible is preferable (from a TAP point of view) to sending it at a limited rate?
The TAP layer could adjust the transmission rate, increasing it if there's data waiting and decreasing it if not. What could the adversary learn by observing changes in the transmission rate and/or manipulating congestion?
Padding could be handled at the BTP layer by choosing a padding multiplier for each stream. The TAP layer would then sit between BTP and the transport and handle chopping and delaying the stream -- that is, segmenting the encrypted, padded stream according to some segment size distribution, and writing segments to the transport according to some inter-segment delay distribution.
The padding, size and delay distributions can be used to produce a characteristic traffic 'shape' for each device or pair of devices:
http://www.cs.kau.se/philwint/pdf/wpes2013.pdf
We can conceal traffic bursts by throttling the output of the TAP layer so that bursts are smoothed out. However, we should make good use of intermittently available transports -- if we send too slowly, the transport connection may be lost before we finish.https://code.briarproject.org/briar/briar/-/issues/58Use double MAC technique for checking MACs2020-11-21T20:17:47ZakwizgranUse double MAC technique for checking MACsComparing a received MAC to the expected MAC in constant time is tricky in high-level languages because the compiler, runtime and JIT may optimise the comparison code so that it no longer runs in constant time. The adversary may be able ...Comparing a received MAC to the expected MAC in constant time is tricky in high-level languages because the compiler, runtime and JIT may optimise the comparison code so that it no longer runs in constant time. The adversary may be able to use the timing of the comparison to discover how many bytes of the received MAC match the expected MAC.
To avoid revealing this information, the recipient can calculate another MAC over each MAC and compare the outer MACs. The adversary can use the timing of the comparison to learn the position at which the outer MACs differ, but that doesn't reveal the position at which the inner MACs differ.
https://www.isecpartners.com/blog/2011/february/double-hmac-verification.aspx
The MAC is being used as a PRF. It seems like this technique could also be used for validating signatures -- the validator can use any MAC key (not necessarily shared with the signer) to calculate MACs over the received and expected signatures, then compare the MACs.https://code.briarproject.org/briar/briar/-/issues/56Handle fatal errors2020-11-21T20:18:34ZakwizgranHandle fatal errorsWe should decide how to handle various errors that prevent the app from starting or continuing. Right now these are handled in ad hoc ways such as throwing an Error, which crashes the app. Situations we need to handle include:
* Can't o...We should decide how to handle various errors that prevent the app from starting or continuing. Right now these are handled in ad hoc ways such as throwing an Error, which crashes the app. Situations we need to handle include:
* Can't open the database
* Services fail to start
* Out of disk space
* Clock moves backwards
* Database state is inconsistent (DbStateException)
This is a UX issue as much as a programming issue. How do we communicate these errors to the user and what do we advise them to do?https://code.briarproject.org/briar/briar/-/issues/49Test the effect of clearing background processes2020-11-21T20:22:30ZakwizgranTest the effect of clearing background processesSamsung's task manager has a 'Clear memory' feature that clears inactive and background processes. Test what effect this has when Briar is running. Does it kill the Briar process and/or the Tor process? Does it call BriarService's `onLow...Samsung's task manager has a 'Clear memory' feature that clears inactive and background processes. Test what effect this has when Briar is running. Does it kill the Briar process and/or the Tor process? Does it call BriarService's `onLowMemory()` callback?https://code.briarproject.org/briar/briar/-/issues/48Test the effect of restricting background data2020-11-21T20:22:58ZakwizgranTest the effect of restricting background dataAndroid has settings to prevent individual apps or all apps from using background data. "Restricting background data usage for individual apps can sometimes be a useful way to reduce your overall data usage. However, this is a drastic me...Android has settings to prevent individual apps or all apps from using background data. "Restricting background data usage for individual apps can sometimes be a useful way to reduce your overall data usage. However, this is a drastic measure that may also affect the app's performance or cause it to malfunction."
https://support.google.com/nexus/answer/2819524
Test how these settings affect Briar.https://code.briarproject.org/briar/briar/-/issues/36Break up CryptoComponent interface2020-11-21T20:28:14ZakwizgranBreak up CryptoComponent interfaceThis monolithic interface should be separated into smaller interfaces relevant to different components.This monolithic interface should be separated into smaller interfaces relevant to different components.https://code.briarproject.org/briar/briar/-/issues/35Break up DatabaseComponent interface2020-11-21T20:28:33ZakwizgranBreak up DatabaseComponent interfaceThis monolithic interface should be separated into smaller interfaces relevant to different components.This monolithic interface should be separated into smaller interfaces relevant to different components.https://code.briarproject.org/briar/briar/-/issues/21Unit tests for encryption using test vectors2020-11-21T20:32:16ZakwizgranUnit tests for encryption using test vectorshttps://code.briarproject.org/briar/briar/-/issues/20Make messages searchable2020-11-21T20:32:52ZakwizgranMake messages searchableWhen a message is fully reassembled, extract a list of words from the message body and place them in a separate DB column, which can be full-text indexed.When a message is fully reassembled, extract a list of words from the message body and place them in a separate DB column, which can be full-text indexed.https://code.briarproject.org/briar/briar/-/issues/18Contacts can't communicate if clock difference is too large2021-07-28T10:11:31ZakwizgranContacts can't communicate if clock difference is too largeIf a device's clock is very inaccurate (e.g. because the user has adjusted the clock when travelling, rather than changing the timezone) then it's possible to add a contact, but not possible to communicate with the contact subsequently b...If a device's clock is very inaccurate (e.g. because the user has adjusted the clock when travelling, rather than changing the timezone) then it's possible to add a contact, but not possible to communicate with the contact subsequently because the devices disagree about which rotation period they're in.
We should check the clock difference when adding a contact and if the difference is excessive, display the time and timezone and warn the users to check that they're using the same timezone. We may also need to make the maximum expected clock difference much larger (on the order of 24 hours rather than an hour), as contacts may change their clocks after adding each other.