[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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

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@xxxxxxxxxxxx> wrote:

On Sun, Nov 29, 2015 at 7:06 PM, Tim Wilson-Brown - teor
<teor2345@xxxxxxxxx> wrote:

On 30 Nov 2015, at 09:13, Nick Mathewson <nickm@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev