[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[minion-cvs] some clarifications and questions on the nym spec
Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/home/arma/work/minion/doc
Modified Files:
nym-desc.tex
Log Message:
some clarifications and questions on the nym spec
Index: nym-desc.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/nym-desc.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- nym-desc.tex 26 Aug 2002 15:26:21 -0000 1.2
+++ nym-desc.tex 26 Aug 2002 20:13:25 -0000 1.3
@@ -1,12 +1,12 @@
Specification of a nym server running on top of Mixminion.
We assume that the underlying anonymizing network (in this case
-MixMinion) provides the following anonymous communications
+Mixminion) provides the following anonymous communications
primitives:
-(A) -> B: M - An anonymous party A sends a message to a named party B
- the message M. M has a maximum length of L.
-A -> (B): M - An named party A sends a message M to an anonymous
+(A) -> B: M - An anonymous party A sends a message M to a named party
+ B. M has a maximum length of L.
+A -> (B): M - A named party A sends a message M to an anonymous
recipient B. M has a maximum length of L.
(A) -> (B): M - An anonymous sender A sends a message M to an
anonymous recipient B. M has a maximum length of L.
@@ -14,7 +14,7 @@
ID can be used to differentiate between different
SURBs.
-Implementing the anonymous primitives using MixMinion
+Implementing the anonymous primitives using Mixminion
[...]
@@ -23,40 +23,43 @@
- The Nym server allows users without any special software (besides
standard SMTP) to send email [RFC2821] to anonymous recipients.
- The Nym server should not be trusted or relied upon to maintain the
- anonymity of the users. Although it should be trusted not to deny
- service to honest users.
+ anonymity of the users. (However, it should be trusted not to deny
+ service to honest users.)
- The Nym server should not be required to maintain more state than
its administrator wishes. In particular the administrator should
- have the option not to store messages in clear or SURBs.
+ have the option not to store unencrypted messages or SURBs.
- The nym server should provide reliable service, even if the
- anonymous communication channels used are not. In particular it
- should ensure that if users follows the protocols correctly none of
- their mail will be dropped.
+ anonymous communication channels do not. In particular it should
+ ensure that if recipients follow the protocols correctly, the nym
+ server will reliably deliver their mail. (Unreliable transport to
+ the nym server will still be unreliable.)
- Clients that do not benefit from any anonymity properties do not
need any special software.
-- Neither clients or nym servers need to actually run anonymous
- remailer nodes themselves. They can function by simply acting as
- clients to the anonymous network, sending and receiving anonymous
- messages.
+[Is this redundant with the first item above? -RD]
+- Clients and Nym servers need not run anonymous remailer nodes
+ themselves. They can function by simply acting as clients to the
+ anonymous network, sending and receiving anonymous messages. However,
+ a nym server which runs a remailer node seems to provide stronger
+ anonymity by blending its messages with other remailer traffic.
+
The Nym model
-Users run special software, the Nym client (that understands MixMinion
-and Nym server commands), and anonymously create a fresh nym account on
-the nym server. After this setup phase any email received by the Nym
-server for the nym is anonymously forwarded to the appropriate
-user. The Nym server makes sure that the message has correctly arrived
-to the user before it is deleted.
+Users (recipients) run special software called the Nym client, that
+understands Mixminion and Nym server commands. They anonymously create
+a nym account on the nym server. After this setup phase any email
+received by the Nym server for the nym is anonymously forwarded to
+the appropriate user. The Nym server makes sure that the message has
+correctly arrived to the user before it is deleted.
- Anonymous Nym Rest
- User <---MixMinion---> Server <--SMTP-- of the
- (Nym Client) World
+ Rest Nym Anonymous
+ of the --SMTP--> Server <---Mixminion---> User
+ World (Nym Client)
Client and Server Databases
-The objective of the design is to minimize the information required to
-be stored by both the client and server, while maintaining high
-reliability.
+The design aims to minimize the information the client and server must
+store, while maintaining high reliability.
Client:
@@ -72,13 +75,14 @@
Server:
Server Signature Key (KSs) + Verification key (KSv)
+Server Address (A)
list of {
Full Nym Name (Nym)
Client Verification key (KCv)
Client Encryption key (KCe)
Hash of Kill Phrase (H(KP))
- Should it keep SURBS? (KS?)
+ Should it store SURBS? (SS)
list of i = 1..n {
SURBS ((Nym)[i])
}
@@ -89,12 +93,13 @@
Nym Server Public Information
-A Nym server needs to advertise its address for both SMTP and
-anonymous access, and a public verification key to verify messages
-sent by it. Additionally policy files need to be available concerning
-the creation of nyms (acceptable names, if it stores SURBs or not),
-and the conditions of service (max. messages sizes, how often SURBs
-should be given, lifetime of accounts, etc.)
+A Nym server should advertise its address for SMTP, as well as its address
+for anonymous access if applicable. If it advertises an address, it must
+also list a public verification key to allow others to verify messages
+sent by it; and policy files must be available concerning the creation
+of nyms (acceptable names, whether it stores SURBs), and the conditions
+of service (maximum message sizes, how often SURBs should be given,
+lifetime of accounts, etc.)
Protocols
@@ -103,55 +108,69 @@
The client chooses a Nym Name (Nym) which will be the base of its
email address on the nym server. The client also provides the server
with public keys to encrypt (KCe) and verify (KCv) messages. The Kill
-Phrase is used in case the Signature keys are stolen or lost for the
-user to be able to destroy the Nym account.
+Phrase is used in case the Signature keys are stolen or lost, to allow
+the user to be able to destroy the Nym account.
In order to create the account the Client provides some means for the
-server to contact them back, in the form of SURB's.
+server to contact her back, in the form of SURBs.
-(C) -> NymServer: {CREATE,Nym, KCv, A, KSv, KCe, H(KP), KS?,n,(C)[1]..(C)[n]}KCs
+(C) -> NymServer: {CREATE,Nym, KCv, A, KSv, KCe, H(KP), SS,n,(C)[1]..(C)[n]}KCs
The Nym Server can deny an account creation request for a variety of
-reasons, which should be communicated to the used using the
-``message''. The server could be full, the Nym already in use, or rude.
+reasons, which should be communicated to the user using one of the
+Messages. The server could be full, the Nym already in use, or rude.
It is important for Nym server operators to have a clear policy on
which nyms are acceptable and which are not.
NymServer -> (C)[x]: {ACCEPT|DENY, A, KSv, Nym, KCv, Message}KSs
+(It's safe to send 'Nym' back to C in cleartext, because the remailer
+network wraps the message in several layers of encryption, which C
+privately peels off.)
+
On Server receiving messages:
-The Nym Server runs an SMTP [RFC2821] service. When a message
-received is addressed to a particular nym, it is encrypted under the
-nym's key (KCe) and stored on permanent storage. Depending on whether
-the Server possesses any SURBs corresponding to the nym it can forward
-the messages or simply wait for more SURBs. At the end of any MESSAGE
-the nym server can specify the number of additional SURBs that it
-requires to flush all messages. The client is not obliged to send the
-specified number of SURBs, but the server may stop receiving mail for
-this particular Nym, or drop the account.
+The Nym Server runs an SMTP [RFC2821] service. When a message received
+is addressed to a particular nym, it is encrypted under the nym's key
+(KCe) and stored on permanent storage. If the Server has a SURB on
+hand that corresponds to the nym, it forwards the message. Otherwise,
+it waits for more SURBs. At the end of any MESSAGE the nym server can
+specify the number of additional SURBs that it requires to flush all
+messages. The client is not obliged to send the specified number of
+SURBs, but the server may stop receiving mail for this particular Nym,
+or drop the account.
-A -> NymServer: M (with SMPT to: NymB)
+[a) If servers may drop accounts that get too much mail, did we just
+ introduce a serious DoS problem? This needs fleshing out.
+ b) If we take in Mixminion messages and deliver them to SURBs, we have
+ no space to add things at the end. Perhaps "number of requested surbs"
+ needs to go in the header (ugh)? (But we *can't*, because we can't see
+ inside the SURB. Hrm.) -RD]
+
+A -> NymServer: M (with SMTP to: NymB)
NymServer -> (B): {MESSAGE, A, KSv, NymB, KCv,
n,{M}KCe[1]..{M}KCe[n],m, info}KSs
+[Do we need to say KSv and NymB and KCv, above? It seems we're supporting
+multiple keys per nym? And I guess we're choosing either to be redundant
+or to not store all the info in the reply block header? -RD]
(B) -> NymServer: {RECEIVED, NymB, KCv, A, KSv, n,
- H({M}KCe[1])..H({M}KCe[n]), m, (B)[1]..(B)[m]}
+ H({M}KCe[1])..H({M}KCe[n]), m, (B)[1]..(B)[m]}KCs
To kill a Nym:
-(A) -> NymServer: KILL,NymA, KP
+(A) -> NymServer: {KILL, NymA, KP}
Since a nym's signature key might be compromised or lost it is
-important to have a backup but abuse proof mechanism to destroy nyms
-on the server, along with all the stored information. Therefore the
-policy should be that if the server receives a kill messages with a
-``Kill phrase'' with a hash that matches the one stored for the nym,
-it must destroy all information about the concerned nym.
+important to have a backup but abuse-proof mechanism to destroy nyms
+on the server, along with all the stored information. Therefore if the
+server receives a kill message with a ``Kill phrase'', where the hash
+of the kill phrase matches the one stored for the nym, it must destroy
+all information about that nym.
Sending messages
[Since we have decided that the SMTP mechanism is general we do not
- need a specific sending ability for the Nym server]
+ need a specific sending ability for the Nym server -GD]
Multiplexed reliable mix communications and Information dispersal techniques
@@ -159,13 +178,13 @@
communication infrastructure it could be helpful if we create a port
abstraction using either an identifier at the beginning of the
payload or different mailbox names for the Local delivery present in
- the last header of the message]
+ the last header of the message -GD]
[In order to avoid retransmissions, that could help traffic analysis,
an idea would be to send the messages of the above protocol using a
forward error correcting scheme. The Server, and clients, could
measure the reliability of the network, by sending messages to
themselves, and encode each message in a (n out of m) fashion. Maybe
- someone who is knowledgeable about such schemes would like to comment?]
+ someone who is knowledgeable about such schemes would like to comment? -GD]
References