Split KeyExchange into synchronous and asynchronous variants
As part of the implementation of go/leto-II-design, an asynchronous interface was added to the KeyExchange class, to allow an implementation which would make an RPC to a service holding the private key. This fit awkwardly into the existing code, and we intended it as a short-term patch until we could come up with a better separation of concerns.
This CL improves matters by splitting the KeyExchange class into two. The AsyncKeyExchange interface has only an asynchronous interface. SyncKeyExchange has both synchronous and asynchronous interfaces, with the latter implemented in terms of the former. The existing "local" key-exchange classes inherit from SyncKeyExchange. Handshaking code which may or may not need to talk to Leto uses the AsyncKeyExchange uniformly, but depending on whether Leto is enabled or not, the concrete objects being used might be local or remote.
This CL also removes the "Factory" pattern previously used for creating KeyExchange objects. It required a bunch of boilerplate and provided little benefit.
gfe-relnote: no-op refactoring in the area of QUIC handshakes. No functional change intended, not flag-protected.
PiperOrigin-RevId: 238508479
Change-Id: Ib5ca6ae5afbdcb712c7d2f86a4d272ef168b90f3
diff --git a/quic/core/crypto/crypto_handshake.h b/quic/core/crypto/crypto_handshake.h
index 7846708..4608889 100644
--- a/quic/core/crypto/crypto_handshake.h
+++ b/quic/core/crypto/crypto_handshake.h
@@ -15,7 +15,7 @@
namespace quic {
class CommonCertSets;
-class KeyExchange;
+class SynchronousKeyExchange;
class QuicDecrypter;
class QuicEncrypter;
@@ -127,7 +127,7 @@
std::vector<std::string> cached_certs;
// client_key_exchange is used by clients to store the ephemeral KeyExchange
// for the connection.
- std::unique_ptr<KeyExchange> client_key_exchange;
+ std::unique_ptr<SynchronousKeyExchange> client_key_exchange;
// channel_id is set by servers to a ChannelID key when the client correctly
// proves possession of the corresponding private key. It consists of 32
// bytes of x coordinate, followed by 32 bytes of y coordinate. Both values
