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

Stateful initialization of crypto backends #94

Open
geonnave opened this issue Sep 12, 2023 · 1 comment · May be fixed by #248
Open

Stateful initialization of crypto backends #94

geonnave opened this issue Sep 12, 2023 · 1 comment · May be fixed by #248

Comments

@geonnave
Copy link
Collaborator

geonnave commented Sep 12, 2023

In the cryptocell310 backend, I tested a change in the initialization code so that it only runs once after boot.
This reduced handshake time by ~80 milliseconds.
Here is the commit for that: geonnave@d58b2ae

The goal with this issue is to bring a similar change to the other crypto backends.

@chrysn
Copy link
Collaborator

chrysn commented Oct 11, 2023

As you pointed out, this could benefit from #103

I don't think it'd even need actual fields in the Crypto -- it could still be ZST, but it'd be only created through the initializer function:

#[derive(Copy, Clone)]
pub struct Crypto {
    _private: ()
}

/// Initialize the cryptography engine by doing some pre-computations.
///
/// unsafe: This writes to a static mut, and thus may only be called while no
/// [Crypto] struct exists. In particular, it is safe to call once, as this is the only
/// constructor of a Crypto.
unsafe fn edhoc_rs_crypto_init() -> Crypto {
    unsafe { /* one-time initialization stuff */ };
    Crypto { _private: () }
}

(If we want to do without unsafe, that's just as fine -- we can have a struct Crypto(CRYS_RND_State_t) with a safe constructor, and impl CryptoTrait for &Crypto, but with the unsafe C SaSi_LibInit etc functions around, it's probably easier this way.)

@geonnave geonnave mentioned this issue Dec 21, 2023
7 tasks
@geonnave geonnave linked a pull request Mar 15, 2024 that will close this issue
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 a pull request may close this issue.

2 participants