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:
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