SHA256 for nRF54L15 by WilliamTakeshi · Pull Request #9 · lake-rs/embedded-cal

WilliamTakeshi · 2025-12-01T10:16:14Z

This PR introduces hardware-accelerated SHA-256 for the nRF54L15.

The implementation still contains some duplication and a few magic numbers because it was translated from the vendor’s C code, and the CRACEN documentation appears to be incomplete.

There is also room for improvement in the “oneshot” API. Doing directly with less copying.

For testing, I added default-members so that cargo test at the workspace root does not attempt to run the nRF54L15 example. Is this the correct approach? I might need to check how other projects handle chip-specific code.

Let me know if you need explanations about any part of the code. It was really hard to understand and adapt from the C examples.

malishav

This all looks very nice, congrats! A left a couple of clarifying questions inline, mainly for my understanding.

Cargo.lock

embedded-cal-nrf54l15/Cargo.toml

malishav · 2025-12-05T14:48:12Z

embedded-cal-nrf54l15/memory.x

+MEMORY
+{
+  FLASH : ORIGIN = 0x00000000, LENGTH = 1524K
+  RAM : ORIGIN = 0x20000000, LENGTH = 128K


At https://www.nordicsemi.com/Products/nRF54L15, I see 1.5 MB flash, but there seems to be 256 kB of RAM. Why have 128 kB as length here?

Fixed here!
ac7b381

But I have a question. The nRF54L15 has 2 cores, the app-core and the flpr-core (link). By using the whole memory.x on the app-core, we will be locking the library users to only use the app-core?

embedded-cal-nrf54l15/src/lib.rs

malishav · 2025-12-05T14:56:23Z

embedded-cal-nrf54l15/src/lib.rs

+    (group_end | DMA_REALIGN) as u32
+}
+
+fn sha256_padding(msg_len: usize, out: &mut [u8; 128]) -> usize {


Padding needs to be done in software only?

That's a good question that can go back to the API.

Apparently, the hardware accelerator does SHA256 but only of full blocks. (So we need a) this padding, and b) block spooling).

Maybe a takeaway from both is to offer a low-level block-only hashing, which the formally-verified part would build on and do the buffering and finalization?

Tracked in #12. Until that is resolved, I think we can leave the code in here, maybe with a remark that it is to be removed, referencing #12.

When that is done, a lot of code here can go out, also out of the struct (removing the block, processed_bytes and block_bytes_used).

malishav · 2025-12-05T15:03:16Z

embedded-cal-nrf54l15/src/lib.rs

+        let next_full_boundary = total & !(BLOCK_SIZE - 1); // round down to nearest multiple of BLOCK_SIZE
+        let bytes_from_data = next_full_boundary.saturating_sub(instance.block_bytes_used);
+
+        let dma = self.p.global_cracencore_s.cryptmstrdma();


I understand that this line only instantiates a struct, could you confirm?

No, it just take a handler to the CRACEN CryptoMaster DMA. It is a zero-cost and probably it disappear on the compilation.

Its just to make it easier to read, instead of having :
self.p.global_cracencore_s.cryptmstrdma().fetchaddrlsb().write(|w| unsafe { w.bits(descriptors.first() as u32) });
we have
dma.fetchaddrlsb().write(|w| unsafe { w.bits(descriptors.first() as u32) });

which is slightly easier to read

chrysn

Thanks; some initial comments.

embedded-cal-nrf54l15/src/lib.rs

embedded-cal-nrf54l15/Cargo.toml

embedded-cal-nrf54l15/src/lib.rs

chrysn · 2025-12-10T13:05:55Z

embedded-cal-nrf54l15/src/lib.rs

+    (group_end | DMA_REALIGN) as u32
+}
+
+fn sha256_padding(msg_len: usize, out: &mut [u8; 128]) -> usize {


That's a good question that can go back to the API.

Apparently, the hardware accelerator does SHA256 but only of full blocks. (So we need a) this padding, and b) block spooling).

Maybe a takeaway from both is to offer a low-level block-only hashing, which the formally-verified part would build on and do the buffering and finalization?

Tracked in #12. Until that is resolved, I think we can leave the code in here, maybe with a remark that it is to be removed, referencing #12.

When that is done, a lot of code here can go out, also out of the struct (removing the block, processed_bytes and block_bytes_used).

embedded-cal-nrf54l15/src/lib.rs

chrysn · 2025-12-10T13:18:55Z

embedded-cal-nrf54l15/src/lib.rs

+        let mut data_desc = Descriptor::empty();
+        let mut padding_desc = Descriptor::empty();
+
+        match instance.state {


That looks familiar from above. Can't the padding data be created, sent into self.update(), with an assertion that (by construction of the padding) there is no data left in the buffer after it?

I dont fully get this one. But I rewrote using DescriptorChain, I think its better documented this way. lmk if still have questions

The issue (that AIU still persists) is that there is a large amount of duplication between the update and the finish function. This would be way more readable and less prone to editing errors if some of that update/finish code were refactored into (non-trait) methods that are then used commonly between update and finalize.

Oh, now I get it. I refactored one execute_cryptomaster_dma here: 3af1f96

testvectors/src/tv.rs

Co-authored-by: chrysn <chrysn@fsfe.org>

The -10 value and associated commented-on trouble was for *selecting KDF algorithms*, not for selecting hash algorithms, which do have proper numbers. See-Also: #9 (comment)

malishav · 2025-12-18T09:39:14Z

embedded-cal-nrf54l15/src/lib.rs

+    // https://www.rfc-editor.org/rfc/rfc9054.html#name-sha-2-hash-algorithms
+    fn from_cose_number(number: impl Into<i128>) -> Option<Self> {
+        match number.into() {
+            -10 => Some(HashAlgorithm::Sha256),


I'm confused, where does -10 come from? I am looking at https://www.iana.org/assignments/cose/cose.xhtml

That was my mistake from mixing up SHA256 with HKDF based on SHA256; this was already discussed (and presumably fixed?) in #9 (comment).

Yes, just merged with recent main (do we prefer merges or rebases?) and fixed on 192920d

The -10 value and associated commented-on trouble was for *selecting KDF algorithms*, not for selecting hash algorithms, which do have proper numbers. See-Also: lake-rs#9 (comment)

WilliamTakeshi added 11 commits November 27, 2025 17:21

Feat: add defmt_test example

7065b10

chore: make testvector no_std so we can use on nrf54l15

f3d602f

feat: add sha256 for nrf54l15

b259f87

feat: real incrementing api

d5fbb8b

chore: change the logic from block_bytes_left to block_bytes_used

82c3e7d

clippy suggestions

aebe560

chore: remove embedded-cal-nrf54l15 from ci tests

e4f1e85

fix: bug where state was updated more than once

751bdf1

feat: more testvectors for sha256

3dbafbb

feat: add descriptorchain idea to simplify the code

3a085c2

chore: move descriptor and descriptorchain to its own file

b8817e8

malishav reviewed Dec 5, 2025

View reviewed changes

WilliamTakeshi added 5 commits December 6, 2025 14:09

feat: add verify on flash cmd

7471dc6

chore: start working on sha512

2c6b454

feat: add test state so they can share the same cal obj

e0bcfa2

feat: add support to sha512

08855d5

feat: add support to sha384 on nrf54l15

977f4ec

chrysn mentioned this pull request Dec 10, 2025

Update architecture: SHA256 also has not-a-full-algorithm building blocks #12

Open

3 tasks

chrysn reviewed Dec 10, 2025

View reviewed changes

WilliamTakeshi and others added 8 commits December 14, 2025 06:53

chore: add comment on HashAlgorithm

2de0a9f

Co-authored-by: chrysn <chrysn@fsfe.org>

chore: remove cargo.lock

9b8c4e6

chore: remove not needed dependencies, move then to dev-dependencies

107489c

chore: make descriptor and descriptor chain pub(crate)

83ce3b2

chore: compile time checks for BLOCK_SIZE

19e6611

chore: add to do comment on peripherals ownership

76f6492

fix: memory.x values

ac7b381

chore: some documentation on descriptors

f69ba3b

chrysn added a commit that referenced this pull request Dec 15, 2025

COSE: Fix hash algorithm numbers

1396d9c

The -10 value and associated commented-on trouble was for *selecting KDF algorithms*, not for selecting hash algorithms, which do have proper numbers. See-Also: #9 (comment)

This was referenced Dec 15, 2025

COSE: Fix hash algorithm numbers #14

Merged

hash: Add block-only algorithm constructor #16

Open

WilliamTakeshi added 5 commits December 16, 2025 17:35

fix: off by one error

ebf0973

improv: reduce the number of peripherals used on nrf54

ae5c31d

improv: remove pub(crates) when not needed

4c7c0b6

chore: dont repeat execute_cryptomaster_dma

3af1f96

doc: add disclaimer about NIST testvectors

3770858

WilliamTakeshi requested review from chrysn and malishav December 18, 2025 08:37

malishav reviewed Dec 18, 2025

View reviewed changes

chrysn and others added 7 commits December 18, 2025 12:50

Link to COSE Algorithms registry in .from_cose_number()

f12e61b

Architecture: Align with implementation progress

93a74d0

Clarifications from Jonas's chat questions

1e6c87d

Architecture: point to issue

de6b0e3

COSE: Fix hash algorithm numbers

675b81f

The -10 value and associated commented-on trouble was for *selecting KDF algorithms*, not for selecting hash algorithms, which do have proper numbers. See-Also: lake-rs#9 (comment)

Reference architecture choices in code documentation

99c5a5c

fix: cose hash256 value

192920d

WilliamTakeshi self-assigned this Dec 22, 2025

chore: use embassy nrf pac

7d88fbd

WilliamTakeshi closed this Feb 10, 2026

Conversation

WilliamTakeshi commented Dec 1, 2025

Uh oh!

malishav 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!

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!

chrysn left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants