[tor-dev] Proposal 261: AEZ for relay cryptography
yawning at schwanenlied.me
Tue Dec 29 01:24:05 UTC 2015
On Mon, 28 Dec 2015 17:43:14 -0500
Nick Mathewson <nickm at torproject.org> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the tor-dev