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

[lists at notatla.org.uk]

tom ritter.vg writes:

> > Look at the use of "antitag" in
> > send_packet() function in chain2.c
> > mix2_decrypt() function in rem2.c

> I don't think that would work. I believe to defeat the tagging attack
> you would need a more significant re-engineering of the protocol.  I
> cannot check the integrity of a subsequent mix header because I do not
> know what it should look like after I decrypt it.  All I see is the
> public key id, the length of the encrypted data, the RSA-encrypted
> session key, and ciphertext.  There is nothing that tells me what it's
> checksum _should_ be, so that I could go "Oh this is corrupted,
> instead of sending it along, I'm going to drop it".

You don't need to know what it will look like _after_ you decrypt it
because this is a MAC provided by the client confirming what should
be received by your honest remailer (and which will be imvalid if the
previous hop has changed a byte as described on your blog).

> Now that said, it SHOULD be possible to use some of the padding at the
> end of the header encrypted to you (328 bytes of it I believe, based
> on https://crypto.is/blog/packet_formats_1 ) to include a checksum of
> the next header.  Then you can tell if it was changed, and if so, drop
> it.  The client would need to calculate the checksums as they layer
> the encryption and include them.

I've put my new data (including the 3 HMAC-SHA256 items) along with the
3DES key inside the RSA encryption so as to avoid reorganising the
encrypted header.  Checksums provided in layered manner by the client is
exactly what it does.

> I should also note that I think it would be much, much more valuable
> to include StartTLS encryption (with ECDHE-based PFS) between
> remailers, and distribute the SSL certificates alongside the remailer
> keys, that way clients and remailers can encrypt the link.  IMO this
> would be way more valuable than defending against an tagging attack
> that requires an active attacker, and just as valuable, if not moreso,
> as upgrading to RSA 2048/4096.

That's more of an MTA configuration issue (together with key distribution)
and can be done independently of changes to mixmaster.  Ideally we will
get both before long.