End-To-End Encryption = Client-Side Encryption (Symmetric) - Possible?

I created a PoC Application with CUBA which employs symmetric (Blowfish) encryption on the server side. It was easy to implement via a JPA Attribute Converter. To have at least some End-To-End Encryption, I added an SSL Layer to the server instance.

However, this solution still requires the provider of the server to be trustworthy. As encryption takes place on the server the provider could connect to the server application and spy out passwords through debugging, logging etc.

Because CUBA provides the whole CRUD functionality between client and server, it seems not too easy (from an Application developers point of view) to implement an End-To-End encryption with it. That would require an extra encryption/decryption layer on the client side as a communiction endpoint for the server part of the application. As nowadays security and encryption plays an important role, that would nevertheless be an interesting feature.

Is is possible to provide End-To-End Encryption for a CUBA Application with reasonable effort?

What kind of use case for encryption in an information system do you have in mind?
I can imagine the following: some set of entity fields (containing secret information) must be accessible only for a certain group of users (say managers). So each manager has a key to encrypt and decrypt these fields in the browser, and data goes through the communication channels and is stored in the database encrypted.
Anything else?

Hi Konstantin,

the use case you described is valid, too. However, my case is a bit different: I want to allow users to save secret information only belonging to them and only readable by them. The application is a password manager. I want to save the information on the server, so the provider (and anybody else in transit) must never see plain text data. Basically, I consider the provider as not trustworthy. There is no need to encrypt meta information like Entity ids or foreign keys, therefore encryption on attribute level is sufficient.

For encryption, I use a hash of the password with salt that the user provides upon login, so the encrypted data should be safe as the password is never stored anywhere. I use Blowfish 448 bit encryption with a PKS5 CBC padding and strong secure random generator which should be pretty much state of the art.

I think your case is a bit simpler, as it does not require storing and sharing keys because they can be derived from entered passwords. Anyway, there should be a browser-side code that encrypts data.
After some discussion with my colleague, we decided that one of the possible ways is to create a special visual component using the technology of wrapping JavaScript components into Vaadin components. Then you can use this component in tables and field groups as a generated column or a custom field.
Any more generic approach with an interception of data in standard CUBA components seems too hard to implement, so we’ll hardly do it in the near future.

Thank you for your insights! The idea of a wrapped JavaScript component for Vaadin sounds feasible, although a bit limited. But for some (if not most) use cases it might be sufficient. For the time being, I have finished exploring CUBA and I am already quite happy with it. I hope to start some new project with it when there is a chance to!

Good to hear that!