5 ms·

To play the devil's advocate, what exactly is the practical use of all this if most of your family and friends are on Gmail (and couldn't be arsed to figure out

To play the devil's advocate, what exactly is the practical use of all this if most of your family and friends are on Gmail (and couldn't be arsed to figure out pgp)? From what I can see, your emails will now be sent in the clear over the internet, instead of staying within google's servers. Either way, the government's going to get your data, but at least you're protected against... /more/ unscrupulous people snooping on your stuff?

thex86 13y ago
That's a great point. Reminds of the time I taught my friend to use PGP and sent him an encrypted email. Every single time, he would reply in plain-text, thus exposing my older conversation. When asked why, he told me it's too much of a pain to do it. So my being careful about my privacy doesn't help if other people don't play along.
- eru 13y ago
  The OTR plugin for Pidgin does a better job of userfriendliness and gives more useful privacy guarantees (like plausible deniability).
  - shrikant 13y ago
    FYI, last I remember, Pidgin stored your passwords in plaintext in an ASCII file on disk, unless you jumped through some hoops to integrate it with your desktop environment's keyring. They even have a article up on their site explaining why it's necessary to do this.
    - eliasmacpherson 13y ago
      https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords well that's just great.
    - claudius 13y ago
      You can disable storing passwords. If you don’t want to have to enter a ‘master password’ when Pidgin starts up, there is no way they can store the passwords more securely than plaintext. Get full disk encryption and be happy.
      - MichaelGG 13y ago
        That's simply not true. For example, on Windows, they can use CryptProtectData. Mac OS has a keychain function too. Pidgin devs are being disingenuous by suggesting that accessible to current user is identical to storing plaintext on disk. Full disk encryption and per-user encryption are good steps. But an accidental backup of Pidgin will still reveal passwords that would be safe if they bothered to use platform specific APIs for such storage.
        claudius 13y ago
        Pidgin is predominantly developed for Linux, where they would have to support Gnome, KDE and probably at least one other mechanism. Sure, that could be done, but it is a lot of work to do that sensibly on all platforms, and, more importantly, of questionable sense: I would classify the logs of my conversation as much more relevant to a potential attacker than the mere password to my XMPP account.
        MichaelGG 13y ago
        All of this is true. But when the Pidgin devs state things like "there's no way" and "it's just as secure" (as they do on the wiki), that's just incorrect. An intellectually honest description would note that many platforms offer protection, but it's not standardized across Linux (I'm assuming). The logs of the conversation can be protected in the same way, so I'm not sure what that has to do with anything. (Although you might wish to keep logs as plaintext, to facilitate backups, if you're not backing up the user's keychain info.)
        claudius 13y ago
        The wiki explicitly says (under “Is that the final word?”): > No. The Pidgin developers are generally open to, and would encourage integration with keyrings (KeyringSupport). and then goes on to state that this is difficult to do, since Pidgin runs on so many different platforms, then stating again that they will happily accept such patches. However, I find it understandable, that the devs don’t go out of their way to support use-cases they don’t feel necessary to support. On their systems, they trust the filesystem and are happy with that, if others don’t have that level of trust in their computer, that’s fine, but not necessarily their problem. My point about the logfiles was that to store these in the keyring (rather than a key to the encrypted files) would probably annoy the keyring somewhat (at least the poorer implementations thereof), given that it is intended for use with few-byte passwords and not multi-megabyte logfiles.
- 1337Coder 13y ago
  This is the exact reason I created this: https://privatemsg.matthew-dove.com/ https://privatemsg.matthew-dove.com/
  - urza 13y ago
    Where can I grab source code?
- kybernetikos 13y ago
  I've been experimenting with encrypting using bitcoin addresses, publishing keys with gravatar and sending encrypted messages as links as a way of trying to make all this stuff easier and more accessible. If you're interested in my proof of concept, it's http://kybernetikos.github.io/VisualSecrecy/ http://kybernetikos.github.io/VisualSecrecy/
  - Domenic_S 13y ago
    Linking bitcoin address to email address doesn't sound like a step forward in privacy...
    - kybernetikos 13y ago
      Depends what you want to use it for. Anyway, you can have multiple bitcoin addresses for different purposes. On top of that, while I wouldn't rely on this cryptographically, the relationship is one-way. Gravatar links email addresses to gravatar images, but it's not intended to link in the other direction, so the same is true for any information stored in the gravatar. You can use my system to reply with encrypted text to a comment on a blog post without knowing the email address of the person you're replying to, only their gravatar image.
- gtt 13y ago
  Can such kind of reply put your secret key in the risk? For example, it gives attacker enough information to deduce the key within reasonable time?
  - tlrobinson 13y ago
    I don't believe so. I think the parent comment was more concerned about the message itself being sent in the clear.
joe_bleau 13y ago
I see encrypted connections to/from gmail all the time. Here's an example from a test I just ran: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.79.27]:25: TLSv1 with cipher RC4-SHA Anonymous TLS connection established from mail-yh0-f48.google.com[209.85.213.48]: TLSv1 with cipher RC4-SHA
- bigiain 13y ago
  Hmmm, no Perfect Forward Secrecy on RC4-SHA... Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?
  - joe_bleau 13y ago
    It could be an artifact of my postfix configuration. Looking over a few logfiles, here are the ciphers I've seen recently (all servers, not just gmail): ADH-AES256-SHA (256/256 bits) AES128-SHA (128/128 bits) AES256-SHA (256/256 bits) DHE-RSA-AES256-SHA (256/256 bits) EDH-RSA-DES-CBC3-SHA (168/168 bits) RC4-SHA (128/128 bits)
    - bigiain 13y ago
      Curiously, I'm seeing a bunch of TLSv1:DHE-RSA-AES256-SHA:256 between one of my machines and google... I wonder why/when the connections end up RC4-SHA instead?
      - viveksec 13y ago
        Google serves up static content uses DHE. We've noticed only Google sites using DSA certs with ECDHE. A report on what we found http://trisul.org/blog/dsa-xdrill/post.html http://trisul.org/blog/dsa-xdrill/post.html
  - viveksec 13y ago
    > Hmmm, no Perfect Forward Secrecy on RC4-SHA... Actually dont see how you can have PFS on DHE either if one of the endpoints doesnt co-operate. You can simply dump the master keys and provide those to the decrypting app.
sliverstorm 13y ago
None of it is impermeable, even your own server. It's just another layer of misdirection and/or difficulty.
tubelite 13y ago
The shuttering of Reader and Gmail's new and awful Compose have convinced me - more than years of Stallman rants and NSA snooping - that relying on closed-source SaaS is a terrible idea. It is a question of if, not when, your SaaS provider does something you intensely dislike, and which you have no power to change. With SaaS, you don't even have the power to say - Damn your improved version, blast your hip new design, I will stick with the old one, thankyouverymuch. You are always on Version Now. The more intertwined your relationship and dependence on integration with related products, the messier the ensuing divorce. This, to my mind, represents a far more inevitable reason to figure a way out of GMail.

thex86 13y ago

That's a great point. Reminds of the time I taught my friend to use PGP and sent him an encrypted email. Every single time, he would reply in plain-text, thus exposing my older conversation. When asked why, he told me it's too much of a pain to do it. So my being careful about my privacy doesn't help if other people don't play along.

eru 13y ago
The OTR plugin for Pidgin does a better job of userfriendliness and gives more useful privacy guarantees (like plausible deniability).
- shrikant 13y ago
  FYI, last I remember, Pidgin stored your passwords in plaintext in an ASCII file on disk, unless you jumped through some hoops to integrate it with your desktop environment's keyring. They even have a article up on their site explaining why it's necessary to do this.
  - eliasmacpherson 13y ago
    https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords well that's just great.
  - claudius 13y ago
    You can disable storing passwords. If you don’t want to have to enter a ‘master password’ when Pidgin starts up, there is no way they can store the passwords more securely than plaintext. Get full disk encryption and be happy.
    - MichaelGG 13y ago
      That's simply not true. For example, on Windows, they can use CryptProtectData. Mac OS has a keychain function too. Pidgin devs are being disingenuous by suggesting that accessible to current user is identical to storing plaintext on disk. Full disk encryption and per-user encryption are good steps. But an accidental backup of Pidgin will still reveal passwords that would be safe if they bothered to use platform specific APIs for such storage.
      - claudius 13y ago
        Pidgin is predominantly developed for Linux, where they would have to support Gnome, KDE and probably at least one other mechanism. Sure, that could be done, but it is a lot of work to do that sensibly on all platforms, and, more importantly, of questionable sense: I would classify the logs of my conversation as much more relevant to a potential attacker than the mere password to my XMPP account.
        MichaelGG 13y ago
        All of this is true. But when the Pidgin devs state things like "there's no way" and "it's just as secure" (as they do on the wiki), that's just incorrect. An intellectually honest description would note that many platforms offer protection, but it's not standardized across Linux (I'm assuming). The logs of the conversation can be protected in the same way, so I'm not sure what that has to do with anything. (Although you might wish to keep logs as plaintext, to facilitate backups, if you're not backing up the user's keychain info.)
        claudius 13y ago
        The wiki explicitly says (under “Is that the final word?”): > No. The Pidgin developers are generally open to, and would encourage integration with keyrings (KeyringSupport). and then goes on to state that this is difficult to do, since Pidgin runs on so many different platforms, then stating again that they will happily accept such patches. However, I find it understandable, that the devs don’t go out of their way to support use-cases they don’t feel necessary to support. On their systems, they trust the filesystem and are happy with that, if others don’t have that level of trust in their computer, that’s fine, but not necessarily their problem. My point about the logfiles was that to store these in the keyring (rather than a key to the encrypted files) would probably annoy the keyring somewhat (at least the poorer implementations thereof), given that it is intended for use with few-byte passwords and not multi-megabyte logfiles.
1337Coder 13y ago
This is the exact reason I created this: https://privatemsg.matthew-dove.com/ https://privatemsg.matthew-dove.com/
- urza 13y ago
  Where can I grab source code?
kybernetikos 13y ago
I've been experimenting with encrypting using bitcoin addresses, publishing keys with gravatar and sending encrypted messages as links as a way of trying to make all this stuff easier and more accessible. If you're interested in my proof of concept, it's http://kybernetikos.github.io/VisualSecrecy/ http://kybernetikos.github.io/VisualSecrecy/
- Domenic_S 13y ago
  Linking bitcoin address to email address doesn't sound like a step forward in privacy...
  - kybernetikos 13y ago
    Depends what you want to use it for. Anyway, you can have multiple bitcoin addresses for different purposes. On top of that, while I wouldn't rely on this cryptographically, the relationship is one-way. Gravatar links email addresses to gravatar images, but it's not intended to link in the other direction, so the same is true for any information stored in the gravatar. You can use my system to reply with encrypted text to a comment on a blog post without knowing the email address of the person you're replying to, only their gravatar image.
gtt 13y ago
Can such kind of reply put your secret key in the risk? For example, it gives attacker enough information to deduce the key within reasonable time?
- tlrobinson 13y ago
  I don't believe so. I think the parent comment was more concerned about the message itself being sent in the clear.

joe_bleau 13y ago

I see encrypted connections to/from gmail all the time. Here's an example from a test I just ran: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.79.27]:25: TLSv1 with cipher RC4-SHA Anonymous TLS connection established from mail-yh0-f48.google.com[209.85.213.48]: TLSv1 with cipher RC4-SHA

bigiain 13y ago
Hmmm, no Perfect Forward Secrecy on RC4-SHA... Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?
- joe_bleau 13y ago
  It could be an artifact of my postfix configuration. Looking over a few logfiles, here are the ciphers I've seen recently (all servers, not just gmail): ADH-AES256-SHA (256/256 bits) AES128-SHA (128/128 bits) AES256-SHA (256/256 bits) DHE-RSA-AES256-SHA (256/256 bits) EDH-RSA-DES-CBC3-SHA (168/168 bits) RC4-SHA (128/128 bits)
  - bigiain 13y ago
    Curiously, I'm seeing a bunch of TLSv1:DHE-RSA-AES256-SHA:256 between one of my machines and google... I wonder why/when the connections end up RC4-SHA instead?
    - viveksec 13y ago
      Google serves up static content uses DHE. We've noticed only Google sites using DSA certs with ECDHE. A report on what we found http://trisul.org/blog/dsa-xdrill/post.html http://trisul.org/blog/dsa-xdrill/post.html
- viveksec 13y ago
  > Hmmm, no Perfect Forward Secrecy on RC4-SHA... Actually dont see how you can have PFS on DHE either if one of the endpoints doesnt co-operate. You can simply dump the master keys and provide those to the decrypting app.

sliverstorm 13y ago

None of it is impermeable, even your own server. It's just another layer of misdirection and/or difficulty.

tubelite 13y ago

The shuttering of Reader and Gmail's new and awful Compose have convinced me - more than years of Stallman rants and NSA snooping - that relying on closed-source SaaS is a terrible idea. It is a question of if, not when, your SaaS provider does something you intensely dislike, and which you have no power to change. With SaaS, you don't even have the power to say - Damn your improved version, blast your hip new design, I will stick with the old one, thankyouverymuch. You are always on Version Now. The more intertwined your relationship and dependence on integration with related products, the messier the ensuing divorce. This, to my mind, represents a far more inevitable reason to figure a way out of GMail.