Ockam VS ring

disclosure: I work at Ockam.

The Portals for Mac app is an example of the type of thing you could build using the open source stack of protocols. The README (linked by parent) links out to all of the relevant parts of the protocol documentation to explain how these work together. The NAT Traversal (https://github.com/build-trust/ockam/blob/develop/examples/a...) part of the README is probably the best explanation of why the free relay you get via Ockam Orchestrator is a useful part of this demo.

As for why would anyone trust this: The protocols are designed so you absolutely don't have to trust the relay. Trust is pushed out to the edges that you control and so you're not susceptible to a MITM attack if something like a relay is compromised. The protocol design for all of this is open and documented, and was independently audited by (IMO) some of the best in the business, Trail of Bits: https://docs.ockam.io/reference/protocols.

🚀 Portals for Mac – A macOS app built in Swift that uses the Ockam Rust library to privately share a service on your Mac with anyone, anywhere. The service is shared securely over an end-to-end encrypted and mutually authenticated Ockam Portal. Your friends will have access to it on their localhost! This app is a great example of the kinds of things you can build with Ockam 👉

Ockam is a suite of programming libraries, command line tools, and managed cloud services to orchestrate end-to-end encryption, mutual authentication, key management, credential management, and authorization policy enforcement — all at massive scale. Ockam's end-to-end secure channels guarantee authenticity, integrity, and confidentiality of all data-in-motion at the application layer.

We’ve been working on something (https://github.com/build-trust/ockam) that enables exactly this, among a whole host of other use cases. If you check out some of the code examples in the docs you’ll see how to setup a tunnel using the CLI.

For other use cases there’s also the programming libraries (only Rust atm, though I was spiking a TypeScript/Node PoC this week) which might provide more flexibility. Personally I’m excited by the idea of being able to move this kind of secure by design connectivity all the way into the application layer though.

If you're not already an active contributor to an open source project or two it can seem very daunting. You don't want to do the wrong thing and embarrass yourself. Remove that anxiety for people by giving them an easy way to do something low risk. Matt did that a couple of years ago by creating a long-lived issue for people to simply say hello. That's it. Say hi, introduce yourself. It's a safe place to make a first step.

Again, this is just a temporary situation, and a matter of burning down a list of small tasks. Not that the OpenSSL license issue is a big deal for most anyway. Feel free to help; see this issue filed by Josh Triplett: https://github.com/briansmith/ring/issues/1318#issuecomment-...

Note also that rustls depends on ring, which has architecture-dependent code in it that is not as widely compatible as eg. OpenSSL/GnuTLS/Mbed-TLS. For example, MIPS is not supported by ring.

The AWS Rust library we were using as a dependency depended on a cryptography library called ring. This library leverages C and assembly code to implement its cryptographic primitives. Unfortunately, cross compiling when C is involved can add complexity to the build process. While it might've been possible to overcome these issues I decided that it wasn't worth digging into more.

That'd be great. Thanks Brian. Re: making ring portable to all platforms: IBM have been graciously maintaining a up to date patchset for Ring for years now and there's an outstanding PR here you may not have seen since they filed it in 2020... https://github.com/briansmith/ring/pull/1057

Beyond the simple matter of Rust being much newer than OpenSSL, one concern for some cryptographic primitives is the timing side-channel.

https://en.wikipedia.org/wiki/Timing_attack

In high level languages like Rust, the compiler does not prioritise trying to emit machine code which executes in constant time for all inputs. OpenSSL has implementations for some primitives which are known to be constant time, which can be important.

One option if you're working with Rust anyway would be use something like Ring:

https://github.com/briansmith/ring

Ring's primitives are just taken from BoringSSL which is Google's fork of OpenSSL, they're a mix of C and assembly language, it's possible (though fraught) to write some constant time algorithms in C if you know which compiler will be used, and of course it's possible (if you read the performance manuals carefully) to write constant time assembly in many cases.

In the C / assembly language code of course you do not have any safety benefits.

It can certainly make sense to do this very tricky primitive stuff in dangerous C or assembly, but then write all the higher level stuff in Rust, and that's the sort of thing Ring is intended for. BoringSSL for example includes code to do X.509 parsing and signature validation in C, but those things aren't sensitive, a timing attack on my X.509 parsing tells you nothing of value, and it's complicated to do correctly so Rust could make sense.

machine learning, neural networks, image processing, cryptography (though it is getting better), font shaping/rendering (though it is getting better), CPU/software rendering (though it is getting better)