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

Rouselakis-Waters ABE #14

Open
rheitjoh opened this issue Apr 7, 2021 · 0 comments
Open

Rouselakis-Waters ABE #14

rheitjoh opened this issue Apr 7, 2021 · 0 comments
Labels
Gitlab Old issue moved over from Gitlab repository

Comments

@rheitjoh
Copy link
Member

rheitjoh commented Apr 7, 2021

(This issue has been imported from the Gitlab repository because it seems to not have been addressed yet)

Original Text (Issue 81)

This ticket proposes adding the Rouselakis-Waters ABE scheme(s) (and/or variants) to the library.

Gennadij advises roughly the following workflow:

  • Implement Rouselakis-Waters: CPA-secure; large universe; (1) ciphertext policy and (2) key policy.
  • Add the option to replace Waters' hash with SHA-i (i>1).
  • Use Yamada (#79) to make the constructions CCA secure.
  • Use Gennadij's transformation to make the constructions CCA secure.

Peter's requirements (considering the SFC project):

  • Ciphertext Policy (Must have), KP optional
  • (R)-CCA secure (replayable CCA)
  • KEM (encryption itself optional)
  • Option: Random oracle hash function.
  • Multi Authority
    • Version 1: Each authority has a certain set of attributes it can issue. Attributes from several authorities can be (conceptually) merged.
      • That paper has a pretty weak security model ("static"): all queries need to be fixed by the adversary before seeing the public parameters. (What does CCA actually give us in this scenario?).
      • Any extensions will be in this weak model.
      • For n=1 (one authority), it's (probably) not the same as the "normal" single-authority version of Rouselakis-Waters (according to Nils) because n=1 does not seem to magically make the multi-authority scheme secure in the normal security model. (They need to fix their public parameters according to the queries, otherwise they cannot answer them correctly).
    • Version 2: k out of n authorities need to come together to issue any set of attributes.
      • Functionally weaker (no restrictions as to what authorities can issue), but better security. Does the SFC scenario require Version 1 semantics?
      • For n=1, it's quite obviously the same as the single-authority version of Rouselakis-Waters.
  • Combined with delegation of pairing computation (Waters, Peter's Oberseminar)
    • Careful: CCA security model for PKE too? (i.e. not ElGamal but some CCA-secure scheme?)

Comment by Jan Bobolz

Update: Nils found a Lewko construction for semantics "version 1" that does not seem to be in this weak model. He'll look into it.

Comment by Peter Günther

Will Gennadij's proposal cover multi authority?

Comment by Jan Bobolz

Will Gennadij's proposal cover multi authority?

Version 2 (k out of n authorities have to come together to issue a key), yes. Not explicitly planned right now but that's going to be an easy extension when the scheme is implemented.

@rheitjoh rheitjoh added the Gitlab Old issue moved over from Gitlab repository label Apr 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Gitlab Old issue moved over from Gitlab repository
Projects
None yet
Development

No branches or pull requests

1 participant