Reasonably Trustworthy Messaging (RTM)

PJ of Groklaw got spooked a Lavabit founder responding to PRISM by saying "if you knew what I did, you wouldn't use the Internet/email".

This is the start of a design for a reasonably trustworthy messaging system, in the same way that PGP was only pretty good privacy.

I'd like to combine 3 tools/concepts on top of the obvious measures.

• SFTP as a file delivery mechanism.

• ACSnet (later MHSnet) was a Store & Forward system that separated content and control while passing files to a content-handler on the far end.

• Bespoke classified message systems contain two useful concepts:
• Messages have an urgency and separate security classification.
• these are used in routing & queuing decisions.
• Every message is tracked & acquitted via multiple sequence numbers:
• Per-link or channel sequence number
• end-end sequence numbers

Obvious measures:

• File splitting
• Everything is a 2Kb or 4Kb block
• I'd prefer an "M of N" redundancy system to allow some data to be lost. 
• Parchive  & friends do this
• There's a "batch reassembly" file implied by this.
• SFTP needs to have some means of grouping batched files together.
• Either a named control file, or
• a directory name, a sequence number in clear or encrypted.

• PGP/GPG encryption
• Encrypt everything
• Compress first, for text files especially.
• Ideally, force different coding tables per file.

• Content-based file naming
• Files only referred to by content: its hash-sum, SHA-1 or MD5 (old)
• Queued blocks can be jumbled and transmitted in any order, being reassembled into correct order later.
• This implies "message headers" contain the hash-keys of contents.

There are old programs, like "fetchmail" (or 'fdm' now), that know how to pull mail from many sources and present to the Mail User Agent in a form it can handle, like the traditional Unix mailbox format.

The ACSnet software was able to accept emails from "sendmail", so a simple SMTP daemon is also needed here to accept outbound messages from Mail Clients, allowing 

An extra layer of obfuscation and aggregation, like ToR or VPN's, makes the task of matching inbound/outbound packets harder. 

One of the central notions is no system, apart from the end-points, ever has the unencrypted files/messages.

• Messages are encrypted with the public-key of the next-hop destination before sending.

• Messages queued to a link/channel should be kept as-received (encrypted for current system), only being decrypted before transmission.

• Small blocks mean encryption can be performed in-memory, without any intermediate results touching a disk. Prevent swapping and VM page-write may be a challenge, but only one layer is lost.

• SFTP/SSH use per-session keys to encrypt transfers.
• With content re-encrypted per hop, there is no common plain-text allowing keys to be compromised.

Solution

That's what I'm aiming for, a low user-intervention system that users can reasonably trust:

• Messages and files sent, when delivered can be shown to intact and complete.

• No messages/files can be read "in clear" on the wire or on any intermediate system.
• Messages/files only appear unencrypted on the source and destination system.
• Simple tools, like USB drives, can be used to transfer files to/from off-line systems.

• Users can get confirmations of delivery and/or acceptance back from each step along the way.

• Data is sufficiently obscured so traffic analysis yield minimal useful metadata:
• Using SFP in a Store+Forward mode removes the normal headers 
• Any SFP service can be used as a relay, if the per-hop encryption can't be organised on the server and exposing one-layer of encryption an acceptable risk.

Use Case

Alice and Bob want to exchange Company-Confidential information.

They both have access to the same SFTP server, or preferably a service that also supports re-encryption.

Or they each have access to SFTP servers hosted by co-operating trustworthy providers.

Alice and Bob both have off-line computers that they load/download encrypted files onto.

Alice and Bob both have internet-connected computers with the RTM App, PGP/GPG & SFTP installed, plus the transfer host PGP/GPG private keys.

Alice and Bob have exchanged their email Public PGP/GPG keys, both only have their private email keys on their off-line system.

Alice and Bob have exchanged their internet-host PGP/GPG public keys with their upstream server.

Alice, on her off-line system, writes one or more messages to Bob (and others) from her usual Mail Client and possibly queues some file transfers with another App.

The RTM software creates a directory of encrypted files which Alice then copies to a USB drive.

On her on-line system, Alice loads the USB drive and starts the RTM software than uses SFTP to transfer files to their shared server. The RTM software creates a control file for the batch and encrypts all files with the public key of the next hop.

The next-hop system receives the files and decrypts the control file, queuing blocks for whichever next hop link is to be used and creates & encrypts control files for batches.

After zero of more hops, Bob's SFTP server receives blocks batched for him from Alice and others and queues them for Bob, ready to encrypt them with his transfer host public key.

Bob, in his own time, starts RTM on his transfer system and downloads the blocks queued for him, decrypting them to copy to his USB drive. These blocks were encrypted for Bob by Alice and others using the email public key he shared with them. They cannot be decrypted on the transfer host.

Bob takes his USB drive to his off-line system and starts RTM to upload the encrypted blocks, decrypt them, checks hash-keys, reassembles the sent files and then delivers to the appropriate 'handler', email, file transfer or other specific tool.

Bob can then check email on his off-line machine using his favourite Mail Client. He can choose to save/distribute the decrypted files transferred by whatever means he needs.

Alice and Bob do not have to use off-line systems with air-gaps. If they accept the risk, they can run both the transfer host and "in-clear" system as Virtual Machines in the same system. A private, internal network can be used to transfer encrypted blocks between the two VM's.

If the system hosting the two VM's is compromised, the most an attacker can do is monitor the display.

I haven't discussed the various passwords/pass-phrases that would be needed in operation.

The system should be simple to install and configure and be mostly self-administering.