Future of the Representation framework for high-level constructions

[JanBobolz]

I feel like the fact that implementors have to implement serialization by hand is somewhat bothersome. While it has improved a lot over the years (and the necessary boilerplate code has been reduced a lot), Representations may still pose our most significant barrier to entry.

So one of the main use-cases for our library is fast prototyping of schemes. The end result is not production-grade secure anyway, so why force people to manually write a serialization format whose main purpose is to offer security through safe deserialization?

I want to collect ideas how to further lessen or remove the overhead represented by the Representation framework for high-level constructions (I'm more fine with Representations being a thing for mid or low level primitives).

Rough initial thoughts:

• Enable/advertise Java's built-in serialization
  • Con: serializations are probably incredibly large. Maybe we can hook into the framework and blend it with Representation stuff?
• Change APIs to make serialization capabilities more optional.
• Come up with even more automation for serialization.
  • We can probably decide via static type what object to use deserialize in 99% of cases. How many EncryptionSchemes can possibly be involved in the current context? For this, maybe we'd have to introduce new interfaces G1,G2,GT or something.

[JanBobolz]

What would also be cool would be a more compact serialization format. Currently, it's probably hard to "fairly" measure the size of messages in a protocol because, for example, the format contains a bunch of unnecessary strings constants. It makes "x KiB sender payload" statistics useless. It's probably not that bad anymore with the more efficient byte string converter, but ... still. I don't know. It would be cool if we could sell "here you can generate great numbers for not only time, but also communication performance".

[rheitjoh]

• Change APIs to make serialization capabilities more optional.

I feel like, if possible, removing all the Representable and StandaloneRepresentable from interfaces would already be a good idea. Having to implement all that serialization when you don't need it is certainly annoying. I don't immediately see a problem with removing those interface implements. Looking at for example our ElGamal implementation, we can just have ElgamalCipherText implement Representable directly if we want serialization support.

Keeping RepresentationRestorer seems fine as you can always just ignore those restoreX methods or throw an UnsupportedOperationException (and I wouldn't want the user to implement that interface themselves).

[feidens]

Regarding the 3rd idea "Come up with even more automation for serialization." there the annotations for the member variables would still be necessary? In general, could you please explain the 3rd option in more detail.

[JanBobolz]

I don't know what this would look like. It's just a rough direction for how this could conceivably be fixed. So no. I can't explain right now.

Potentially no need for annotations, if the static java type is "verbose" enough. Maybe just an annotation to denote "this should be part of serialization, this shouldn't", not "this should be deserialized with these restorers".

[JanBobolz]

@rheitjoh I feel like even if we remove Representable from the interfaces, you're still forced to implement it, e.g., for benchmarking and to make your application work at all. You can somewhat delay having to implement it, but it will eventually have to be done, no?

Downside of removing Representable from interfaces: lots of typecasting when using those clases.