lowRISC / opentitan

OpenTitan: Open source silicon root of trust
https://www.opentitan.org
Apache License 2.0
2.43k stars 729 forks source link

[cryptolib] need an API for low-level drivers to implement unsupported functionality #22806

Open vsukhoml opened 2 months ago

vsukhoml commented 2 months ago

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

jadephilipoom commented 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!

vsukhoml commented 2 months ago

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.