Please help us help you and fill where relevant:
Your LimeSurvey version: Version 3.28.55+230328
Own server or LimeSurvey hosting: own in a cloud (a2hosting)
Survey theme/template: default-sea-green
==================
I am going to update to V5 and I am very much interested in the possibility of encryption of responses at the question level. 
I analyse data by pulling them via RemoteControl API into R ( github.com/cloudyr/limer ). If I understand correctly, the pulled responses would be encrypted and I would need to write a routine that would decrypt the response(s) before processing them locally on my laptop. That should not be a problem as R already provides bindings to libsodium  but I am a little unclear about the keys.
Do I understand correctly that both the private and the public keys are configured in the relevant config file? /application/config/security.php
So that means if someone were to be able to attack the server that limesurvey runs on, they would get both keys and would be able to read all the responses.
I had imagined that ideally the key pair gets generated during the installation and is given to the installation owner/admin, the public key is stored on the server and is used for encryption, but decryption could only happen when the owner/administrator provides the private key. Is this something that would be possible in the future? In my case the decryption would only happen locally after the encrypted data were pulled off limesurvey. I understand that this would be inconvenient for viewing data in LS interface, but it would be great if this were an option in the future.

In the Limesurvey backend you can see encrypted answers "unencrypted", so the key needs to be there to show the answers in clear text in the system.

So the encryption feature is implemented differently that you imagined.

Thanks, I understand that it is implemented differently (I think I did try to convey that in my question too - that private key was needed on the server to show the unencrypted responses).

I was wondering rather if this might seem like a good feature to add in the future. For example to encrypt the confidential data that you never want to go astray, such as textual responses by patients, or if the patient is identifiable by a response they submit. For such use cases it would be really good if LS would have an option to encrypt responses AND leave them encrypted, unless key is deliberately supplied (locally). Right now, I understand, the main protection is from database admins or whoever is able to gain access to the database tables. 

But please do not get me wrong, I think LS is fantastic as it is and it is good that there is an encryption option.

I agree it would be a good thing to encrypt data this way, but I think it is pretty risky for 'normal' users. And I guess it wouldn't work for the SaaS service that Limesurvey GmbH is providing.

I mean you can create a feature request. But I wouldn't get my hopes up too much. Usually for a feature request to get implemented takes a while.

holch wrote:

I mean you can create a feature request. But I wouldn't get my hopes up too much. Usually for a feature request to get implemented takes a while.
 

Yes, but here : i really think it's a must have …
 

I have created a feature request by the way. Carsten looked at it and said they would consider, it seems sensible. The bugtracker id is bugs.limesurvey.org/view.php?id=18709

We need 2 different key, one for "public" encryot (current one) and another one with "private" encryot.

Maybe private encrypt key generation can be done by survey ?

It's a big feature, not in 5.X , unsure for 6.X

DenisChenu wrote:

We need 2 different key, one for "public" encryot (current one) and another one with "private" encryot.
Maybe private encrypt key generation can be done by survey ?
 

You wording is a bit dangerous. The public key encryption has always two keys. The public key and the secret key (which some call private key).
Currently the encryption is also used to save the password of mailaccount settings.

The main goal of the feature request is to prevent the storage of the private key on the server.
The minimum are one keypair for application stuff (participants database, mailserver password, etc.) and one keypair for all surveys.
Some users might want one keypair for all survey, some user might want keys per survey.
You might consider having a key-management section, where you can import/export public/private keys and assign and remove them on surveys and surveygroups.
A way to backup keys might be important for LimeSurvey cloud users as well.
 

jelo wrote:

You might consider having a key-management section, where you can import/export public/private keys and assign and remove them on surveys and surveygroups.
A way to backup keys might be important for LimeSurvey cloud users as well.

 

Ah right, the private (crypt) key still can be used to generate the public (decrypt) key …
But if you choose a "NoAutomaticDecrypt" system : GUI must not offer to get public (decryt) key after generation. Else any body with GUI access can decrypt …

jelo wrote:

The main goal of the feature request is to prevent the storage of the private key on the server.

 

But you need the crypt key … then private key must be on server.
 

DenisChenu wrote:

But you need the crypt key … then private key must be on server.
 

The public key is to encrypt data. The private key is to decrypt data which was encrypted with the public key.

The key pair is currently created via LimeSurvey on the server. Advanced users might be offered a way to not only remove the private key from the server but also allow to upload a public key (which is created by the advanced user on a local system). That way the private key never need to be on the webserver.

Slightly off-topic:
That scenario is the only one really offering a security.  With an private key on the webspace I don't see much protection. The main attack vector is via the webserver and not via the database server. The credentials to access the database would be available to an attacker of the webspace.

jelo wrote:

The public key is to encrypt data. The private key is to decrypt data which was encrypted with the public key.

 

You're sure of this ?
With SSL and PGP : private key crypt data and public key decrypt data.

It's cool if we can keep only public key to crypt.

(else about Off Topic : fully agree)