feat(Keys): Constrain the encryption in broadcast #6408
Assignees
Comments
Closed
|
This is a duplicate of #1139, with a bit more context on components. |
This was referenced May 15, 2024
LHerskind
added a commit
that referenced
this issue
May 18, 2024
Fixes #5901. Uses the new format to match the keys and logs spec. The current implementation here is still using a typescript implementation to encrypt the data, mainly using the new flow. The intention is that #6408 and #1139 can be addresses separately and than we can just replace the import to use the constrained version instead of the oracle at that point. Note, that the outgoing logs are currently less than meaningful, as some of the infrastructure is not yet in place to handle those nicely, see #6410 for more on that. What was called the encrypted_log_payload in #6348 have been moved into the l1_payload, to better integrate with the rest of the setup.
signorecello
pushed a commit
that referenced
this issue
May 20, 2024
Fixes #5901. Uses the new format to match the keys and logs spec. The current implementation here is still using a typescript implementation to encrypt the data, mainly using the new flow. The intention is that #6408 and #1139 can be addresses separately and than we can just replace the import to use the constrained version instead of the oracle at that point. Note, that the outgoing logs are currently less than meaningful, as some of the infrastructure is not yet in place to handle those nicely, see What was called the encrypted_log_payload in #6348 have been moved into the l1_payload, to better integrate with the rest of the setup.
LHerskind
added a commit
that referenced
this issue
Jun 6, 2024
Fixes #6408. Chans the noir implementation of incoming body slightly to easily fit in with the broadcast format currently in use. Have some todo's in the payload.nr file, mainly to use meaningful outgoing keys #6410 and to use tags when we get to it. For the `eph_sk` also pulling only a Fr while we use it for Fq so we are slightly biased. @iAmMichaelConnor if you got some news on if this is acceptable would be cool 👀. Using the unsafe random atm.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The individual encryption components #5867, #5899 and #5900 is to be tied together such that they can be used like the oracle for the fix of #5901. Should be possible to simply "plug-in" when those 4 are merged.
Note that while we can fully constrain this, we might not have the infrastructure in place for picking a meaningful outgoing logs #6410 which can be handled separately.
The text was updated successfully, but these errors were encountered: