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@schwanenlied.me> wrote:
On Thu, 19 May 2016 17:21:47 +0000
Deirdre Connolly <durumcrustulum@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.

Regards,

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