Granted that this is an experimental implementation (as acknowleged by the Boring devs) in a very different protocol with different tradeoffs.
On Thu, 19 May 2016 17:21:47 +0000
Deirdre Connolly <durumcrustulum@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev