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@alum.mit.edu wrote:
On Sun, Nov 29, 2015 at 7:06 PM, Tim Wilson-Brown - teor <teor2345@gmail.com mailto:teor2345@gmail.com> wrote:
On 30 Nov 2015, at 09:13, Nick Mathewson nickm@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@lists.torproject.org mailto:tor-dev@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