6 ms·

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 t

by lawl 6y ago

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. 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. 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. Say you have a requirement to build some chat somewhere, and it sais somewhere that it needs to be encrypted, which I think is a reasonably realistic example. So you use crypto_box, but then you realize you don't have forward secrecy. Ok, no problem, you remember libotr[1] just use that. Now you realize that OTR can't do group chats, so figure ok, most group chats are small everyone can just have an OTR session with everyone else and send their messages to everyone (which of course means you can give different people different messages, but let's ignore that). 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[2]. But libsignal was just built for signal and doesn't look easily integratable. Then I guess there's also (Meg)Olm[3] but that looks like the same story as signal. [0] https://nacl.cr.yp.to/box.html https://nacl.cr.yp.to/box.html [1] https://otr.cypherpunks.ca/ https://otr.cypherpunks.ca/ [2] https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm [3] https://gitlab.matrix.org/matrix-org/olm/-/tree/master https://gitlab.matrix.org/matrix-org/olm/-/tree/master

tasn 6y ago
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 https://www.etebase.com Docs: https://docs.etebase.com 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/ https://doc.libsodium.org/ [1] https://verifpal.com/ https://verifpal.com/ [2] https://www.etesync.com https://www.etesync.com
- uryga 6y ago
  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
  - tasn 6y ago
    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.
- NetOpWibby 6y ago
  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.
  - tasn 6y ago
    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.
- lawl 6y ago
  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!
auganov 6y ago
> 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.
michelpp 6y ago
The libsodium secretstream API supports ratcheting and forward secrecy by rekeying on every exchange: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre...
- loup-vaillant 6y ago
  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 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/ https://noiseprotocol.org/
upofadown 6y ago
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.
- eximius 6y ago
  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.
  - upofadown 6y ago
    Forward secrecy does not protect against a break of the cryptography.
    - eximius 6y ago
      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.
cryptokitty2 6y ago
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 https://github.com/google/tink
cryptbe 6y ago
>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 https://github.com/jedisct1/libsodium [2] https://github.com/google/tink https://github.com/google/tink
- lawl 6y ago
  > 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")` 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")` https://example.org")`.

by lawl 6y ago

tasn 6y ago

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 https://www.etebase.com Docs: https://docs.etebase.com 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/ https://doc.libsodium.org/ [1] https://verifpal.com/ https://verifpal.com/ [2] https://www.etesync.com https://www.etesync.com

uryga 6y ago
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
- tasn 6y ago
  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.
NetOpWibby 6y ago
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.
- tasn 6y ago
  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.
lawl 6y ago
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!

auganov 6y ago

> 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.

michelpp 6y ago

The libsodium secretstream API supports ratcheting and forward secrecy by rekeying on every exchange: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre...

loup-vaillant 6y ago
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 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/ https://noiseprotocol.org/

upofadown 6y ago

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.

eximius 6y ago
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.
- upofadown 6y ago
  Forward secrecy does not protect against a break of the cryptography.
  - eximius 6y ago
    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.

cryptokitty2 6y ago

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 https://github.com/google/tink

cryptbe 6y ago

>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 https://github.com/jedisct1/libsodium [2] https://github.com/google/tink https://github.com/google/tink

lawl 6y ago
> 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")` 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")` https://example.org")`.