[tor-dev] Some Gosling Updates!

[Richard Pospesel]

Hi Everyone!

It's been a minute since the last time I posted to this list about 
Gosling (December, 2021 what the actual heck: 
https://lists.torproject.org/pipermail/tor-dev/2021-December/014684.html 
). Well, since then I have been quite busy leading the applications team 
and shipping browsers by day, and developing Ricochet-Refresh and 
Gosling by night!

To summarise, gosling is a Rust crate (and cgosling is a C-FFI library) 
which generalises and encapsulates all the hard parts of building 
peer-to-peer applications using tor, where a peer's long-term identity 
is an onion-service id. My vision and hope is that this allows for the 
creation new peer-to-peer applications with all of the various 
properties and guarantees of tor baked in, and that developers won't 
need to go spend some years becoming tor experts to do it correctly and 
safely.

The next version of Ricochet-Refresh will be using Gosling as its 
foundation, and so of course heavily informed Gosling's features and 
development direction.

The specific properties/features offered by Gosling:

- long-term peer identity: an onion-service id
- anonymous: it's onion-services and tor
- secure: end-to-end encrypted from tor-client to tor-client because tor
- nat-punching: more tor
- censorship-circumvention: tor + pluggable-transports and bridges

Ok and the novel/harder stuff:

- authentication: cryptographically prove connecting clients control the 
private key of their claimed onion-service identity and their provided 
client-auth keys
- customisable/application-specific handshakes: on top of the baseline 
cryptographic authentication, the 'add me as a peer' handshake also 
allows for an additional challenge+response requirement; imagine for 
instance a one-time code verification, password verification, socialist 
millionaire scheme, proof-of-work or stake, etc
- metadata-resistant: the only metadata available to untrusted clients 
is your primary identity's onion-service's online/offline status; this 
onion-service is not required to be online to connect with trusted 
clients (unlike with other Ricochet-derived IM clients)

If any of this sounds exciting or useful to you, I'd love to invite you 
over to the project Github to take a look:

- https://github.com/blueprint-freespeech/gosling

I'm hoping for Gosling to hit version 1.0.0 and lock-down/converge on a 
plausible stable API before the end of this year. The current API 
surface is very informed by my experience with what would be useful for 
Ricochet-Refresh, but I'm sure there are blind-spots here or 
improvements that could be made for other potential use-cases.

The goal from day one has been to make this code usable outside the Rust 
ecosystem. To that end, I've tried to make the C-FFI API design 
consistent, familiar and safe as possible, since it eventually will be 
used from Ricochet-Refresh's C++ codebase.

---

The vast majority of the protocol work and initial implementation was 
completed around the beginning of 2023. So what have I been up to for 
the past couple years?

Basically, all of the 'boring' (quite exciting actually) software 
engineering work to get Gosling both usable and trustworthy. To be 
specific, I've been working on the following areas:

- code-cleanup: refactored Gosling into separate crates which may be 
individually useful:
   - honk-rpc: the bson-based, json-rpc inspired RPC protocol
   - tor-interface: probably should have a better name, but this 
encapsulates the tor-daemon configuration and lifecycle, control-port 
communications, and connectivity
   - gosling: the Rust protocol implementation
   - cgosling: gosling wrapped in a safe+friendly C-FFI
- improved CMake project layout; cgosling should be relatively 
usable/integratable into existing CMake projects
- build+test automation: build and run tests on github CI/CD Linux, 
macOS, and Windows runners, publish code-coverage, generated Rust 
documentation, doxygen C/C++ documentation
- fuzzing: fuzz the Rust crates including the C-FFI
   - identified and fixed a lot of bugs in the entire stack this year :D
- language bindings: build a cbindgen -> c-header -> json idl pipeline 
for the cgosling crate; json idl used to automatically generate:
   - C/C++ headers, static+shared libraries
   - python bindings to shared library
   - Java/JNI shared library and jar
- packaging/deployment
   - published Rust crates to crates.io
   - deb-source package generation for debian-based Linux
   - homebrew flask formula generation for macOS
   - MSYS2 pkgbuild generation for Windows
- some minor new features:
   - connect API to connect to non-gosling onion-services and clearnet 
targets using tor
   - use an already-running tor rather than running/configuring own tor 
process
   - configure bundled tor with all the familiar stuff: proxy, firewall, 
pluggable transports, and bridges
- initial protoyping for in-proc arti-client backend (currently on 
version 0.18 so a bit behind)

The remaining planned work in this area before hopefully shifting my 
focus back on Ricochet-Refresh are a documentation pass on all my Rust 
crates, cleaning up/documenting the example projects, and completing a 
security audit. The Java and Python bindings could also use some love 
and automation.

--

Anyway, I think that's enough technical non-sense for your inbox. If any 
of this sounds interesting, come check things out the project website ( 
https://gosling.technology/ ) which links to all the relevant stuff.

best,
-richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xDE47360363F34B2C.asc
Type: application/pgp-keys
Size: 8030 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240706/e39d8f5a/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240706/e39d8f5a/attachment.sig>