[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[minion-cvs] remove tabs, fix some typos
Update of /home/minion/cvsroot/doc
In directory moria.mit.edu:/home/arma/work/minion/doc
Modified Files:
minion-spec.tex
Log Message:
remove tabs, fix some typos
Index: minion-spec.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-spec.tex,v
retrieving revision 1.78
retrieving revision 1.79
diff -u -d -r1.78 -r1.79
--- minion-spec.tex 14 Feb 2003 12:19:06 -0000 1.78
+++ minion-spec.tex 18 Feb 2003 21:43:48 -0000 1.79
@@ -12,8 +12,8 @@
4. Description of mixing algorithm should go in descriptor blocks. -NM
[XXXX Unless the mixing method requires special packaging of the message
we could require the servers to specify the amount of anonymity that
- they expect to give to each message. The information theoretic one
- presented by myself and Andrei could do the job quite well. -GD]
+ they expect to give to each message. The information theoretic one
+ presented by myself and Andrei could do the job quite well. -GD]
6. We should specify: are 'DROP'-type messages dropped before they go
into the mix pool, or after they're pulled from the pool?
@@ -56,7 +56,7 @@
1. Statistics Information Exchange format
[Not for first cut]
2. Specify: verification for directories.
- [not for first cut]
+ [not for first cut]
[Actually, we may need these first two pieces for Mixminion 1.0;
else we won't be deployable. -NM]
3. When do dummy messages get generated?
@@ -334,8 +334,8 @@
PROCEDURE: Create a single header.
Inputs: A_1 .. A_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),
+ 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)
@@ -345,26 +345,26 @@
Process:
// Calculate the sizes of the subheaders
for i = 1 .. N
- SIZE_i = 128 + Len(EXT(RI_i))
+ SIZE_i = 128 + Len(EXT(RI_i))
// Calculate the Junk that will be appended during processing:
J_0 = ``'';
for i = 1 .. N
- J_i = J_(i-1) | PRNG(HASH(SK_i | ``RANDOM JUNK'')[0:16], SIZE_i)
+ J_i = J_(i-1) | PRNG(HASH(SK_i | ``RANDOM JUNK'')[0:16], SIZE_i)
Stream_i = PRNG(HASH(SK_i | ``HEADER SECRET KEY''), 128*15 + SIZE_i);
- J_i = J_i XOR Stream_i[128*15 -Len(J_i) + SIZE_i:Len(J_i)];
+ J_i = J_i XOR Stream_i[128*15 -Len(J_i) + SIZE_i:Len(J_i)];
end
// Create the Header
H_(N+1) = Rand(128*16 - sum(SIZE_1 .. SIZE_N));
for i = N .. 1
- K = HASH(SK_i | ``HEADER SECRET KEY'')[0:16];
- IF i = N (set appropriate routing type and A_i)
- EH = EXT( RI_i+1 )
+ K = HASH(SK_i | ``HEADER SECRET KEY'')[0:16];
+ IF i = N (set appropriate routing type and A_i)
+ EH = EXT( RI_i+1 )
REST = Encrypt(K, (EH | H_(i+1)))
- DIGEST = HASH(REST | J_i-1)
- H_i = ESHS(PK_i, V, SK_i, DIGEST, len(RI_i+1), RT_i+1, RI_i+1) | REST
+ DIGEST = HASH(REST | J_i-1)
+ H_i = ESHS(PK_i, V, SK_i, DIGEST, len(RI_i+1), RT_i+1, RI_i+1) | REST
end
return H_1;
@@ -399,20 +399,20 @@
// Phase 1
if (H2 is a reply block)
P = SPRP_ENC(SURB secret key, "PRIVATE SURB KEY", P)
- else // (H2 is *not* a reply block)
- for i = N .. 1
- P = SPRP_ENC(SK2_i, "PAYLOAD ENCRYPT", P)
- end
+ else // (H2 is *not* a reply block)
+ for i = N .. 1
+ P = SPRP_ENC(SK2_i, "PAYLOAD ENCRYPT", P)
+ end
endif
- // Phase 2
- H2 = SPRP_ENC(SHA1(P), ``HIDE HEADER'', H2)
+ // Phase 2
+ H2 = SPRP_ENC(SHA1(P), ``HIDE HEADER'', H2)
P = SPRP_ENC(SHA1(H2), "HIDE PAYLOAD", P)
- for i = N .. 1
- H2 = SPRP_ENC(SK1_i, "HEADER ENCRYPT",H2)
- P = SPRP_ENC(SK1_i, "PAYLOAD ENCRYPT",P)
- end
- M = (H1, H2, P)
+ for i = N .. 1
+ H2 = SPRP_ENC(SK1_i, "HEADER ENCRYPT",H2)
+ P = SPRP_ENC(SK1_i, "PAYLOAD ENCRYPT",P)
+ end
+ M = (H1, H2, P)
\section{Processing of Messages}
@@ -421,30 +421,30 @@
PK receiving message M = (H1, H2, P) performs the following operations:
PROCEDURE: Process a message M
- SHS(V, SK, D, RS, RT, RI) = PK_Decrypt(PK,H1[0:128]);
+ SHS(V, SK, D, RS, RT, RI) = PK_Decrypt(PK,H1[0:128]);
If there is any problem with the OAEP padding discard the message.
Check that D = HASH(H1[128:15*128]), and discard if not.
Let n_extra = number of extended headers = Ceil( (RS-44) / 128 )
H1 = H1[128:15*128] | PRNG(HASH(SK | "RANDOM
JUNK")[0:16],128+128*n_extra)
- H1 = H1 XOR PRNG(HASH(SK, "HEADER SECRET KEY")[0:16], Len(H1))
+ H1 = H1 XOR PRNG(HASH(SK, "HEADER SECRET KEY")[0:16], Len(H1))
RI = RI | H[0:128*n_extra]
H1 = H1[128*n_extra:128*16]
- H2 = SPRP_DEC(SK, ``HEADER ENCRYPT'',H2);
- P = SPRP_DEC(SK, ``PAYLOAD ENCRYPT'',P);
+ H2 = SPRP_DEC(SK, ``HEADER ENCRYPT'',H2);
+ P = SPRP_DEC(SK, ``PAYLOAD ENCRYPT'',P);
- if routing type is DROP:
+ if routing type is DROP:
End.
- if routing type is SWAP-FWD:
+ if routing type is SWAP-FWD:
P = SPRP_DEC(SHA1(H2), "HIDE PAYLOAD", P)
- H2 = SPRP_DEC(SHA1(P), ``HIDE HEADER'', H2)
- Swap H1 and H2;
+ H2 = SPRP_DEC(SHA1(P), ``HIDE HEADER'', H2)
+ Swap H1 and H2;
if routing type is SWAP-FWD or FWD:
- Put (H1, H2, P) in queue to be sent to the address in RI.
+ Put (H1, H2, P) in queue to be sent to the address in RI.
Otherwise:
- Give (RT, RI, HASH(SK,``APPLICATION KEY''), P) to
- Module manager.
+ Give (RT, RI, HASH(SK,``APPLICATION KEY''), P) to
+ Module manager.
The ``Application Key'' is provided to the module as a shared secret
between the constructor of the header and the module that is in charge
@@ -473,10 +473,10 @@
* The begin marker is the ASCII 4-byte string 'SURB'.
* The version number contains the format version of the SURB.
(should be hex 01 and 00 for this standard).
-* Routing type/routing size/routing info: Definded as in subheaders.
+* Routing type/routing size/routing info: Defined as in subheaders.
These fields encode the address of the hop which the SURB user should
use as an exit point.
-* Use-by-Date: indicated the expiry date the SURB should be used by. Can
+* Use-by-Date: indicates the expiry date the SURB should be used by. Can
be calculated using the key rotation frequencies of the intermediate
nodes. This field must be given as a number of seconds since
midnight GMT on Jan 1, 1970 -- but must be aligned to the start of a
@@ -486,8 +486,7 @@
(Rationale: a seconds-level granularity allows us to move to a
tighter schedule later on in order to support a synchronous mixnet.)
-* SURB data: Containst the SURB that is created as described
- above.
+* SURB data: Contains the SURB that is created as described above.
* Encryption key: used to LIONESS-encrypt the payload before sending it
into the network.
@@ -589,8 +588,8 @@
[Note that both cases require the same number of bytes and
processing time. Implementations must make sure the real message
- and the padding cases are indistinguishable to a third party, or
- even to the parties involved after the keys have been
+ and the padding cases are indistinguishable to a third party, or
+ even to the parties involved after the keys have been
updated.]
* After sending a batch of messages, A sends an TLS handshake
@@ -644,9 +643,9 @@
(Notation: X*: 0 or more occurrences of X.
X+: 1 or more occurrences of X.
- X?: 0 or 1 occurrences of X.
+ X?: 0 or 1 occurrences of X.
X Y: An occurrence of X followed by an occurrence of Y.
- X*{Y}: 0 or more occurrences of X separated by occurrences
+ X*{Y}: 0 or more occurrences of X separated by occurrences
of Y.
X|Y: Either an occurrence of X, or an occurrence of Y.)
@@ -692,7 +691,7 @@
this key should be at least 2048 bits long and no more than
4096 bits long. The exponent of this key must be 65537.
- Clients should at least give a warning if the identity key of
+ Clients should at least give a warning if the identity key of
any server should ever change.
'Digest': The digest of this block. See below.
'Signature': The signed digest of this block. See below.
@@ -873,7 +872,7 @@
Inputs: Q (a queue of messages)
N (the number of messages in the queue).
- MIX_INTERVAL (algorithm parameter; time to wait between
+ MIX_INTERVAL (algorithm parameter; time to wait between
batches of messages. Should be around
XXXXX. Must be >= 0.)
POOL_SIZE (algorithm parameter; minimum size of pool. Should
@@ -986,9 +985,9 @@
[Incoming/Mix2]
Address: (type II remailer's email address)
Key: (type II key)
- KeyID: (type II keyid)
+ KeyID: (type II keyid)
Signature: (signature of identity key with type II key)
- (Optionally, KeyID and Signature repeated any number of
+ (Optionally, KeyID and Signature repeated any number of
times.)
This section advertises that the mix can handle type II messages