[Remops] mixmaster's 1024-bit RSA is getting old

[Lance Cottrell]

This is an excellent proposal.

In practice, no one uses more than a few hops for real messages. I suspect that 5 is the realistic upper limit to ensure reasonable delivery time and reliability.
I really went over the top in using 20 header blocks.

Roll out will be a key. One does not want client software that only has one or two servers through which it could route, nor would one want to be one of only a few few users of the new key size, since that would be easily tracked as well.

	-Lance 

--
Lance Cottrell
loki at obscura.com



On Oct 29, 2013, at 2:34 AM, Steve Crook <steve at mixmin.net> wrote:

> On Tue, Oct 29, 2013 at 02:15:09AM +0000, lists at notatla.org.uk wrote:
>> Mixmaster has long used 1024-bit RSA with a packet format that allows
>> a maximum of 20 hops; each encrypted with a different RSA key.  The
>> data for each hop occupies 512 bytes.
>> 
>> Given the declining protection offered by a key size from the 1990s I
>> decided to investigate adapting mixmaster to use 2048-bit keys (each
>> in a larger header block) at a cost of reducing the longest chain to
>> 10 hops.
>> 
>> It turned out possible to exceed this goal.  By using a header of
>> 1024 bytes (max 10 hops) new code can use key sizes of 2048, 3072
>> and 4096 for RSA.  E.g. 10 hops of 4096; or 2 of 1024 and 9 of 4096.
>> (Key generation might be "mixmaster -G --size=4096 --lifetime=90".)
>> The default size in the new code is 2048 bits.
> Coincidentally we appear to have arrived at very similar solutions.
> I've also got a working Mixmaster alternative that uses 10 headers of
> 1024 bytes each.  This adds support for up to 4096-bit RSA keys and
> maintains the same overall packet size of 20480 bytes.
> 
> My spec is:
> 
> Packet Info (256 Bytes):-
> Packet type 0 (intermediate hop):
>    [ 9 Initialization vectors     144 bytes ]
>    [ Next address                 112 bytes ]
> 
> Packet type 1 (final hop):
>    [ Chunk number                   1 byte  ]
>    [ Number of chunks               1 byte  ]
>    [ Message ID                    16 bytes ]
>    [ Initialization vector         16 bytes ]
>    [ Padding                      222 bytes ]
> 
> Mixmaster currently has three Packet Types but I couldn't see the point
> of seperating Exit and Chunked Exit when Exit can just be a single Chunk.
> 
> 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 ]
> 
> Payload:
>    [ Length                         2 bytes ]
>    [ SHA2-512 Message Digest       64 bytes ]
>    [ Content                    10174 bytes ]
> 
> This is currently only something I'm playing with so it should be easy
> to modify it to concur with your specification.
> 
> 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.
> 
>> Actions:
>> 1.  To review and discuss the code please use Mixmaster-devel at lists.sourceforge.net
>>    (still a  useful place to hold discussion although the SF maintainers are inactive ).
>> 2.  To discuss testing and deployment use Remops at lists.mixmin.net (it would be helpful
>>    to have some short-term test remailers even if they were not to remain long term.)
>>    Some traffic may be relevant on both those lists and maybe also cryptography at metzdowd.com .
>> 3.  Development of a more advanced remailer needs a lead maintainer:
>>    mixminion-dev at seul.org
>>    http://mixminion.net/
>>    https://github.com/nmathewson/mixminion
>> 4.  Restore freedom to the galaxy!
>> 
>> Code location:
>> http://www.zen19351.zen.co.uk/mixmaster302/mixmaster-3.0.2.tar.gz
>> SHA256(mixmaster-3.0.2.tar.gz)= a88b93ea21c42ff588db6bc506b3e6eea4e8eb666d5a90beb1dd785b7e0920ed
> Thanks very much for your efforts, I'll take a look and provide some
> feedback.
> _______________________________________________
> Remops mailing list
> Remops at lists.mixmin.net
> http://lists.mixmin.net/mailman/listinfo/remops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mixmin.net/pipermail/remops/attachments/20131029/0cadc233/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4877 bytes
Desc: not available
URL: <http://lists.mixmin.net/pipermail/remops/attachments/20131029/0cadc233/attachment.bin>