Freemail channels are designed so as to maximum privacy, anonymity, and reliability. Use of the Freenet architecture allows cultivation of anonymous identities with widespread reputations. The locations of mail messages within Freenet are constructed and transmitted in such a way that only the parties involved are aware of the source, destination, and even transmission of the messages. Eavesdropping is prevented by the use of strong encryption (Diffie- Hellman negotiated symmetric keys). Forgery is prevented by the use of Freenet's secure subspace key concept and cryptographic signatures. Freemail relies on the robustness of Freenet's secure key subspaces to prevent denial-of-service attacks on established channels.
The reference implementation of Freemail is written in Java. Encryption functionality is provided by the Java Cryptography Engine. XML parsing and serialization is provided by the Apache Xerces library (by way of IBM's xml4j).
Currently, Freemail requires Sun's Java 2 v1.4 Runtime Environment.
The implementation has been tested on Linux, Solaris, and Windows.
The channel initiation protocol specifies how one party (the "requester") can
establish a channel with another party (the "requestee") who is known to the
requester. It is unnecessary for the requestee to have any previous knowledge
of the requester. All messages transmitted during channel initiation are
secured with Triple-DES keys as specified below, preventing eavesdropping
on the channel parameters. These parameters are required before an attacker
may even detect the transmission of mail messages. The following phases
define the creation and secure, reliable exchange of channel parameters.
This method has the usual disadvantages associated with slot-based KSK boxes
(also used in Frost in FMB, for instance). In particular, this method is
susceptible to message loss (where a requester publishes a request in a slot
that was once filled but whose request subsequently disappeared from Freenet),
and denial-of-service attacks (where an attacker fills the slotbox with
garbage requests, forcing both the requestee and requesters to search through
many slots unnecessarily).
This channel is fairly reliable under normal circumstances (depending on Freenet
conditions), and highly unreliable under attack. However, the reliability
degrades over time as early requests disappear from the network.
This method makes denial of service attacks more difficult, as an attacker
must constantly follow the moving proposal window in order to flood it.
However, the extra layer of redirection decreases the reliability of this
method. Additionally, a persistent attacker may still hinder establishment
of new channels.
Compared to the fixed-window method, this method is less reliable under
normal circumstances, much more reliable under sustained attacks, and
less reliable under unsustained attack. Unlike the fixed-window method,
however, this method does not suffer from a decay in reliability over time.
This method is highly reliable; in fact, provided a receipt can be transmitted
through Freenet, its success is guaranteed. However, it is not applicable to
anonymous introductions. For parties who would like to migrate existing
communications to Freemail, this is the preferred method.
This method is slightly less reliable than external transmission, as an extra
message is required. In all other regards it is identical.
NOTE: Some portions of these DTDs are out of date pending
further revision.
Note that there may be more than one content section; these should be
concatenated by the receiving client.
How to Read This Document
This document provides a top-level specification of the Freemail protocol,
as implemented by the reference program. Though this document fully specifies
the behavior of Freemail, it may not contain all the information necessary
to produce a compatible implementation.
Freemail Protocol Overview
Freemail provides channels, which convey information bidirectionally
between two parties. The Freemail protocol is designed to allow channels to be
securely formed between parties with no existing method of communication,
thereby preserving the anonymity of both parties.
Channel Initiation
Identity creation phase
Initially, a requestee must create a document called an "identity" establishing
how requesters may contact him. This document (or, preferably, an address
locating it) should be distributed in public communications, allowing other
users to confidently associate those communications with the Freemail identity.
The following steps describe the creation of an identity.
The format of this document is specified
below.
Channel request phase
Once the requestee has established a reputation associated with his Freemail
identity, users may wish to contact him. Though dissemination and retrieval
of the identity is not specified by Freemail, publishing it into Freenet is a
sensible practice. Once a requester has obtained the requestee's identity, she
can use it to contact said requestee. The following steps describe the process
of contacting the requestee described above.
The format of this document is specified
below.
Channel acceptance phase
The format of this document is specified
below.
Channel confirmation phase
Request Transport
The anonymous-introduction capability of Freemail presents difficulties in that
an attacker can pretend to be many legitimate users and flood a requestee with
many requests. Freemail provides a variety of request transport protocols to
work around this fundamental limitation, and limit the damage of such attacks
when they occur.
1) Fixed-Window Publication
This method establishes a public address space within Freenet where new senders
may place proposals of new channels for a recipient. The address space is
implied by a user's address (i.e., public SSK key), and takes the form
KSK@freemail/requests/<requesteePublicSSKKey>/<slot>.
To publish a request into this "slotbox", a requester attempts to retrieve
request documents, starting from slot=1. The requester then
publishes her request in the first empty slot.
2) Dynamic-Window Publication
This method extends the fixed-window method by providing for a moving request
publication address. Specifically, a new KSK subspace is generated for
proposal messages at a regular interval or as needed. The location
of the subspace is published in an SSK key which is updated whenever the
proposal window changes. Currently this is achieved with a Freenet DBR key,
which essentially changes content with a defined frequency (typically one day).
3) External Transmission
This method allows two parties who have an existing communication channel
outside of Freemail to establish a Freemail channel with optimal reliability.
To use this method, the requester exports a request from Freemail and transmits
it to the requestee using the existing channel. The channel need not be
secure, as the request is still encrypted.
4) Known Location
This method is a convenient extension of the external transmission method.
The process is exactly the same, except that Freemail itself publishes the
request into Freenet, and the users need only communicate the address of the
request separately. This is useful if the existing channel has a exceedingly
low-bandwidth (e.g., stenographic channels), and transmitting an entire
request document is prohibitive.
Mail
Freemail's mail protocol is a simple application of the channel parameters.
Sending
Receiving
Message and Storage Formats
All message and mailbox information storage data are enclosed in XML. The
following DTDs specify document types used in Freemail (note that Freemail
currently does its own validation and does not use these DTDs internally).
Documents that include a "version" field are intended for wire transmission
(possibly encrypted). Freemail implementations are explicitly disallowed from
processing a document whose version is more recent than that included in said
implementation. All versioned documents are currently at version "0.1".
Mailstore Information
The mailstore file contains the information necessary for sending and receiving
Freemail messages. This is typically a disk file. The mailstore should never
be distributed, as it contains private and secret keys in cleartext.
<!DOCTYPE mailstore [
<!ELEMENT mailstore (version,alias,publicSSKKey,privateSSKKey,
privateDHKey,publicDHKey,dhParamSpecG,dhParamSpecP,cryptoParams,
lastIndexProposal,inbox*,outbox*)>
<!ELEMENT version (#PCDATA)>
<!ELEMENT alias (#PCDATA)>
<!ELEMENT publicSSKKey (#PCDATA)>
<!ELEMENT privateSSKKey (#PCDATA)>
<!ELEMENT privateDHKey (#PCDATA)>
<!ELEMENT publicDHKey (#PCDATA)>
<!ELEMENT dhParamSpecG (#PCDATA)>
<!ELEMENT dhParamSpecP (#PCDATA)>
<!ELEMENT cryptoParams (#PCDATA)>
<!ELEMENT lastIndexProposal (#PCDATA)>
<!ELEMENT inbox (alias,senderPublicSSKKey,channelName,secretKey,
cryptoParams,lastMessageIndex)>
<!ELEMENT outbox (alias,channelName,recipientPublicSSKKey,secretKey,
cryptoParams,lastMessageIndex)>
<!ELEMENT senderPublicSSKKey (#PCDATA)>
<!ELEMENT recipientPublicSSKKey (#PCDATA)>
<!ELEMENT channelName (#PCDATA)>
<!ELEMENT secretKey (#PCDATA)>
<!ELEMENT lastMessageIndex (#PCDATA)>
]>
User Identity
The user identity contains information necessary to contact a recipient via
Freemail. The current version of this document only supports the static
dropbox contact protocol.
<!DOCTYPE identity [
<!ELEMENT identity (version,alias,recipientPublicSSKKey,
dhParamSpecG,dhParamSpecP,recipientPublicDHKey,cryptoParams)>
<!ELEMENT version (#PCDATA)>
<!ELEMENT alias (#PCDATA)>
<!ELEMENT recipientPublicSSKKey (#PCDATA)>
<!ELEMENT dhParamSpecG (#PCDATA)>
<!ELEMENT dhParamSpecP (#PCDATA)>
<!ELEMENT recipientPublicDHKey (#PCDATA)>
<!ELEMENT cryptoParams (#PCDATA)>
]>
Channel Request
At the top level, a channel request is composed of three parts: the requester's
Diffie-Hellman public key, the negotiation symmetric parameters (for 3DES), and
the request data. The DH key part is a Base64 encoding of the byte data of the
serialized key. ("Base64" is an encoding scheme that contains 6 bits of data
per character; Freemail uses a custom Base64 encoding that is not compatible
with that used by Freenet.) The negotiation symmetric parameters are also
Base64-encoded. The request document (specified by the following DTD) is
encrypted with the negotiation symmetric key and encoded as a Base64 string as
well. The three Base64-encoded strings are delimited by linefeeds ('\n').
<!DOCTYPE request [
<!ELEMENT request (version,requesterAlias,ee2erChannelName,
ee2erSecretKey,ee2erCryptoParams,receiptAddress,negotiationSecretKey?,
negotiationCryptoParams?)>
<!ELEMENT version (#PCDATA)>
<!ELEMENT requesterAlias (#PCDATA)>
<!ELEMENT ee2erChannelName (#PCDATA)>
<!ELEMENT ee2erSecretKey (#PCDATA)>
<!ELEMENT ee2erCryptoParams (#PCDATA)>
<!ELEMENT receiptAddress (#PCDATA)>
<!ELEMENT negotiationSecretKey (#PCDATA)>
<!ELEMENT negotiationCryptoParams (#PCDATA)>
]>
The elements are defined as follows:
Request Receipt
The request receipt provides acknowledgment of a channel request's acceptance,
and provides channel parameters not included in the request. The information
is split in this manner so that each user can specify the maximum key strength
he is capable of using, and to mediate damage caused by a compromised random
number generator on one side (however unlikely).
Mail Message
Freemail messages are transported according to the following DTD. The content
section is Base64-encoded to prevent XML-escaping difficulties. The serialized
XML document is then encrypted with the channel's outbound secret key and
inserted into Freenet as raw bytes.
<!DOCTYPE message [
<!ELEMENT message (version,content+,id,toAddress,fromAddress)>
<!ELEMENT version (#PCDATA)>
<!ELEMENT content (#PCDATA)>
<!ELEMENT id (#PCDATA)>
<!ELEMENT toAddress (#PCDATA)>
<!ELEMENT fromAddress (#PCDATA)>
]>
Caveats
Freemail should be used as a secure communications platform only after a
careful weighing of these considerations:
At present, these are considered "strong" algorithms with "strong"
keysizes. However, they may not remain so indefinitely. Freenet may store
your messages longer than you know, preserving your communications for
future eavesdroppers with more powerful decryption tools. Also, be aware
that the security of a channel's Blowfish keys is entirely compromised by
the failure of its 3DES key (Blowfish is used for speed, while 3DES is used
for compatibility with the JCE's Diffie-Hellman key agreement facilities).
Glossary
Document revision:
$Author: athomasonx $
$Header: /cvsroot/freenetmail/freenetmail/docs/specification.html,v 1.3 2002/06/09 23:39:19 athomasonx Exp $
$Revision: 1.3 $
$Date: 2002/06/09 23:39:19 $
$Log: specification.html,v $
Revision 1.3 2002/06/09 23:39:19 athomasonx
Added XML DTDs.
Merged David Wei's dynamic dropbox spec.
Revision 1.2 2002/05/30 20:00:39 athomasonx
Added second stage protocol.
Added mail sending to usage example.
Revision 1.1 2002/05/29 01:48:56 athomasonx
Initial version.