The initial idea is to have users receiving encrypted values, such as the treasurer of an organization, have an asymmetric cryptography RSA or EC key pair. The public key would reside in the database and be referenced in the field specs for encryption. The private key would initially be stored in the database, encrypted with the user's password, and later moved to a solution residing on the user's devices or a YubiKey or similar, one key per device, ensuring that should the database and the users's password be breached simultaneously, the encrypted values would still be safe.
Users other than the recipient would see a message like ”🔒 This field is encrypted. You do not have access to its values" when browsing through expense claims. The recipient would see a button ”🔓 Show encrypted field value," prompting for a password to decrypt the value, cached for a session. This process would also apply during export, allowing the choice of including or excluding encrypted values.
The suggested approach is to use JSON Object Signing and Encryption (JOSE) for keys (JWK) and values (JWE), leveraging existing libraries to avoid low-level cryptography concerns. For each value to encrypt, a symmetric encryption key is created that is only used for encrypting this value. This symmetric key is then encrypted using each recipient public key and stored alongside the value.
Another item for possible future improvement is encrypted uploaded files that would be encrypted with the recipient keys before uploading to S3 (Minio). However, there is no immediate use for this, so this should not be prioritized at the moment.
The initial idea is to have users receiving encrypted values, such as the treasurer of an organization, have an asymmetric cryptography RSA or EC key pair. The public key would reside in the database and be referenced in the field specs for encryption. The private key would initially be stored in the database, encrypted with the user's password, and later moved to a solution residing on the user's devices or a YubiKey or similar, one key per device, ensuring that should the database and the users's password be breached simultaneously, the encrypted values would still be safe.
Users other than the recipient would see a message like ”🔒 This field is encrypted. You do not have access to its values" when browsing through expense claims. The recipient would see a button ”🔓 Show encrypted field value," prompting for a password to decrypt the value, cached for a session. This process would also apply during export, allowing the choice of including or excluding encrypted values.
The suggested approach is to use JSON Object Signing and Encryption (JOSE) for keys (JWK) and values (JWE), leveraging existing libraries to avoid low-level cryptography concerns. For each value to encrypt, a symmetric encryption key is created that is only used for encrypting this value. This symmetric key is then encrypted using each recipient public key and stored alongside the value.
Another item for possible future improvement is encrypted uploaded files that would be encrypted with the recipient keys before uploading to S3 (Minio). However, there is no immediate use for this, so this should not be prioritized at the moment.