Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 694
    • Issues 694
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 16
    • Merge Requests 16
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #59

Closed
Open
Opened Dec 01, 2015 by akwizgran@akwizgranOwner

Traffic analysis prevention layer

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.

Edited Nov 21, 2020 by Cleopatra
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: briar/briar#59