Asymmetric encryption facility

Feature Request
#1

Expand the encryption facility to include asymmetric (separate encryption and decryption keys).

#2

Yes yes yes, I would love this, too. :heart: :heart: :heart:

1 Like
#3

I don’t have any knowledge about this but from @Apple’s explanation in your other post it seems that I might need it in the future.

Could you explain a use case for this? Could you make something related to a diffie-hellman key exchange to make end to end encrypted messaging for example?

#4

Yes:

I encrypt my message with your public key and send it to you
You receive the message and decrypt it with your private key

This way both the recipient and sender are using different keys, so you don’t need to know the recipient’s password in order to encrypt the message, only its public key (which is really meant to be public)

For end-to-end messaging you still have to determine how to handle the private keys (e.g.: no point storing those in the database, otherwise it’s the same as not having encryption)

3 Likes
#5

A good analogy is having a padlock which is open so anyone can put something into the storage box. They put something into it and then lock the padlock. But they don’t have the key to it so can’t open it and remove the contents. Only the keyholder can do that.

2 Likes
#6

Sounds great! So would be a helpful feature indeed. Are there any libraries that you know that could be integrated? Maybe I’ll spend some time figuring out how to make an extension for it

#7

What comes to my mind when it comes to “assymetric encryption” is GPG, but I don’t know if that’s the best approach in Wappler context. It’s definitely what people use on a day-to-day basis for secure communication though. Doing a quick search on the web, I found this:

It seems it uses the old-style callbacks instead of the newer Promises or async/await syntax, here’s a promisified version:

I also found this one that seems simpler to use, but it’s not GPG and doesn’t show details about the key’s strength:

Perhaps this would be a better suited tutorial:

Edit: Pinging @JonL, he might be able to give better advice

2 Likes
#8

I’m afraid I don’t have a better advice :slight_smile: Crypto(the real one) is not really my field of expertise. The options you gave are probably the ones I would dig into.

My question is why is this needed? Is it just to encrypt DB data at rest? If so, I would use the tools provided by the database engine. I wouldn’t handle this with Wappler.

pgsodium provides a useful pattern where a trigger is used to encrypt a column of data in a table which is then decrypted using a view. This is called Transparent Column Encryption and can be enabled with pgsodium using the SECURITY LABEL … PostgreSQL command.

If an attacker acquires a dump of the table or database, they will not be able to derive the keys used to encrypt the data since they will not have the root server managed key, which is never revealed to SQL See the example file for more details.

An ELI5 of how this works.

  1. You configure your PG database to encrypt certain columns always(or following some condition).
  2. Each time you insert a row PG will encrypt the columns you specified in 1)
  3. To show decrypted data you call a view of that same table that is provided by default by this functionality. The decryption is done again by PG.

You don’t have to be adding formatters/actions in Wappler each time you need to encrypt/decrypt data which is prone to human errors and will certainly add computational overhead on the server.

I am guessing mysql/mariadb have also similar functionalities.