Expose a safe interface for EVP_AEAD

[initsecret]

Fix #58

[jyn514]

This looks like a good start :) I left a lot of comments - none of them are critical, but it would be nice to address at least some before merging.

Could you add EVP_aead_aes_256_gcm_randnonce and EVP_aead_aes_128_gcm_randnonce under a cfg(feature = "fips") flag? EVP_aead_aes_128_ccm_bluetooth, EVP_aead_aes_128_ccm_bluetooth_8, and EVP_has_aes_hardware also seem to be missing, I think you can add those unconditionally.

[jyn514]

Casting here doesn't seem correct - can you change this to return libc::size_t instead? Same for all the other functions returning usize.

[initsecret]

I tried to maintain parity with symm.rs which uses this pattern when returning lengths:

boring/boring/src/symm.rs

Lines 187 to 191 in e6ddc40

	/// Returns the length of keys used with this cipher.
	#[allow(clippy::trivially_copy_pass_by_ref)]
	pub fn key_len(&self) -> usize {
	unsafe { EVP_CIPHER_key_length(self.0) as usize }
	}

[jyn514]

Let's use the upstream documentation here, I'd prefer not to reuse the word "overhead" when defining what it means.

Suggested change

	/// Returns the maximum ciphertext overhead with this AEAD.
	/// Returns the maximum number of additional bytes added by the act of sealing data with `self`.
	///
	/// Corresponds to [`EVP_AEAD_max_overhead`](https://commondatastorage.googleapis.com/chromium-boringssl-docs/aead.h.html#EVP_AEAD_max_overhead).

[jyn514]

boring does this elsewhere in the codebase with ForeignType - is there a reason you didn't use that here? https://docs.rs/boring/latest/boring/dh/struct.Dh.html#impl-ForeignType

[initsecret]

I tried to follow the one in symm.rs.

boring/boring/src/symm.rs

Lines 182 to 185 in e6ddc40

	#[allow(clippy::trivially_copy_pass_by_ref)]
	pub fn as_ptr(&self) -> *const ffi::EVP_CIPHER {
	self.0
	}

[jyn514]

How do you know the cipher is thread-safe?

[initsecret]

Good catch, I don't, I accidentally assumed that it was, and the the documentation doesn't seem explicit on this, so I'll remove the lines.

[jyn514]

you mentioned wanting to come up with a better name - I think AeadContext would be a good fit. But this also seems fine as-is.

[jyn514]

should this be an inherent method on Aead maybe?

[initsecret]

I agree. I defined them separately for parity with symm.rs.

boring/boring/src/symm.rs

Lines 635 to 685 in e6ddc40

	/// Like `encrypt`, but for AEAD ciphers such as AES GCM.
	///
	/// Additional Authenticated Data can be provided in the `aad` field, and the authentication tag
	/// will be copied into the `tag` field.
	///
	/// The size of the `tag` buffer indicates the required size of the tag. While some ciphers support
	/// a range of tag sizes, it is recommended to pick the maximum size. For AES GCM, this is 16 bytes,
	/// for example.
	pub fn encrypt_aead(
	t: Cipher,
	key: &[u8],
	iv: Option<&[u8]>,
	aad: &[u8],
	data: &[u8],
	tag: &mut [u8],
	) -> Result<Vec<u8>, ErrorStack> {
	let mut c = Crypter::new(t, Mode::Encrypt, key, iv)?;
	let mut out = vec![0; data.len() + t.block_size()];
	c.aad_update(aad)?;
	let count = c.update(data, &mut out)?;
	let rest = c.finalize(&mut out[count..])?;
	c.get_tag(tag)?;
	out.truncate(count + rest);
	Ok(out)
	}
	/// Like `decrypt`, but for AEAD ciphers such as AES GCM.
	///
	/// Additional Authenticated Data can be provided in the `aad` field, and the authentication tag
	/// should be provided in the `tag` field.
	pub fn decrypt_aead(
	t: Cipher,
	key: &[u8],
	iv: Option<&[u8]>,
	aad: &[u8],
	data: &[u8],
	tag: &[u8],
	) -> Result<Vec<u8>, ErrorStack> {
	let mut c = Crypter::new(t, Mode::Decrypt, key, iv)?;
	let mut out = vec![0; data.len() + t.block_size()];
	c.aad_update(aad)?;
	let count = c.update(data, &mut out)?;
	c.set_tag(tag)?;
	let rest = c.finalize(&mut out[count..])?;
	out.truncate(count + rest);
	Ok(out)
	}

[jyn514]

Suggested change

	Ok(output[..bytes_written_to_output].to_vec())
	output.truncate(bytes_written_to_output);
	Ok(output)

[jyn514]

ditto, this seems better as an inherent method.

[jyn514]

Could you use something other than zeros here? I'm not sure what boringssl does on zeros, and it seems better to be closer to a real scenario anyway.

[initsecret]

Thank you for detailed comments! I made a few of the suggested changes; the others seem to break parity with symm.rs which afaict seems okay, but I wanted to confirm with you before making the change.