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

[Tom Ritter]

On 30 October 2013 22:13,  <lists at notatla.org.uk> wrote:
> 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.

Sorry, I completely spaced.  I see in the first email that you are
indeed asserting the validity of the next header (and the payload) -
that's what I was going after to block the tagging attack.  Sorry
about that.

It's not clear to me where the HMAC key for a header comes from; it
must be shared between the client and the node whose header that it
is.  I assumed it's derived from the symmetric key that the client
RSA-encrypts to the node?


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

I agree it's seperate in the 'stack', but looking at it from an
ecosystem perspective - it's a giant omission and security issue that
hasn't been addressed yet.


On 31 October 2013 06:20, Steve Crook <steve at mixmin.net> wrote:
> 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.

Yes. As notatla mentioned in the first email I spaced on, (2) and (3)
specifically protect against tagging attacks.  Thinking things
through, I'm not sure (1) is strictly necessary, but as we've seen in
TLS, it's cryptographic best practice and not doing it can lead to
attacks down the road by someone who spends more than 2 minutes on a
train thinking about it ;)

-tom