|
| 1 | +# Tock Cryptography WG Meeting Notes |
| 2 | + |
| 3 | +**Date:** 6-30-26 |
| 4 | + |
| 5 | +**Participants:** |
| 6 | + - Tyler Potyondy |
| 7 | + - Bobby Reynolds |
| 8 | + - Kat Fox |
| 9 | + - Amit Levy |
| 10 | + - Hans Martin |
| 11 | + |
| 12 | +## SHA Capsule - https://github.com/tock/tock/pull/4855 |
| 13 | +- Bobby: Are we in agreement that SHA is in the purvey of the wg? |
| 14 | +- Amit: Yes, I think so. |
| 15 | +- Bobby: Are we happy with the shape of the SHA HIL? If we aren't, do we want to wait on some of these changes? |
| 16 | +- Amit: The current state is that they are a complete mess. Brad observed that the existing capsule is copied from the hmac capsule and doesn't work with sha. |
| 17 | +- Amit: Changing the SHA capsule to make it decent is blocking people using it. I have some things I'd like to see changed, but at the same time, this seems to be an improvement over what is currently there. |
| 18 | +- Amit: The tension is that if getting it right takes a while, we probably don't want to block and we label this more experimental. |
| 19 | +- Bobby: I agree that we don't want perfect to be the enemy of good. At the same time, we should add this to our horizon for deciding what the end state should look like. Specifically, what does Tock's governance look like moving forward for code touching crypto related functionality. |
| 20 | +- Tyler: Amit, can you articulate some of your concerns a bit more. |
| 21 | +- Amit: The interface in particular. The interface is exposing a hash/verify interface that seems non standard and would be challenging/memory intensive to implement in hardware or in applications. |
| 22 | +- Amit: It seems tuned for the software implementation of what we provide already. |
| 23 | +- Bobby: I'm confused, why is there a verify function here? |
| 24 | +- Bobby: Verify here seems like it should not be in the kernel/capsule. Typically we use the hash to verify, but verify is more "business logic". |
| 25 | +- Amit: I agree with this. I see some reasons (e.g., memory savings) we'd want this here, but broadly, I agree. |
| 26 | +- Amit: Internally, there are some weird holdovers that makes the driver non generic over the bit size. This is good in some ways since the hardware/software libraries are 256, but there are relics still of the more general interface. |
| 27 | +- Bobby: I agree with these criticisms, but at the same time I'm not sure we want to force all these fixes. |
| 28 | +- Amit: Yes, and this is not a clear final state. |
| 29 | +- Bobby: The only grey area I would call out is if this PR opens the door for applications to build a dependency on capsule functionality we want to eventually change. |
| 30 | +- Bobby: Most of our future changes likely wouldn't break this functionality (besides the verify). |
| 31 | +- Tyler: So do we want to merge this with the caveat it is experimental? |
| 32 | +- Amit: I propose we relabel driver number to experimental range, push back on adding the verify method. |
| 33 | +- Bobby: I am anti having the verify method that is more of a creature comfort. |
| 34 | +- Tyler: Keeping the verify method in userspace is very much on theme with some of our more recent discussions having the kernel do less and pushing this functionality to userspace. |
| 35 | + |
| 36 | +## Process for Merging PR |
| 37 | +- Amit: Logistically, one approved maintainer needs to hit approve to merge. What do we want our policy for the wg to be for merging? |
| 38 | +- Bobby: Long term tactics (e.g., crypto governance) or short term plan for these PRs? |
| 39 | +- Amit: We shouldn't let these PRs sit for too long. |
| 40 | +- Bobby: My opinion here for these PRs is that silence implies approval in the meetings. If someone from crypto-wg approves and no feedback, then we can merge. |
| 41 | +- Tyler: I would like to discuss this the notifications mechanisms for crypto-wg PRS. We have missed a lot of these PRs just because notifications weren't working. |
| 42 | +- Amit: We can look further into this (solving offline). |
| 43 | +- Consensus: Mechanism moving forward is to tag @mention the crypto-wg team when crypto-wg label is added. |
| 44 | +- Bobby: Do we want approval/merging to be async or wait for meetings? |
| 45 | +- Amit: Preference is for async. |
| 46 | +- Bobby: So async, with silence implying approval for PRs and discussing further if needed in biweekly meetings. |
| 47 | + |
| 48 | +## AES HIL Changes PR - https://github.com/tock/tock/pull/4861 |
| 49 | +- Consensus: Mostly constant naming changes, uncontroversial and should be approved soon. |
| 50 | + |
| 51 | +## Crypto HIL Redesign - https://github.com/tock/tock/compare/master...reynoldsbd:tock:aes-hil |
| 52 | +- Tyler: I've worked briefly with the new HIL implementing for the nrf5x chip and have so far liked it. |
| 53 | +- Bobby: I'll give a quick overview and then we can talk about next steps. |
| 54 | +- Bobby: Pattern for HIL is pass in parameters for the encryption. Otherwise, uses async/callback driven pattern for retrieving key material/nonces/buffers etc. |
| 55 | +- Bobby: Depending on the cipher mode you select, different sets of callbacks will be invoked. Data moves through buffers that are not static. This gives flexibility for working with this. |
| 56 | +- Tyler: Yes, this was nice and makes it easier for the impl with them not being static. |
| 57 | +- Bobby: We have an enum for modes and the enum contains mode specific info as needed. |
| 58 | +- Bobby: I would like to extend the flavor of this HIL to other crypto interfaces. High level feedback wanted and specifically what are the next steps/things we want implemented around this HIL. |
| 59 | +- Amit: What does it look like implementing this on chips that don't have support for all the combinations of all the modes and key lengths. |
| 60 | +- Bobby: From the intention of the API, this is going to be an errorcode from the crypt method. In this case, the recent PR for user services would be compatible with this (e.g., sw crypto in userspace). |
| 61 | +- Amit: Right, but the concern is in practice, there is then going to be a lot of runtime checks and branching (e.g., which mode is supported, which key size etc). |
| 62 | +- Bobby: So there is always going to be a return code, so I don't see a world where client code is not going to need an error check. So I would argue that the impact is negligible vs the cognitive complexity for encoding this into the typesystem. |
| 63 | +- Tyler: It seems a lot of this complexity could be encapsulated in a single "cryptography controller" capsule that routes syscall commands to hardware if supported, or back to userspace software crypto library via something like userspace services. |
| 64 | +- Amit: So if we moved key length and mode to be generics could we mitigate some of this? |
| 65 | +- Bobby: For keylength being a generic, would we have marker traits? |
| 66 | +- Amit: Or a const generic. |
| 67 | +- Bobby: What about if hw supports multiple key sizes? |
| 68 | +- Amit: We could have marker traits or multiple structs, but I see the larger point. |
| 69 | +- Amit: I think keylength and mode should ideally be specified in the type-system. If kernel clients (e.g., syscall driver) I know at compile time which keylength and mode I'm going to use. If the hardware/system doesn't support that, then getting an errorcode of unsupported is an unrecoverable error. So it seems this should be in the type system. So what is the downside for the type system version? |
| 70 | +- Amit: One answer from earlier is that it isn't obvious for doing this if impl supports multiple key lengths. |
| 71 | +- Bobby: If we go down the rabbit hole for representing this in the type system, I would break apart the cipher mode/block cipher algorithm. Then you would have AES or other block ciphers so you can mix and match these as traits. Then as a client, I could take something that implements the underlying primitive like ECB or CTR. |
| 72 | +- Bobby: My suggestion (but also question) is can we keep something like this that has runtime checking, at least initially, and try to lift more into the type system over time. |
| 73 | +- Tyler: I had some similar feedback for encoding more into the type-system previously. Bobby convinced me why this is challenging though. It is still worth Amit taking a look at though to see if he can think of a nice way to encode this. |
| 74 | +- Bobby: So next steps now that we are reasonably happy with the interface is to start implementing for specific chips, update the syscall interface/capsule that uses this and then update the respective libtock-c/rs bindings. Once we do this, we can see if we are happy with this revised interface and then from there move onto a new crypto mode hil we want to improve. |
0 commit comments