3 ms·

What's the suggested method to securely exchange the key? It feels a bit like this is a step backwards in many ways. Being a non-webmail user, how can I benefi

by anemitz 13y ago

What's the suggested method to securely exchange the key? It feels a bit like this is a step backwards in many ways. Being a non-webmail user, how can I benefit from this? If this were an implementation of SMIME/GPG it would be more widely adoptable since anyone with a compatible GMail plugin, desktop, or mobile client could use this. Edit: Good read about JS encryption and its downsides: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/

StavrosK 13y ago
I also couldn't find a link to the source to sort-of audit it, so, caveat user.
- joebadmo 13y ago
  You mean this? https://github.com/StreakYC/StreakSecureGmail https://github.com/StreakYC/StreakSecureGmail It's right there under "Open Source"
  - StavrosK 13y ago
    Contextual blindness, thanks. EDIT: Audit results: It just uses the SJCL, looks good to me.
OmarIsmail 13y ago
The intention of this isn't to be the most secure solution on the planet - you're not going to be using Gmail if that's the case. Instead we wanted to build a starting point that was A) easy to use, and B) easy to extend. Our initial plan was to use a GPG solution, but that introduced a lot of complexity to the UX and also had other security holes. But the main thing is that if something is too complicated, it's not going to be used by the broader masses - kind of like GPG right now. With this solution only the sender has to have the extension installed to send an encrypted email.
- gholap 13y ago
  "With this solution only the sender has to have the extension installed to send an encrypted email." Hmm... but to read the mail, even the receiver needs to have the extension. I don't see much point in advertising "only sender needs the extension" bit.
  - alooPotato 13y ago
    I think the distinction is that the receiver need not have signed up or installed anything at the time the message is sent. That is, the sender need not worry if the receiver is currently using SecureGmail, they can send the message now and the receiver can install the extension later.

by anemitz 13y ago

StavrosK 13y ago

I also couldn't find a link to the source to sort-of audit it, so, caveat user.

joebadmo 13y ago
You mean this? https://github.com/StreakYC/StreakSecureGmail https://github.com/StreakYC/StreakSecureGmail It's right there under "Open Source"
- StavrosK 13y ago
  Contextual blindness, thanks. EDIT: Audit results: It just uses the SJCL, looks good to me.

OmarIsmail 13y ago

The intention of this isn't to be the most secure solution on the planet - you're not going to be using Gmail if that's the case. Instead we wanted to build a starting point that was A) easy to use, and B) easy to extend. Our initial plan was to use a GPG solution, but that introduced a lot of complexity to the UX and also had other security holes. But the main thing is that if something is too complicated, it's not going to be used by the broader masses - kind of like GPG right now. With this solution only the sender has to have the extension installed to send an encrypted email.

gholap 13y ago
"With this solution only the sender has to have the extension installed to send an encrypted email." Hmm... but to read the mail, even the receiver needs to have the extension. I don't see much point in advertising "only sender needs the extension" bit.
- alooPotato 13y ago
  I think the distinction is that the receiver need not have signed up or installed anything at the time the message is sent. That is, the sender need not worry if the receiver is currently using SecureGmail, they can send the message now and the receiver can install the extension later.