Skip to content
This repository has been archived by the owner on Aug 12, 2023. It is now read-only.

Email encryption #24

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Email encryption #24

wants to merge 13 commits into from

Conversation

svenpopping
Copy link
Member

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.

@praseodym
Copy link
Member

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)?

@svenpopping
Copy link
Member Author

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
If there is an (accidental) database breach that the adversary does not have a list of TU Delft employees email addresses in plaintext. Increasing the number of steps the adversary has to make to obtain the email addresses and thus improving security.

@praseodym
Copy link
Member

praseodym commented Nov 4, 2018

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.

@svenpopping
Copy link
Member Author

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.

@svenpopping
Copy link
Member Author

Implemented random IV to improve security

@Fastjur
Copy link
Member

Fastjur commented Dec 10, 2018

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...

@svenpopping
Copy link
Member Author

Is this still relevant?

@Fastjur
Copy link
Member

Fastjur commented Jun 13, 2020

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.

@Fastjur
Copy link
Member

Fastjur commented Jun 13, 2020

I resolved the conflicts using the web editor, they were only imports.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants