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 <[email protected]> wrote: > On Thu, 19 May 2016 17:21:47 +0000 > Deirdre Connolly <[email protected]> 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
