Author: dbkr
Date: 2006-07-25 01:22:05 +0000 (Tue, 25 Jul 2006)
New Revision: 9742
Modified:
trunk/apps/Freemail/docs/spec/spec.tex
Log:
Modifications to the spec discussed with Toad:
* Using the ACK SSK for CTS messages
* Symmetric encryption of RTS messages
* Hash sequence slots on commssks for forward secrecy.
Modified: trunk/apps/Freemail/docs/spec/spec.tex
===================================================================
--- trunk/apps/Freemail/docs/spec/spec.tex 2006-07-24 19:50:45 UTC (rev
9741)
+++ trunk/apps/Freemail/docs/spec/spec.tex 2006-07-25 01:22:05 UTC (rev
9742)
@@ -46,11 +46,12 @@
\item messagetype - This should be 'rts', to indicate that this message is an
RTS.
\item to - The Freenet URI that appears encoded in Bob's Freemail address.
This is necessary in order to prevent surreptitious forwarding to support the
encryption explained later.
\item mailsite - Alice's mailsite URI
-\item ctsksk - A randomly generated KSK that Bob should insert to once he has
received Alice's RTS message in order to acknowledge that he is ready to
receive messages. This should be randomly generated and un-guessable so that
only Bob knows which key to insert to.
\end{itemize}
-Following the last data item, there are two carriage-return-line-feeds,
followed by Alice's signature. This is the SHA-256 hash of the message RSA
encrypted with Alice's private key, included as raw bytes. The resulting
message is then RSA encrypted with Bob's public key. If the resulting message
is longer than a single RSA block, the message is encoded in chunks equal to
the maximum block size and the ciphertext blocks are concatenated to form the
final message.
+Following the last data item, there are two carriage-return-line-feeds,
followed by Alice's signature. This is the SHA-256 hash of the message RSA
encrypted with Alice's private key, included as raw bytes.
+The final message comprises a randomly generated AES session key, encrypted
with Bob's public RSA key, followed by this message-signature combination
encrypted with this sessions key. The encrypted session key must be precicely
one RSA block of ciphertext. All bytes after this are part of the symmetrically
encrypted message.
+
It is the sender's responsibility to keep the private part of the 'commssk'
key private. It is valid to assume that any message inserted on 'commssk' was
written by Alice and intended for Bob, since only Alice has the private key and
only they have the public key.
The 'to' field is included to prevent surreptitious forwarding. That is, to
prevent Bob from decrypting the message, leaving Alice's signature intact and
encrypting it to someone else (say, Charlie), who would then be lead in to
believing that Alice wished to communicate with him, which is fact not the case.
@@ -64,25 +65,24 @@
Bob then records the value of the 'commssk' key so that he can poll this SSK
for messages periodically.
-Before doing so, Bob inserts some data to the value of the 'ctsksk' key in the
RTS message. The data he inserts is irrelevant - the presence of the key is
sufficient to prove to Alice that he has received the message. This completes
Bob's part of the channel setup procedure.
+Before doing so, Bob inserts some data to the value of 'ackssk', followed by
the string 'cts'. That is, he inserts to "SSK@<long SSK key base>/cts". The
data he inserts is irrelevant - the presence of the key is sufficient to prove
to Alice that he has received the message. This completes Bob's part of the
channel setup procedure.
This message contains no valuable information and so does not need to be
encrypted. It also does not need to be signed since only Alice and Bob know the
KSK to which it must be inserted, so Alice knows that Bob must have inserted
the message. The KSK that Bob inserts this message to tells Alice what RTS it
relates to if there is any ambiguity.
-Alice should check periodically for the insertion of this CTS message. If it
does not arrive, Alice should re-send the RTS message with a different
'ctsssk', in order that she can be certain which RTS message any given CTS
message corresponds to. All other field should be the same. The client may try
several times before declaring the message undeliverable.
+Alice should check periodically for the insertion of this CTS message. If it
does not arrive, Alice should re-send the RTS message. The client may try
several times before declaring the message undeliverable.
\section{Message Exchange}
\subsection{The Messages}
-Once Bob has inserted this CTS message, he begins polling for messages on keys
derived from the value of the 'commssk' key which he obtained from the RTS
message. These keys are the value of 'commssk' with the string 'message-' and a
natural number appended, where the number is the lowest number that does not
form a key on which Bob has already received a message (the 'lowest free
slot'). For example:
+Once Bob has inserted this CTS message, he begins polling for messages on keys
derived from the value of the 'commssk' key which he obtained from the RTS
message. These keys are the value of 'commssk' a 256 bit base32 encoded hash
appended. The hash is initially the value of 'initialslot' in the RTS message.
Each subsequent slot's hash is the SHA-256 digest of the previous slot's hash,
forming a seqence of message slots. This hash sequence gives forward security,
provided that clients destroy values of the hash, and 'initialslot' once they
have been used. Alice should insert a new message to the first slot to which
inserting does not causes a collision. Formulaically, Bob first polls the key:
-SSK at
9GXtGxN4CEJD~8a30\-7V6yzyhl8Gx5UYb\-WVDTEyUXH6o,gDWfr2CqVmDAeJ\-urKF2iieM5AkjXs\-tOl2V5jyuTHeo4,AQABAAE/message-1
+SSK@<SSK key base>/<initialslot>
Once Bob has successfully retrieved this key, he begins to periodically
request the key:
-SSK at
9GXtGxN4CEJD~8a30\-7V6yzyhl8Gx5UYbW\-VDTEyUXH6o,gDWfr2CqVmDAeJ\-urKF2iieM5AkjXs\-tOl2V5jyuTHeo4,AQABAAE/message-2
+SSK@<SSK key base>/<H(initialslot)>
It is recommended that clients poll several messages ahead rather than just
the immediately next message, since simulations suggest that it is possible for
single keys not to be retrievable in this kind of circumstance. So for example,
once Bob has sent his CTS messages, he should start polling for the keys:
-number that does not form a key on which Bob has already received a message
(the 'lowest free slot'). For example: \\
\\
SSK at
9GXtGxN4CEJD~8a\-307V6yzyhl8Gx5U\-YbWVDTEyUXH6o,gDWfr2CqVm\-DAeJurKF2iieM\-5AkjXstOl2V5j\-yuTHeo4,AQABAAE/message-1
\\
\\
