Re: [Mixmaster-devel] [Remops] mixmaster's 1024-bit RSA is getting old

[<li...@no...>]

Steve Crook <steve mixmin.net> writes:

> Coincidentally we appear to have arrived at very similar solutions.

There was a certain obviousness about the main thrust of our designs.

> Encrypted Header (384 Bytes):
>     [ Packet ID                     16 bytes ]
>     [ AES key                       32 bytes ]
>     [ Packet type identifier         1 byte  ]
>     [ Packet Info                  256 bytes ]
>     [ Timestamp                      2 bytes ]
>     [ Padding                       13 bytes ]
>     [ SHA2-512 Message digest       64 bytes ]
> 
> Header (1024 Bytes):
>     [ Public key ID                 16 bytes ]
>     [ Length of RSA-encrypted data   2 bytes ]
>     [ RSA-encrypted session key    512 bytes ]
>     [ Initialization vector         16 bytes ]
>     [ Encrypted header part        384 bytes ]
>     [ Padding                       30 bytes ]
>     [ SHA2-512 Message digest       64 bytes ]

I see you've moved message digests to predictable
positions at the end of each block to avoid the
current mess where you need to somewhat use the
block before you can check it matches the digest.

I doubt 65536 different public keys sizes are needed.
My guess is 4096 (only) is good for the near term and
then the best recommendation will be some EC - but which
one nobody may know for a while.  Who knows whether in
a couple of years NIST and DJB might endorse a few of
the same curves?

With a new incompatible alternative you have options
such as a protocol version field to indicate what is
coming later in the packet.

> This is currently only something I'm playing with so it should be easy
> to modify it to concur with your specification.

I don't think an alternative needs to follow my spec which is a minimal
change for easy migration.  If you're aiming for a new codebase and no
more 3DES then you have a new start.

I think the worthwhile points to lift are:
 -  On intermediate hops require an integrity check on the following hop
    as explained on Ritter's blog.
 -  Use hashes iterated twice (as reccomended by Schneier).  The style
    of iterations I've used is HMAC.
 -  Encrypt under RSA data that is not a symmetric key itself but is something
    that hashes to the symmetric key.  Then if a break against RSA leaks half
    your bits the search space has not been much reduced.  (I think I read that
    in Schneier too.)
 -  If the first design leaves space inside the RSA-encrypted data it may be useful later.
 
> I'm also looking at using HTTP as a transport instead of SMTP.  The
> justification for this being that HTTP is used extensively on the Tor
> network.  This should make it very easy to run remailers as Tor Location
> Hidden Services.

HTTP(S) typically has small requests and large replies.  That suggests a change from
an SMTP-like model to a POP3-like model where each node would query other nodes with
"any messages for me? show me one".  To do this each node would have to know
where to receive from (information that starts out in the client that prepares the onion
packaging).  So some way of introducing nodes to each other is required.