:+1:
Seems a good idea.

Maybe have a look to https://github.com/SamMousa/limesurvey-encrypt system : whole response line was encrypted , and current response was deleted.

Another idea : 1. We need 2 different settings for encryption : the current one, and the "private" one.
If we have a private one : we need a private/public key generator by survey, not globally.

Discussion on forum, and idea for this new feature

1. Add a "Upload your private key" management system (Global ? By User ? By Survey) : never generate new key by LimeSurvey, only add a link to manual for way to generate key.
2. In Survey settings : add a "Crypt settings" : Way to crypt data :
   • With default LimeSurvey key (automatically decrypted, allow reloading and statistics)
   • With "Drop-down or key" : no decrypt, broke reloading and statistics.
   • Enter your crypt key here
3. On development we extend crypt/decrypt function for Response and SurveyDynamic model (no change for other because they need to be reused by LimeSurvey transparently)
4. Crypt with the key set in Survey settings
5. Decrypt or not according to key set in Survey settings.

I'm happy to create a Pull Request for this if it's OK to implement in core.

Just to clarify better, why I thought this is needed. If you deal with potentially sensitive personal data, one does not really wish to store direct personal information (names, e-mails, etc) in a mysql database on a server even encrypted. As long as the private key is on the server and becomes available to an attacker, they can decrypt the personal data. So for such material direct personal information will be stored locally on the user's system and the only link with the LS survey records will be a one-way hash (the link between the local and protected participant record and the LS answers table). Denis asked - why encrypt then, if no direct personal information is on the server.

To not encrypt is relatively OK with numeric data. But if you want to go a step further and allow patients to submit free text responses, you can have a situation where people disclose personal data either theirs or of others inadvertently (or deliberately). Let us call it indirect personal information - you were not asking for it, but people submitted it anyway. You still have the duty to protect it as best you can. For an example, think of mental healthcare settings where desire to protect vulnerable people's info is high and people not always have the capacity to evaluate properly what they are writing.

If you have the text responses encrypted, you are not worried about the free text responses. Even if Limesurvey were to be compromised, the responses are safe. And if encryption is available - why not encrypt also numeric answers for good measure.

I am not sure if people know just how difficult it is to trust with personal data in healthcare settings, but healthcare providers are big organisations and they need good open-source mechanisms to collect and use patient feedback. The setup with LS and R or Python would fit the need very well, especially if responses can be encrypted as decrypting them in an automated way locally is trivial if you have the private key.

Just to add - if direct personal information is NOT stored on LS server - there is no need to worry about participant table or token encryption. They are not used, because that part of making respondent links and distributing them (making the links with id codes embedded, QR codes) is handled locally. It is pretty easy to do that and I'd be happy to publish a scheme how this.