integration tests perform encryption manually

[tiziano88]

oak/oak_functions_enclave_service/tests/integration_test.rs

Lines 108 to 113 in 2980d12

	// Encrypt request.
	let mut client_encryptor =
	ClientEncryptor::create(&server_encryption_public_key).expect("couldn't create encryptor");
	let encrypted_request = client_encryptor
	.encrypt(&[1, 2, 3], EMPTY_ASSOCIATED_DATA)
	.expect("couldn't encrypt request");

we should use a version of some OakClient library, also to make it easier for the tests to be maintained as we make changes to the protos and other parts of the encryption stack

[tiziano88]

cc @johnniechan

to add a bit more details: at the moment, in these tests we manually build the encryptor object based on the initial request, and then use that to encrypt the invocation request. All of this logic is already encapsulated in the oak_client crate:

oak/oak_client/src/client.rs

Lines 63 to 85 in 2980d12

	pub async fn invoke(&mut self, request_body: &[u8]) -> anyhow::Result<Vec<u8>> {
	// Encrypt request.
	let mut client_encryptor = ClientEncryptor::create(&self.server_encryption_public_key)
	.context("couldn't create encryptor")?;
	let encrypted_request = client_encryptor
	.encrypt(request_body, EMPTY_ASSOCIATED_DATA)
	.context("couldn't encrypt request")?;
	// Send request.
	let encrypted_response = self
	.transport
	.invoke(&encrypted_request)
	.await
	.map_err(|error| anyhow!("couldn't send request: {:?}", error))?;
	// Decrypt response.
	// Currently we ignore the associated data.
	let (response, _) = client_encryptor
	.decrypt(&encrypted_response)
	.context("client couldn't decrypt response")?;
	Ok(response)
	}

it may be necessary to adjust the underlying trait abstractions in order to support the tests, since there would not be an actual gRPC channel in tests, but the logic should be abstract enough to work in both cases