4 ms·

Really cool execution. Love the cyphertext view. The key exchange seems a little non-secure given the length of the sharing URL? How does it work?

by spolu 12y ago

buu700 12y ago
Thanks! As far as the crypto, right now it's just straight OTR (https://arlolra.github.io/otr/ https://arlolra.github.io/otr/), but we have some cooler stuff in the works for non-intrusive non-ephemeral encryption. I think the way we handle the URL mitigates a lot of potential issues (the design goal there was to make it as resistant to someone brute forcing the address space as possible, within reason): * It expires after 10 minutes, at which point it's immediately recycled * It's also immediately recycled the second the other guy connects to the cyph (meaning that, hypothetically, two unrelated pairs of people could be cyphing each other at the same URL) That isn't perfect on its own, but it's good enough for almost any use case. That said, in a few weeks we're also rolling out a two-factor auth feature to verify your friend via her phone number or email address, for when you really need to be sure. (We'll flesh this out a bit more later on, e.g. possibly integrating with Google Authenticator.)
- sweis 12y ago
  People can't trust that the site is actually serving the right JS crypto implementation. It can be broken at any time, which would allow the site to intercept communications. It needs client-side code to do it correctly, for example, something like the e2e Chrome extension.
  - buu700 12y ago
    Agreed that it's not a perfect solution (you still have to trust that I'm not brazenly serving up backdoored crypto), but it's a lot better than nothing. (And practically speaking, before building Cyph, Josh and I pretty much avoided having to use encryption except in cases where there was no alternative.) But I definitely agree that we'll have to come up with a clever solution to this problem. Off the top of my head (haven't thought this through — could be totally stupid), we may be able to do something clever with html5 appcache and notifying users when the hash of the code changes (and giving them the option to stay on their known good version). Of course, once we have our native app out this issue will be trivial to avoid for people who really need to. Edit: To clarify, I should correct you on that we are definitely performing the end-to-end encryption from the client — anything else would kinda defeat the purpose of Cyph...

Really cool execution. Love the cyphertext view. The key exchange seems a little non-secure given the length of the sharing URL? How does it work?

by spolu 12y ago

Really cool execution. Love the cyphertext view. The key exchange seems a little non-secure given the length of the sharing URL? How does it work?

buu700 12y ago

Thanks! As far as the crypto, right now it's just straight OTR (https://arlolra.github.io/otr/ https://arlolra.github.io/otr/), but we have some cooler stuff in the works for non-intrusive non-ephemeral encryption. I think the way we handle the URL mitigates a lot of potential issues (the design goal there was to make it as resistant to someone brute forcing the address space as possible, within reason): * It expires after 10 minutes, at which point it's immediately recycled * It's also immediately recycled the second the other guy connects to the cyph (meaning that, hypothetically, two unrelated pairs of people could be cyphing each other at the same URL) That isn't perfect on its own, but it's good enough for almost any use case. That said, in a few weeks we're also rolling out a two-factor auth feature to verify your friend via her phone number or email address, for when you really need to be sure. (We'll flesh this out a bit more later on, e.g. possibly integrating with Google Authenticator.)

sweis 12y ago
People can't trust that the site is actually serving the right JS crypto implementation. It can be broken at any time, which would allow the site to intercept communications. It needs client-side code to do it correctly, for example, something like the e2e Chrome extension.
- buu700 12y ago
  Agreed that it's not a perfect solution (you still have to trust that I'm not brazenly serving up backdoored crypto), but it's a lot better than nothing. (And practically speaking, before building Cyph, Josh and I pretty much avoided having to use encryption except in cases where there was no alternative.) But I definitely agree that we'll have to come up with a clever solution to this problem. Off the top of my head (haven't thought this through — could be totally stupid), we may be able to do something clever with html5 appcache and notifying users when the hash of the code changes (and giving them the option to stay on their known good version). Of course, once we have our native app out this issue will be trivial to avoid for people who really need to. Edit: To clarify, I should correct you on that we are definitely performing the end-to-end encryption from the client — anything else would kinda defeat the purpose of Cyph...