[otbn] RTL implementation of the KMAC interface by etterli · Pull Request #30283 · lowRISC/opentitan

etterli · 2026-06-03T14:56:28Z

The last commit of this PR implements the OTBN side of the KMAC interface. The interface is specified in #30278.

All other commits are part of one of these PRs:

[kmac] Specify and implement a dynamic app interface extension #30141: RTL on KMAC side
[kmac] Extend KMAC app interface with a dynamic interface type #30143: DV for KMAC side
[otbn] Specify the OTBN side of the KMAC interface #30278: Specification of this implementation.

etterli · 2026-06-04T11:18:52Z

The interface no longer automatically sends a process command when a partial message is sent. It just detects it and waits for SW to issue a process command.

etterli · 2026-06-04T11:45:30Z

+  ////////////////////////////////////
+  // KMAC_DATA_Sx secure wipe delay //
+  ////////////////////////////////////


This whole concept of delaying the secure wipe for the relevant 64 bits (or rather 128 for both shares) of the message is quite ugly. But I haven't found a better way how to ensure that the data does not change. And there is an assertion in the msg FIFO inside the KMAC (prim packer and also downstream) that it must remain stable.

Any idea is welcome.

In my view we don't need to buffer / delay the secure wipe word here for the following reasons:

The secure wipe is fed from URND and we do two wipes with a URND reseed in between.

We do two wipes with a reseed in between to not allow recovering the URND output of the first wipe as this could potentially allow for a SCA attack on the secret using the leakage between the secret and the URND output.

The secret here is always shared because KMAC consumes and provides shared data. So there would be at most second order leakage. This is different from regular WDRs where we can have shared and unshared data.

So instead of buffering / delaying the wipe I would do the following:

If there is not outstanding request, wipe based on the wipe input signal and using URND.

If there is an outstanding request

Track that we have to do the wipe at a later point.

Once that point comes, generate a URND update/advance signal (no reseed). At that point, the main wipe may have finished and OTBN may be idle (URND at rest) otherwise.

Wipe the entire WSRs instead of individual 64-bit beats to reduce complexity.

Would that work?

Alternatively, I would also be fine to not adhere to the valid-locked-in principle here. This is really a corner case and I am not sure we will be able to trigger this at the top level. We may be able to trigger it with a FI simulation test but then can also deactivate the relevant SVAs in KMAC and reason why this is necessary for that specfiic test.

Thank you for the proposal. This sounds good. Not guaranteeing two wipes for these WSRs just means that these should not be used as extra WDRs when the KMAC IF is not used.

I also checked the consequences of not adhering to the valid locked-in principle again in more detail. If it is violated, then the only consequence is that the digest value computed by the KMAC is undefined. But it does not lock up the KMAC IP. The recovery mechanism will still bring the KMAC IP back to the Idle state. And when a secure wipe happens, we anyway ignore any digest data. The strobe however should be stable.

Therefore, I think the best is if we just secure wipe these registers in the normal way and accept the corner case. The configuration and strobe registers can simply be reset to the default values once the recovery ends.

Fully agree, thanks @etterli !

etterli · 2026-06-08T14:24:02Z

+  // Extract command from write.
+  assign current_cmd = ispr_kmac_ctrl_w.cmd & {$bits(kmac_cmd_t){ispr_kmac_ctrl_wr_i}};


This extracts the cmd from the current instruction and thus makes current_cmd combinatorial. I designed the FSM in such a way that there is no timing path directly to the interface. But maybe it would make more sense if the write goes to an actual register and the FSM decides on a flopped value?

Hm, good question. If we used a CSRWI instruction, the command would come out of an immediate but also other paths would be possible. Maybe we need a 1 cycle delay then for the START command. This shouldn't be critical for performance as it's done just once per session.

We now have already a one cycle delay because the FSM will issue the request in another state than when it detects the command (OtbnKmacIdle vs OtbnKmacStarting, and similar for all other commands). In OtbnKmacIdle the state transition depends on the command. And in OtbnKmacStarting the FSM sets the request valid signal but the command signal is not evaluated anymore.

The question now is whether having 2 states actually serves as a cut between the command signal and the request signal generation. This comes down how the FSM is implemented/optimized when synthesizing the design. But I suggest let's do a synthesis and see the effect. This would be easy to refactor.

Yes, I fully agree with you here.

vogelpi

Thanks Pascal, this looks pretty nice so far. I've reviewed the first half and will continue later.

etterli

Thanks @vogelpi for the first review. Here is the updated version. The KMAC_CTRL is now split into KMAC_CTRL and KMAC_CFG.

vogelpi

I've now also reviewed the rest. I would try to simplify the secure wipe (it's a corner case) and instead optimize the digest reading (the fast case we care about).

vogelpi · 2026-06-09T20:19:43Z

+  // TODO: Do we need integrity or any other duplication? We could duplicate the config and then
+  // send the config on both data share signals.


Yes, I would just do that. And I would duplicate these bits also in the CSR. So software would have to provide the config for both shares. These couple of flops are not expensive but it's a lot simpler from a hardening perspective than reasoning about where what could go wrong.

Ok if we postpone this because it also requires changes on the KMAC side? I created an issue for this. Rephrased the TODO so it's no longer a question.

Actually, it doesn't require KMAC side changes. KMAC should ignore share1 for config commands, no?

Ah yes true. It is now implemented on the OTBN side.

vogelpi · 2026-06-09T20:22:42Z

+  // TODO: Do we need integrity?
+  assign ispr_kmac_strb_rdata_o = kmac_strb_q;


I think it should be sufficient to check on the receiving side, i.e., inside KMAC that there are no empty message beats (strobe == 0) in between the last beat and the process command. I am not worried about dropping or shortening a single beat, but more about sending all-zero messages.

Manipulating the strobe can result in undefined behaviour / digest values or a message is interpreted as empty message. Both cases must be detected somehow. I agree that this should be handled on the KMAC side because otherwise we would also have to harden the data signals.

Created an issue for this.

vogelpi · 2026-06-09T20:51:43Z

+  ////////////////////////////////////
+  // KMAC_DATA_Sx secure wipe delay //
+  ////////////////////////////////////


In my view we don't need to buffer / delay the secure wipe word here for the following reasons:

The secure wipe is fed from URND and we do two wipes with a URND reseed in between.

We do two wipes with a reseed in between to not allow recovering the URND output of the first wipe as this could potentially allow for a SCA attack on the secret using the leakage between the secret and the URND output.

The secret here is always shared because KMAC consumes and provides shared data. So there would be at most second order leakage. This is different from regular WDRs where we can have shared and unshared data.

So instead of buffering / delaying the wipe I would do the following:

If there is not outstanding request, wipe based on the wipe input signal and using URND.

If there is an outstanding request

Track that we have to do the wipe at a later point.

Once that point comes, generate a URND update/advance signal (no reseed). At that point, the main wipe may have finished and OTBN may be idle (URND at rest) otherwise.

Wipe the entire WSRs instead of individual 64-bit beats to reduce complexity.

Would that work?

Alternatively, I would also be fine to not adhere to the valid-locked-in principle here. This is really a corner case and I am not sure we will be able to trigger this at the top level. We may be able to trigger it with a FI simulation test but then can also deactivate the relevant SVAs in KMAC and reason why this is necessary for that specfiic test.

etterli · 2026-06-10T16:05:58Z

The latest version features:

Rebased on the newest version of [kmac] Extend KMAC app interface with a dynamic interface type #30143 (minimized DV changes and squashed everything).
The implementation of the new OTBN SW command CLOSE
Simplified the secure wipe behaviour for KMAC_DATA_S0/1.
- These are now wipe like any other WSR.
- We accept the corner case that we violate the valid locked-in principle for the request channel when a wipe happens whilst sending a message.
The interface is now capable of accepting the next response in the same cycle the previous digest is consumed/read.

vogelpi

Very nice, thanks for the various improvements @etterli !

nasahlpa

Thanks Pascal - I have checked whether the RTL matches the spec, which is the case.

etterli

I have now addressed all the feedback and implemented the duplicated KMAC_CFG register.

Also see #30384 for how the interface is integrated into OTBN.

etterli · 2026-06-11T15:30:11Z

+  // Extract command from write.
+  assign current_cmd = ispr_kmac_ctrl_w.cmd & {$bits(kmac_cmd_t){ispr_kmac_ctrl_wr_i}};


We now have already a one cycle delay because the FSM will issue the request in another state than when it detects the command (OtbnKmacIdle vs OtbnKmacStarting, and similar for all other commands). In OtbnKmacIdle the state transition depends on the command. And in OtbnKmacStarting the FSM sets the request valid signal but the command signal is not evaluated anymore.

The question now is whether having 2 states actually serves as a cut between the command signal and the request signal generation. This comes down how the FSM is implemented/optimized when synthesizing the design. But I suggest let's do a synthesis and see the effect. This would be easy to refactor.

etterli · 2026-06-11T15:30:40Z

+  // TODO: Do we need integrity or any other duplication? We could duplicate the config and then
+  // send the config on both data share signals.


Ah yes true. It is now implemented on the OTBN side.

Signed-off-by: Pascal Etterli <pascal.etterli@lowrisc.org>

vogelpi

Thanks, this looks really great @etterli !

vogelpi · 2026-06-16T15:02:44Z

+  // Extract command from write.
+  assign current_cmd = ispr_kmac_ctrl_w.cmd & {$bits(kmac_cmd_t){ispr_kmac_ctrl_wr_i}};


Yes, I fully agree with you here.

vogelpi · 2026-06-16T15:09:20Z

CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_kmac_if.sv

nasahlpa · 2026-06-16T15:20:41Z

CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn_kmac_if.sv

nasahlpa · 2026-06-16T15:30:46Z

merging as the Private CI run already passed but it is not correctly visualized here and the time out in the FPGA test run is fine.

etterli requested review from h-filali, nasahlpa, rswarbrick and vogelpi June 3, 2026 14:57

etterli changed the title ~~Otbn rtl kmac if~~ [otbn] RTL implementation of the KMAC interface Jun 3, 2026

etterli force-pushed the otbn-rtl-kmac-if branch 2 times, most recently from 44b855f to 4ab11e9 Compare June 4, 2026 11:18

etterli force-pushed the otbn-rtl-kmac-if branch 2 times, most recently from 039bb39 to a0cf520 Compare June 4, 2026 11:41

etterli commented Jun 4, 2026

View reviewed changes

Comment thread hw/ip/otbn/rtl/otbn_kmac.sv Outdated

etterli force-pushed the otbn-rtl-kmac-if branch 8 times, most recently from 8d318c7 to b116425 Compare June 5, 2026 15:08

etterli commented Jun 8, 2026

View reviewed changes

etterli force-pushed the otbn-rtl-kmac-if branch from b116425 to 4cb285f Compare June 8, 2026 14:50

rswarbrick removed their request for review June 9, 2026 09:32

vogelpi reviewed Jun 9, 2026

View reviewed changes

etterli commented Jun 9, 2026

View reviewed changes

Comment thread hw/ip/otbn/rtl/otbn_kmac_if.sv Outdated

etterli commented Jun 9, 2026

View reviewed changes

Comment thread hw/ip/otbn/rtl/otbn_kmac.sv Outdated

Comment thread hw/ip/otbn/rtl/otbn_kmac.sv Outdated

Comment thread hw/ip/otbn/rtl/otbn_kmac_if.sv

Comment thread hw/ip/otbn/rtl/otbn_kmac.sv Outdated

etterli force-pushed the otbn-rtl-kmac-if branch from 4cb285f to f439c5c Compare June 9, 2026 19:56

vogelpi reviewed Jun 9, 2026

View reviewed changes

etterli force-pushed the otbn-rtl-kmac-if branch from f439c5c to bded919 Compare June 10, 2026 16:02

etterli force-pushed the otbn-rtl-kmac-if branch 5 times, most recently from 2b8e25d to cd9a0b5 Compare June 11, 2026 12:32

vogelpi approved these changes Jun 11, 2026

View reviewed changes

nasahlpa approved these changes Jun 12, 2026

View reviewed changes

etterli force-pushed the otbn-rtl-kmac-if branch from cd9a0b5 to b048304 Compare June 12, 2026 14:07

etterli commented Jun 12, 2026

View reviewed changes

etterli mentioned this pull request Jun 12, 2026

[otbn] Integrate the KMAC interface into the OTBN #30384

Merged

etterli force-pushed the otbn-rtl-kmac-if branch 2 times, most recently from 10b4d80 to 8b5d864 Compare June 15, 2026 09:36

etterli requested a review from vogelpi June 15, 2026 09:58

[otbn,rtl] Implement the KMAC interface on OTBN

5299174

Signed-off-by: Pascal Etterli <pascal.etterli@lowrisc.org>

etterli force-pushed the otbn-rtl-kmac-if branch from 8b5d864 to 5299174 Compare June 15, 2026 13:58

etterli marked this pull request as ready for review June 15, 2026 13:59

vogelpi approved these changes Jun 16, 2026

View reviewed changes

vogelpi added the CI:Rerun Rerun failed CI jobs label Jun 16, 2026

github-actions Bot removed the CI:Rerun Rerun failed CI jobs label Jun 16, 2026

nasahlpa added this pull request to the merge queue Jun 16, 2026

Merged via the queue into lowRISC:master with commit 0c4e476 Jun 16, 2026
43 of 47 checks passed

		// Extract command from write.
		assign current_cmd = ispr_kmac_ctrl_w.cmd & {$bits(kmac_cmd_t){ispr_kmac_ctrl_wr_i}};

		// TODO: Do we need integrity or any other duplication? We could duplicate the config and then
		// send the config on both data share signals.

		// TODO: Do we need integrity?
		assign ispr_kmac_strb_rdata_o = kmac_strb_q;

Uh oh!

Conversation

etterli commented Jun 3, 2026

Uh oh!

etterli commented Jun 4, 2026

Uh oh!

etterli Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etterli Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vogelpi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

etterli left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

vogelpi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etterli commented Jun 10, 2026

Uh oh!

vogelpi left a comment

Choose a reason for hiding this comment

Uh oh!

nasahlpa left a comment

Choose a reason for hiding this comment

Uh oh!

etterli left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

etterli Jun 4, 2026 •

edited

Loading

etterli Jun 10, 2026 •

edited

Loading

etterli left a comment •

edited

Loading