Skip to content
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

Misuse-resistance audit (nucypher-ts <> nc/nc) #152

Closed
jMyles opened this issue Jan 12, 2023 · 2 comments
Closed

Misuse-resistance audit (nucypher-ts <> nc/nc) #152

jMyles opened this issue Jan 12, 2023 · 2 comments
Assignees

Comments

@jMyles
Copy link

jMyles commented Jan 12, 2023

No description provided.

@jMyles jMyles changed the title Misuse-resistance audit (nucypher-ts <> nc/nc) & fixes Misuse-resistance audit (nucypher-ts <> nc/nc) Jan 12, 2023
@jMyles
Copy link
Author

jMyles commented Jan 25, 2023

OK, @theref and I had two fairly hard-hitting calls-and-walkthroughs on this topic. We have identified each secret requiring custody, given the protocol possibilities we have discussed, in this codebase in particular (ie, with passing recognition only, at most, to Ursula's secrets). We tried to consider protocol possibilities that have been seriously discussed but not yet finalized (ie, Enrico signing the Condition set), but to exclude those discussed only briefly or not discussed at all.

The primary outcome is with respect to the issues linked below; either opened during the course of this investigation or, during it, understood as having an impact on misuse resistance.

The secondary goal was (and secondary achievement is) to explore this codebase with enough inquiry into the matter of where and how these secrets are actually handled (or will be handled) to be able to discuss the matter intelligently with @piotr-roslaniec (which joined us for a little bit of our second call - thanks man :-) ). @KPrasch also offered storms of brain as this call wound down.


The following are notes I scratched during the second call, marked where appropriate with issues that we've subsequently opened:

'''

  • Do (we want it to be the case that) conditions get signed?
    -- Condition signature attestation possibilities:
    --- Bob says, "See? The access I was granted was legitimate, given these conditions - see for yourself."
    --- Ursula says, "I applied the conditions as they were written - see the signature here."

  • At reencryption time: Ursula can sign (perhaps toggleable by Enrico or Alice) a message containing:
    -- Bob address (if available)
    -- Conditions
    -- CFrag
    -- Latest block hash

(Note after-the-fact: we discussed these four as a kit representing a sort of next-generation HRAC, providing a potential vector for authentication not of "what" of the payload shared with Bob, but of the "how" - seems possibly useful in metaverse contexts or something?)

-- EverymanManBob decrypting material is not secret; needs to be marked as such ( #159)

'''

Does Bob need an additional secret in order to access the Conditions, for local verification?

#56 (comment)


How does Alice adhere the conditions? Is a secret needed?

nucypher/nucypher#3050

@jMyles
Copy link
Author

jMyles commented Jan 30, 2023

I believe that the comment above now represents comprehension as of the current ref. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Completed
Development

No branches or pull requests

1 participant