Open jschneider-bensch opened 1 year ago
I still have problems building the wasm demo of scrambledb on the main branch.
Executing the command
CC=emcc AR=emar wasm-pack build --target web --features wasm
with the latest version of the emsdk toolchain results in the following error
Pinning the libcrux version as mentioned in the thread above or reverting to some (arbitrary) older version of emsdk did not resolve the issue for me.
Anything else I could try?
Thanks for your report on this issue! I'll look into this now.
Thanks, this completely fixes my issues building the project.
Also, why is there a difference in visuals between the current version and the online demo? It does not seems to restrict me in any way, I was just wondering where it came from.
That's good to know, thanks for the update! I've focused on the build issues first, and have not gotten around to making sure everything is consistent with the old demo build.
In particular, I've replaced the demo sample data with much shorter strings since the new re-rerandomizable encryption scheme is quite inefficient.
In more detail, fixing the build issue meant replacing the default dependency on libcrux
in the demo. In ScrambleDB, there is a requirement for a re-randomizable public key encryption scheme. In the original publication, this is the ElGamal PKE on its own, which makes it so data is limited to whatever can be represented as ElGamal plaintexts, i.e. single group elements and in particular not arbitrary length data (since that could not be encoded in a single group element). This is also what is part of the original specification and demo (we do a little sleight of hand behind the scenes to make it seem, for the purpose of the demo, as though we're handling arbitrary length input data, when we're really handling the hash of that data into the group).
The dependency on libcrux
came in to provide an implementation of HPKE, so we can replace purely ElGamal based data encryption with a much more efficient version based on double encryption using HPKE, which can also properly handle arbitrary lenght plaintext data. Unfortunately, this doesn't give exactly the same guarantees as the purely El Gamal version, and can't be easily compiled to WASM, leading to the build issue you ran into.
I wanted to address both the demo build and the insufficiency of the default ElGamal scheme in one go, so I implemented a new ElGamal based scheme, which (quite inefficiently) encodes and decodes between arbitrary length data and vectors of group elements and encrypts / decrypts these vectors component-wise. This way we can compile to WASM and handle arbitrary length data, but it's very inefficient.
_Originally posted by @franziskuskiefer in https://github.com/cryspen/atlas/pull/40#discussion_r1383236974_