Port shared secret encryption from nucypher-core #646

Muhammad-Altabba · 2025-04-09T18:06:52Z

Type of PR:

Bugfix
Feature
Documentation
Other

Required reviews:

1
2
3

What this does:

It contains ported code for the 2 Rust methods: encrypt_with_shared_secret and decrypt_with_shared_secret.
A compatibility test run against test vectors generated from [WIP] Generate shared secret test vectors nucypher-core#102.

Issues fixed/closed:

Closes part of https://github.com/nucypher/sprints/issues/150. It only covers encrypt/decrypt with shared secret. Subsequent PR is to be opened for the rest of the needed functions.

netlify · 2025-04-09T18:07:16Z

✅ Deploy Preview for taco-demo ready!

Name	Link
🔨 Latest commit	`9093538`
🔍 Latest deploy log	https://app.netlify.com/sites/taco-demo/deploys/67f6b73fa192f70008527a10
😎 Deploy Preview	https://deploy-preview-646--taco-demo.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

netlify · 2025-04-09T18:07:19Z

✅ Deploy Preview for taco-nft-demo ready!

Name	Link
🔨 Latest commit	`9093538`
🔍 Latest deploy log	https://app.netlify.com/sites/taco-nft-demo/deploys/67f6b73f9c5a5000083dab1b
😎 Deploy Preview	https://deploy-preview-646--taco-nft-demo.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

+ prettifying 2 other files

…rated json test vectors

packages/shared/src/encryption/shared-secret.ts

packages/shared/test/fixtures/shared-secret-vectors.json

derekpierre · 2025-04-15T13:19:58Z

packages/shared/test/fixtures/shared-secret-vectors.json

@@ -0,0 +1,235 @@
+{
+  "test_vectors": [


I noticed the fixed nonce, specific shared secret - does it make sense to also have more random values in the test vector? Or is that something planned for later in the process?

The values are randomly generated at the Rust code and fed as constants to the compatibility tests. For values that are randomly generated in this project, there is the unit test in the other file.

The values are randomly generated at the Rust code and fed as constants to the compatibility tests.

Perhaps I'm misunderstanding. The values for the nonce, shared secret don't seem that "random"...? In one case the nonce is just 0s or 1s and the shared secret is just ints 0-31...?

Yeah, sorry my bad. I forgot that I updated this in Rust. Yes, the values are fixed. But since the values does not have special numerical meanings, in relation to the algorithm, they are still counted as random (or you may say simi-random).
However, we can generate different values every time. But it will make debugging harder in case of an issue.

Hey @cygnusv, Could you please, provide your input if testing with new random values is needed for this cryptography validation.

Yes, the values are fixed.

Just to clarify: the test vectors should still contain specific values, but I expected each vector in the generated file to use different values for completeness. These values would originally have been generated randomly or pseudo-randomly.

For example, to generate the test vector file, you could use a fixed seed. Then, using that seed, you can deterministically generate pseudo-random nonces, shared secrets, etc., rather than reusing the same values or incrementing bytes only sequentially.

The seed approach ensures that the same file is generated every time (due to the fixed seed), but each test vector contains distinct, realistic inputs like unique nonces and shared secrets. This avoids test vectors that only differ trivially (e.g. same nonce in every case), which could miss edge cases or failures.

Actually, in all cases, the typescript tests should run on any provided data in this json 😄 . So, whatever will be generated from nucypher-core, should be usable here regardless of what the values are.

Yep. I'm referring to the strategy used in the code that generated the test vectors from nucypher-core.

Would like continue this the conversation about the generated test vectors at nucypher/nucypher-core#105.
Thanks,

Sorry for being a bit late to the discussion. I've been following along while working on nucypher/nucypher-core#105 and I changed my mind a few times during this process. The production and consumption of test vectors are a bit more complicated than expected due to how our internal protocol objects work, since in some cases serialization/deserialization is more difficult or not possible without adding code. I'm still iterating a proper method for producing test vectors in my PR, but on the PRs in taco-web we should strive to consume test vectors without resorting to duplicated implementations.

With respect to the specific issue discussed here, the test vector ideally should be generated in a 100% deterministic way (i.e. using a seed). However, there's nothing wrong about adding some hard-coded, obviously not random examples, like [1, 1, 1, .....1].

packages/shared/test/shared-secret-compatibility.test.ts

derekpierre · 2025-04-15T13:56:15Z

packages/shared/test/shared-secret.test.ts

+  // Counter to ensure each call generates different values
+  let counter = 0;
+  return {
+    randomBytes: (size: number) => {


For my benefit, could you clarify what this is doing?

This is to mock this function to make it give random but deterministic values (simi-random). Which is to make debugging the tests easy when needed. Because for every run of the tests the same simi-random value will be used.

random but deterministic values (simi-random)

Does the test only work for a specific order of randomness - is there some limitation in the test that requires determinism?

My overall concern is about the test not actually using proper randomness/pseudo-randomness, which is closer to what would occur in the wild. Just trying to understand why encryption/decryption testing needs to use deterministic keys/values...

Similar comment regarding why the shared secret needs to be deterministic (L36-L39)?

Does the test only work for a specific order of randomness - is there some limitation in the test that requires determinism?

No, the tests work with any values and there is no limitations in the tests. This mocking of random value generation can be totally removed and the tests still works great.

My overall concern is about the test not actually using proper randomness/pseudo-randomness, which is closer to what would occur in the wild. Just trying to understand why encryption/decryption testing needs to use deterministic keys/values...

As far as I know, as long as the provided values are not special in relevance to the algorithm they are random and there is no concern about them being generated. The values would be special to the algorithm, if it is for example the algorithm is the raising to the power of 2, and the values are just zeros.

So, as far as I know, having deterministic values is not of any concern. But it still make it easy to debug any issue if it is faced later. Such that every run to the test would have the same inputs.

I think @cygnusv would help us if there is any concern regarding the deterministic values. If yes, the mocking will be just removed.

Thanks all,

No, the tests work with any values and there is no limitations in the tests. This mocking of random value generation can be totally removed and the tests still works great.

If this is the case, then let's just remove the mocking.

So, as far as I know, having deterministic values is not of any concern. But it still make it easy to debug any issue if it is faced later.

Not sure what you mean by debugging (?) - tough to debug ciphertext issues and additionally it's likely any failure would signify an issue with our use of the libraries, and not the underlying crypto since we are simply using existing crypto libraries and not rolling our own crypto.

Such that every run to the test would have the same inputs.

This is exactly what I'm hoping to avoid - that is a very limited test.

My overall mental model for our testing of this "taco-on-mobile" library falls into two key categories (correct me if I’m mistaken):

Rust Interoperability / Test Vector Parity:
We need to verify that the library can correctly match encryption and decryption behaviour with the existing nucypher-core Rust code. These tests rely on fixed test vectors—includes associated shared secrets, nonces, and payloads—to ensure deterministic parity. The goal is to validate that data encrypted/decrypted by the Rust implementation matches what was produced by "taco-on-mobile" library, ensuring compatibility across platforms.
(this covers the deterministic part)

Testing the TACo on Mobile library Itself:
We also need to verify that the "taco-on-mobile" library can properly perform encryption and decryption on data it generates. By using randomly generated shared secrets and nonces, this simulates real-world usage, where inputs are not fixed. These tests should be run with randomized inputs each time they are run (locally or in CI). Of course we are not looking to test the underlying crypto (since those are the underlying libraries we are using), but I do think that us generally using randomness for testing where we can is a good thing.
(this covers the random part - the randomness is fine because encryption/decryption are mirror operations of each other i.e. if the same combination of sharedsecret,nonce is used for both encryption/decryption it should be fine)

This test code seems to be for 2), but is only testing specific input for every run of the test - as opposed to the test using random nonces/shared secrets on every run of the tests (locally, CI etc.). Using random values would be a more robust and complete set of tests that ensures that the code is continuously tested with new inputs every run.

Many thanks @derekpierre for the discussion.
I did more search and I am more now in favor of having deterministic values for the randomness of our tests here. And probably if we are doing the cryptographic library we would keep this simi-random but have additional completely random values that change with every run.

However, since I am not very much into cryptography related stuff, I will leave this to you (@derekpierre) and @cygnusv to recommend.
When I first showed @cygnusv this way of generating the nonce, I think he liked it. But I hope him to provide his input, if it is better for it to be like this, or if not, after he read this discussion.

Thanks all,

…al checks

derekpierre · 2025-04-17T13:17:13Z

packages/shared/test/fixtures/shared-secret-vectors.json

@@ -0,0 +1,235 @@
+{
+  "test_vectors": [


Yep. I'm referring to the strategy used in the code that generated the test vectors from nucypher-core.

derekpierre · 2025-04-17T13:22:13Z

packages/shared/test/shared-secret-compatibility.test.ts

+        const { sharedSecret, plaintext, fixedNonce, expectedCiphertext } =
+          vector;
+
+        if (fixedNonce && sharedSecret) {


Are there cases where this is not true? i.e. do test vectors ever not contain a fixedNonce or sharedSecret value? I'm wondering if we need this if statement.

[Sorry, it should be only checking for fixedNonce. The code is now updated.]
And this is just to give the confidence that even if the test vectors did not contain the nonce (so the encryption of data would not be possible, and the decryption is the only available), the plaintext could be retrieved by decrypting the cipher text.

However, if this case is unnecessary to check, the nucypher/nucypher-core#105 would not generate it and I will remove this if from here 😄 .

packages/shared/test/shared-secret-compatibility.test.ts

derekpierre · 2025-04-17T13:25:56Z

packages/shared/test/shared-secret.test.ts

+  // Counter to ensure each call generates different values
+  let counter = 0;
+  return {
+    randomBytes: (size: number) => {


No, the tests work with any values and there is no limitations in the tests. This mocking of random value generation can be totally removed and the tests still works great.

If this is the case, then let's just remove the mocking.

So, as far as I know, having deterministic values is not of any concern. But it still make it easy to debug any issue if it is faced later.

Not sure what you mean by debugging (?) - tough to debug ciphertext issues and additionally it's likely any failure would signify an issue with our use of the libraries, and not the underlying crypto since we are simply using existing crypto libraries and not rolling our own crypto.

Such that every run to the test would have the same inputs.

This is exactly what I'm hoping to avoid - that is a very limited test.

My overall mental model for our testing of this "taco-on-mobile" library falls into two key categories (correct me if I’m mistaken):

Rust Interoperability / Test Vector Parity:
We need to verify that the library can correctly match encryption and decryption behaviour with the existing nucypher-core Rust code. These tests rely on fixed test vectors—includes associated shared secrets, nonces, and payloads—to ensure deterministic parity. The goal is to validate that data encrypted/decrypted by the Rust implementation matches what was produced by "taco-on-mobile" library, ensuring compatibility across platforms.
(this covers the deterministic part)

Testing the TACo on Mobile library Itself:
We also need to verify that the "taco-on-mobile" library can properly perform encryption and decryption on data it generates. By using randomly generated shared secrets and nonces, this simulates real-world usage, where inputs are not fixed. These tests should be run with randomized inputs each time they are run (locally or in CI). Of course we are not looking to test the underlying crypto (since those are the underlying libraries we are using), but I do think that us generally using randomness for testing where we can is a good thing.
(this covers the random part - the randomness is fine because encryption/decryption are mirror operations of each other i.e. if the same combination of sharedsecret,nonce is used for both encryption/decryption it should be fine)

This test code seems to be for 2), but is only testing specific input for every run of the test - as opposed to the test using random nonces/shared secrets on every run of the tests (locally, CI etc.). Using random values would be a more robust and complete set of tests that ensures that the code is continuously tested with new inputs every run.

packages/shared/test/shared-secret.test.ts

manumonti · 2025-07-29T11:41:59Z

Removing myself as reviewer while this is not ready to be reviewed. Don't hesitate to add me if there is progress on this!

port shared secret encryption from nucypher-core

9093538

Muhammad-Altabba changed the base branch from main to epic-v0.6.x April 9, 2025 18:07

Muhammad-Altabba added 2 commits April 9, 2025 22:13

generate the shared secret test vectors from rust

dfb7647

refactor shared secret compatibility tests mock to work in the CI

acc7bd3

+ prettifying 2 other files

Muhammad-Altabba changed the title ~~[WIP] Port encryption from nucypher-core~~ Port shared secret encryption from nucypher-core Apr 10, 2025

Muhammad-Altabba marked this pull request as ready for review April 10, 2025 13:35

Muhammad-Altabba requested review from cygnusv, derekpierre and manumonti April 10, 2025 13:35

Merge branch 'epic-v0.6.x' into 140-taco-on-mobile-encryption-decryption

2198670

Muhammad-Altabba changed the base branch from epic-v0.6.x to epic-port-nucypher-core-into-ts April 12, 2025 18:54

Muhammad-Altabba added 2 commits April 14, 2025 23:53

update json variables names accrding to new modifications at the gene…

62b9958

…rated json test vectors

add index file at encryption folder

6804223

Muhammad-Altabba mentioned this pull request Apr 15, 2025

[WIP] Port session keys from nucypher core #647

Draft

7 tasks

derekpierre reviewed Apr 15, 2025

View reviewed changes

Muhammad-Altabba added 3 commits April 16, 2025 13:38

set ChaCha20Poly1305 nonce length into a constant

9f0cd82

simplify shared secret test by removing verbose logging and condition…

3961182

…al checks

Refactor test vectors and improve test structure using it.each

0bd45aa

Muhammad-Altabba requested a review from derekpierre April 16, 2025 22:22

derekpierre reviewed Apr 17, 2025

View reviewed changes

tiny edits at shared secret tests in responce to review comments

74e6004

derekpierre marked this pull request as draft July 2, 2025 18:45

manumonti removed their request for review July 29, 2025 11:42

Port shared secret encryption from nucypher-core #646

Are you sure you want to change the base?

Port shared secret encryption from nucypher-core #646

Uh oh!

Conversation

Muhammad-Altabba commented Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify bot commented Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for taco-demo ready!

Uh oh!

netlify bot commented Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for taco-nft-demo ready!

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!

derekpierre Apr 16, 2025 • 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!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

derekpierre Apr 16, 2025 • 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!

Muhammad-Altabba Apr 16, 2025 • 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!

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!

Uh oh!

manumonti commented Jul 29, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Muhammad-Altabba commented Apr 9, 2025 •

edited

Loading

netlify bot commented Apr 9, 2025 •

edited

Loading

netlify bot commented Apr 9, 2025 •

edited

Loading

derekpierre Apr 16, 2025 •

edited

Loading

derekpierre Apr 16, 2025 •

edited

Loading

Muhammad-Altabba Apr 16, 2025 •

edited

Loading