| Frequently Asked QuestionsThis section is part of the Romance.ucam.org online help system. (show contents). You can also view the entire document as a single very long page.
Encrypted messagingIntroduction
On every system that exchanges messages/email, the users must implicitly trust the administrator of that site (and of all the network devices and ISPs en-route) to respect their privacy, and not to read their messages.
Snooping on messages is deeply unethical, and we recoil at the idea. We don't do it, [except when specifically asked to intervene by the recipient if a message is reported as offensive], and we think we are worthy of your trust.
But it's a power we are reluctant to have, and don't want, not even in principle. We believe in protecting your privacy... but you shouldn't have to just take our word for it: Quis custodiet custodes ipsos?
The solution is to use public-key cryptography: (specifically PGP,
implemented by GPG).
Messages are encrypted by the sender and decrypted by the recipient: our site then has no access, not even in principle, to the private text of your conversation.
Likewise, if your messages are forwarded to your email account, that mail-server cannot read them. Encryption protects your privacy with mathematics, not just law and personal morality.
This is rather technical! If you do take no action, everything will work normally: the site will behave exactly as it always has, and you just won't be using the optional encryption feature.
For most people, most of the time, you just don't need to worry about this: your private messages are perfectly well protected even without encryption. PKI is a way to iron-clad your privacy, not a requirement.
Typically, messages on this site are confidential, but not "super-secret". Encryption could be important in conversations between people who choose to keep their sexuality private (i.e. are not "out").
Sending encrypted messages
Sending encrypted messages is simple: just use the "encrypt" button on the send-message page. This option appears when someone has configured their profile for inbound encryption.
Before sending the message, remember to save a local copy of the plaintext (on your own computer) if you want to keep it.
Once the message is encrypted, only the recipient can decrypt it; nobody else can (not even the original sender). This means that your sent-box/correspondence will contain only the encrypted text, not your original message.
(We could change that, but it would then defeat the whole point: though the recipient's copy of the message would be secret, we'd be able to access access the sender's unencrypted copy!). [In the case where both parties
have public keys on the site, this problem is solved, by encrypting a copy for both parties]. • Don't use the spell-checker: it
sends the uncencrypted text across the network (though it isn't stored by us). • Optionally, you can use the recipient's public key and your own copy of GPG, and copy-paste the encrypted text.
Receiving encrypted messages
To enable your account for receiving encrypted messages, just add a (dedicated) public key on your settings page (see instructions below).
Note that certain features of the site are incompatible with encrypted messaging: notably reply-quoting and HTML-formatting; it also means your correspondents won't have convenient access to their sent-messages.
Technical Details
GPG instructions:
• First, install GNU Privacy Guard: this is free software, downloadable for Linux/Windows/MacOS. Look at the instruction manual.
• Create a public-private key pair with GPG: gpg --gen-key. You should create a dedicated key-pair for your use of Romance.ucam.org, even if you already have one. Your user-ID for the key can be seen by everyone, so
we recommend that you use: "Your RUO Nickname (Romance.ucam.org) <your_ruo_nickname@example.com>", so
as not to reveal your personal details. Email addresses "@example.com" are intentionally un-routable, so you can use them disposably. If you choose to use your real email address, that's fine (if it's intentional):
it will allow you to sign the keys with a keyserver, but you'll lose pseudonymity.
• Once you have a private key, export it in asci-armored format: gpg --armor --export. It should look like
this: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFA8hC8BEACsTWUFacQ6uG5KnHFMnATFJbedpeaChrlWCvPbamJuMqb7ww+F ... etc. ... ZrzHx7X3wtBhJJm62d6L0UktByqLv0jGT8QAY4kx+2b4eRh4Gv5oc/H/WDwcXdo= -----END PGP PUBLIC KEY BLOCK-----
• Then, save the key in your settings. (You can remove it later by deleting the key). We'll share it with anyone who wants to send you an encrypted message.
• Don't lose your private-key, or you'll never be able to decrypt your messages.
• To manually encrypt a message: import their key, encrypt the message, and copy-paste the ciphertext into the send-message box. Remember to keep your own local copy if you want, because your RUO sentbox will only contain ciphertext, which nobody but the recipient can decrypt.
• To decrypt messages, use gpg --decrypt --no-mdc-warning. (the modification detection code isn't supported by the javascript library we used).
• Recommendation: test everything in correspondence with yourself.
Theory:
Public-key encryption, with current versions of GPG and algorithms is unbreakable [as far as anyone knows: if you could find a way, you'd probably win a Nobel prize for mathematics]. But the system is only as good as the implementation; here's
what you need to consider:
• Because your identity is pseudonymous, you have to delegate key distribution to us. That means that we could, technically, engage in a man-in-the-middle
attack, intercepting, decrypting, and re-encrypting text. You have to trust us to pass on the same public key that you provide to us... of course, feel free to verify this for yourself at any time.
• When you provide a public key, this contains a textual identifier, such as "NAME (COMMENT) <email@address>". You should create a dedicated key-pair just for your use on this site, and not include your real-name or email-address.
Otherwise, you are giving out your personal information to everyone (which is OK if you want to do it, but don't do it by mistake!). On the other hand, if you do use a widely-known key, which you publish on a keyserver, this can mitigate the
MITM problem. If you use this key elsewhere, people can google for it, so it "leaks" information.
• We still know who you are, and which members you choose to communicate with. Your profile (necessarily) remains unencrypted, and visible to other members.
• PGP is a perfect system for secure communication between two people who already know each other, and have physically exchanged keys. We're using it between two initially unknown, anonymous contacts: in this context, it's good, but not perfect (see above).
• Assuming that you trust us, we can guarantee forward-secrecy, protection of the server and backups (even against theft of the physical server), and security against snooping (aka "lawful-intercept").
• Our in-browser PGP encryption is based on this: feel free to view-source to see the javascript we use.
• Encryption using Javascript in the message form (rather than explicitly using GPG and copy/paste) has some further caveats: use your own copy of GPG if you wish.
• Note that our server only ever stores a single copy of messages: a given chunk of text is stored once, and only the metadata is duplicated between sender and recipient. So we don't store an encrypted copy for the recipient, and an
unencrypted copy for the sender! [If we have public keys for both parties, the text is encrypted once for each.]
What are the catches?
• There is a trade-off between security and convenience. If you use encryption, the sender must perform the extra step of encryption, and the recipient must decrypt.
• Senders must keep a separate copy of your sent messages: once you've encrypted them with someone else's public key, you cannot decrypt them again. [If we also have the sender's public key, this problem is resolved, by encrypting for the sender too.]
• Some features of the site will work slightly less well: automatic reply-quoting, spell-checking, and HTML message-formatting will break, and the correspondence feature will be awkward to read (especially for sent-messages).
• If you receive an offensive encrypted message, you needn't reveal your private key to report it; selectively reveal a single one-time message key with gpg --show-session-key; gpg --override-session-key {key}.
• If you lose your private key, you can't (ever) decrypt the text.
• Adding a public key is just a request to the sender that they encrypt the message; they may choose not to do so.
• If we (in future) write a text-search feature, this won't be able to search within encrypted text.
[ ↑ contents]
|