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

[Steve Crook]

On Wed, Oct 30, 2013 at 09:43:52PM -0400, Tom Ritter wrote:
> 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.

Hi Tom,

Thanks for your description of the Tagging Attack.  If I understand
correctly, there are a number of steps to resolving it:-

1) Include pad bytes when calculating header digests.
2) Add a digest within each intermediate header for the encrypted next-hop
   header.
3) Add a digest within each header for the encrypted payload.

All of these digests to be calculated by the client during encoding.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.mixmin.net/pipermail/remops/attachments/20131031/42b85cf3/attachment.sig>