My boss came up with a strange idea in my opinion. He doesn't want to keep email addresses in the database. However, we use them to log people in, and we keep newsletters to those who actively gave consent. Also, every now and then, we have to contact the whole bulk of people. Even with those 3 cases, he doesn't want them clear in the database.
So he came up with this: after normalizing them (trimming space, lower casing them and a couple more conversions), I should strong hash them. This would give us access to the "login" part.
After that, he understood we still need email addresses for those that signed up in the newsletter. So he suggested to keep another field with an encrypted email address, but nil to those that don't want a newsletter. Enough to say, the key to decrypt the email address needs to be in the server, so that the process can be done automatically.
The third case. Those cases where we really need to contact them. It turns out keeping the whole encrypted list is okay, as long as the password is stored in paper. This means that every time we needed to get all the email addresses, human intervention is needed. Worth noting that email addresses are clear in the database until we also run a process where we introduce the "paper password", moment where clear email addresses are deleted. This process is done weekly, so there are 6 days with a good sum of clear email addresses.
Honestly, I could buy the hash part, but the other two could seem more of a problem for the everyday employee (partial email address searches was also a thing to look for specific clients that could have badly entered the email address in the process and needed a little bit of help) than for any hacker, that could anyway gain access to the code, or brute force the paper-password ones.
Does it make sense to try to obfuscate email addresses at that level?