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

Implement generic Fujisaki-Okamoto transform #63

Open
rheitjoh opened this issue Apr 7, 2021 · 1 comment
Open

Implement generic Fujisaki-Okamoto transform #63

rheitjoh opened this issue Apr 7, 2021 · 1 comment
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 65)

As discussed with Gennadij just now, we can implement Fujisaki-Okamoto ("fo") transform in a blackbox way.

Some thoughts:

  • Some of this is already implemented somewhat generically (according to Fabian) in the .fo-package schemes
  • We need to give a warning in Javadoc: applying fo on schemes other than standard encryption does not necessarily result in anything secure (Gennadij said he may want to prove that for predicate encryption, though, which would immediately handle ABE, etc.)
  • We should probably add a new interface that fo-compatible schemes can implement
  • Ensures only schemes that are secure afterwards can be run through the transform
  • Adds methods to encrypt with given randomness (or random group elements as additional input)
  • The fo class itself should be parameterized with
  • a symmetric and a (ABE/IBE/vanilla/...) asymmetric encryption scheme (with interface above)
  • a hash function to derive randomness for the asymmetric scheme
  • a key derivation function for the symmetric scheme
  • Implementations should probably extend the fo class. We can again do this generically for every kind of scheme (ABE/IBE/vanilla encryption...)
  • Open problem: how to fo-encrypt/decrypt in JCA? If the asymmetric encryption is at the end of the ciphertext stream, decryption is impossible without looking at the end of the stream first. The other way around is impossible for encryption. Overall, this stream model is difficult. Buffering is a simple fix, but obviously not incredibly elegant.

After this is done, there will be no need for the individual .fo packages anymore.

@rheitjoh rheitjoh added the Gitlab Old issue moved over from Gitlab repository label Apr 7, 2021
@rheitjoh
Copy link
Member Author

rheitjoh commented Apr 7, 2021

We already have an Elgamal FOT Kem, but that is probably not generic in the sense of this issue?

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