cryptimeleon / predenc Goto Github PK

Currently, the Github actions Java CI always uses the composite build script to build and test. On release branches such as main, we should instead build using the dependencies hosted on Maven Central. This also applies to the other projects.

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

Original Text (Issue 80)

Currently, we only offer ABE and IBE (and fuzzy IBE) in our predicate-encryption interfaces.
Let's put our APIs to good use and expand this. I propose to add (some of) the following scheme types to our library:

• Hierarchical identity-based encryption (kInd and cInd are sequences of something, predicate is prefix).
• http://eprint.iacr.org/2009/385.pdf (todo: ask Gennadij whether this is THE state-of-the-art construction)
• Broadcast encryption (kInd is an identity, cInd is a set of identities, predicate is inclusion).
• https://eprint.iacr.org/2012/216.pdf (todo: ask Gennadij whether this is THE state-of-the-art construction)

What may also be interesting to add is:

• Some dynamically secure ABE (all our currently implemented constructions are only selectively secure). -> Lewko.
• PE for finite automata. (probably somewhat more work, but cool).

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

Original Text (Issue 56)

Many ABE constructions use the Waters Hash function to obtain security in the standard model. The Waters Hash function requires multi-exponentiation in G1 or G2 and is potentially expensive. This issue proposes to make the Hash function interchangeable in the schemes, thus enabling efficient construction in the RO model.

This issue is related to issue 52 because the proposal is to model Waters Hash function as one possible implementation of the interface HashIntoStructure.

Comment by Peter Günther

I implemented Waters Hash function as one possible implementation of HashIntoStrcuture (see also commit https://git.cs.uni-paderborn.de/ag-bloemer/sis/-/commit/63189866e5b28ff4fd69e0ecdc71526c7dc85705). Then, different hash functions can be instantiated. I guess it should be possible to give a generic proof that a scheme S that is secure with Waters hash function in the standard model is also secure in the RO model. Hence, in the RO model that models the complete Hash function into G1 or G2 the schemes should be secure.

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

Original Text (Issue 202)

also applies to full ident kem

(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.

The script then does not correctly checkout develop in all cases. Instead it will try to checkout the branch corresponding to the branch name of the repository that is currently being built. Already fixed this for Groupsig, but this issue serves as a reminder.

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

Original Text (Issue 79)

Yamada CCA construction was until 5th of September implemented, but only with the old PG API.
We want a generic implementation for all ABE constructions using the new API.

Comment by Fabian Eidens

This generic construction would give us CCA secure ABE from our CPA ABE schemes.

For details see https://git.cs.uni-paderborn.de/ag-bloemer/sis/uploads/a4ebdb9551b0e9277d8f2963a885cb53/FaEi_Presentation.pdf and https://git.cs.uni-paderborn.de/ag-bloemer/sis/uploads/72ab735fec5337419e3f391395f675f2/yamada_cca_waters.pdf and talk to me.

The math dependency is not necessary as craco already designates its own math dependency as an api dependency (and thus exports its api). The craco dependency should be marked as api dependency as otherwise the craco classes cannot be accessed when using predenc. This would then also make the math api accessible when using predenc

This means that currently, classes such as EncryptionKey are not available when just using predenc. This is bad since all classes that are part of the predenc API should also be accessible by predenc users.

Also, the javadoc linking that is part of the javadocLatex task should only be done for release versions as online versions of math's and craco's javadoc can only be guaranteed to exist for those.

As this induces an API change (but a backwards-compatible one), this would increase the MINOR version number.

The readme is currently very bare bones. We should include information about this library, its purpose, and which schemes it implements.

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

Note: This scheme is not in Predenc anymore. I guess it was never implemented?

Original Text (Issue 142)

ATM this commit introduced a refactored version of the DistributedFuzzyScheme from the old PG. Unfortunately, I cannot find the bug that causes this whole scheme to fail. I did several code reviews and compared it to the paper. Somehow the Lagrange-Interpolation in the encrption(!) fails. This means that either the KeyShares are incorrect, or the test of the validity of the KeyShares in the encrypt method fails (this is unlikely since the EncryptionSchemeTest fails even if the KeyShare validity test is not performed). Since I unfortunately do not have the theoretical background knowledge to understand where my implementation differs from the paper either [at]feidens or [at]jbobolz should check this implementation (A good starting point would be to check if the scheme has a correct setup in the DistributedFuzzyParams class).

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

Original Text (Issue 52)

This should be done after the keys (public parameters, public key, private keys) are representable. More specific, they should be decoupled and implemented as separated classes. Then they should know how to represent themselves.

Comments

Refer to the original issue for comments.

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

Original Text (Issue 180)

Some of the examples are not suitable anymore, e.g. hybrid kem should be removed and new kem implementations should be presented.

Additionally, consider to add more examples and check the existing.

Comment by Fabian Eidens

What do you want to do with the examples?

Comment by Denis Diemert

decided to exclude the examples for the first publish