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
[email protected]
On Oct 29, 2013, at 2:34 AM, Steve Crook <[email protected]> wrote:
> On Tue, Oct 29, 2013 at 02:15:09AM +0000, [email protected] 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
>> [email protected]
>> (still a useful place to hold discussion although the SF maintainers are
>> inactive ).
>> 2. To discuss testing and deployment use [email protected] (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
>> [email protected] .
>> 3. Development of a more advanced remailer needs a lead maintainer:
>> [email protected]
>> 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
> [email protected]
> http://lists.mixmin.net/mailman/listinfo/remops
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________ Mixmaster-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixmaster-devel
