cryptimeleon / craco

CRyptogrAphic COnstructions
Apache License 2.0
11 stars 5 forks source link

Move "layer 3" constructions into their own repositories #30

Closed JanBobolz closed 3 years ago

JanBobolz commented 3 years ago

The goal for this repository is to contain a "layer 2" library, that is: cryptographic schemes that would be considered building blocks (secret sharing, basic signatures, zero-knowledge stuff), but not "layer 3" stuff, which builds upon "layer 2" to construct something more powerful, which itself is not usually considered a building block (e.g., ABE, group signatures, ...).

Taken from our internal discussions, in German:

Also so grob gibt es in der Welt mehrere Ebenen an Krypto - also wenn ich ein Paper bei ePrint sehe, könnte ich sofort einordnen, auf welche Ebene das gehört: Layer 1: Mathematik-Krams (elliptic curves, Lattices) - meist Grundlagenforschung oder so "Sicherheitsparameter"-Krams Layer 2: Basic Building Blocks (PS sigs, SPSEQ, DMS, ZK proof systems) - meist Paper mit Titel der Form "[building block] and applications to [foo]". Layer 3: High level protocols - hat in den Preliminaries eine Definition von "SNARKs" oder MSPs oder PS signatures und PRFs und sonstwas (aus Level 2) stehen und baut daraus iregndein riesiges Monster zusammen, was meist eher praktisch orientiert ist

Concretely, we want to move the following features to new projects that depend on this project:

Unless new arguments against this emerge, this move includes the corresponding interfaces.

rheitjoh commented 3 years ago

I have established two new projects for this: https://github.com/upbcuk/upb.crypto.predenc and https://github.com/upbcuk/upb.crypto.groupsig

There are some dependency problems with moving the ABE Stuff:

The secretsharing package depends on abe.accessStructure.exception.NoSatisfyingSet, abe.accessStructure.exception.WrongAccessStructureException, abe.interfaces.LinearSecretSharing, policy.Policy, policy.PolicyFact and policy.ThresholdPolicy.

Furthermore, the policy package depends on abe.accessStructure.exception.WrongAccessStructureException, interfaces.pe.CiphertextIndex and interfaces.pe.KeyIndex.

We somehow need to disentangle these dependencies since craco should not have a dependency on the predenc project.

Only moving over the schemes themselves could also work here, I would think.

feidens commented 3 years ago

All dependencies of secretsharing that you mention are more related to secretsharing than to abe (attribute-based encryption), because MSP and policy stuff belongs to layer 2. Similar argument can be made for policy and the abe.accessStructure.exception.WrongAccessStructureException.

The dependencies of policy with extends KeyIndex, CiphertextIndex is an interesting one. Removing the extends is not a good idea, because then the subclasses of Policy are no longer useable in the new abe repo predenc. Following the new layer 2 view KeyIndex and CiphertextIndex fits more into layer 2 than 3. Since usually an ABE scheme just uses such things.

rheitjoh commented 3 years ago

I am also moving the ABE and Fuzzy IBE based KEM's to the Predenc project since those obviously use those ABE schemes. Unless we want to create a separate KEM project that depends on Predenc.

feidens commented 3 years ago

I think we can live with the process that someone who wants to use ABE-KEMs has to go to the predenc library.

rheitjoh commented 3 years ago

With #33 predicate encryption schemes have been moved to https://github.com/upbcuk/upb.crypto.predenc and the unfinished group signature code has been moved to https://github.com/upbcuk/upb.crypto.groupsig. The KEM's that rely on predicate encryption schemes have also been moved to Predenc.

The only KEM now still in Craco is the ElGamal KEM based on FOT. That will not be moved.