[tor-dev] RFC: AEZ for relay cryptography, v2

Mon Nov 30 07:12:06 UTC 2015

Hi Nick,

The AEZ paper says:

"We impose a limit that AEZ be used for at most 2^48 bytes of data (about 280 TB); by that time, the user should rekey. This usage limit stems from the existence of birthday attacks on AEZ, as well as the use of AES4 to create a universal hash function."

http://web.cs.ucdavis.edu/~rogaway/aez/rae.pdf <http://web.cs.ucdavis.edu/~rogaway/aez/rae.pdf>

Since we change the tweak for every cell, do we have to be worried about this limit?
(Regardless of the tweak change, we are keeping the key constant, and using the same key forwards and backwards.)

It seems to me that the 280 TB limit so large that we don't have to worry about it being reached in any real-world circuit.
But I'm not sure of the maximum data volumes or lifetimes of current Tor circuits.

Should we include a method of rekeying in the Tor AEZ specification, in case the recommended limit is reduced in future?

Tim

> On 30 Nov 2015, at 12:21, Nick Mathewson <nickm at alum.mit.edu> wrote:
> 
> On Sun, Nov 29, 2015 at 7:06 PM, Tim Wilson-Brown - teor
> <teor2345 at gmail.com <mailto:teor2345 at gmail.com>> wrote:
>> 
>> On 30 Nov 2015, at 09:13, Nick Mathewson <nickm at torproject.org> wrote:
>> ...
>> 2.2. New relay cell payload
>> ...
>>  When encrypting a cell for a hop that was created using one of these
>>  circuits, clients and relays encrypt them using the AEZ algorithm
>>  with the following parameters:
>> 
>>      Let Chain denote chain_val_forward if this is a forward cell
>>         or chain_forward_backward otherwise.
>> 
>> 
>> chain_val_backward?
> 
> Yes, whoops.
> 
>> ...
>> 
>> 3.3. Why _not_ AEZ?
>> 
>>  ...
>> 
>>  THIRD, it's really horrible to try to do it in hardware.
>> 
>> 
>> This may be considered an advantage against an adversary with the resources
>> to employ custom hardware to attempt to break AEZ-based encryption.
> 
> Ooh.  Interesting.
> 
>> ...
>> 
>> ...
>> 4.3. A forward-secure variant.
>> 
>> 
>> How is this different to what you've specified in the main body of the
>> proposal?
>> 
>> 
>>  We might want the property that after every cell, we can forget
>>  some secret that would enable us to decrypt that cell if we saw
>>  it again.
> 
> Whoops; it's leftover text from an earlier version of the proposal.
> 
> --
> Nick
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev>
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151130/8639f6d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151130/8639f6d2/attachment-0001.sig>