add "improving the sphinx mix network"

[david415]

http://www.cs.ru.nl/~bmennink/pubs/16cans.pdf

[Yawning]

The paper is somewhat flawed.

The core of their premise appears to hinge upon the assumption that people implementing Sphinx (and the original paper) suggest using Anderson/Biham's experimental setup from the original BEAR/LION paper, which is flat out wrong. They're also seem to have missed the point of the BEAR/LION paper, in that BEAR/LION/LIONESS are generic constructs, and the experimental setup in the 90s with SHA-1/SEAL was part of an experimental performance evaluation setup.

Other notes:

• The LRW construct they propose is utterly unusable for a lot of use cases due to the rather short limit on AD/plaintext size (1023/1023 - alpha respectively).
• SHA-3 (or more specifically Keccak-f 1600) is ridiculously slow.
• AEZ has a per-key usage cap of 2^48 bytes (2^44 blocks). I'm not sure why they're freaking out over birthday bound issues.
• AEZv4's problem with E() was fixed. (http://web.cs.ucdavis.edu/~rogaway/aez/bug.pdf)

The one useful thing they're doing is "Have the per hop mac that authenticates the header, also cover the payload". But at that point, I question the need for a fragile/wide-block construct for payload encryption in general.