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

Tom Ritter tom at ritter.vg
Thu Oct 31 01:43:52 GMT 2013


On 30 October 2013 14:56,  <lists at notatla.org.uk> wrote:
>
>> In the process of revising the mixmaster header spec, is there any way
>> to eliminate the tagging attack illustrated by Tom at http://crypto.is?
>> Seems like it should be possible to incorporate something to solve this
>> problem.
>
> To beat the tagging attack the remailer must not only check
> the integrity of the header it processes but if there is a
> further hop it must check the integrity of the next hop to
> see it is unchanged since leaving the client.
>
> Look at the use of "antitag" in
> send_packet() function in chain2.c
> mix2_decrypt() function in rem2.c
>
> I have tested all the HMAC checks with a corrupt client that changes a byte
> in the relevant field just after the HMAC is made and confirmed the remailer
> rejects them ae messages the correct place.


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".

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 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.

-tom


More information about the Remops mailing list