[tor-dev] [proposal] Post-Quantum Secure Hybrid Handshake Based on NewHope
durumcrustulum at gmail.com
Thu May 19 18:48:43 UTC 2016
Granted that this is an experimental implementation (as acknowleged by the
Boring devs) in a very different protocol with different tradeoffs.
On Thu, May 19, 2016 at 2:42 PM Yawning Angel <yawning at schwanenlied.me>
> On Thu, 19 May 2016 17:21:47 +0000
> Deirdre Connolly <durumcrustulum at gmail.com> wrote:
> > Not sure if this has been noted before on this thread, but the
> > BoringSSL team is working on something very similar:
> > https://boringssl-review.googlesource.com/#/c/7962/
> Skimming the code:
> * The protocol level stuff is not useful at all because the sort of
> problems that need to be solved (or changes) with the Tor
> wire protocol for any sort of PQ handshake are rather different than
> "just adding another TLS key exchange mechanism".
> * Their hybrid construct is unauthenticated (handled separately by TLS,
> with a signature), and is `X25519SharedSecret | NHSharedSecret`,
> passed into a KDF.
> * They have their own special snowflake newhope variant (The code is
> based on the `ref` version, with Google copyrights bolted on top),
> functional changes are:
> * CTR-AES128 instead of SHAKE is used to sample `a` (same
> algorithm, doesn't have the sampling optimization or attempt to
> hide the rejection sampling timing variation).
> * SHA256 is used instead of SHA3-256 to generate `mu` from `nu`.
> * RAND_bytes() is called for noise sampling instead of using
> ChaCha20 or CTR-AES256.
> I don't find these changes to be particularly interesting. Any
> system where using AES-CTR like this makes sense will benefit more
> from using a vectorized NTT/reconciliation.
> Yawning Angel
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev