(no title)
yoklov | 4 years ago
1. What's the point? In end-to-end encryption situations usually the concern is around data storage (perhaps), but for just sending messages typically TLS is enough (or seems it, anyway, from my perspective as a non-security engineer)
2. The codebase seems to have separate C, Rust, and Elixir versions. Are they interchangeable, or do they serve different purposes?
Of these I only have rough answers. For the first, it seems like this solves the problem where, say, a single TLS connection isn't enough to get the data all the way to where it's needed (perhaps you need to go over bluetooth, or do multiple steps of HTTP, etc).
And for the second, well, I'm not sure. I think the C implementation might be equivalent, and be being replaced by the Rust one?
staticassertion|4 years ago
One use case I've used e2e for is password storage.
Assuming something like:
Browser -> nginx -> Web API -> Auth Service -> DB
This is a pretty common way to set up something like password auth, but a cleartext password will be exposed to nginx and your web api, for no reason, if you just use TLS. It's not uncommon for passwords to end up in request logs or that sort of thing in a system like this.
You could use ZKP, which gets you slightly stronger guarantees than e2e, but imo e2e is a really good sweet spot for solving this - the plaintext password will only be decrypted within a single function (the one that hashes it) in your secret server.
__mrinal__|4 years ago
1. The protections of TLS are constrained by the length and duration of the underlying TCP connection. If an application's data flow involves two or more TCP connections then TLS can't guarantee end-to-end data integrity and authenticity.
If an application involves communication between entities that are not online at the same time or if the data flow involves multiple transport protocols like the first hop is bluetooth and the second hop in TCP etc. - In all these cases TLS and other transport layer solutions cannot keep an applications data safe from forgery and tampering.
Turns out application entities are rarely connected by a simple point-to-point TCP connections - even the simplest web app these days is at least - on tcp hop to a load balancer, second tcp connection hop to an application web server. For example, in a different guide, we show how application data could remain end-to-end protected while traveling from Alice to a Cloud Service to Kafka to Bob https://github.com/ockam-network/ockam/tree/develop/document...
2. Our long term plan is to have Ockam libraries available in many languages. We started our development in C and Elixir and later added Rust.
Elixir - because it's easy to scale concurrent messaging systems on the Erlang BEAM virtual machine (see RabbitMQ, WhatsApp, Discord and many other messaging systems that have achieved scale with Erlang BEAM).
C - because we want to support embedded environments along with server environments. However, a few months into developing with C, our team discovered Rust and got very excited about how memory safety features of Rust eliminate a large class of security bugs. It is much easier to create performant yet loosely coupled abstractions in Rust - this makes it possible for us to keep our library modular and pluggable. Rust tooling is also a lot better than C so we've moved development focus from C to Rust.
Later we plan to wrap the Rust library in FFI wrappers and expose it in other languages (including C). The Ockam Elixir library already uses our Rust crates for various cryptographic features.
orangesite|4 years ago