Differential D6925 Diff 23388 services/identity/src/pake_grpc.rs

Changeset View

Standalone View

services/identity/src/pake_grpc.rs

This file was added.

				use comm_opaque::Cipher;
				use opaque_ke::CredentialFinalization;
				use opaque_ke::CredentialRequest;
				use opaque_ke::RegistrationRequest;
				use opaque_ke::RegistrationUpload;
				use opaque_ke::ServerLogin;
				use opaque_ke::ServerLoginFinishResult;
				use opaque_ke::ServerLoginStartParameters;
				use opaque_ke::ServerLoginStartResult;
				use opaque_ke::ServerRegistration;
				use opaque_ke::ServerRegistrationStartResult;
				use rand::rngs::OsRng;
				use tonic::Status;
				use tracing::error;

				use crate::config::CONFIG;

				/// This file is meant to expose the opaque_ke actions, but
				/// returning tonic::Status as the error type to reduce boilerplate
				/// around describing PAKE failures to grpc.

				pub fn server_registration_start(
				pake_registration_request: &Vec<u8>,
				varunUnsubmitted Done Inline Actions can this function take `rng: &mut (impl Rng + CryptoRng)` ? i'd like the flexibility to change the rng if needed varun: can this function take `rng: &mut (impl Rng + CryptoRng)` ? i'd like the flexibility to change…
				jonAuthorUnsubmitted Done Inline Actions In https://linear.app/comm/issue/ENG-3147, I was hoping to refactor this code completely. There's not a good reason for grpc endpoints to know about what Rng implementation the oqaque protocol is using. jon: In https://linear.app/comm/issue/ENG-3147, I was hoping to refactor this code completely.
				) -> Result<ServerRegistrationStartResult<Cipher>, Status> {
				let registration_bytes = RegistrationRequest::deserialize(
				&pake_registration_request[..],
				)
				.map_err(\|_\| {
				Status::invalid_argument("Unsuccessfully converted registration to bytes")
				varunUnsubmitted Done Inline Actions we should keep the status message more opaque like we had before and just use tracing::error to log errors in detail. this feedback is applicable in other places in this diff varun: we should keep the status message more opaque like we had before and just use tracing::error to…
				})?;
				ServerRegistration::<Cipher>::start(
				&mut OsRng,
				registration_bytes,
				CONFIG.server_keypair.public(),
				)
				.map_err(\|_\| {
				Status::invalid_argument("Unsuccessfully started PAKE server response")
				varunUnsubmitted Done Inline Actions aborted? also same feedback as above about keeping status message vague and logging the detailed error varun: aborted? also same feedback as above about keeping status message vague and logging the…
				jonAuthorUnsubmitted Done Inline Actions That's probably fair. jon: That's probably fair.
				})
				}

				pub fn server_registration_finish(
				server_registration: ServerRegistration<Cipher>,
				registration_upload_bytes: &Vec<u8>,
				) -> Result<ServerRegistration<Cipher>, Status> {
				let upload_payload = RegistrationUpload::deserialize(
				registration_upload_bytes,
				)
				.map_err(\|e\| {
				error!("Failed to deserialize registration upload bytes: {}", e);
				Status::aborted("registration failed")
				varunUnsubmitted Done Inline Actions invalid_argument? varun: invalid_argument?
				})?;
				server_registration.finish(upload_payload).map_err(\|e\| {
				error!(
				"Encountered a PAKE protocol error when finishing registration: {}",
				e
				);
				Status::aborted("server error")
				})
				}

				pub fn server_login_start(
				server_registration: ServerRegistration<Cipher>,
				varunUnsubmitted Done Inline Actions let's take rng as a param here varun: let's take rng as a param here
				jonAuthorUnsubmitted Done Inline Actions Eventually I would like to move to something like https://linear.app/comm/issue/ENG-3147. And just have the RNG managed similar to Cipher, that can be shared across both client and server jon: Eventually I would like to move to something like https://linear.app/comm/issue/ENG-3147. And…
				pake_credential_request: &[u8],
				varunUnsubmitted Done Inline Actions i don't have a preference on Vec vs slice but we should be consistent varun: i don't have a preference on Vec vs slice but we should be consistent
				jonAuthorUnsubmitted Done Inline Actions I decided to just receive a slice, as it's similar to `&str` jon: I decided to just receive a slice, as it's similar to `&str`
				varunUnsubmitted Done Inline Actions I meant, in `server_login_finish` and other functions we pass a `Vec<u8>`, but here we're passing a `[u8]`. Let's stick with one or the other. Can you call this out specifically in ENG-3147? varun: I meant, in `server_login_finish` and other functions we pass a `Vec<u8>`, but here we're…
				) -> Result<ServerLoginStartResult<Cipher>, Status> {
				let credential_request =
				CredentialRequest::deserialize(pake_credential_request).map_err(\|e\| {
				error!("Failed to deserialize credential request: {}", e);
				Status::invalid_argument("invalid message")
				})?;
				ServerLogin::start(
				&mut OsRng,
				server_registration,
				CONFIG.server_keypair.private(),
				credential_request,
				ServerLoginStartParameters::default(),
				)
				.map_err(\|e\| {
				error!(
				"Encountered a PAKE protocol error when starting login: {}",
				e
				);
				Status::aborted("server error")
				})
				}
				pub fn server_login_finish(
				server_login: ServerLogin<Cipher>,
				pake_credential_finalization: &Vec<u8>,
				) -> Result<ServerLoginFinishResult<Cipher>, Status> {
				let finalization_payload =
				CredentialFinalization::deserialize(&pake_credential_finalization[..])
				.map_err(\|e\| {
				error!("Failed to deserialize credential finalization bytes: {}", e);
				Status::aborted("Could not deserialize login credentials")
				varunUnsubmitted Done Inline Actions invalid_argument? varun: invalid_argument?
				})?;
				server_login.finish(finalization_payload).map_err(\|e\| {
				error!(
				"Encountered a PAKE protocol error when finishing login: {}",
				e
				);
				Status::aborted("server error")
				})
				}