Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Part of moving Parsec to use psa-crypto #28

Merged
merged 9 commits into from
Jun 16, 2020
1 change: 1 addition & 0 deletions psa-crypto-sys/src/c/shim.h
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,7 @@ psa_algorithm_t shim_get_key_algorithm(const psa_key_attributes_t *attributes);
psa_key_usage_t
shim_get_key_usage_flags(const psa_key_attributes_t *attributes);
psa_key_attributes_t shim_key_attributes_init(void);
psa_status_t shim_get_key_attributes(psa_key_handle_t key_handle, psa_key_attributes_t *attributes);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to tidy this code up a bit while you're at it. How about having the return type consistently on the same line as the function name and putting the functions in alphabetical order as they already mostly are?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to add CI linting (potentially clang-format)? Wouldn't take care of the alphabetical order, but it would keep other things tidy. Might be a bit overkill, tho


void shim_set_key_algorithm(psa_key_attributes_t *attributes,
psa_algorithm_t alg);
Expand Down
5 changes: 5 additions & 0 deletions psa-crypto-sys/src/constants.rs
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,9 @@ pub const PSA_ERROR_HARDWARE_FAILURE: psa_status_t = -147;
pub const PSA_ERROR_INSUFFICIENT_ENTROPY: psa_status_t = -148;
pub const PSA_ERROR_INVALID_SIGNATURE: psa_status_t = -149;
pub const PSA_ERROR_INVALID_PADDING: psa_status_t = -150;
pub const PSA_ERROR_CORRUPTION_DETECTED: psa_status_t = -151;
pub const PSA_ERROR_DATA_CORRUPT: psa_status_t = -152;
pub const PSA_ERROR_DATA_INVALID: psa_status_t = -153;
pub const PSA_ERROR_INSUFFICIENT_DATA: psa_status_t = -143;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last two (-143 and -136) seem to be in the wrong place but that's not part of this patch so I shouldn't really complain.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remind me why these values can't come from the C library somehow? In a previous patch we had something like pub const PSA_SOMETHING: psa_something_t = shim_PSA_SOMETHING; in the Rust code and const psa_something_t shim_PSA_SOMETHING = PSA_SOMETHING; in shim.h. It would be nice to explain in a comment at the top of constants.rs why these values are being repeated like this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We removed from the shim all the values that are defined by the specification. That way, it allows you to use those value, without having to link with a PSA Crypto implementation (that is the implementation-defined feature). That is useful for Parsec interface where we re-use some of these values but do not want to link to a PSA Crypto implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least I hope I removed all the duplication, as I did everything manually

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't realised some values are defined by the specification. Should that be mentioned in a comment in constants.rs?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that makes sense - we do have a module comment in this file, it might be worth expanding that to explain the logic of what's hidden by implementation-defined - there's a brief explanation here but it should really be in docs.rs too.

pub const PSA_ERROR_INVALID_HANDLE: psa_status_t = -136;

Expand Down Expand Up @@ -87,6 +90,8 @@ pub const PSA_KEY_USAGE_DECRYPT: psa_key_usage_t = 512;
pub const PSA_KEY_USAGE_SIGN: psa_key_usage_t = 1024;
pub const PSA_KEY_USAGE_VERIFY: psa_key_usage_t = 2048;
pub const PSA_KEY_USAGE_DERIVE: psa_key_usage_t = 4096;
pub const PSA_KEY_SLOT_COUNT: isize = 32;
pub const PSA_MAX_PERSISTENT_KEY_IDENTIFIER: psa_key_id_t = 0x3fff_ffff;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These values seem to be Mbed Crypto specific. Ideally this crate is common to all PSA Crypto implementation so it would be better, I think, to declare those values in the code that needs them directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they are Mbed Crypto specific. Should they be moved to parsec?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think it will be better.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably PSA_MAX_PERSISTENT_KEY_IDENTIFIER will be replaced with something else in PSA Crypto 1.0?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably PSA_MAX_PERSISTENT_KEY_IDENTIFIER will be replaced with something else in PSA Crypto 1.0?

That's a good point, on section 9.1.1, for psa_key_id_t, it defines ranges of key identifiers. For example for application key identifiers, it can range from PSA_KEY_ID_USER_MIN (0x00000001) to PSA_KEY_ID_USER_MAX (0x3fffffff). Which is the same value as the one above 😄! So I guess as PSA_KEY_SLOT_COUNT should be removed, PSA_MAX_PERSISTENT_KEY_IDENTIFIER can be renamed to PSA_KEY_ID_USER_MAX


#[cfg(feature = "implementation-defined")]
pub const PSA_DRV_SE_HAL_VERSION: u32 = 5;
6 changes: 3 additions & 3 deletions psa-crypto-sys/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -39,9 +39,9 @@ pub use types::*;

#[cfg(feature = "implementation-defined")]
pub use psa_crypto_binding::{
psa_close_key, psa_crypto_init, psa_destroy_key, psa_export_public_key, psa_generate_key,
psa_import_key, psa_key_attributes_t, psa_open_key, psa_reset_key_attributes, psa_sign_hash,
psa_verify_hash,
mbedtls_psa_crypto_free, psa_close_key, psa_crypto_init, psa_destroy_key,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for mbedtls_psa_crypto_free, I don't think we should declare it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how we should deal with this. For psa-crypto to be portable to any PSA Crypto implementation, we can't have this mbedtls specific method declared here, but I'm not sure how we remove it from psa-crypto and allow Parsec to call it without binding straight through to mbedtls.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is is used inside Mbed Crypto for testing but should not be required in this crate. If it is, and creating leaks in our applications, we should probably discuss this at a PSA Crypto level.

psa_export_public_key, psa_generate_key, psa_get_key_attributes, psa_import_key,
psa_key_attributes_t, psa_open_key, psa_reset_key_attributes, psa_sign_hash, psa_verify_hash,
};

// Secure Element Driver definitions
Expand Down
2 changes: 1 addition & 1 deletion psa-crypto-sys/vendor
19 changes: 18 additions & 1 deletion psa-crypto/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ static INITIALISED: AtomicBool = AtomicBool::new(false);
/// ```
#[cfg(feature = "with-mbed-crypto")]
pub fn init() -> Result<()> {
// It it not a problem to call psa_crypto_init more than once.
// It is not a problem to call psa_crypto_init more than once.
Status::from(unsafe { psa_crypto_sys::psa_crypto_init() }).to_result()?;
let _ = INITIALISED.compare_and_swap(false, true, Ordering::Relaxed);

Expand All @@ -96,3 +96,20 @@ pub fn initialized() -> Result<()> {
Err(Error::BadState)
}
}

/// Closes mbedtls, releasing resources
///
/// Example
///
/// ```
/// use psa_crypto::{init, drop};
/// init().unwrap();
/// // ...
/// drop();
/// ```
#[cfg(feature = "with-mbed-crypto")]
pub fn drop() {
unsafe {
psa_crypto_sys::mbedtls_psa_crypto_free();
}
}
15 changes: 7 additions & 8 deletions psa-crypto/src/operations/asym_signature.rs
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ pub fn sign_hash(
let mut signature_length = 0;
let handle = key.handle()?;

Status::from(unsafe {
let sign_res = Status::from(unsafe {
psa_crypto_sys::psa_sign_hash(
handle,
alg.into(),
Expand All @@ -75,10 +75,9 @@ pub fn sign_hash(
&mut signature_length,
)
})
.to_result()?;

.to_result();
key.close_handle(handle)?;

sign_res?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is actually quite clever 😄 Never thought of doing it like that before.

Comment on lines -79 to +80
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For these cases where you need to do a cleanup operation that may fail (after some other core operation might've failed in the first place) we have to decide: if both fail, which error do we want to be returned? I'd say the error on the "core" operation should take precedence, in which case the two branches (as in, if the core operation failed or not) will be different

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I wish we had a better approach to this kind of problem where you have some cleanup to do whenever you exit the function. In this case it's fine since there's not much branching, but in some cases it might end up being a pain having to call that close_handle for each possible path before doing ?.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally had it returning the first operation error, then the close handle error but after a brief discussion with @hug-dev, it was changed to how it is now. I think the reason was the PSA API states keys aren't used, IDs are, so it should be getting removed at some point (soon? 😄) anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think that makes sense for this case, my comment was more general - we should have a statement somewhere as to how to prioritize these errors throughout the library. I'd even say that this applies to Parsec too. The last error to occur is not necessarily the one we should return.

Ok(signature_length)
}

Expand Down Expand Up @@ -130,7 +129,7 @@ pub fn verify_hash(key: Id, alg: AsymmetricSignature, hash: &[u8], signature: &[

let handle = key.handle()?;

Status::from(unsafe {
let verify_res = Status::from(unsafe {
psa_crypto_sys::psa_verify_hash(
handle,
alg.into(),
Expand All @@ -140,7 +139,7 @@ pub fn verify_hash(key: Id, alg: AsymmetricSignature, hash: &[u8], signature: &[
signature.len(),
)
})
.to_result()?;

key.close_handle(handle)
.to_result();
key.close_handle(handle)?;
verify_res
}
118 changes: 90 additions & 28 deletions psa-crypto/src/operations/key_management.rs
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,10 @@
//! # Key Management operations

use crate::initialized;
use crate::types::key::{Attributes, Id};
use crate::types::key::{Attributes, Id, Lifetime};
use crate::types::status::{Result, Status};
use core::convert::TryFrom;
use psa_crypto_sys::{psa_key_handle_t, psa_key_id_t};

/// Generate a key or a key pair
///
Expand Down Expand Up @@ -47,25 +48,20 @@ use core::convert::TryFrom;
/// ```
pub fn generate(attributes: Attributes, id: Option<u32>) -> Result<Id> {
initialized()?;

let mut attributes = psa_crypto_sys::psa_key_attributes_t::try_from(attributes)?;
let mut key_attributes = psa_crypto_sys::psa_key_attributes_t::try_from(attributes)?;
let id = if let Some(id) = id {
unsafe { psa_crypto_sys::psa_set_key_id(&mut attributes, id) };
unsafe { psa_crypto_sys::psa_set_key_id(&mut key_attributes, id) };
id
} else {
0
};
let mut handle = 0;
let gen_res =
Status::from(unsafe { psa_crypto_sys::psa_generate_key(&key_attributes, &mut handle) })
.to_result();
Attributes::reset(&mut key_attributes);

Status::from(unsafe { psa_crypto_sys::psa_generate_key(&attributes, &mut handle) })
.to_result()?;

Attributes::reset(&mut attributes);

Ok(Id {
id,
handle: Some(handle),
})
complete_new_key_operation(attributes.lifetime, id, handle, gen_res)
}

/// Destroy a key
Expand Down Expand Up @@ -113,8 +109,7 @@ pub fn generate(attributes: Attributes, id: Option<u32>) -> Result<Id> {
pub unsafe fn destroy(key: Id) -> Result<()> {
initialized()?;
let handle = key.handle()?;
Status::from(psa_crypto_sys::psa_destroy_key(handle)).to_result()?;
key.close_handle(handle)
Status::from(psa_crypto_sys::psa_destroy_key(handle)).to_result()
}

/// Import a key in binary format
Expand Down Expand Up @@ -166,26 +161,23 @@ pub unsafe fn destroy(key: Id) -> Result<()> {
pub fn import(attributes: Attributes, id: Option<u32>, data: &[u8]) -> Result<Id> {
initialized()?;

let mut attributes = psa_crypto_sys::psa_key_attributes_t::try_from(attributes)?;
let mut key_attributes = psa_crypto_sys::psa_key_attributes_t::try_from(attributes)?;
let id = if let Some(id) = id {
unsafe { psa_crypto_sys::psa_set_key_id(&mut attributes, id) };
unsafe { psa_crypto_sys::psa_set_key_id(&mut key_attributes, id) };
id
} else {
0
};
let mut handle = 0;

Status::from(unsafe {
psa_crypto_sys::psa_import_key(&attributes, data.as_ptr(), data.len(), &mut handle)
let gen_res = Status::from(unsafe {
psa_crypto_sys::psa_import_key(&key_attributes, data.as_ptr(), data.len(), &mut handle)
})
.to_result()?;
.to_result();

Attributes::reset(&mut attributes);
Attributes::reset(&mut key_attributes);

Ok(Id {
id,
handle: Some(handle),
})
complete_new_key_operation(attributes.lifetime, id, handle, gen_res)
}

/// Export a public key or the public part of a key pair in binary format
Expand Down Expand Up @@ -227,17 +219,87 @@ pub fn export_public(key: Id, data: &mut [u8]) -> Result<usize> {
let handle = key.handle()?;
let mut data_length = 0;

Status::from(unsafe {
let export_res = Status::from(unsafe {
psa_crypto_sys::psa_export_public_key(
handle,
data.as_mut_ptr(),
data.len(),
&mut data_length,
)
})
.to_result()?;
.to_result();
key.close_handle(handle)?;
export_res?;
Ok(data_length)
}

/// Gets the attributes for a given key ID
///
/// The `Id` structure can be created with the `from_persistent_key_id` constructor on `Id`.
///
/// # Example
///
/// ```
/// # use psa_crypto::operations::key_management;
/// # use psa_crypto::types::key::{Attributes, Type, Lifetime, Policy, UsageFlags};
/// # use psa_crypto::types::algorithm::{AsymmetricSignature, Hash};
/// # let mut attributes = Attributes {
/// # key_type: Type::RsaKeyPair,
/// # bits: 1024,
/// # lifetime: Lifetime::Volatile,
/// # policy: Policy {
/// # usage_flags: UsageFlags {
/// # sign_hash: true,
/// # sign_message: true,
/// # verify_hash: true,
/// # verify_message: true,
/// # ..Default::default()
/// # },
/// # permitted_algorithms: AsymmetricSignature::RsaPkcs1v15Sign {
/// # hash_alg: Hash::Sha256.into(),
/// # }.into(),
/// # },
/// # };
/// psa_crypto::init().unwrap();
/// let my_key = key_management::generate(attributes, None).unwrap();
/// //...
/// let key_attributes = key_management::get_key_attributes(my_key);
/// ```

pub fn get_key_attributes(key: Id) -> Result<Attributes> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a way, this function is a contructor of Attributes so I think it could be placed inside the impl Attributes block. In that case, we could rename it, using namespacing. What about something like from_key? It would then be Attributes::from_key(...) to invoke it.
Agree that we would deviate from the PSA Crypto naming but I think it is fine if we make it more Rust-like!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from_key_id - Id is not a key per se and we keep naming things as if it is.

initialized()?;
let mut key_attributes = unsafe { psa_crypto_sys::psa_key_attributes_init() };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we follow the specs, the attributes created here might allocate some extra space that needs to be freed with a call to psa_reset_key_attributes (Attributes::reset). I think that might be needed on every path leaving the function once psa_key_attributes_init has been called.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hence my pet peeve with these cleanup methods.
What happens if both close_handle and psa_reset_key_attributes fail, which value do we return? Maybe we should really return a generic error when some of these "internal" methods fail, that the user should not really know about.

An alternative would be to make a "layered" function, where for each variable that needs cleaning up we wrap everything after it in a function that returns a Result. If the result is Ok, attempt to clean up and if that fails return an error, otherwise return the Ok you got. If what you got was Err, then do the clean up anyway and return the Err you got from the next layer function. If you have two things that you need to clean, unfortunately you'd have 2 "layer" functions. But the benefit is that you're sure that you clean up everything and you return the Err that's most appropriate.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think psa_reset_key_attributes can't fail, though that doesn't invalidate the general point, just that particular example!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also, I think you don't need to call psa_reset_key_attributes if calling psa_key_attributes_init is all you've done with the psa_key_attributes_t, and according to the 1.0 spec there seem to be certain psa_set_key_ functions that you can call without needing to do the reset.)

let handle = key.handle()?;
let attributes_res = Status::from(unsafe {
psa_crypto_sys::psa_get_key_attributes(handle, &mut key_attributes)
})
.to_result();
key.close_handle(handle)?;
attributes_res?;
Ok(Attributes::try_from(key_attributes)?)
}

Ok(data_length)
/// Completes a new key operation (either generate or import)
///
/// If key is not `Volatile` (`Persistent` or `Custom(u32)`), handle is closed.
///
/// If a key is `Volatile`, `Id` returned contains the key `handle`. Otherwise, it does not.
fn complete_new_key_operation(
key_lifetime: Lifetime,
id: psa_key_id_t,
handle: psa_key_handle_t,
operation_result: Result<()>,
) -> Result<Id> {
if key_lifetime != Lifetime::Volatile {
Status::from(unsafe { psa_crypto_sys::psa_close_key(handle) }).to_result()?;
}
operation_result?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that if psa_generate_key or psa_import_key failed you still need to close the key? I would have thought that if those operations fail, they do not open the key.
The documentation of psa_generate_key says:

 * \param[out] handle       On success, a handle to the newly created key.
 *                          \c 0 on failure.

So I think this is fine not passing operation_result to this function (checking in the caller if it failed or not).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have checked psa_generate_key and psa_import_key - you are correct, a handle should not be created unless the operation succeeds.

Ok(Id {
id,
handle: if key_lifetime == Lifetime::Volatile {
Some(handle)
} else {
None
},
})
}
5 changes: 4 additions & 1 deletion psa-crypto/src/types/key.rs
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,9 @@ use crate::types::status::{Error, Result};
#[cfg(feature = "with-mbed-crypto")]
use core::convert::{TryFrom, TryInto};
use log::error;
pub use psa_crypto_sys::{
psa_key_id_t as key_id_type, PSA_KEY_SLOT_COUNT, PSA_MAX_PERSISTENT_KEY_IDENTIFIER,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the renaming of psa_key_id_t required? I think it is easier to understand when you have the original type name but that might be a personal opinion 😋

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not required. I think I just did it so it was clear in my head when I was making the change, so I didn't trip up with the other reference to the same type from the binding, when I was swapping them over. I agree, it'll be clearer if the original name is kept 😃

};
use serde::{Deserialize, Serialize};

/// Native definition of the attributes needed to fully describe
Expand Down Expand Up @@ -473,7 +476,7 @@ pub struct UsageFlags {
#[cfg(feature = "with-mbed-crypto")]
#[derive(Copy, Clone, Debug, PartialEq, Serialize, Deserialize)]
pub struct Id {
pub(crate) id: psa_crypto_sys::psa_key_id_t,
pub(crate) id: key_id_type,
pub(crate) handle: Option<psa_crypto_sys::psa_key_handle_t>,
}

Expand Down
14 changes: 9 additions & 5 deletions psa-crypto/src/types/status.rs
Original file line number Diff line number Diff line change
Expand Up @@ -186,6 +186,9 @@ impl From<psa_crypto_sys::psa_status_t> for Status {
psa_crypto_sys::PSA_ERROR_INVALID_PADDING => Error::InvalidPadding.into(),
psa_crypto_sys::PSA_ERROR_INSUFFICIENT_DATA => Error::InsufficientData.into(),
psa_crypto_sys::PSA_ERROR_INVALID_HANDLE => Error::InvalidHandle.into(),
psa_crypto_sys::PSA_ERROR_CORRUPTION_DETECTED => Error::CorruptionDetected.into(),
psa_crypto_sys::PSA_ERROR_DATA_CORRUPT => Error::DataCorrupt.into(),
psa_crypto_sys::PSA_ERROR_DATA_INVALID => Error::DataInvalid.into(),
s => {
error!("{} not recognised as a valid PSA status.", s);
Status::Error(Error::GenericError)
Expand Down Expand Up @@ -218,19 +221,20 @@ impl From<Error> for psa_crypto_sys::psa_status_t {
Error::InsufficientStorage => psa_crypto_sys::PSA_ERROR_INSUFFICIENT_STORAGE,
Error::CommunicationFailure => psa_crypto_sys::PSA_ERROR_COMMUNICATION_FAILURE,
Error::StorageFailure => psa_crypto_sys::PSA_ERROR_STORAGE_FAILURE,
//Error::DataCorrupt => psa_crypto_sys::PSA_ERROR_DATA_CORRUPT,
//Error::DataInvalid => psa_crypto_sys::PSA_ERROR_DATA_INVALID,
Error::DataCorrupt => psa_crypto_sys::PSA_ERROR_DATA_CORRUPT,
Error::DataInvalid => psa_crypto_sys::PSA_ERROR_DATA_INVALID,
Error::HardwareFailure => psa_crypto_sys::PSA_ERROR_HARDWARE_FAILURE,
//Error::CorruptionDetected => psa_crypto_sys::PSA_ERROR_CORRUPTION_DETECTED,
Error::CorruptionDetected => psa_crypto_sys::PSA_ERROR_CORRUPTION_DETECTED,
Error::InsufficientEntropy => psa_crypto_sys::PSA_ERROR_INSUFFICIENT_ENTROPY,
Error::InvalidSignature => psa_crypto_sys::PSA_ERROR_INVALID_SIGNATURE,
Error::InvalidPadding => psa_crypto_sys::PSA_ERROR_INVALID_PADDING,
Error::InsufficientData => psa_crypto_sys::PSA_ERROR_INSUFFICIENT_DATA,
Error::InvalidHandle => psa_crypto_sys::PSA_ERROR_INVALID_HANDLE,
e => {
// Commented out as all errors are currently matched against and this causes compilation error
/*e => {
error!("No equivalent of {:?} to a psa_status_t.", e);
psa_crypto_sys::PSA_ERROR_GENERIC_ERROR
}
}*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's great, thanks for completing this conversion. Feel free to delete that block altogether 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove

}
}
}
Expand Down
Loading