[messaging] [Fwd: Re: Ronion anonymous routing protocol framework]

[Nazar Mokrynskyi]

On 10/18/17 6:57 AM, Nazar Mokrynskyi wrote:
> On 10/18/17 12:58 AM, Jeff Burdges wrote:
>> Read about the Sphinx mix network packet format for more details on
>> building the tags via the tails of moretags.  In fact, we were actually
>> speaking in the context of Sphinx where the iv and body are empty. 
> I've read about Sphinx packet format and generally familiar with the way it works. But still you have to reserve some space for those tags in total packet size, which is an undesired overhead.
> So even if you only use 3 hops, but system is designed to use up to 10 hops, then you'll have that overhead of 7 unused hops, assuming the packet size is fixed.
>
> Assuming packet size is 512 bytes like in Tor, 7 unused hops will result in 22% useless overhead, not taking into account the rest of the Sphinx header. This might be fine for large packets size, but I think for smaller ones it is too much.

It takes time to analyze everything you're writing here, but I've just read through AEZ v5 paper and have some more thoughts.

It looks like a perfect candidate for use with Ronion.
Multi-layer AEZ (assuming it actually provides what it claims in paper) can be used as kind of non-authenticated encryption on top of authenticated encryption to prevent tagging attacks. Nonce in this case can be omitted since AEZ will be applied to unique ciphertext and ciphertext expansion can also be 0 bytes since there is MAC from authenticated encryption already.In other words, it is possible to have just one MAC in the packet for the whole circuit of arbitrary length.
Message will still reach receiver (not dropped early), but from corrupted message it should not be possible to recover any structure that will allow to confirm tagging attack, it should look like rubbish.

Alternatively (doesn't fit Ronion spec yet), some smaller ciphertext expansion can be used instead of complete MAC in order to gain ability of dropping packets early with some probability, while also not having too big overhead.

I'll think about AEZ more, but it seems to be a very interesting approach so far, thanks for mentioning it in previous messages!

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171018/b73a53c4/attachment.html>