Adding illustrations
This commit is contained in:
parent
1cadc489c9
commit
e5cba8e323
|
@ -7,3 +7,4 @@ title = "Cwtch Secure Development Handbook"
|
|||
|
||||
[output.html]
|
||||
mathjax-support = true
|
||||
default-theme = "navy"
|
||||
|
|
|
@ -7,6 +7,8 @@ To enhance this openness, automated builds, testing and packaging are defined
|
|||
as part of the repositories - improving te robustness of the code base at every
|
||||
stage.
|
||||
|
||||
![](/1.png)
|
||||
|
||||
While individual tests aren't perfect, and all processes have gaps, we should be
|
||||
committed to make it as easy as possible to contribute to Cwtch while also
|
||||
building pipelines and processes that catch errors (unintential or malicious)
|
||||
|
|
|
@ -6,6 +6,9 @@ ecosystem, to document the known risks and mitigations, and to enable
|
|||
discussion about improvements and updates to Cwtch secure development
|
||||
processes.
|
||||
|
||||
![](/2.png)
|
||||
|
||||
|
||||
## History
|
||||
|
||||
In recent years, public awareness of the need and benefits of end-to-end
|
||||
|
|
|
@ -6,6 +6,8 @@ and to conduct large scale social network analysis to feed mass surveillance.
|
|||
Metadata resistant tools are in their infancy and research into the construction
|
||||
and user experience of such tools is lacking.
|
||||
|
||||
![](/4.png)
|
||||
|
||||
Cwtch was originally concieved an extension of the metadata resistant protocol
|
||||
Ricochet to support asynchronous, multi-peer group communications through the
|
||||
use of discardable, untrusted, anonymous infrastructure.
|
||||
|
|
20
src/tapir.md
20
src/tapir.md
|
@ -130,6 +130,26 @@ we expect it to be protected via a preceeding app in an `ApplicationChain` e.g.
|
|||
|
||||
* No direct testing (tested via integration tests and unit tests)
|
||||
|
||||
### Ephemeral Connections
|
||||
|
||||
Occasionally it is desirable to have a peer conenct to another / a service
|
||||
without using their long term identity (e.g. in the case of connecting to
|
||||
a Cwtch Server).
|
||||
|
||||
In this case we want to enable a convenient way to allow connecting with an
|
||||
ephemeral identity.
|
||||
|
||||
It turns out that doing this securely requires maintaining a completely separate
|
||||
set of connections and applications in order to avoid side channel around avoid
|
||||
duplicate connections (i.e. if we did mix them up then a service might be able
|
||||
to exploit the fact that clients avid duplicate connections by attempting to
|
||||
connect to known-online peers and observing if they reject the connection
|
||||
because they already have an outbound ephemeral connection open.)
|
||||
|
||||
Because of this, we don't provide an explicit Ephemeral Connect api and instead
|
||||
recommend that peers maintain one long term service and multiple ephemeral
|
||||
services.
|
||||
|
||||
## Known Risks
|
||||
|
||||
### Impersonation of Peers
|
||||
|
|
Loading…
Reference in New Issue