-
Notifications
You must be signed in to change notification settings - Fork 2
Email encryption #24
base: master
Are you sure you want to change the base?
Email encryption #24
Conversation
Reusing the IV makes the encryption scheme completely insecure. More importantly, I'm wondering about the threat model here: what threat is mitigated by implementing this encryption scheme (provided it were properly implemented)? |
Using a fixed IV is not completely insecure. CBC with a fixed IV is IND-PASS secure, meaning that the system is secure if an advantage is “small” for all polynomial-time adversaries A. Threat model |
Adding IND-PASS security to some columns of the database, while not reviewing a wider threat model just doesn’t make sense. As for this concrete case, TU Delft employee names and email addresses are public information (e.g. through the find employees page and course browser) which makes this PR even more debatable. |
The TU does not allow us to store this information without it being encrypted, so there is not much to discuss if we should do it or not. It is a requirement by the TU. |
Implemented random IV to improve security |
To add to the threat model. In case of a data breach, the TU wants the feedback to be connected to an encrypted name/email of said staff member. Don't ask me why... |
23e404b
to
c30e785
Compare
Is this still relevant? |
I would assume it still is. The TU still would only allow us to use the feedback tool if it is encrypted. So I am assuming we still need this. |
I resolved the conflicts using the web editor, they were only imports. |
use actions and ghcr
b602285
to
eafb232
Compare
Requested by the TU Delft
This PR contains the encryption and decryption of the name and email of the employees of the TU Delft. The crypto scheme uses AES/CBC/PKCS5Padding encryption with a fixed IV.
A fixed IV is used to make the implementation a lot easier otherwise the IV should be stored somewhere which makes the encryption and decryption a lot harder/messier.