-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ACP/ThresholdMessageKit Work #74
Conversation
…ldDecryptionRequest. Requires changes to DkgPublicKey in ferveo.
Codecov Report
@@ Coverage Diff @@
## main #74 +/- ##
==========================================
+ Coverage 21.22% 23.38% +2.16%
==========================================
Files 16 18 +2
Lines 3176 3540 +364
==========================================
+ Hits 674 828 +154
- Misses 2502 2712 +210
|
…olicy to "acp"; also rename accessor method.
nucypher-core/src/versioning.rs
Outdated
/// | ||
/// NOTE: Underlying struct members for types that must remain backwards compatible should | ||
/// also remain backwards compatible as well. | ||
fn must_remain_backwards_compatible() -> (bool, u16) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that is the solution for smooth switching from development to the production version?
Not sure how I feel about it. Seems kind of brittle. Maybe just a different type would be the way to go. You'd have to do some additional work when switching to production, but that would solidify the commitment, so to speak. The new type may still save/check the last development major version in the serialized form, to allow the usage of objects created during development, but I'm not sure how much the convenience here outweighs the safety. Perhaps it is better to force the devs to start the production objects from a clean slate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's muse more about this in #75.
I think it might be better to extract the permanent-support objects into a separate PR, because it's pretty important and shouldn't be mixed up with the rest of the stuff that's going on here. |
…ing use/exposure of key encapsulation i.e. use of CiphertextHader, and rework of Ciphertext.
Removed the functionality from this PR and moved to #75. |
…ta object which works around to chicken and egg issue for obtaining the aad to use when encrypting data, but which is needed for the AccessControlPolicy after the ciphertext is signed. Update bindings/tests.
… can be returned from the same call. Added python/wasm bindings.
…xt object purely to get the CiphertextHeader. Add decrypt_with_shared_secret to ThresholdMessageKit so that to decrypt data, the ciphertext does not need to be returned to python/js from Rust and then passed back in to Rust to decrypt. Keep it in Rust and just do the decryption internally.
@final | ||
class AuthenticatedData: | ||
|
||
def __init__(self, public_key: DkgPublicKey, conditions: Optional[Conditions]): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@derekpierre I just recalled your comment on Optional<&Condition>
in DKG structures. Are conditions supposed to be optional here? Or is it just downstream of that optionality in the DKG structures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is downstream.
This is something that came to me last night, but it pervades many types in nucypher-core
(ThresholdDecryptionRequest, ... etc.) and I didn't have time to fix it across all of them. I think we should fix it in a separate PR. Basically for DKG types Conditions should not be Optional but should be specified. Hence I filed #76 .
// | ||
#[wasm_bindgen] | ||
#[derive(PartialEq, Eq, Debug, derive_more::From, derive_more::AsRef)] | ||
pub struct ThresholdMessageKit(nucypher_core::ThresholdMessageKit); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed that in some places in nucypher-core
, we're using { backend: InnerType }
and (InnerType)
in others. Perhaps we could settle on one way to define structs. It's not relevant to this PR, just a general comment on style
@@ -699,14 +699,23 @@ fn threshold_decryption_request() { | |||
let context: JsValue = Some(Context::new("{'user': 'context'}")).into(); | |||
|
|||
let dkg_pk = DkgPublicKey::random(); | |||
|
|||
let auth_data = | |||
AuthenticatedData::new(&dkg_pk, &conditions_js.unchecked_into::<OptionConditions>()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using unchecked_into
is type-unsafe, but it's fine here because it's a test
pub fn aad(&self) -> Box<[u8]> { | ||
let public_key_bytes = self.public_key.to_bytes().unwrap(); | ||
let condition_bytes = self.conditions.as_ref().unwrap().as_ref().as_bytes(); | ||
let mut result = Vec::with_capacity(public_key_bytes.len() + condition_bytes.len()); | ||
result.extend(public_key_bytes); | ||
result.extend(condition_bytes); | ||
result.into_boxed_slice() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm tempted to suggest this functional approach
pub fn aad(&self) -> Box<[u8]> { | |
let public_key_bytes = self.public_key.to_bytes().unwrap(); | |
let condition_bytes = self.conditions.as_ref().unwrap().as_ref().as_bytes(); | |
let mut result = Vec::with_capacity(public_key_bytes.len() + condition_bytes.len()); | |
result.extend(public_key_bytes); | |
result.extend(condition_bytes); | |
result.into_boxed_slice() | |
} | |
pub fn aad(&self) -> Result<Box<[u8]>, Error> { | |
Ok([ | |
self.public_key.to_bytes()?, | |
self.conditions.as_ref().map(|c| c.to_bytes()).unwrap_or_else(|| Ok(vec![]))?, | |
] | |
.concat() | |
.into_boxed_slice()) | |
} |
Is there a good reason to unwrap()
(and hence, panic) here? I take that we should always expect conditions to be present here (per discussion on optionality in DKG).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@piotr-roslaniec Can you take care of this change for me - either as part of this PR or a follow-up 🙏 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can address any non-critical changes in a follow-up PR. I can take care of that once I test this PR with nucypher-ts
.
} | ||
} | ||
|
||
impl Eq for AuthenticatedData {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we #[derive(Eq)]
on AuthenticatedData
instead? I assume there is a reason for deriving Eq
in this particular way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may have mistakenly thought that you have to do this if you implemented PartialEq
. Was that mistaken? In any case, it's not a blocker right...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#[derive(Eq)]
is an automatic way to impl Eq ...
, so these are equivalent. I was just curious if there was a reason to specifically implement an empty impl Eq {}
instead of deriving.
It's not a blocker, we can address it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While working on #77 I realized that automatic derivation of Eq
is not possible since DkgPublicKey
from ferveo
doesn't implement it either.
So it makes sense to provide an implementation stub impl Eq {}
as a workaround. We need Eq
do implement ProtocolObjectInner
for AccessControlPolicy
. Tracking this here: nucypher/ferveo#157
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a solid piece of work.
I have some comments, mostly nitpicks. AFAIK this is functionally correct.
I'm not approving yet because I want to test these changes in nucypher-ts
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just did a first read. Looks good on first read. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Successfully tested in nucypher/taco-web#273
Type of PR:
Required reviews:
What this does:
Issues fixed/closed:
Depends on nucypher/ferveo#156
Related to nucypher/nucypher#3194
Why it's needed:
Notes for reviewers: