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

Set ulIvBits and more graceful error handling #249

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

jaeparker22
Copy link

Author: Jason Parker
Email: [email protected]

Modify GcmParams::new to return a Result rather than panic!() and auto-set ulIvBits to support those HSMs that require it, such as Thales. If the IV length is such that ulIvBits is too long, it will be set to 0 as previously. Either the HSM doesn't care and can work without it, or the operation would fail either way.

Tests using GCM params have been updated to reflect the function now returning a Result and a test has been added for the new operation with ulIvBits.

…re graceful error handling

Signed-off-by: Jason Parker <[email protected]>
@jaeparker22 jaeparker22 force-pushed the ulivbits-optional-assign branch from 05673ff to 6524352 Compare March 17, 2025 19:43
@jaeparker22 jaeparker22 marked this pull request as ready for review March 17, 2025 20:00
Copy link
Collaborator

@wiktor-k wiktor-k left a comment

Choose a reason for hiding this comment

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

Looks good, a couple of nits.

/// This function panics if the length of `iv` or `aad` does not
/// fit into an [Ulong].
pub fn new(iv: &'a mut [u8], aad: &'a [u8], tag_bits: Ulong) -> Self {
pub fn new(iv: &'a mut [u8], aad: &'a [u8], tag_bits: Ulong) -> Result<Self, &'a str> {
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 I'd leave the "Panics" section but rename it to "Errors" since then it'd be clear when this function fails.

While &'a str is not ideal (a custom error would be better) it's not super-bad IMO (but maybe the lifetime of that should be 'static since it's just static messages? It's not tied to iv in any way).

Copy link
Author

Choose a reason for hiding this comment

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

There is a TryFromIntError in the crate, which I initially thought to use and is the natural error generated. Only reason I didn't was because I wanted to maintain the original error message.

Copy link
Member

Choose a reason for hiding this comment

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

Only reason I didn't was because I wanted to maintain the original error message

Do you mean your custom error message?

I think it would be perfect to use TryFromIntError here 😃 I think users would understand based on the context/line number?

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 users would understand based on the context/line number?

Happy to be corrected here but AFAIK Errors generally don't provide any kind of backtrace when they're captured (it is possible to manually capture a Backtrace but I didn't find any mention of it being automatic in std::error::Error). This is one of the benefits of panics (but of course, not really applicable to production code).

I'm OK with just using TryFromIntError for now (even if that means it'll be harder to find the cause).

.try_into() {
Ok(len) => len,
Err(_e) => return Err("aad length does not fit in CK_ULONG"),
},
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
.try_into() {
Ok(len) => len,
Err(_e) => return Err("aad length does not fit in CK_ULONG"),
},
.try_into().map_err(|_| "aad length does not fit in CK_ULONG")?

I think something like this would be shorter...

@hug-dev hug-dev linked an issue Mar 19, 2025 that may be closed by this pull request
jaeparker22 and others added 4 commits March 19, 2025 12:26
Signed-off-by: Jason Parker <[email protected]>
Co-authored-by: Wiktor Kwapisiewicz <[email protected]>
Signed-off-by: Jason Parker <[email protected]>
Signed-off-by: Jason Parker <[email protected]>
@jaeparker22 jaeparker22 force-pushed the ulivbits-optional-assign branch from d2e1a2e to bd41a6b Compare March 19, 2025 17:26
Copy link
Member

@hug-dev hug-dev left a comment

Choose a reason for hiding this comment

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

Thanks a lot! It looks all good for me, I would though be more in favour of re-using our Error type

/// This function panics if the length of `iv` or `aad` does not
/// fit into an [Ulong].
pub fn new(iv: &'a mut [u8], aad: &'a [u8], tag_bits: Ulong) -> Self {
pub fn new(iv: &'a mut [u8], aad: &'a [u8], tag_bits: Ulong) -> Result<Self, &'a str> {
Copy link
Member

Choose a reason for hiding this comment

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

Only reason I didn't was because I wanted to maintain the original error message

Do you mean your custom error message?

I think it would be perfect to use TryFromIntError here 😃 I think users would understand based on the context/line number?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GcmParams ulIvBits being set to 0 causes issues with Thales HSMs
3 participants