[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[minion-cvs] From peter: remove trailing whitespace
Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv8521
Modified Files:
E2E-spec.txt api-spec.txt dir-agreement.txt dir-spec.txt
minion-spec.txt nym-spec.txt spec-issues.txt
Log Message:
From peter: remove trailing whitespace
Index: E2E-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/E2E-spec.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- E2E-spec.txt 12 Sep 2003 15:32:28 -0000 1.10
+++ E2E-spec.txt 1 Oct 2003 22:15:23 -0000 1.11
@@ -92,14 +92,14 @@
1.1. Terminology
* "Packet" - A Type III mix packet. Fixed in size to 32 KB.
-
+
* "Message" - A variable size end-to-end message, transmitted
from one location from another. May be larger or smaller
than a single packet.
* "Forward message" - A message sent anonymously to a known
recipient.
-
+
* "Direct reply message" - A message sent to an known recipient,
with no attempt to maintain sender anonymity.
@@ -112,7 +112,7 @@
* "Forward encrypted message" - A forward message encrypted to
the public key of its recipient.
- * "Corrupted packet" - A packet which has had its payload
+ * "Corrupted packet" - A packet which has had its payload
corrupted on the second leg of its path. [Other forms of
corruption will result in the message's not being delivered.]
@@ -137,7 +137,7 @@
[XXXX]
2.1.1. Compression
-
+
We define a compression primitive based on ZLIB, as defined in
RFC-1950 and RFC-1951. Because these standards describe only a
message format, and do not mandate a single compression algorithm,
@@ -160,18 +160,18 @@
from the Gzip team has averred that this is so with all zlib
versions from 1.0.4 through 1.1.4, but *may* change in some future
version.
-
+
We also define DECOMPRESS as the inverse of COMPRESS: namely, ZLIB
decompression as described in RFCs 1950 and 1951. Note that not
DECOMPRESS is not defined for every sequence of bytes.
-
+
2.1.2. K-of-N fragmentation
We define a primitive, FRAGMENT, that breaks a K-packet message
into N>K packets, such that any K of those packets are sufficient
to reconstruct the original message with high probability.
FRAGMENT(M,K,N,i) is the i'th such packet.
-
+
We also define a primitive RECONSTRUCT(K,N,P_i1, P_i2,...P_iK) that
reconstructs the original message.
@@ -182,7 +182,7 @@
Currently, we use the algorithm described by Luigi Rizzo in several
papers and implemented in software at
- http://info.iet.unipi.it/~luigi/fec.html .
+ http://info.iet.unipi.it/~luigi/fec.html .
This algorithm has
several advantages: first, it has freely-available implementations
in C and Java under a modified-BSD style license. Second, it runs
@@ -200,7 +200,7 @@
reconstructed if and only if K packets from each chunk arrive
intact. Because packet loss is likely to be nonuniformly concentrated
at specific remailers and links, this is not so dangerous to
- reliability as it might initially appear.
+ reliability as it might initially appear.
[NOTE: I am not happy with this current situation: there needs to
be _some_ unpatented probabilistic O(N) algorithm out there! -NM]
@@ -213,26 +213,26 @@
PS: payload sized (fixed)
EXF: expansion factor (fixed: everyone must use the same EXF,
see below.)
-
+
Let M_SIZE = CEIL(LEN(M) / PS)
Let K = Min(16, 2**CEIL(Log2(M_SIZE)))
Let NUM_CHUNKS = CEIL(M_SIZE / K)
-
+
Let M = M | PRNG(Len(M) - NUM_CHUNKS*PS*K)
-
+
For i from 1 to NUM_CHUNKS:
Let CHUNK_i = M[(i-1)*PS*K : i*PS*K]
End
-
+
Let N = Ceil(EXF*K)
-
+
For i from 0 to NUM_CHUNKS-1:
For j from 0 to N-1:
FRAGMENTS[i*N+j] = FRAGMENT(CHUNK_i, K, N, j)
End loop
End loop
-
+
Return FRAGMENTS.
[If we find an unpatented O(N) algorithm, we use it instead of this
@@ -255,7 +255,7 @@
turning DIVIDE from an erasure correcting code into a full secret
sharing encoding: If insufficient packets are received to reconstruct
the whole message, none of the message can be reconstructed.
-
+
2.2. Generating messages
When sending a message as packets, a sender follows these steps:
@@ -268,18 +268,18 @@
3. Annotate each payload with a payload header. (The payload
header includes size, integrity, and fragmentation
information.)
- 4. According to the type of the message, encode each payload into
+ 4. According to the type of the message, encode each payload into
a final 28KB paylaod and (possibly) 20-octet decoding handle.
5. For each payload, select a list of servers to form a path
through the network.
6. Using the decoding handle, payload contents, and route for
each payload, generate a 32KB type III packet.
- 7. Deliver each packet
+ 7. Deliver each packet
This section will describe steps 1, 2, 3, 4. Step 5 is described
more fully in "path-spec.txt". Steps 6 and 7 are described in
- "minion-spec.txt".
-
+ "minion-spec.txt".
+
2.2.1. Packet format
As described in minion-design.txt, every mixminion packet contains a
@@ -305,28 +305,28 @@
* Plaintext forward - the handle is unused; its value is random.
* Encrypted forward - the handle holds the first 20 octets of the
- RSA-encrypted session key for this packet.
+ RSA-encrypted session key for this packet.
- * Reply - the handle (generated by the SURB creator) contains a
+ * Reply - the handle (generated by the SURB creator) contains a
random seed used to seed the RNG that generated the master
secrets for this SURB header.
2.2.1.2. Payload formats
The payload of every packet, when decrypted, begins with the one of
- the two following headers.
+ the two following headers.
SINGLE-PACKET-MESSAGE Payload: [Header size is 22 octets]
-
+
(Single-packet message flag) [1 bit: 0]
(Length of packet contents) [15 bits]
(Hash of packet contents) [20 octets]
The length field encodes the size of the contents of the packet
- after compression.
+ after compression.
FRAGMENT Header: [Header size is 47 octets]
-
+
(Multi-packet message flag) [1 bit: 1]
(Packet index) [23 bits]
(Hash of remaining fields and packet
@@ -341,7 +341,7 @@
We define the constants FRAGMENT_HEADER_LEN = 47 and
SINGLETON_HEADER_LEN=22.
-
+
To break a message into packets with headers (steps 2 and 3 in 2.2
above), an implementation follows these steps:
@@ -357,19 +357,19 @@
- OVERHEAD
Let PADDING = Rand(PADDING_LEN)
-
+
Return a singleton payload containing:
Flag 0 | Int(15,LEN(M_C)) | Hash(M_C | PADDING) | M_C | PADDING
Otherwise:
Let FRAGMENTS = DIVIDE(M_C, 28KB-OVERHEAD-FRAGMENT_HEADER_LEN)
-
+
Let ID = Rand(TAG_LEN)
Let SZ = Int(32,Len(M_C))
For every FRAGMENT_i in FRAGMENTS:
-
+
Let PAYLOAD_i = a fragment payload containing:
Flag 1 | Int(23,i) | Hash(ID | SZ | FRAGMENT_i ) | ID
| SZ | FRAGMENT_i
@@ -465,14 +465,14 @@
procedure. To use this method, SURB generators must store a
separate long-term secret for each identity they wish to associate
with a chain of SURBs.
-
+
(Client software MUST support multiple identities, and MUST make
it clear to the user which identity has been associated with each
incoming SURB.)
To generate a SURB for a path of length PATH_LEN, using a long-term
secret SEC:
-
+
Repeat:
Let SEED = a random 159-bit seed.
Until Hash(SEED | SEC | "Validate") ends with a 0 byte.
@@ -501,7 +501,7 @@
Message decoders recognize plaintext (singleton or fragment)
payloads by checking whether the hash fields match the calculated
- hash of the rest of the packet.
+ hash of the rest of the packet.
If a message decoder knows one or more SURB secrets, it then checks
the decoding handle 'TAG' to see whether Hash(TAG | SEC |
@@ -509,7 +509,7 @@
decoder generates secrets from TAG | SEC as in SURB generation, and
successively decrypts the payload with up to MAX_PATH of them,
checking each time for a plaintext payload.
-
+
If no SURB secrets are known, or if no SURB secrets yield a
plaintext payload, and the decoder knows one or more secret keys
SK_i, it then checks whether PK_Decrypt(SK_i, TAG |
@@ -532,7 +532,7 @@
If P[2:HASH_LEN] = Hash(P[2+HASH_LEN:Len(P)-2-HASH_LEN]):
SZ = P[0:2]
Return "Singleton", P[2+HASH_LEN : SZ]
- Otherwise,
+ Otherwise,
Return "Unknown"
Otherwise, if the first bit of P[0] is 1:
If P[3:HASH_LEN] = Hash(P[3+HASH_LEN:Len(P)-3-HASH_LEN]):
@@ -560,17 +560,17 @@
Let P_t = P.
For j in 0 ... MAX_PATH-1:
Let P_t = SPRP_Encrypt(STREAM[j * KEY_LEN : KEY_LEN],
- "PAYLOAD_ENCRYPT",
+ "PAYLOAD_ENCRYPT",
P_t)
If DECODE_PLAINTEXT_PAYLOAD(P_t) is not "Unknown", return it.
-
+
For all SK_i:
Let E0 = TAG | P[0:Len(SK_i)-TAG_LEN]
Let P0 = PK_Decrypt(SK_i, E0).
If the OAEP padding is valid:
Let K = P0[0:KEY_LEN]
Let P0' = P0[KEY_LEN:Len(P0)-KEY_LEN]
- Let P1 = SPRP_Decrypt(K, "END-TO-END ENCRYPT",
+ Let P1 = SPRP_Decrypt(K, "END-TO-END ENCRYPT",
P[Len(SK_i)-TAG_LEN : Len(P)-Len(SK_i)+TAG_LEN])
If DECODE_PLAINTEXT_PAYLOAD(P0'|P1) is not "Unknown", return it.
@@ -599,14 +599,14 @@
When a server receives a plaintext forward packet containing a
fragment of a message, it should behave as follows:
-
+
- If the server does not support reconstruction, or if the hash
of the packet is invalid, it drops the packet.
- From the declared message size of the message, it calculates
the number of packets it expects. If this number is higher
than the maximum number of packets the server is willing to
- construct, it drops the packet.
+ construct, it drops the packet.
- If the server has already logged this message ID as finished,
it drops the packet.
@@ -668,7 +668,7 @@
header MUST be "plaintext".
[XXXX Right now, there's no way to specify an encoding in a
- message. Don't worry--you didn't misread. -NM]
+ message. Don't worry--you didn't misread. -NM]
3.1.2. RFC822 headers
@@ -734,20 +734,20 @@
3.2.2. Formatting: Message body
- Header encoding is as described in 3.1.2 above.
+ Header encoding is as described in 3.1.2 above.
The following headers are allowed:
"SUBJECT" (any. Must be no more than 900 characters long.)
"FROM" (any sequence of printing ASCII characters
excluding '"', '[', ']', and ':'. )
-
+
"IN-REPLY-TO" (an RFC2822 msg-id)
"REFERENCES" (a list of RFC2822 msg-ids)
[XXXX Are msg-ids really what we want? Should we say more? Should
we restrict encoding? -NM]
- Unrecognized or malformatted headers MUST be removed.
+ Unrecognized or malformatted headers MUST be removed.
3.2.3. Delivery
@@ -788,7 +788,7 @@
words, Eve can already tell which messages set their from
addresses; she gains nothing by learning that those messages
have chosen an exit node with From support to do so. -NM]
-
+
The "Date" line should be the current date.
The "In-Reply-To" and "References" lines should be taken verbatim
@@ -814,7 +814,7 @@
longer than this by a factor of ~1.33. The value must be at least
"32". It MUST contain a "Allow-From" line, containing 'yes' if the
server allows user-supplied from addresses and 'no' if it does not.
-
+
3.3. SMTP
The routing type 0x100 corresponds to SMTP (email) delivery.
@@ -834,7 +834,7 @@
HOSTPART ::= ATOM | LOCALPART DOT ATOM
ATOM ::= ATOMCHAR | ATOM ATOMCHAR
ATOMCHAR ::= Any character in the range hex 21 through hex 7E,
- excluding '[', ']', '(', ')', '<', '>', '@', ',', '.',
+ excluding '[', ']', '(', ')', '<', '>', '@', ',', '.',
';', ':', '\', and '"'.
AT ::= '@' (ASCII hex 40)
DOT ::= '.' (ASCII hex 2E)
@@ -845,7 +845,7 @@
[XXXX I suspect the above should be "SHOULD NOT." -NM]
3.3.2. Formatting: Message body
-
+
The message body format is exactly as the MBOX format, as
described above in 3.2.2.
@@ -854,11 +854,11 @@
To deliver an SMTP message, an exit node that supports the SMTP
delivery type SHOULD construct an RFC2822 message as described in
3.2.3 above, additionally setting the 'To' line to the mailbox
- given in the message header.
+ given in the message header.
Implementations SHOULD allow exit node operators to configure
additional fields, and to block specific 'To' addresses.
-
+
3.3.4. Server descriptor section
Servers that support SMTP delivery MAY include a [Delivery/SMTP]
@@ -873,7 +873,7 @@
longer than this type. It MUST contain a "Allow-From"
line, containing 'yes' if the server allows user-supplied from
addresses and 'no' if it does not.
-
+
3.4. Fragments
3.4.1. Server descriptor section
@@ -885,7 +885,7 @@
The section, if present, MUST contain a 'Version' entry, with the
value "1.0". It also MUST contain a "Maximum-Fragments" line,
containing the maximum size (in fragments) of a message that the
- server is willing to reconstruct.
+ server is willing to reconstruct.
A.1. Apendix: versioning and alphas
Index: api-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/api-spec.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- api-spec.txt 22 Aug 2003 01:17:59 -0000 1.2
+++ api-spec.txt 1 Oct 2003 22:15:24 -0000 1.3
@@ -42,7 +42,7 @@
*/
typedef void *(*mix3_allocator)(size_t n);
typedef void (*mix3_deallocator)(void *ptr);
-void mix3_set_allocator(mix3_allocator allocator,
+void mix3_set_allocator(mix3_allocator allocator,
mix3_deallocator deallocator);
/* Anything that will be freed by a mix3_* function must be
* mix3_alloc'd; anything that was alloced by a mix3_* function must
@@ -75,7 +75,7 @@
MIX3_NOMEM,
/* The operation failed because the arguments given to the
* function were invalid.
- */
+ */
MIX3_BADARGS,
/* The operation failed because the directory, server
* descriptor, message, etc provided was not correctly
@@ -104,13 +104,13 @@
/* XXXX We need __way__ more error codes. I don't know */
} mix3_status;
-/* Effects: Given a mix3_status code, return a English string.
+/* Effects: Given a mix3_status code, return a English string.
* Allocates: nothing.
*/
const char *mix3_status_string(mix3_status status);
/* ==================== */
-/* Directories */
+/* Directories */
/* ==================== */
/* Opaque struct to hold a Type III directory */
@@ -130,7 +130,7 @@
* approximately -n random servers are chosen.
*/
typedef struct mix3_pathcomponent {
- enum { MIX3_PC_NICKNAME, MIX3_PC_DESCRIPTOR, MIX3_PC_RANDOM,
+ enum { MIX3_PC_NICKNAME, MIX3_PC_DESCRIPTOR, MIX3_PC_RANDOM,
MIX3_PC_SWAP } type;
union {
char *name;
@@ -157,7 +157,7 @@
} mix3_capability_spec;
/* Struct to specify the destination of a Type III message. */
typedef struct mix3_address_spec {
- enum { MIX3_ADDR_EMAIL, MIX3_ADDR_MBOX, MIX3_ADDR_NEWS,
+ enum { MIX3_ADDR_EMAIL, MIX3_ADDR_MBOX, MIX3_ADDR_NEWS,
MIX3_ADDR_DROP, MIX3_ADDR_OTHER, MIX3_ADDR_REPLY, } type;
union {
char *address;
@@ -238,18 +238,18 @@
* directory that match certain properties.
*
* Arguments:
- * servers_out -- If the function succeeds, *servers_out will be a
+ * servers_out -- If the function succeeds, *servers_out will be a
* NULL-terminated array of pointers to server descriptors.
* byNickname -- If not NULL, the function only yields server
* descriptors whose nicknames match byNickname.
* byCapability -- If not NULL, the function only yields server
* descriptors that have at leas tthe capabilities set in
- * *byCapability.
+ * *byCapability.
* validBy -- If not 0, the function only yields server descriptors
* that become valid at some time before validBy.
* validUntil -- if not 0, the function only yields server
* descriptors that do not become invalid before validUntil.
- *
+ *
* Allocates: servers_out; it must be freed.
*/
mix3_status mix3_directory_get_servers(
@@ -284,7 +284,7 @@
/* === Helper functions for server descriptors. === */
/* Return a raw field from a server descriptor, by section and field
- * name.
+ * name.
*/
const char *mix3_serverdesc_get_field(mix3_serverdesc *desc,
const char *section,
@@ -303,7 +303,7 @@
* validate -- If true, check the signature on the descriptor.
*
* Allocates: *serverdesc_out, which must be freed with
- * _mix3_serverdesc_free.
+ * _mix3_serverdesc_free.
*/
mix3_status _mix3_serverdesc_parse(
mix3_serverdesc **serverdesc_out,
@@ -377,7 +377,7 @@
/* A structure to specify a message header for a SMTP or NEWS message.
*/
typedef struct mix3_header_spec {
- enum { MIX3_HDR_FROM, MIX3_HDR_SUBJECT, MIX3_HDR_IN_REPLY_TO,
+ enum { MIX3_HDR_FROM, MIX3_HDR_SUBJECT, MIX3_HDR_IN_REPLY_TO,
MIX3_HEADER_REFERENCES } header;
char *value;
} mix3_header_spec;
@@ -402,7 +402,7 @@
* Allocates: *mix3_payload_out. Each element of *mix3_payload_out[]
* should be passed to mix3_free, followed by *mix3_payload_out
* itself.
- *
+ *
* XXXX This fails if the message won't all fit into memory with the
* payloads. That's probably okay.
*/
@@ -535,13 +535,13 @@
* MIX3_WANTREAD or MIX3_WANTWRITE as status.
*
* Allocates: *mix3_mmtp_connection, which must be freed with
- * mix3_mmtp_connection_free.
+ * mix3_mmtp_connection_free.
*/
mix3_status mix3_mmtp_new_connection(
mix3_mmtp_connection **out,
mix3_serverdesc *server,
bool blocking);
-/* XXXX What to do about DNS, if we ever do DNS. */
+/* XXXX What to do about DNS, if we ever do DNS. */
/* XXXX We also need to do something about 'REJECTED' replies. */
@@ -609,7 +609,7 @@
*/
int mix3_mmtp_get_n_acks(mix3_mmtp_connection *conn);
-/* Renegotiate a key with a connected MMTP server. Returns as above.
+/* Renegotiate a key with a connected MMTP server. Returns as above.
*/
mix3_status mix3_mmtp_renegotiate(mix3_mmtp_connection *conn);
@@ -671,7 +671,7 @@
/* Identity of a fragment within a fragmented message */
typedef unsigned long mix3_fragment_fragment_id;
-
+
/* Return the length of the (compressed) message corresponding to
* pkt. */
size_t mix3_decoded_packet_get_length(mix3_decoded_packet *pkt);
Index: dir-agreement.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-agreement.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- dir-agreement.txt 14 Aug 2003 21:25:36 -0000 1.4
+++ dir-agreement.txt 1 Oct 2003 22:15:24 -0000 1.5
@@ -7,7 +7,7 @@
This is a draft document describing a directory agreement protocol
for Type III remailers. If people like it, we'll merge in into
- Mix3:3 "dir-spec.txt".
+ Mix3:3 "dir-spec.txt".
It's substantially identical to what Nick was blathering about at
Defcon.
@@ -21,7 +21,7 @@
Currently, we have specifications for most of the type III
directory system, including: server descriptor structure, directory
- structure, publishing to directories, building directories,
+ structure, publishing to directories, building directories,
downloading directories, and using directories. One critical
piece remains: directory agreement.
@@ -43,7 +43,7 @@
which directory helps the attacker mount statistical
partitioning attacks on the network based on client
knowledge.
-
+
(If users try to avoid this attack by using multiple
directories, they only make their situation worse: Instead
of dividing themselves into D possible states of knowledge,
@@ -61,12 +61,12 @@
an absolute requirement. In particular, the protocol should
succeed even when the directory servers do not agree on who is
a directory server.
-
+
- The protocol should allow old directory servers to shut down,
and new directory servers to join, but should not allow an
attacker to control the final directory by signing up a large
number of directory servers.
-
+
- When the protocol succeeds, it should create a directory
signed by a large quorum of directory servers. If at least
half of the quorum has signed a directory, clients should be
@@ -79,7 +79,7 @@
- If at least half of the directory servers in a quorum are
running, cooperative, and able to communicate, then they
should produce a signed directory.
-
+
- The protocol should discourage social engineering attacks
aiming to fragment a quorum of directory servers. Although
it is impossible to *force* only a single directory to exist
@@ -136,7 +136,7 @@
directory.
Below, I discuss this protocol in more detail.
-
+
1. Terminology
@@ -261,7 +261,7 @@
and new server descriptors.
Phase 1: Declarations (22:00)
-
+
Once a day, at 22:00, every directory server publishes (at some
well known URL) a signed Declaration. A Declaration includes:
@@ -295,12 +295,12 @@
For auditing purposes: Along with their pre-directories,
directory servers also publish a signed copy of the declarations
they have used to compute the pre-directory.
-
+
Phase 4: Pre-directories are collected (23:00-23:50)
Directories collect one another's signed pre-directories as in
Phase 2.
-
+
Phase 5: A directory is published (00:00)
Every directory collects the pre-directories from step 4 from
@@ -406,7 +406,7 @@
- It lists mixes as "recommended" iff they are considered
reliable by enough members of the quorum and they are
considered credible by enough members of the quorum.
-
+
[If the quorum has an odd number N members, "enough" is
FLOOR(N/2)+1.]
Index: dir-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- dir-spec.txt 4 Sep 2003 16:14:02 -0000 1.14
+++ dir-spec.txt 1 Oct 2003 22:15:24 -0000 1.15
@@ -49,7 +49,7 @@
A.2. Appendix: Suggested path selection algorithm
1. Introduction
-
+
For a Mix network to provide anonymity to its users, it is vital
that those users to provide cover traffic to one another by
behaving as similarly as possible when choosing paths and servers
@@ -70,14 +70,14 @@
* Server Descriptor - A human-readable text message describing a
set of keys and capabilities for a single Mix.
-
+
* Directory - A human readable text message describing a list of
Mixes and their keys.
* Identity Key - A long-term signing RSA key used for
authenticating server descriptors and directories.
- * Nickname - A human-readable unique identifier for a Mix.
+ * Nickname - A human-readable unique identifier for a Mix.
This document uses the terms "MUST", "SHOULD", "MAY", "MUST
NOT", "SHOULD NOT", and "MAY NOT" as defined in RFC 2119.
@@ -153,10 +153,10 @@
To enable backward-compatible extensions of the Exchange format, all
processors of Mix Information Exchange Messages MUST behave as
follows when encountering unrecognized headers or entries.
-
+
When processing a section with an unrecognized identifier, the
processor must ignore the section completely.
-
+
When processing a section with a recognized identifier, the
processor must check whether it recognizes the version number of
that section (usually encoded in an entry with the identifier
@@ -177,7 +177,7 @@
- All numeric quantities are represented in decimal.
- All dates are represented in YYYY-MM-DD format.
-
+
- All times are represented in YYYY-MM-DD HH:MM:SS or YYYY-MM-DD
HH:MM:SS.mmmm format, relative to UTC.
@@ -204,9 +204,9 @@
Address ::= '*' | IP OptMask
OptMask ::= '/' IP |
IP ::= <an IPv4 dotted quad>
-
+
OptPortSpec ::= | Port | Port '-' Port
-
+
An omitted mask defaults to 255.255.255.255. '*' is a synonym
for 0.0.0.0/0.0.0.0. An omitted PortSpec defaults to 48099 for
'allow' entries and 0-65535 on 'deny' entries.
@@ -239,16 +239,16 @@
to and downloaded from directory servers. A server descriptor is a
promise, by a mix's administrators, to provide a given set of
services, keys, and exit policies over a set period of time.
-
+
The first section must be a 'Server' section. This section MUST
include each of the following entries in any order, exactly once.
-
+
'Descriptor-Version': the string '1.0'
'Nickname': A human-readable identifier for this server. It
MUST be no more than 128 characters. It MUST contain only
the characters [A-Za-z0-9_@] and '-'.
-
+
'Identity': This Mix node's identity key, represented in ASN.1,
and encoded in BASE64. The modulus of this key should be at
least 2048 bits long and no more than 4096 bits long. The
@@ -312,11 +312,11 @@
normalize CR and CR-LF style newlines to a single NL, and remove
any spaces and tabs that may have been introduced at the ends of
lines.]
-
+
If this server accepts incoming MMTP connections, it MAY have an
'Incoming/MMTP' section, with the following entries, exactly once
each:
-
+
'Version': The string '1.0'
'IP': An IPv4 address, in dotted-quad format. [Deprecated but
@@ -338,28 +338,28 @@
'Protocols': A comma-separated list of the versions of MMTP this
server accepts.
-
+
The 'Incoming/MMTP' section MAY contain any number of entries of
the form:
'Allow': AddressPattern
'Deny': AddressPattern
-
+
If this server supports outgoing MMTP connections, it MAY have an
'Outgoing/MMTP' section, with the following entries, exactly once
each:
-
+
'Version': The string '1.0'
'Protocols': A comma-separated list of versions of MMTP this
server supports for outgoing connections.
-
+
The 'Outgoing/MMTP' section MAY contain any number of entries of the
form:
-
+
'Allow': AddressPattern
'Deny': AddressPattern
-
+
These entries are order-significant; the first one to match wins.
The default policy is 'Deny: *'.
@@ -368,18 +368,18 @@
Implementations MUST NOT require any specific entries within 'Testing';
implementations also MUST NOT require any specific format for entries
that may be present.
-
+
If this server supports outgoing delivery mechanisms, it MAY have
corresponding delivery sections. See 'E2E-spec.txt' for more details
on specific types, including SMTP and MBOX.
-
+
Other services provided by this server SHOULD each have their own section.
-
+
Note: A server MAY omit some of its capabilities from its descriptor.
It is permissible (for example) for a server that supports incoming
MMTP connections to omit the Incoming/MMTP section. A server
MUST NOT, however, advertise any capabilities it does not support.
-
+
3.1. Server Identity
Every server descriptor contains two fields that identify the
@@ -401,7 +401,7 @@
When choosing between multiple server descriptors for the same Mix
that are valid at the same time, implementations SHOULD choose the
most recently published descriptor.
-
+
The interval of time between a descriptor's 'Valid-After' and
'Valid-Until' dates is called its Lifetime.
@@ -413,28 +413,28 @@
same server, that descriptor is said to be Superceded.
4. Directory Format
-
+
A directory contains a list of Mixminion servers which are believed
to be operational at a given time. A directory MUST contain all of
the following, in order:
- A 'Directory' section,
- - A 'Signature' section,
- - A 'Recommended-Software' section,
+ - A 'Signature' section,
+ - A 'Recommended-Software' section,
- One or more server descriptors (see section 3 above).
The 'Directory' section MUST contain the following entries:
-
+
- 'Version': The string '1.0'
-
+
- 'Published': The time when this directory was generated.
-
+
- 'Valid-After' : A date. This directory SHOULD NOT be used before
midnight GMT on this date.
- 'Valid-Until' : A date. This directory SHOULD NOT be used after
midnight GMT on this date. This date SHOULD be exactly one day
after the date in 'Valid-After'.
-
+
- 'Recommended-Servers' : A comma-separated list of server
nicknames. Clients SHOULD NOT depend on servers whose nicknames
are not on this list to be reliable or trustworthy.
@@ -454,7 +454,7 @@
The 'Recommended-Software' section MUST contain the following
entries:
-
+
- 'MixminionClient' : A comma-separated list of up-to-date versions
of Mixminion. If a client is running a version more
recent than any on the list, it SHOULD issue a warning. If a
@@ -493,9 +493,9 @@
band.
5.2. Publishing a server descriptor
-
+
A directory server SHOULD provide one or more well-known HTTP URLs
- to publish server descriptors to the directory.
+ to publish server descriptors to the directory.
To upload a descriptor block, a client performs an HTTP POST request
to the upload URL, with the server block as the contents of a single
@@ -517,13 +517,13 @@
be accepted into the directory, the status MUST be 0, and the
message SHOULD be a description of why the server descriptor was not
accepted.
-
+
Finally, if the upload was successful, but the descriptor will only
be accepted into the directory when manually approved by the
administrator, the status MUST be 1, and the message MUST be a
description of the status of the descriptor, and MUST NOT be
'Accepted.'.
-
+
6. Generating server descriptors
Servers SHOULD generate at least a [[two weeks]] of keys in advance,
@@ -548,9 +548,9 @@
all sections except 'Server' absent.
7. Generating directories
-
+
Directory servers SHOULD change their directories only at midnight
- GMT.
+ GMT.
For every mix, the directory SHOULD either include no descriptors
from that mix; or include all of that mix's published descriptors
@@ -563,7 +563,7 @@
its users anonymity. A 'reliable' mix is one that delivers packets
with high probability and reasonable latency. Directories SHOULD
include only trustworthy and reliable mixes on their
- 'Recommended-Servers' entry.
+ 'Recommended-Servers' entry.
8. Downloading directories
@@ -602,7 +602,7 @@
of length N', and 'random path of random length (E[length]=N)'.
[This algorithm is implemented in Mixminion 0.0.5]
-
+
The inputs to this algorithm are:
1) The earliest time at which the path must be valid. (T_Start)
2) The latest time at which the path must be useable. (T_End)
@@ -631,7 +631,7 @@
meets these criteria:
E) Has its nickname the 'Recommended-servers' list.
-
+
Next, the client resolves explicitly specified servers: every
server specifier with a provided nickname resolves into the
'current' server descriptor with that nickname. If there is no
@@ -648,4 +648,4 @@
specifiers. The client picks 'preferred' server descriptors at
random, with replacement, avoiding any sequence of two consecutive
server descriptors with the same nickname.
-
+
Index: minion-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/minion-spec.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- minion-spec.txt 1 Oct 2003 00:29:57 -0000 1.13
+++ minion-spec.txt 1 Oct 2003 22:15:24 -0000 1.14
@@ -108,7 +108,7 @@
and others, based on the PGP message format, using SMTP for an
underlying transport. Also known as the "cypherpunk"
implementation.
-
+
* Type II - an anonymity service originally designed by Lance
Cottrell to address the flaws of the Type I system, and
implemented in the software "Mixmaster".
@@ -118,7 +118,7 @@
This document uses the terms "MUST", "SHOULD", "MAY", "MUST
NOT", "SHOULD NOT", and "MAY NOT" as defined in RFC 2119.
[XXXX is this wise? Observable variation=linkability. -NM]
-
+
* Packet - A 32 kilobyte string transmitted anonymously through
the Type III remailer network.
@@ -135,7 +135,7 @@
In this section, we provide an overview of the operations of Type
III remailers
-
+
[XXXX We need to be more explicit here, or somewhere, about
crossover points and what exactly is encrypted with what. XXXX]
@@ -182,7 +182,7 @@
8. The server waits until enough time has passed, and/or enough
packets have been received. [A suggested rule is described
in appendix A.1 below.]
-
+
9. If the server is the final mix on the path, it delivers the
message to the recipient [as described in section
3.2.5.2.], else it delivers it to the next mix [as described
@@ -208,7 +208,7 @@
3. Through some means the recipient delivers the SURBs
anonymously to the sender, possibly as the contents of a
- forward message.
+ forward message.
4. The sender constructs one or more packets for the recipient
and inserts them into the network to be delivered, as in
@@ -240,7 +240,7 @@
[XXXX]
3.1.1. Cryptographic primitives
-
+
Implementing a Type III remailer only requires the combination of
standardized cryptographic primitives. Most third party
cryptographic libraries or providers should support RSA-OAEP (PKCS#1
@@ -275,7 +275,7 @@
value will make the decryption look like random bits, we use an
instance of the LIONESS SPRP, with SHA-1 for a hash and the
stream described in 3.1.1.2 above.
-
+
Thus, in the notation described below, we encrypt a message M with
a key K as follows:
K1 = K
@@ -314,14 +314,14 @@
ASCII string (a quotation from Thomas Paine):
"He who would make his own liberty secure, must guard even his
- enemy from oppression."
+ enemy from oppression."
- (In hexadecimal, the hash of P is:
+ (In hexadecimal, the hash of P is:
[90 89 60 BC 88 EF 92 B0 9c 58 26 C4 BE 32 B3 34 A7 1C AA 5A].)
For all public key operations in Type III packets, we use 2048-bit
keys. We define:
-
+
PK_OVERHEAD_LEN = 42 (octets added by OAEP padding)
PK_ENC_LEN = 256 (size of RSA-encrypted data)
PK_MAX_DATA_LEN = PK_ENC_LEN - PK_OVERHEAD_LEN = 214
@@ -333,12 +333,12 @@
We use the following function-style notations in describing our
packet format.
-
+
- Len(A) - The length, in octets, of an octet array A.
- A[i:j] - If A is an octet array, A[i:j] is a subarray starting at
octet i with length j. (Len(A[i:j]) = j)
-
+
- Rand(n) - Generates n random octets by any secure method.
Successive instances of Rand generate different and uncorrelated
sequences. (Len(Rand(n)) = n)
@@ -361,27 +361,27 @@
Len(PK_Encrypt(PK,M) = PK_ENC_LEN = 256)
- PK_Decrypt(SK, M) - The private-key decryption of an octet array
- M using the secret key SK.
+ M using the secret key SK.
(0 <= Len(PK_Decrypt(SK,M)) <= PK_MAX_DATA_LEN = 214)
- PK_Encode(PK) - The ASN.1 encoding of a public key PK.
- PRNG(K, n) - Uses a cryptographic stream generator to produce n
octets, using key K. (Len(K) = KEY_LEN = 16; Len(PRNG(K,n)) = n)
-
+
- Encrypt(K, M) = M ^ PRNG(K,Len(M)) - The encryption of an octet array
M with our stream cipher, using key K. (Encrypt(Encrypt(M)) = M.)
- - SPRP_Encrypt(K, M) - The encryption of an octet array M using our
- super-pseudorandom permutation with key K.
+ - SPRP_Encrypt(K, M) - The encryption of an octet array M using our
+ super-pseudorandom permutation with key K.
(Len(K) = SPRP_KEY_LEN = 20; Len(SPRP_ENC(K,M)) = Len(M))
- SPRP_Decrypt(K, M) - The decryption of an octet array M using our
- super-pseudorandom permutation with key K.
+ super-pseudorandom permutation with key K.
(Len(K) = SPRP_KEY_LEN = 20; Len(SPRP_DEC(K,M)) = Len(M))
- SubKey(K,S) - Derivation of a named sub key, using a master key K
- (Len(K) = 16) and an aribrary length ASCII String.
+ (Len(K) = 16) and an aribrary length ASCII String.
(Len(SubKey(K,S)) = 16)
SubKey(K,S) = Hash(K, S)[0:16]
@@ -389,8 +389,8 @@
integer N.
To improve the readability of our specification, we use the
- following symbolic constants:
-
+ following symbolic constants:
+
- HASH_LEN = 20
- KEY_LEN = 16
- PK_OVERHEAD_LEN = 42
@@ -441,7 +441,7 @@
protocol. If a Mix receives a packet with an unrecognized
version, it must discard that packet. Note that the major and
minor version numbers are stored using their binary
- representations (not the corresponding ASCII codes.)
+ representations (not the corresponding ASCII codes.)
(Nodes must advertise in their status blocks what versions of
the protocol they support; see "dir-spec.txt".)
@@ -467,9 +467,9 @@
We will refer to the fixed-size part of the subheader structure as:
FSHS(V, SK, D, RS, RT) = V|SK|D|RS|RT [MIN_SH = 42 octets]
-
+
We will refer to the entire subheader as:
- SHS(V, SK, D, RS, RT, RI) = FSHS(V,SK,D,RS,RT) | RI
+ SHS(V, SK, D, RS, RT, RI) = FSHS(V,SK,D,RS,RT) | RI
[42+Len(RI) octets]
3.2.1.1. Routing information
@@ -518,7 +518,7 @@
a server is addressed via a static IPs, it should use a dotted quad
as their hostname. As of Mixminion 0.0.7, the types formerly
associated with *FWD/IPv4 will become unallocated.]
-
+
See 'E2E-spec.txt' for more information about SMTP and MBOX delivery.
3.2.2. Header Structure
@@ -537,17 +537,17 @@
be more or less than PK_MAX_DATA_LEN=214 octets long, some of the
RI field may spill into the stream-encrypted portion, or some of
the next mix's header may spill into the RSA-encrypted portion.
-
+
These diagrams should help explain:
1. If the subheader is less than PK_MAX_DATA_LEN octets long, it
fits into a single RSA encryption along with some of the data
from the rest of the header.
-
+
Before: (S is the new subheader, H is the existing header material)
SSSSSSSSSS HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH.....
- After:
+ After:
(Encrypted with RSA) (Encrypted with AES)
SSSSSSSSSSHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH.....
@@ -569,9 +569,9 @@
H1 = PK_Decrypt(PK, H[0:PK_ENC_LEN])
K = SubKey(H1[2:KEY_LEN], "HEADER SECRET KEY")
H2 = Encrypt(K, H[PK_ENC_LEN: 2048 - PK_ENC_LEN]
-
- // Reads the length of the routing information and extracts the
- // sub header.
+
+ // Reads the length of the routing information and extracts the
+ // sub header.
SH = (H1|H2)[0:MIN_SH + H1(38:2)]
MH = (H1|H2)[Len(SH):2048-Len(SH)]
@@ -579,14 +579,14 @@
[XXXX writeme]
3.2.4. Constructing a Type III packet
-
+
The information about how to build packets, headers and SURBs is
provided for information purposes only, since a pure type III
remailer server is not required to be capable of creating
packets. Understanding how packets are created may be beneficial
for understanding why the remailer processes them in the way
specified in section 3.2.5.
-
+
3.2.4.1. Building a header
Each type III packet has two headers with identical structure. These
@@ -645,14 +645,14 @@
PROCEDURE: Create a single header.
- Inputs: RI_1..RI_n, RT_1..RT_N (addresses of intermediate nodes),
+ Inputs: RI_1..RI_n, RT_1..RT_N (addresses of intermediate nodes),
PK_1 .. PK_N (Public keys of intermediate nodes),
SK_1 .. SK_N (Secret keys to be shared with intermediate nodes),
R Routing type and information of last header (FWD, DROP,
SWAP, etc.)
Output: H (The header)
- Process:
+ Process:
// Calculate the sizes of the subheaders.
for i = 1 .. N
// OAEP Padding plus invariant parts plus routing info.
@@ -693,7 +693,7 @@
SH0 = SHS(V, SK_i, Z(20), len(RI_(i+1)), RT_(i+1), RI(i+1))
SH_LEN = LEN(SH0)
H0 = SH0 | H_(i+1)
-
+
REST = H0[PK_MAX_DATA_LEN : Len(REST) - PK_MAX_DATA_LEN]
EREST = Encrypt(K, REST)
@@ -801,13 +801,13 @@
If Len(PK_PART) != PK_MAX_ENC_LEN, discard the packet.
FSHS(V, SK, D, RS, RT) = <extract from PK_PART[0:MIN_SH]>
- Check that D = Hash(H1[PK_ENC_LEN:HEADER_LEN-PK_END_LEN]),
+ Check that D = Hash(H1[PK_ENC_LEN:HEADER_LEN-PK_END_LEN]),
and discard if not.
Check for replays, as described in 3.2.5.1.
JUNK_KEY = SubKey(SK, "RANDOM JUNK")
- H1 = H1[PK_ENC_LEN : 2048-PK_ENC_LEN] |
+ H1 = H1[PK_ENC_LEN : 2048-PK_ENC_LEN] |
PRNG(JUNK_KEY, OAEP_OVERHEAD + MIN_SH + RS)
HEADER_KEY = SubKey(SK, "HEADER SECRET KEY")
H1 = H1 ^ PRNG(HEADER_KEY, Len(H1))
@@ -815,7 +815,7 @@
FULL_H = PK_PART[MIN_SH:Len(PK_PART)-MIN_SH] | H1
RI = FULL_H[0:RS]
H1 = FULL_H[RS:Len(FULL_H) - RS]
-
+
H2 = SPRP_Decrypt(SK, "HEADER ENCRYPT",H2)
P = SPRP_Decrypt(SK, "PAYLOAD ENCRYPT",P)
@@ -836,7 +836,7 @@
as "RFC822 mailbox") and a correct disposition of P (such as
"decode and deliver via SMTP"). For more information, see section
2.2.1.1 and 'E2E-spec.txt'.
-
+
3.2.5.1. Replay avoidance
The nodes MUST implement a mechanism to make sure that packets
@@ -872,10 +872,10 @@
3.3. SURB exchange formats.
This section describes how to encode SURBs for storage or
- transmission.
+ transmission.
A SURB can be encoded in a standard binary or ASCII format.
-
+
Binary Format:
Begin Marker: 4 octets
@@ -918,7 +918,7 @@
To encode a SURB for transport, implementations SHOULD support
OpenPGP-style ASCII armor, with the header text "BEGIN TYPE III
- REPLY BLOCK" and a single armor header, "Version: 1.0".
+ REPLY BLOCK" and a single armor header, "Version: 1.0".
4. Transport protocol
@@ -961,7 +961,7 @@
- B invents a DH key and sends a certificate chain containing:
- a certificate with B's transport public key, signed by B's
- identity key.
+ identity key.
- a self-signed certificate containing B's identity key.
* A checks that the Hash of the identity key is the same as
@@ -977,7 +977,7 @@
(Future clients that support more protocols should transmit
"MMTP ", a list of comma-separated protocol versions, and a CRLF.)
- * If B is not willing to use any protocol A supports, B closes the
+ * If B is not willing to use any protocol A supports, B closes the
connection.
B sends "MMTP 1.0", CRLF. This indicates B's choice of protocol.
@@ -1013,7 +1013,7 @@
* A sends "SEND", CRLF, M, HASH(M|"SEND") (6 + 32k + 20 octets)
* B sends "REJECTED", CRLF, HASH(M|"REJECTED") (10 + 20 octets)
-
+
[B must reject a packet if its hash is incorrect; if the
disk is full, or if for some other reason B cannot accept the
packet. Again, implementations should not be distinguishable
@@ -1025,19 +1025,19 @@
* If a connection persists for longer than 15 minutes, the client
must initiate key renegotiation. If it has not, the server must
close the connection.
-
+
NOTE:
The old keys must be permanently overwritten. Special care should be
- taken to permanently erase them from the Hard Disk and memory.
+ taken to permanently erase them from the Hard Disk and memory.
The standard transport mechanism over which the MixMinion Transfer
- Protocol talks is TCP over IP. The standard listening TCP port should be
+ Protocol talks is TCP over IP. The standard listening TCP port should be
number 48099 (until we register a port with www.iana.org)
All possible checks should be performed during the transfer protocol
and if any fail the connection MUST stop and all state MUST
- be deleted. An error MAY be logged.
+ be deleted. An error MAY be logged.
A.1. Appendix: A suggested pooling rule
@@ -1047,7 +1047,7 @@
to flooding attacks. Implementors are strongly encouraged to use
this algorithm, or another equally robust against active and
passive attacks. (Be sure to read \cite{batching-taxonomy}. [XXXX
- Ref])
+ Ref])
PROCEDURE: Choose sets of messages to transmit ("Cottrell-style batching")
@@ -1073,7 +1073,7 @@
Transmit the selected messages.
3. Repeat indefinitely.
-
+
A.2. Appendix: Backward compatibility with Type II remailers
In order to share anonymity sets with Type III remailers while
@@ -1082,7 +1082,7 @@
Nodes that accept both type II and type III may advertise the fact
in their server descriptor by including a section of the form:
-
+
[Incoming/Mix2]
Address: (type II remailer's email address)
Key: (type II key)
Index: nym-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/nym-spec.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- nym-spec.txt 28 Jul 2003 01:03:55 -0000 1.3
+++ nym-spec.txt 1 Oct 2003 22:15:24 -0000 1.4
@@ -202,9 +202,9 @@
1.3.1. Non-goals
The following properties are *not* goals or requirements of this
- protocol.
+ protocol.
- - Full transport neutrality.
+ - Full transport neutrality.
(Although this protocol does not require a Type III mix
network specifically, it assumes that its underlying transport
@@ -218,7 +218,7 @@
generator.)
- Minimal nymserver storage requirement
-
+
(This protocol assumes that nymservers will have to devote a
certain amount of space to each nym in order to store SURBs
(under ordinary load) and pending messages (under high load).
@@ -256,7 +256,7 @@
- To allow the nymserver to communicate back to the anonymous
nymholder, the nymholder provides the nymserver with a stock of
- SURBs, and replenishes them periodically.
+ SURBs, and replenishes them periodically.
(Because the nymholder uses a separate SURB identity secret for
each pseudonym it generates, it can distinguish reply messages
@@ -343,7 +343,7 @@
A 'sent' tristate: "Nothing sent", "Synopsis-sent", "Sent-In-Full".
A time of receipt.
- - A set of SURBs
+ - A set of SURBs
2.2. Processing incoming emails
@@ -375,7 +375,7 @@
Anytime delivery to the nymserver fails, bounces should
also be sent back as per the SMTP server's policies. I
think a nymserver will probably be some kind of local
- delivery agent.
+ delivery agent.
XXXX]
@@ -520,13 +520,13 @@
Let M_C = COMPRESS(M).
Let PADDING_LEN = CEIL(LEN(M_C)/P) - LEN(M_C).
Let M_P = M | Z(PADDING_LEN).
-
+
Let K = R(16).
Let M_Enc = SPRP_Encrypt(K, "", M_P)
Let RSA_LEN = Len(PK_nym) - OAEP_OVERHEAD - 16
Let RSA_PART = PK_Encrypt(PK_nym, K | M_Enc[0:RSA_LEN])
- Return RSA_PART | M_Enc[RSA_LEN:Len(M_Enc)-RSA_LEN]
+ Return RSA_PART | M_Enc[RSA_LEN:Len(M_Enc)-RSA_LEN]
For efficiency reasons, a nymserver tries to encrypt several
synopses at once, so that zlib can compress them effectively.
@@ -535,7 +535,7 @@
between forward security (which would mandate encrypting each
synopsis as soon as possible) and between efficiency and
traffic-analysis resistance (which would mandate minimizing the
- number of packets sent between client and server).
+ number of packets sent between client and server).
We strike the following compromise: a nymserver encrypts synopses
for a user whenever it has eight or more pending synopses to
@@ -554,7 +554,7 @@
synopses the message ID of every synopsis, in order, contained
therein. It can only delete the set of synopses when it has
deleted every corresponding email.)
-
+
4.3. Control message format: messages to the nymserver
This section describes the control messages sent from the
@@ -566,7 +566,7 @@
All of the control messages described below follow the following
format.
-
+
Header:
SIG Signature (PK_LEN=256 octets)
NL Nym Length (1 octet)
@@ -615,7 +615,7 @@
empty (0-octet) nym, and should be signed with the identity key
given in the NEWPK command. The nymserver replies with a CREATED
command, which the nymholder confirms with a CREATE2 command.)
-
+
[XXXX specify a proof-of-work system.]
4.3.2. CREATE2 [0x01]
@@ -671,7 +671,7 @@
unencoded. When the server delivers the email, it adds a From
line with the correct nym mailbox, and sets the name as given in
the headers.
-
+
4.3.6. GET [0x05]
A GET command requests that the server transfer a set of emails to
@@ -743,7 +743,7 @@
All of the control messages described below follow the following
format.
-
+
Sequence of:
CT Command type (1 octet)
CS Command data size (3 octets)
@@ -757,7 +757,7 @@
of the size of the immediately following CD field.
The following values for CT are recognized:
- 0x00 : CREATED (Acknowledge a new nym)
+ 0x00 : CREATED (Acknowledge a new nym)
0x01 : STATUS (Acknowledge messages and describe status)
0x02 : SUMMARY (Describe pending emails)
0x03 : MSGS (Send emails to the client)
@@ -813,14 +813,14 @@
A SUMMARY command has the following body structure:
VALID_BF Bitfield: which entries in ES have an email? (2 octets)
- ES Encrypted set of synopses.
+ ES Encrypted set of synopses.
(variable length; rest of command)
The LSB in Valid_BF corresponds to the first synopsis in ES, and so
on.
4.4.4. MSG [0x03]
-
+
A MSG command relays an email to the client.
The body of MSG commands have the following structure.
@@ -845,7 +845,7 @@
4.4.6. ERROR [0x05]
NONCE Nonce from client message; Z(20) if none. (20 octets)
- ERROR English-language error message
+ ERROR English-language error message
(variable length; rest of command)
5. Filtering and abuse prevention
Index: spec-issues.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/spec-issues.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- spec-issues.txt 4 Sep 2003 16:14:02 -0000 1.6
+++ spec-issues.txt 1 Oct 2003 22:15:24 -0000 1.7
@@ -38,7 +38,7 @@
2.4. Abuse prevention
2.5. Path selection in non-freeroute networks -- RESOLVED, NEED SPEC
2.6. News -- RESOLVED, NEED SPEC
- 2.7. PKI bootstrapping
+ 2.7. PKI bootstrapping
2.8. Multiple recipients
2.9. Plaintext payload versioning
3. Issues in MIX3:3: 'dir-spec.txt'
@@ -142,7 +142,7 @@
[3Aug: Let's not do hashcash; Nick will write why in FRS. Neglect
multiplier issues for now.]
-
+
2. Issues in MIX3:2: 'E2E-spec.txt'
2.1. Mail gateways
@@ -168,7 +168,7 @@
way to send multi-part messages.
This functionality *may* take the format of a canonical subset of
- MIME, but Lucky thinks that such a thing would drive us into a
+ MIME, but Lucky thinks that such a thing would drive us into a
Lovecraftian state of madness.
[3Aug: Canonicalize encodings; allow types. PGP-mime is "hard".]
@@ -194,7 +194,7 @@
Right now, we have some vague ideas about users emailing admins to
get themselves blacklisted. This should be specified and
- automated.
+ automated.
Additionally, there are probably some other means of preventing
abusive behavior. If these don't make it into the specification,
@@ -251,9 +251,9 @@
2.9. Plaintext payload versioning
We should burn a byte or two for a version number on plaintext
- payloads. This way, we have some hope of changing to a better
+ payloads. This way, we have some hope of changing to a better
fragmentation algorithm in the future, or what have you.
-
+
Doing this doesn't break the key property that forward payloads
can be recognized as okay, but that corrupt payloads, reply
payloads, and encrypted payloads are indistinguishable except to
@@ -346,7 +346,7 @@
(mixes knowing about directory servers). This way one can run
independently a directory server, without any collaboration
from the mix network (other than the ability to request info).
-
+
Let's not forget that the mixes *sign* their information with
a long term key, therefore after you establish that you trust
a signing key to belong to an honest server, the operation of
@@ -358,7 +358,7 @@
use will ruin its anonymity. On the other hand if key updates
are not frequent, then the client can slowly update its
database in the background.
-
+
Even more possibilities open up if each mix server give on
request not only their information but also what they think
the state of other servers, they have contacted in the past,
@@ -368,13 +368,13 @@
orthogonal issue, but once it is decided the updated
information could flow very quickly. (this is in fact a gossip
protocol)
-
+
These are the reasons why I think it might be a good idea to
have automatic on request information from servers. -GD]
[Hm. You may have a point. I'm still going to suggest that we
do not do this yet, for a few reasons.
-
+
First, we need a way for servers to publish their descriptors
to directory servers. (Otherwise, a directory server couldn't
learn about new servers for the first time.) In other words,
@@ -382,16 +382,16 @@
directory servers may or may not need a pull mechanism: we do
not yet have a design that requires this. Let's not build it
till we have a use for it.
-
+
Second, it's a bit tricky to specify *which* descriptor a
server should return. Today's? Tomorrow's? All the ones it
knows about?
-
+
Third, (this is a variant of 'First') because client use of
this feature is prone to misuse, we should only provide it to
clients wrapped in some safe mechanism. That safe mechanism
has yet to be specified.
-
+
Therefore, I'm going to suggest that we call this feature
possibly desirable... but that we should first design
directories or whatever other node discovery mechanisms *may*
@@ -415,7 +415,7 @@
Finally, there may be some value in allowing server S1 and server S2
with the same administrator to also share the same set of keys, thus
forming a single 'virtual server'.
-
+
[PARTIALLY RESOLVED 3Aug: Treat twins as separate for traffic
purposes, but don't do adjacently. Don't do jurisdictions until
we can either verify them, or show that they are beneficial even
@@ -437,7 +437,7 @@
standardized, though they would not form a part of any of the
current specification documents.
-4.1. RFC822-style interface
+4.1. RFC822-style interface
It'd be nice to have a standard way to feed a single text file to
a CLI and get a message sent.