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 <[email protected]> wrote: > > On Sun, Nov 29, 2015 at 7:06 PM, Tim Wilson-Brown - teor > <[email protected] <mailto:[email protected]>> wrote: >> >> On 30 Nov 2015, at 09:13, Nick Mathewson <[email protected]> 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 > [email protected] <mailto:[email protected]> > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
