Hacker News Reader

I couldn't agree more, and it's actually something I've been working on for the last few months, though in a sense for the last few years. I was going to do a Show HN in the next few weeks, but heck, may as well mention it now too.

What I'm working on is called Etebase. Etebase makes it easy to build end-to-end encrypted applications by taking care of the encryption and its related challenges such as data-integrity, data-deduplication, collaboration and etc. Everything is open-source, it uses libsodium[0] behind the scenes, and we plan on releasing a full spec soon as well as formally verify the protocol using Verifpal[1].

Website: https://www.etebase.com

Docs: https://docs.etebase.com

It's essentially a spin-off of the next version that powers my other project, EteSync[2] - a secure, end-to-end encrypted, and privacy respecting sync for your contacts, calendars and tasks.

Would love to hear your thoughts!

[0] https://doc.libsodium.org/

[1] https://verifpal.com/

[2] https://www.etesync.com

i don't wanna sound dismissive, i'm sure Etebase is a good fit for some things. but GP was asking for a crypto library, not a whole SaaS that will host all their chat data

No worries, you don't sound dismissive, though let me address your points:

First of all, Etebase is not "a whole SaaS", since it's open-source you can self host it, so the SaaS is optional.

As for what the GP was asking, I disagree. I think it's exactly what he was asking for. He was lamenting the lack of complete solutions, and having to figure out things on your own. Without the server part and network protocol, Etebase is essentially just libsodium, which GP already mentioned.

I'm glad I found this, I've been spending my morning looking at libsodium and it's secure box function. I'm doing a refactoring of Socii, my social network project, and want to add E2E encrpytion.

Your pricing looks good and I don't expect to have users for quite some time, haha.

Haha. :P

Please let me know (email: tom @ the domain) if you have any questions or feedback! Though I'd love to hear what you are working on anyway (I love hearing about new privacy projects!) so would be great to chat regardless.

This looks pretty cool, but to be perfectly honest. At the moment I'd be quite weary to use this. And the reason is that I have no idea who you are and if you can write crypto code. Please don't take this as an offence, i'm sure you do, but I have no way of verifying this.

So my heuristic so far has basically been "is this from someone who's known to know their shit", e.g. djb and/or "has this been audited by someone/some company that's known to know their shit".

In general though, an end2end encrypted open source firebase-like stack does sound pretty awesome though. But you'd need to publish at least one external audit of the crypto for me to consider using it.

Anyways, I have it bookmarked and wish you success!

Thanks for the feedback, and these are all fair concerns. Some points that would hopefully alleviate some of them: 1. We have been running EteSync for >3.5 years and have been in the space for much longer, so I'm not just some rando, though yes, I'm definitely not djb. :) 2. We use libsodium for everything so the harder crypto parts are audited and battle-tested. 3. We are going to formally verify the protocol. 4. We have been been awarded a grant by NLnet's PET fund and as part of that we will get a mini security audit. Though to be honest, I think the formal verification is a much more serious assurance.

With that being said, I'm not trying to convince you. I think it's a very important point that we are working on addressing.

> Next you realize people aren't always online at the same time and you can't send offline messages. So you remember Signal's double ratchet

The part that enables sending messages to an offline person is uploading an ephemeral key and one time keys to the server.

The problem with libraries is many parts here aren't strictly cryptographic at all. So say one time keys. The server has keep track of them and your client also has to save them and keep track of them. Once in a while the client will have to replenish the keys on the server. It's hard to librarize this without being very imposing as to the implementation. And the actual cryptographic part isn't too different from normal DH schemes at all.

You should take a look at the library written by the author of this post (and the rest of my team), Tink [1]. It's written so that we can do security reviews at Google more easily, by making sure that the crypto library is fairly hard to misuse, in particular that the crypto library integrates well with key management.

[1] https://github.com/google/tink

>I of course agree with all of this, but as someone pretty much at the bottom of the food chain who just wants to encrypt some data, there's often no libraries that safely glue the primitives together in the way that I require.

>I hope this doesn't come off as entitled, but I feel like the best way to get people to stop rolling their own crypto is to provide more/better libraries.

Author here. I mentioned libsodium [1] and Tink [2]. We started Tink because we want to provide more/better libraries.

>Granted, this is getting better, for example NaCl's crypto_box[0] is awesome and very hard to misuse. But say you want forward secrecy now. chirp, tumbleweed.

It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?

[1] https://github.com/jedisct1/libsodium

[2] https://github.com/google/tink

> It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?

I don't have any particular plans of something I want to build at the moment. I was just using group chat as an example where there on one hand you're told to not roll your own crypto, but otoh you can't really just use someone else's crypto because there's no way to just use it.

Say I want to use an encrypted transport, that's trivial, I can just use TLS relatively easy. For the most straight forward case i can do `http.Get("https://example.org")` in go and not have to worry at all about the crypto.

If I want E2E, there's libsodium and tink, yes. But then am I "allowed" to build e.g. a forward secrecy scheme using ephemeral keys with these libraries? On one hand I know enough about crypto that I could do that, otoh, I also know enough about crypto that doing so would already make me uncomfortable.

So what I dream about is to have something like "ssh/tls" for E2E. Something like libsignal generalized. Of course you will have to do some key management, and it will never be as simple as `http.Get("https://example.org")`.

The libsodium secretstream API supports ratcheting and forward secrecy by rekeying on every exchange:

https://doc.libsodium.org/secret-key_cryptography/secretstre...

That only prevents attackers who read the current symmetric key from reading past messages. That won't protect you against the disclosure of a private key involved in the prior key exchange. https://doc.libsodium.org/key_exchange

The only way to achieve true forward secrecy is to throw away the private half of the involved key pairs. You need ephemeral keys. Which Libsodium does not provide out of the box. You'd need something like Noise. https://noiseprotocol.org/

I don't think you would ever want to choose a complicated protocol like Signal if you were not intimately familiar with how it worked. There would be a lot of ways for things to go wrong. If you understood the problem that well you are probably safer doing something simple targeted to your particular problem.

You don't need all the crypto features all the time.

Added: A good example based on the suggested need for forward secrecy. Forward secrecy only protects against the disclosure of a private key. In almost all cases, the ability to get a private key is going to mean that you also get any saved messages. So if your chat application requires the long term storage of old messages then you can skip the forward secrecy part.

It's more important property is keeping messages that are scooped up by malevolent 3 letter agencies secure if a random message in the middle is cryptographically broken.

Forward secrecy does not protect against a break of the cryptography.

No, but it does multiply the cost. It means instead of breaking one key per conversation, there would be many. That could be the difference required.