Avoiding RIPA

[Peter Fairbrother]

James Hammerton wrote:

>> James Hammerton wrote:
>>> Simon Stated:
>>>> Fine.  Encrypt it.  Share it with friends whom you trust to decrypt it and
>>>> protect it and its source.
>>> And when the govt demands my private key (on pain of 2 years in
>>> prison) because they want to know what I'm hiding?
>> 
>> assuming asymmetric encryption (and no "encrypt to self" option) there is no
>> way Plod could get you to decrypt the data, even with access to every
>> private key you own.
> 
> (1) With my private key they can decrypt the encrypted information sent to
> me by others. 
> 
> (2) If I refuse to give my private key I got to jail.
> 
> (3) The stuff I encrypt and send to others can be decrypted with the
> keys of the recipients and they are then in the same position as I am
> under points 1 and 2.

Yus, that's the wrong way to go about it. m-o-o-t uses a publicly-readable
database of ephemeral public keys that (user-transparently) change every
time the recipient collects mail.

The sender asks the database for an ephemeral public key for the recipient,
which is dated and signed by the recipient using a long-term signing key,
used for no other purpose. This signing key can be revoked if it is
compromised (though it shouldn't be possible to demand such a key - I'm
hoping for the Pt3 CoP will confirm this, or not, doesn't matter much
though).

As soon as the message is received and decoded, the private keypart is
securely deleted, and a new key-pair is generated and sent to the database.
Then the recipient cannot give the private key, he no longer has it, and the
sender cannot decrypt the encrypted message anyway.



It would be quite easy to add this functionality to PGP or GPG, but afaik
they haven't done it yet. Maybe when Pt3 gets commenced and the threat is
actual... Anyone can post a signed ephemeral key on his site today, if he
wants to. Just needs maintenance.



Unfortunately it makes it easy to trace communications, as accesses to the
database can be logged, but we use TLS to the database server, and later we
intend to use PIR techniques, to partially defeat this - and eventually
develop PIR techniques to get computational message anonymity.


What's really needed is a proper 'net broadcast technology, or an 802.11
mesh might do it given a few years, so we can set up a "feed". With OTP.
Unbreakable anonymity, and unbreakable crypto, all in one...   :)



There are methods that can be set up between pairs of correspondents to get
around the delay between sending and receiving, but they are deniable in
nature and require both parties to lie.  You would have to trust your
correspondant. I'm unsure whether to include it - probably not. We may
include a (keyed but real, with automatic covertext) OTP on a USB dongle
instead though.

I'm also considering a keyed code, whereby nouns are replaced by nouns,
verbs by verbs etc., so a message can have many plausible decryptions and it
is impossible to tell which is the intended message, but we haven't started
implementation of this yet (yes, I've done the unicity calculations, you can
probably google some early ones, and with some tweaking it works for the
average email. With a little more tweaking it might even be possible to make
the cyphertext (codetext?) into a plausible message too...   :)


That's the best I can come up with for indirect messaging, any other
suggestions? Any suggestions for anonymity between sender and an untrusted
recipient, eg for anonymous posting, apart from "trusted" remailers?


-- Peter