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

Re: [tor-dev] Proposal 261: AEZ for relay cryptography



[snipping liberally]

On Mon, 28 Dec 2015 17:43:14 -0500
Nick Mathewson <nickm@xxxxxxxxxxxxxx> wrote:

> 3.3. Why _not_ AEZ?
> 
>    There are also some reasons to consider avoiding AEZ, even if we do
>    decide to use a wide-block cipher.
> 
>    FIRST it is complicated to implement.  As the specification says,
>    "The easiness claim for AEZ is with respect to ease and versatility
>    of use, not implementation."
> 
>    SECOND, it's still more complicated to implement well (fast,
>    side-channel-free) on systems without AES acceleration.  We'll need
>    to pull the round functions out of fast assembly AES, which is
>    everybody's favorite hobby.
> 
>    THIRD, it's really horrible to try to do it in hardware.
> 
>    FOURTH, it is comparatively new.  Although several cryptographers
>    like it, and it is closely related to a system with a security
> proof, you never know.
> 
>    FIFTH, something better may come along.

SIXTH, using AEZ requires implementing proposal 262.  It's a good idea
and we should do it anyway, but it is added complexity.

> 4.3. Other hashes.
> 
>    We could update the ntor definition used in this to use a better
> hash than SHA256 inside.

We should benchmark HMAC-SHA256 vs SHA3-256 since we have code for
both.  I think SHA3 is a better hash function over all, so I'd be ok
with a minor performance hit here, since this is parallelized already
and our threadpool is currently underutilized.

Regards,

-- 
Yawning Angel

Attachment: pgpMI4XZ4GQDw.pgp
Description: OpenPGP digital signature

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