Open vsukhoml opened 2 months ago
As we discussed a couple of weeks ago, I don't think the OT cryptolib should export these things since the cryptolib API is an important boundary and the drivers are intended to be called within it (e.g. they rely on their caller having already done certain checks on the input). The API for the drivers is also not intended to be stable between hardware versions. If you want to add low-level functionality that we've decided not to support in the main repo, I recommend forking the repository and adding additional code using the drivers at that level before packaging and distributing the crypto library.
As a side note, we do have AES-GCM in streaming mode already in the main API, so it shouldn't be necessary for that.
p.s. I think you intended to tag me here rather than the other GH account with a similar name, you may want to edit the original post!
I don't think the OT cryptolib should export these things since the cryptolib API
We will try to add feature in OT repo first. I wonder if we should add a folder under https://github.com/lowRISC/opentitan/tree/master/sw/device/lib/crypto, like google
and add all the non-generic code (like SKU-specific key generation -- where to get seeds, how to mix it, etc) there, add a bazel target for cryptolib with these additions.
I recommend forking the repository
There are pros and cons in this. So far we would like to use as much as possible, which should help both ways going forward with certifications. This proposal to expose certain low-level APIs is kind of hybrid approach to accelerate development on our end while not diverging much from existing code (no fork).
I think you intended to tag me here rather than the other GH account with a similar name, you may want to edit the original post!
Yes, for some reason Github truncates names when I click enter on the name from drop-down list... :-) I need to be more attentive.
Description
Currently cryptolib provides certain public API, but the decision was made to not provide some deprecated features like SHA-1, TDES or use AES GCM in streaming mode. Certain workloads though needs those and they could be implemented on top of existing cryptolib if some low-level functions would be exposed.
Proposal is to package header files from https://github.com/lowRISC/opentitan/tree/master/sw/device/lib/crypto/drivers into cryptolib distribution, make these headers not dependent on many others OT header files. This includes:
@cfrantz , @jadephilipoom