Many thanks for discussing this.
Just to note about keys. Sodium supports both
symmetric cryptography - i.e. one key is used to encrypt and decrypt. It must be stored somewhere on the server/database so that LS would be able to encrypt. It is not what is used. If server were to be compromised data can be decrypted using the said key. Instead
asymmetric encryption is used on LS with two keys private and public. They are generated at the same time by a program (similar to ssh-keygen); the private key _can_ be password protected, but does not have to. The essential bit here is that the private key should be kept in a very safe place (e.g. your own computer, memory stick, etc). The public key may be kept wherever (even on public keyservers). The data you encrypt with the public key can be only decrypted by the private key. If both keys (pub&priv) are on the server and the server is compromised, the situation is as good as with the symmetric encryption key.
> 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.
Yes indeed. Absolutely - something like a key management for gitea or github. In gitea scenario you are responsible for making the pub&priv key pair and then you have to upload the public key (which is easy - it is just a string of text). That might be actually the better way to implement the second encryption scenario. If that is done, I would volunteer to write the manpage in English for this. That would be encryption "method-two" (the more secure one) and would require the user to generate the keys, which is not too difficult actually. The benefit is - LS does not have to temporarily store the private key - even in server memory (if LS is to generate the key pair, then it should be reasonably sure the user has got the private key - which is doable, but may be cumbersome). What should be there - a mechanism for the user to verify that the key pair works, before they start data collection. It should not be too difficult - the user could be given some string encrypted by the public key and should be given clear instructions how to decrypt it and paste back to LS for verification. Something like that. Or it maybe just as simple as asking the user to submit some test data to survey and decrypting on the local computer, using their private key. Which does bring up some complication - but there are open source solutions for that such as
opencsv
and on basis of that there could be some local application to do that. The problem is that the csv arrives with the csv structure (commas and line breaks) unencrypted, in plain text so to speak, but the values between commas are encrypted. Processing it in R would be fairly trivial, but I am sure there could be some solutions, however, I think, they do not need to be provided by Limesurvey. Only something to make sure the public key that LS sees on the server works with the private key that the user has.
I understand - it would make things a little bit more complex, but not everyone needs to care about survey data encryption. People in healthcare have to, though.
> 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.
Thanks; yes, exactly, this is why I started this topic and raised the feature request.
