You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm still reading the code, so this may be a non-issue, but is there a concept of a crypto-abstraction layer for devices that have hardware support?
While people are quick to throw out "pkcs11" as _the_ abstraction for these things, I'm not sure it makes sense here (or most places ;) ). Some SoCs have support for hardware acceleration and it might be nice to plan for some ability to switch between software and hardware implementations.
The text was updated successfully, but these errors were encountered:
Take a look at cs1a.c init for an example of the abstraction, where function pointers are returned for the different crypto calls that e3x requires.
My expectation is that when another implementation shows up to just replace one algo in a cipher set (such as AES-128) that we extend/grow that list of callbacks and let e3x overlay them (add a cs1a_accel_init after the base one that e3x would overlay onto the first when the CSID matches).
Of course, that plan has to encounter the first real world example yet :)
I'm still reading the code, so this may be a non-issue, but is there a concept of a crypto-abstraction layer for devices that have hardware support?
While people are quick to throw out "pkcs11" as _the_ abstraction for these things, I'm not sure it makes sense here (or most places ;) ). Some SoCs have support for hardware acceleration and it might be nice to plan for some ability to switch between software and hardware implementations.
The text was updated successfully, but these errors were encountered: