Go to Top

安徽快三推荐: Emails and GDPR – The Need and Drawbacks of Encrypting Emails

With the GDPR in full effect now, some companies still struggle with the processes to make their IT compliant to the new regulations. Since the GDPR covers many aspects of data security as well as reasons for data leakage there is almost not a single IT process not effected by the new European law. While most of the process to change are quite obvious, some are not.

Such a required change is the need to encrypt emails which contain personal information of clients and customers, employees or anyone else. Since article 25 of the GDPR requires data protection “by design and by default” for all business (IT) processes for products and services and the whole law is supposed to make personal data more secure and to prevent data leaks more unlikely, many lawyers argue that this new law requires all emails to be encrypted by default. Even though it is not clear now, if this is true or not, it makes sense to – if you did not do so already, to think about the consequences.

Remember: An email is like a postcard! When you send an email, some people like for example the enterprise IT administrator or the internet service provider can read its content if they want to. Therefore sending a normal email including personal or sensitive information without encryption is considered to be illegal under GDPR.

Email encryption is not as common as it should be. That is because of the fact, that implementation of this feature is not easy. There are currently two different methods available to choose from:

  1. Transport encryption

Transport encryption means that the email(s) will be encrypted when they are send (transferred) from one server to another. The emails are send through an encrypted tunnel when using this method. The emails are encrypted when the depart from one server and decrypted when the arrive on the other server. All emails on the server are not encrypted when they are stored on the server. Sending encrypted emails over the internet you would use for example the POP3S email transfer protocol with the Transport Layer Security (TLS) network protocol (which is the new name for the Secure Sockets Layer (SSL) protocol used for quite some years now).

TLS combined with POP3S therefore creates an encryption tunnel – also known as site-to-site-encryption or end-to-end-encryption, which is a great solution when you connect two servers directly. However most companies do not have such close relations that they connect their email servers directly. Most likely there will be some other server on the way, where the emails will pass through. Therefore another solution is needed… such as…

  1. Content encryption

When using content encryption the email will be encrypted and not the network transport tunnel where the email is transferred through. Today the most common standards for email content encryption is either the S/MIME (Secure/Multipurpose Internet Mail Extensions) standard or using Open PGP.

S/MIME can be for example implemented in your MS Exchange Server. S/MIME is based on asymmetric cryptography and uses a pair of of mathematically related keys to operate. Those are the public and private keys. An email is encrypted with the recipient (not the senders) public key, while the email is decrypted with your private key. Even though the technology of S/MIME is not easy to explain, I try to keep it simple here: When implementing S/MIME in an MS Exchange Server a certificate is produced which contains the signature of the user and also contains his public key. When he sends another user (user “B”) this signature, he proves that he is the person he claims to be and gives his email recipient his public key and therefore gives him the right to send him encrypted emails. When user B then sends an encrypted email the next time to user A, the email client of user A ?recognizes“ that the email is from a secure and known sender, searches for his private key inside the email client and decrypts the email on the fly.

The same procedure is true for OpenPGP. It is also based on public and private key exchange for encryption and decryption of emails. You generate a pair of keys – one that encrypts the email (the public key) and the other one that decrypts the encrypted email (the private key). You share your public key to all those persons you want to get encrypted emails from. Once you receive an encrypted email from a known source your email client will decrypt your email. That is how it works. However implementing an OpenPGP solution can be quite time-consuming and difficult. An example of how this can be done, can be found here

Nowadays when enterprises use encryption for emails they implement S/MIME in their MS Exchange or other email exchange server while private individuals use OpenPGP based encryption solutions like for example GnuPG or other open source variants.


The dangers of email encryption

As we have seen using transport email encryption like TLS means that on both the sender as well as on the receiving email server (as well as the email clients) the messages as well as their attachments are stored non-encrypted. Therefore when an email server malfunctions like for example when an internal hard disk drive fails or when the whole systems stops due to user errors of the software, data recovery experts like those from Ontrack Data Recovery are able to reassemble the file systems as well as the emails without greater challenges.

However when content encryption – regardless if S/MIME, OpenPGP or a gateway solution – is used, there can be cases where recovery of encrypted emails is challenging.

In any case the so-called public and private keys must be available to the data recovery experts in order to begin or try to recover any emails. If these keys – or in case of the private key, which is actually a certificate – are not available, then there is not a slight chance to recover the original content inside the email.

Since for example the smallest symmetric key length (or key size) of OpenPGP is 128 Bit, it would take 1.44 billon years to crack that symmetric encryption key. And with 256 Bit keys most crypto experts state that it is impossible even for governmental security agencies and their supercomputers to decrypt that encryption key.

Therefore you should always keep and store your encryption keys, certificates or decryption passwords separate from the original email server or desktop computer so when a data loss occurs, then the data recovery experts can use them later on when they were able to recover the encrypted raw data.



Picture copyright: John-Mark Smith/www.pexels.com


CCO license

Leave a Reply

Your email address will not be published. Required fields are marked *

  • 有没有上城客在越南的踪迹? 2019-02-15
  • 税费“红包”助推高质量发展 2019-02-06
  • 广东水漫大街市民触电身亡,是天灾还是人祸? (原创首发) 2019-02-06
  • 【北京页川车型报价】北京页川4S店车型价格 2019-02-03
  • 北京加强外地车管控:设置过渡期 限“进京证”次数 2019-01-11
  • 回复@无名小卒也:我只是针对过去的“计划供应”不能很好的满足人们的需求来谈问题,并未否认计划经济,计划经济在市场经济时代,已经转化为政府职能 2019-01-11
  • 搂住所言延退对于企业和零活就业者或专家型科技工作者而言很恰当,可是对于公务员这一群体来说延退可能导致利益固化行政僵化,这是普罗大众不能够容忍的。 2019-01-07
  • 主城赏荷地图出炉 快带上相机出发 2019-01-07
  • 生发“神药”乱象:广告造假无底线 同批号多个名 2019-01-05
  • 2018首届“中新广州知识城杯”绘画摄影作文大賽·奥一网 2018-12-25
  • 周纪龙:为262名残疾人的幸福领路 2018-12-25
  • 全国人大代表、上海市黄浦区委书记杲云:打造卓越的全球城市核心区 2018-12-12
  • 那些吃不惯汉堡牛排的中国留学生们,是怎么在美国活下来的? 2018-12-12
  • 深圳白石洲村民旧城改造有户主一栋楼补偿四千万,算不算勤劳致富? 2018-12-12
  • 崇拜不劳而获是腐败的根源之一,正气不足是腐败的第二个根源,沉迷于初级趣味易滋生腐败,提高素质力争不想腐,以医者之心防治腐败。 2018-12-09
  • 52| 921| 452| 43| 544| 25| 631| 928| 658| 145|