Note: the current development discussion lies in the Signal Extensions section of the low-level subproject. The below is an overview of our larger goals with this project.

We want to build two prototypes of a cryptosystem to support anonymous, group-fungible identities. Eventually, our goal is to additionally support forward-secret verification and legacy GPG interop. We propose to build this on top of the Signal double ratchet ¹ and X3DH algorithms ² as follows:

1. minimal: use the Signal Protocol, adding CLI commands to create and manipulate a special new class of group-fungible identities.
2. gpg: expose an inter-group message type which creates ephemeral gpg keys for signing, encryption, and/or decryption.
3. full: we perform a collaborative design process on what app(s) we want to build and what
4. live: make a p2p protocol, or a single server which supports our modified "grouplink" protocol.
5. safe: research traffic anonymization and formal analysis to conclude that our system is safe.

We also obsolete the blockchain concept in a later proposed extension.

We will attempt to apply these wherever reasonable.

• A very very simple theoretical model (all units are dimensionless (?)) for how long a parallel computer could take to crack a private key given a public key, if it had started at the exact time the public key was created.
• This should be an upper bound against brute-force attacks!
• Assuming it started when the key was created assumes that essentially all of your messages are being listened to (!).
• We should probably not allow users to update the base "speed" -- let it be hardcoded in the app but specified as a variable in the model.

• A UX paradigm wherein all security risks are represented next to the content in the UI, updating over time.
• The point is to never rely on synchronous acknowledgements hidable UI.
  • Instead, at all times, we represent the theoretical risk of some data having been hacked using simple to understand rules!

ALTHOUGH: we should avoid solutions which dump the responsibiity on the user!

Use the let users prompt themselves model to warn about message tampering, according to a function calculated by the estimated "safety against fast supercomputer value of the private keys in the message and when the message was first created.

• A user can attach a variety of special statuses (revoked, forwarding address, etc) to an identity.
• This helps to manage so many identities!

A user may post an arbitrary signed public text status to their own "wall with the tamper notification protocol.

• they may also post arbitrary messages on someone else’s wall to be visible to others — perhaps to warn them the user is dangerous.
• we pretend this helps the cops and design it so it does not help the cops.
  • rather, this is the basis of an effective self-moderation process!.
  • which itself would be worthy of its own paper.
• "provable" DDOS safety against:
  • automated trolls, aka Democracy DDOS
    • When viewing, filter out wall entries from people you don’t know.

• Confirmed that the Signal Protocol itself has no dependency on a phone number, just the app.
• We are now wrapping the rust signal protobuf library [^libsignal-rust].
• Perform a minimal enc/dec test for a buffer.
• Perform a minimal encrypted session.
  • Discuss memory motion through the stores a bit with @ireneista and co.
    • Try to agree on which actions/entities each corresponds to in the double-ratchet ¹ or sesame ³ protocols.

Then, see if the following still makes sense:

• Add an "endpoint" to the Signal Protocol to create a new group-fungible identity, which doesn't do anything yet.
• Add corresponding endpoints for:
  • Adding another such identity to the group.
  • Sending a message to the group.
  • Sending a message as the group (hence making it "group-fungible").

• Modify the Signal Protocol library [^libsignal-protocol-c] to use group-fungible identities instead of UserIDs.
• Make it work in a CLI tool.
  • i.e. externalize the identities and message keys into concrete files.

• Encrypted messages can be sent between group-fungible identities in a test case.
• A Rust CLI tool can create and send group-fungible messages with a modified version of the Signal Protocol library.

• Create a group message type which produces a public/private GPG key pair.
  • This should be very similar to the result of a "DH ratchet" step in the double ratchet protocol ¹.
  • This should use libgcrypt ⁴.
• This should be parameterizable by sign/encrypt/decrypt.
• This should produce all necessary keys to send an encrypted message from one group to another.
• This should upload all generated public keys to a keyserver.
• This should interop with static GPG identities.

Ephemeral GPG identities can be created and used for:

1. forward-secret signatures
2. legacy GPG interop

• Create a server implementing the above "grouplink" protocol with GPG support, either by:
  • modifying the Signal Server ⁵ to invoke the rust CLI tool.
  • (preferred) creating a rust server which extends the code from the CLI tool.
  • extending the grouplink protocol into a p2p communication (TODO: next consider anonymization!).

An arbitrary device can perform the operations of the grouplink protocol with GPG support by sending encrypted requests to an externala server, or through a p2p protocol.

The below are a bunch of things we thing are of relative importance to user safety on a technical, UX, and docs level.

• Implement all elements of identity management!!!

• Consider whether the Cryptol ⁶ tool can validate any properties we want to validate.

Then consider this discussion:

• Consider the configuration options we want to present to the user:

@turingtarpit "think about whether there’s any room for letting the user configure to have degraded service in some situations for increased privacy" @ireneista there's a trade-off in terms of actually implementing it any time you add something the user can configure, if the setting they chose can be detected by an attacker, the attacker can use it to fingerprint them so we'll want to provide a minimal number of settings so as not to leak too many bits

yep! 33 bits of entropy identifies anyone (because log base 2 of 8 billion is 33); we can document how much each setting leaks though in reality the bits leaked in theory are just an approximation, because users don't choose all possible values uniformly but it's still good to document so we can ballpark things

Then consider (more) our approach to elliptic curve encryption:

• Consider introducing elliptic curve encryption methods via libgcrypt:

@vintroxx: main benefit of ECC is smaller key lengths but a lot of the curves aren't necessarily trustworthy. would recommend curve25519 though

good resource: ⁷

• Proposes a cryptographically signed ledger on top of the grouplink system.
• Ledger groups only send public signed messages with:
  • source signature
  • dest signature
  • amount (uninterpreted unicode text)
  • a list of ledger signatures, starting with a signature for all the above items in the current message
  • a signed ledger signature of the checksummed contents of the previous block
• ledgers are normal groups — users must both be members to send a group message
• a send is directional, with three individual messages required:
  • A CREATES ledger group and INVITES B.
  • A sends ledger message which SENDS money to B’s public key.
  • B RECEIVES message and SENDS: "B saw this" (signed).
• A server which supports ledgers would then overwrite a single current block with a new one containing this info.
  • There would be configuration available (for the owner of the ledger) where to ferry off the ledger entry to to make it real.
    • if that config exists, retrieve and send the block to any number of other known ledgers (your bank, ideally)
    • Oh and your only banking identity is just a separate ledger chat with your bank’s public identity.
      • You should be able to stay as a completely anonymous identity, and present only a credential with secret info signed by your bank.
• This would be a really neat way to test traffic anonymization techniques ⁸, since it's easier to chunk money than messages.

But also, banking isn’t as important as cryptographically auditing corporations!!!! If we require corporations to produce such a blockchain of their accounting, it can be cryptographically verified at each step. This should be good for accounting folks so they can know exactly who introduced a change.

AGPLv3 (not any later version): https://www.gnu.org/licenses/agpl-3.0.html

[^libsignal-rust] https://github.com/signalapp/libsignal-client