Re: [minion-cvs] more minor patches to the spec

[George Danezis <gd@theory.lcs.mit.edu>]

Dear All,

Yes I am one of these sad people that reads the commit messages. I am not 
sure about one of the modifications:

> @@ -166,17 +158,7 @@
>  * The address data length is specified by the ``Routing Size'' field
>    contained in the subheader.
>  * Padding of zeroes is used to make the size of the Routing Extension a
> -  multiple of 128 bytes.  
> -
> -  [XXXX Something's wrong here. the routing size limits the routing info
> -        in the first subheader to fit within the 86 byte limit (the
> -        size of the plaintext of a subheader), but here we talk about
> -        128, the size of the crypttext of the subheader. What's up?
> -   -RD]
> - 
> -  [XXXX OAEP padding adds 41 bytes.  Thus, for PK_Encrypt(Foo, K) to
> -        fit in 127 bytes (to be input for RSA), you need Len(Foo)<=86.
> -   -NM]
> +  multiple of 86 bytes.  

I think the original "128 bytes" was right. The Routing extrnsion is not 
encrypted using RSA, but simply using a symmetric cipher. It still needs to 
be the same size as multiple sub headers, therefore a multiple of 128.

>  
>  The Routing Extension corresponding to a particular subheader is
>  encrypted using the Encrypt function with key=Hash(Shared Secret,
> @@ -196,6 +178,9 @@
>  [XXXX They used to be Flags and Address. We do not have a Flags
>  anymore since all the information is contained in the address. -GD]
>  
> +[XXXX so should we remove F and rename A to R? Does SHS include the
> +routing extension blocks? -RD]
> +

Yes it should be changed.

> +[XXXX should we mention david hopwood's remark about 'mailbox' vs
> + 'email address'? -RD]
> +

We should clarify that both paradigms can be supported using LOCAL/SMTP 
final addresses.

>  [XXXX I would add a type field for identification, and I think it is
>  ok -GD]
>  
> +[XXXX That's interesting. My first thought would have been to PK-encrypt
> +      the hop secrets to the recipient. So not even a (separate) password
> +      needs to be remembered. But I guess that takes up a lot of
> +      space. -RD]
> +
> +[XXXX Speaking of which, exactly 32 bytes of what? it looks like the
> +      above proposed 'tag' format has some recognizable plaintext? So
> +      we may need to PK-encrypt it anyway, or otherwise make it always
> +      plausible? -RD]
> +
> +

This was my original idea as well: The client has a 1024 bit RSA key (like 
mixes) and the last sub-header is encrypted under it. It does not 
therefore need to remember anything.

Yours,

George