Sleep would be good about now... (It refuses to come, so I think about encryption)


Okay, I'm sure there's some obvious reason this won't work, since it seems so obvious, and lots of people are working in this area, but it's keeping me awake, so may as well inflict it on others...

Goal: make encrypted email communication the norm.
Partial Problem: need for registration with keyservers, resolution of who is a friend to keyserver-registered key.
Partial Solution: use in-band communications, rather than out-of-band communications to provide opportunistic encrypted communication.

Concretely: every mail client generates/acquires a key for their user, and promiscuously communicates the key in a header "x-please-encrypt", and the signature in a header "x-signed" (or whatever). Every mail client then also keeps track of the x-please-encrypt keys associated with those addresses in their address book (and, of course, messages will retain their x-please-encrypt headers).

Whenever we reply to an address which (or send a message to an address-book record which) has sent an x-please-encrypt header (with key), we use the key to send the message in encrypted form.

Now, when replying to an un-encrypted message, there's a chance that you might have a man-in-the-middle attack that's replaced the key on the message, but if you're worried about that, you can check the key against a key-server or some out-of-band mechanism.

Now, when an attacker sends a message with a different key, we have a problem, and can inform the user of the potential security issue so that they can verify the identities to decide whether to accept the new key. However, it is often going to be the case that the user can simply use the old key to ask the other user whether they have changed keys or not.

The basic idea is that for opportunistic encryption we don't really need to worry about the panopticon attacks (i.e. China), where every single x-please-encrypt header is rewritten to allow for monitoring. People in those circumstances are worried enough to use out-of-band verification. What we're looking at is simply providing a privacy conduit for the normal case of email communications among friends/relatives/colleagues.

The effect is to create pseudonymous identities bound up with the email address and key used to send email. You can verify that an individual is the same individual who you have been talking to, and continue to talk to them with some measure of privacy. There is the possibility that you've been talking to an imposter the entire time, but then the guarantee still holds. Success relies on the relative lack of pervasive attacks to establish the regime, but if pervasive attacks were to become commonplace then you can imagine that individuals would likely become concerned enough to start worrying about encryption.

Well, now, maybe I can go to sleep...

Comments

  1. x

    x on 03/01/2005 11:19 a.m. #


    The real-world problem with this is: people don't care.<br />
    <br />
    Therefore no one's going to implement it.<br />
    <br />
    However since the real-world is no fun, a few points anyhow:<br />
    <br />
    Kmail/KAddressbook has pretty interesting support for this sort of thing. If you open KAddressBook you'll find every person it it has an entire "Crypto Settings" tab where you can config various options on how you want to communicate with them. This is not automatic, requested by the sender; but is pretty flexible and could be extended even further.<br />
    <br />
    KMail also has the ability to have individual crypto settings per "identity"; which then can be attached to folders. Good for some purposes.<br />
    <br />
    Every once in a while in the past i'd turn on automatic message signing for some of my identities. I'd think it would look impressive for all my "support@vex.net" emails to be cryptographically signed... but, after a while it just looks pretentious and noisy to me... so i turn it off. <br />
    <br />
    That is a more modest goal which doesn't interfer with the recipients ability to read the mail, nor rely on sender's config, if you'd consider it a first step in your grand plan: just get everyone to SIGN their outgoing messages automatically.<br />
    <br />
    KMail also has an interesting method of displaying encrypted/signed messages. Basically it's a big box it draws around the message which is colour coded (and has additional info at the top in some circumstances). Actually it's somewhat annoying the way it's currently implemented; but it's a good idea. It just needs some streamlining. It's pretty much impossible to be unaware of the crypto status of any message in kmail. <br />
    <br />
    You may recall back in the day when PGP was the coolest thing and a lot of geeks took to adding their public key to their message signatures. That was annoying and noisy! Ugh. <br />
    <br />
    There was a bit of a move to put the keys in email headers using X-My-PGP-Key, or similar. <br />
    <br />
    I personally, ages past, always included my PHP fingerprint in email headers. In fact... let me see.. Yes, here is a header from March 1996 (when i used to still use Yarn on DOS---in a DOS window)!<br />
    <br />
    X-PGP-Fingerprint: A4 3B D5 A9 C2 26 F2 34 FD 85 A5 8E 15 09 79 6B<br />
    <br />
    I should add that back to my headers. Just for the principle. Not that particular key: though i still l have that one, generated in 1994, and may even be able to remember the pass key; i generated a new bigger key finally in 2002.<br />
    <br />
    No one has ever encrypted an email to me in the 10 years i've had a key (except as tests, long long ago). <br />
    <br />
    Oh look. I have your key in my keyring! I didn't even know I did. mcfletch@golden.net... 1996! I assume that's you. The real-world problem with this is: people don't care.<br />
    <br />
    Therefore no one's going to implement it.<br />
    <br />
    However since the real-world is no fun, a few points anyhow:<br />
    <br />
    Kmail/KAddressbook has pretty interesting support for this sort of thing. If you open KAddressBook you'll find every person it it has an entire "Crypto Settings" tab where you can config various options on how you want to communicate with them. This is not automatic, requested by the sender; but is pretty flexible and could be extended even further.<br />
    <br />
    KMail also has the ability to have individual crypto settings per "identity"; which then can be attached to folders. Good for some purposes.<br />
    <br />
    Every once in a while in the past i'd turn on automatic message signing for some of my identities. I'd think it would look impressive for all my "support@vex.net" emails to be cryptographically signed... but, after a while it just looks pretentious and noisy to me... so i turn it off. <br />
    <br />
    That is a more modest goal which doesn't interfer with the recipients ability to read the mail, nor rely on sender's config, if you'd consider it a first step in your grand plan: just get everyone to SIGN their outgoing messages automatically.<br />
    <br />
    KMail also has an interesting method of displaying encrypted/signed messages. Basically it's a big box it draws around the message which is colour coded (and has additional info at the top in some circumstances). Actually it's somewhat annoying the way it's currently implemented; but it's a good idea. It just needs some streamlining. It's pretty much impossible to be unaware of the crypto status of any message in kmail. <br />
    <br />
    You may recall back in the day when PGP was the coolest thing and a lot of geeks took to adding their public key to their message signatures. That was annoying and noisy! Ugh. <br />
    <br />
    There was a bit of a move to put the keys in email headers using X-My-PGP-Key, or similar. <br />
    <br />
    I personally, ages past, always included my PHP fingerprint in email headers. In fact... let me see.. Yes, here is a header from March 1996 (when i used to still use Yarn on DOS---in a DOS window)!<br />
    <br />
    X-PGP-Fingerprint: A4 3B D5 A9 C2 26 F2 34 FD 85 A5 8E 15 09 79 6B<br />
    <br />
    I should add that back to my headers. Just for the principle. Not that particular key: though i still l have that one, generated in 1994, and may even be able to remember the pass key; i generated a new bigger key finally in 2002.<br />
    <br />
    No one has ever encrypted an email to me in the 10 years i've had a key (except as tests, long long ago). <br />
    <br />
    Oh look. I have your key in my keyring! I didn't even know I did. mcfletch@golden.net... 1996! I assume that's you.

  2. x

    x on 03/01/2005 11:38 a.m. #


    Ha ha! Just noticing D'Arcy's key in my keyring... i remember it was at BSDCan last year, the keysigning party... D'Arcy finally generated a key and was all about the key signing for a few weeks. Got about a dozen signature on his key (which of course makes the things rather big chunks of text when exported---definitely don't want this thing in your email sig!). And D'Arcy, being the security rationalist he is, actually put an expiry on his subkey! And guess what. It's now expired. (-: So his key is useless in my keyring... unless i get an update... or can you use an expired key? Not sure. But what are the changes he's updated it or even knows it's expired....<br />
    <br />
    Ah yes, the fun of cryptographic *management*...<br />
    <br />
    (BTW, if you haven't tried it, the kgpg utility for kde is not too shabby...)<br />
    <br />

Comments are closed.

Pingbacks

Pingbacks are closed.