S/MIME and PGP: not compatible with each other

First of all, it is important to know that the email encryption methods S/MIME and PGP are not compatible with each other. In order to protect their own emails by encrypting them with S/MIME or PGP, enterprises or users must first decide which method they want to use– and then clarify whether they can do so with their respective contact partner. It may therefore be necessary to make the extra effort to use both encryption methods in parallel.

No one-size-fits-all solution for private users

What makes the use of S/MIME and PGP even more difficult in the private sector is that there is no "one S/MIME" or "one PGP" that can be used for email encryption. Email is used in many forms: there are email programmes that can be installed on an operating system directly as well as internet browsers that can access various email clients. The actual integration of email encryption with S/MIME and PGP depends on the individual circumstances of the person who wants to encrypt. Unfortunately, there is no one way that everyone can use S/MIME and PGP for email encryption, meaning these do not provide a uniform solution for all users.

For end users, email encryption simply needs to work. This means that it must be possible to send encrypted messages without in-depth technical knowledge or preconditions. Ideally, the user should have to do as little as possible for this themself; after all, not everyone is an IT administrator. S/MIME and PGP have clear shortcomings for the end user, particularly concerning the critical point of user-friendliness. This is because of the way these two encryption methods work and also because of all the things the user has to do to set them up.

For enterprises, security only works through usability and acceptance

Even with solutions for S/MIME and PGP specifically for the use of encryption in enterprises, there are differences in the concrete design and the scope of functions. For companies, however, the requirements go even further. They too need a solution for protected business communication that is easy to use and maintains email as a popular medium for their workforce as well as their communication partners. For this, it is crucial that the gain in security is not at the expense of usability. Any security solution can only be implemented effectively throughout the company if users first accept and then use it. Even the smallest hurdle in its application is often too high and can cause even the best technical solution to fail, so it really can't be simple enough.

Why encryption for communication alone is not enough for enterprises

In the modern business world, however, communication from and with enterprises also has major intersections with areas such as data protection, IT security, compliance, the automation of communication processes, etc. With this comes requirements and needs that go far beyond mere encryption and demand a lot more from communication solutions. Many solutions for companies that provide email security by means of common email encryption methods are more user-friendly than S/MIME and PGP are for private use. However, they fall short and do not provide the added value that makes the difference for today's business communication.

Basic principle and function of S/MIME encryption

S/MIME ("Secure Multipurpose Internet Mail Extension") was developed in 1995 and defined in 1999. With this procedure, messages can be encrypted and signed so that their content cannot be read by unauthorised third parties, and the recipient knows that the specified sender is in fact the one who sent the message. It can be individually determined whether a message is to be encrypted and/or signed. Nowadays, S/MIME is supported by most email clients and does not require any additional software installation for private use. To use email encryption with S/MIME, two things are required:

1. The X.509 certificate must be obtained for the user in question.
2. This certificate must then be integrated into the respective email client of the user.

In the actual implementation, however, there are still a few intermediate steps for both of these points, which must be successfully completed by the respective user.

Nowadays, the use of S/MIME in enterprises is mostly done via special business solutions from third-party providers. The concrete implementation of such solutions for email encryption, which function on the basis of S/MIME, depends on the given circumstances and is carried out by the IT experts, usually the respective admin.

Email encryption with S/MIME – a hybrid encryption method

Encryption with S/MIME works with key pairs. Each communication partner has a public and a private key, which makes this an asymmetric encryption method as both parties use different keys. The encryption is carried out by the sender, who encodes the message by means of a session key; this takes place within the framework of a symmetrical encryption. The session key is then encrypted asymmetrically with the recipient's public key. Since both symmetric encryption (with the session key) and asymmetric encryption (with the public key) are used in this procedure, S/MIME is referred to as hybrid encryption.

During decryption, the recipient decodes the encrypted message with their private key. To ensure that no one else can do this, it is therefore important to store the private key carefully and to make sure that no one has access to it.

Signing messages with S/MIME

Signing emails serves to authenticate the identity of the sender and simultaneously transmits the sender's public key to the recipient. This enables the recipient to verify beyond doubt whether the email really comes from the specified sender. In the corporate environment, this is therefore particularly interesting for the defence against phishing attacks. With S/MIME, a unique signature is added to an email to be sent using the sender's private key. On the recipient's side, the signature is then checked using the sender's public key. If something is wrong, the recipient is notified and must assume that the message has been tampered with.

Key exchange between communication partners as a basic requirement for encrypted email communication

For encrypted email communication with S/MIME, the desired email communication partners must know the public key. This works on the one hand, as already mentioned, via the signature: with this, the public key of the sender is transmitted to the recipient at the same time. In addition to the possibility of transmitting the public key directly to the relevant contacts, it can also be uploaded to an external key server. Other methods include publishing the key on a website or transmission in physical form, for example on a USB stick. In practice, however, the latter is unusual and rather inconvenient. The public key is then used to encrypt all emails to the key holder. S/MIME does not work without the exchange of public keys.

Decryption of messages with S/MIME

Emails encrypted with S/MIME are then decrypted with the private key of the recipient. This decrypts the session key, which can then be used to decrypt the encrypted message.

The private key must therefore only be known to its owner and must also be protected by a password. If the private key should fall into the hands of a third party, the entire communication for which this key was used is affected. This means not just an email or the correspondence with one contact partner, but everything.

S/MIME certificates for key generation

For the use of S/MIME for email encryption, an X.509 certificate is required. Private users can obtain this from various providers or generate one themselves. The latter option is free of charge but quite time-consuming, as you have to make sure that your own certificate is accepted. It is then necessary to first create a so-called root certificate, which all contact partners must import for the email exchange before the public keys are finally exchanged. Typically, recognised certification authorities are therefore used to obtain certificates.

Certification authorities and certificate classes

Certification authorities offer the advantage of ensuring that public keys and their owners really belong together, meaning that the key belongs to the intended recipient and that an email actually originates from the specified sender. This is an advantage over PGP, where this certainty does not exist in this form.

There are different classes for certificates; the class to which a certificate belongs depends on how the person who wants to obtain the certificate is checked:

• Class 1: the existence of specified email address is verified.
• Class 2: in addition to the email address, the name and, if applicable, the company are confirmed in writing.
• Class 3: the certificate holder must authenticate their identity, e.g. with the help of an identity card.
• Class 4: the certificate holder proves their identity by appearing in person at the respective certification authority. This would be the most secure way to authenticate identity, but it is impractical and expensive and therefore not an option that is actually used in practice.

These classes have no effect on the security of email encryption with S/MIME certificates; they only say something about whether/how the applicant for the certificate has confirmed their identity. The certificates are of limited validity, which is usually one year (but there are also those that are valid for longer). In order to be able to use S/MIME permanently and reliably, it is therefore absolutely necessary to ensure that you always have a currently valid certificate.

For the successful issue of a certificate, a number of provider-specific steps must be completed. After the certificate has been successfully issued, it can usually be downloaded or the private user receives an email which contains the corresponding URL where it can be retrieved.

Setting up S/MIME manually

Overall, setting up S/MIME is easier to implement than PGP. In recent years, technical requirements have been created to support S/MIME in various configurations.

S/MIME in an email client

After the S/MIME certificate has been obtained, a personal certificate must be generated and then installed. Next, the necessary settings must be made in the email client so that it uses S/MIME with the help of the corresponding certificate. Usually, the email client is restarted after the configuration is complete.

Is there a simpler way? S/MIME solutions in enterprises

When you briefly estimate how many employees would have to set up S/MIME manually – and how many of their contact partners would potentially have to do the same – does this sound like a practicable solution for everyday business in companies? Hardly! Not to mention the hurdles in the actual use of S/MIME for email encryption.

More influence for the admin with gateway solutions

There are various providers on the market who have specialised in the use of S/MIME for email encryption in companies. Their solutions reduce the workload for their corporate customers that the respective company's own admin would otherwise have had when setting up S/MIME for the staff independently and manually. As a rule, such products are gateway solutions; otherwise, the use of S/MIME would be very costly. In addition, much of this would then also take place at the individual user level. This would be critical, however, as there would be a great dependence on correct user behaviour and the admin would thus have fewer opportunities to exert centralised influence with regard to IT security and compliance.

A mail gateway has the advantage that the administrator has leeway for a company-specific configuration. For example, they can connect archiving for their own company or centrally define encryption. At the same time, however, despite the use of S/MIME, this no longer represents end-to-end encryption because there is no encryption from the sender to the gateway for the email. As a concrete example: from Outlook to the Exchange Server, it would be a completely ordinary (and thus unencrypted) email.

Implementation takes less time with such S/MIME solutions and usability for end users is better than it is with "regular S/MIME", such as in the private sector.

Even with S/MIME solutions, various basic problems remain for companies

1. Size restrictions for file attachments 
   Often, it is not the messages themselves but rather the attached files that contain the data worth protecting and requiring encryption. This quickly results in file sizes of more than 25 MB. However, operating within a regular email infrastructure, such files are too large for mail servers and thus cannot be transmitted in encrypted form between sender and recipient. Some of the S/MIME solutions do have additional modules for the transfer of large files that can be added – but this is usually associated with an extra charge. 

2. Ad hoc
   Even if different S/MIME solutions work together and encryption takes place: all those who do not use S/MIME (and this is still the clear majority) are left out and excluded from ad hoc communication. There are alternative approaches for recipients without S/MIME, e.g. making the message available in a web mailer; but here the recipient must first log in with a username and password. This creates another hurdle, which is detrimental to usability on the recipient's side. * 

3. Static key pairs
   S/MIME solutions use static key pairs: the public key is used for encryption and the private key for decryption. These do not change during their entire period of validity and remain the same for all correspondence. If a private key is compromised and third parties have access to the business correspondence, not only can one email from the person concerned be viewed but also retroactively all data that can be decrypted with the compromised key. If the user is unaware of the unauthorised access, even all future incoming messages and files will be affected until a new key is used.

4. Metadata such as the subject line are transmitted unencrypted
   While messages with S/MIME are protected by encryption in transmission, metadata such as the subject line is excluded from this. But even subject lines contain data worthy of protection, which, especially when aggregated, allows valuable and personal conclusions to be drawn. These can be misused, for example in social engineering attacks.

S/MIME for email encryption - conclusion

With the solutions offered by various providers, email encryption for companies is becoming more practical – in setting up S/MIME for the admin as well as in using encryption for users in the workforce. 

Nevertheless, it is important to realise that there are also significant shortcomings. Secure digital communication for companies reaches its limits, even with S/MIME solutions, when it comes to simple ad hoc exchanges with anyone where everything transmitted is encrypted – including subject lines and large files. In addition, all communication partners must use a solution based on S/MIME so that the encrypted exchange of mails also functions without hurdles. Contacts who do not use S/MIME are left out in the cold and suffer noticeable disadvantages. 
Encryption on the basis of S/MIME thus means that encrypted emails can no longer be exchanged 

• between anyone
• at any time and 
• easily. 

Thus, encryption ultimately becomes a hurdle to usability after all. This, however, means that email loses a great deal of its most important feature.

Disadvantages of remaining in the email infrastructure

The use of communication solutions that remain in the email infrastructure in their approach also entails potential risks from man-in-the-middle attacks. This is because even if emails are protected in transfer with SSL/TLS, they are unencrypted on the mail servers en route. Added to this are the size limitations of the mail server when sending and receiving files and the fact that redundancies often arise in data storage. Thus, the mail server quickly degenerates into a data graveyard, which results in additional costs for the company. In addition, there is significant potential for GDPR violations if the overview of which data is stored where and for how long is lost. 

Compliance is a particularly important area, in combination with the increasing automation of communication processes and adaptability to company-specific IT security, where modern communication solutions must offer enterprises added value. Here, however, many S/MIME solutions often fall short.

What about email encryption using PGP, how does this method compare in terms of acquisition and set-up? And what steps are needed in order to use PGP to encrypt email communication?
 

Email encryption with PGP – a hybrid encryption method

With PGP, the encryption process works with key pairs consisting of a public and a private key for each communication partner. Since both parties use different keys, this is basically an asymmetric encryption method. However, these procedures require a lot of computing power, which is why the entire message is not encoded with the public key. The encryption is done with so-called session keys, which are symmetrical and are created randomly and each time anew. The session key is then asymmetrically encrypted with the recipient's public key and appended to the sent message. In this way, the required computing power can be noticeably reduced, which is particularly important when sending messages to multiple recipients. Through the combination of asymmetric encryption (with public keys) and symmetric encryption (with session keys), PGP is a hybrid encryption. 

Signing messages with PGP

When signing with PGP, a unique fingerprint is generated from the plain text of the respective message by a cryptological hash function (SHA-256), which is then encrypted with the sender's private key and appended to the message. The recipient can then use the sender's public key to check whether the message actually is from the sender or whether it has been manipulated by a third party.

Key exchange among communication partners as a basic requirement for encrypted email traffic

For encrypted email communication to take place at all, the desired email communication partners must know the public key. Therefore, it is necessary to either transmit it directly to the respective contacts or to upload it to an external key server. The public key is then used to encrypt all emails to the key holder. The exchange of public keys is an essential component without which PGP would not work. This process requires – depending on which form of PGP is used – some intermediate steps that have to be carried out for each individual communication partner.

However, since it is possible for a person with a public key to impersonate someone else, it requires verification of the authenticity of that key. 

"Web of trust", the PGP trust network – a decentralised approach to verifying key authenticity

For verification of key authenticity, PGP uses a decentralised approach, the so-called "web of trust". This is based on participants in the web of trust who express their trust in each other and confirm that public keys belong to specified owners by signing them. This is therefore a manual process without a central authority. With GnuPG, a free encryption system that conforms to the OpenPGP standard, the software itself determines the trustworthiness of a key. If existing signatures of a public key have already been made by users who are credible in the web of trust, the corresponding degree of trustworthiness is derived from this. The more the corresponding users are trusted, the higher the degree of credibility for the key that was classified as trustworthy by them. Each signing of a key creates a certificate (which acts as a digital confirmation). Each certificate that a public key receives from the participants in the web of trust is then attached to it. The more such certificates a key receives, the greater the certainty that the key and the stated owner really belong together.

Disadvantages of the web of trust

However, all of this requires prior technical knowledge on the part of the users and is neither easy nor intuitive to handle for those less experienced. Moreover, public keys are also linked to personal data. The signatures of keys by other people contain a list of all those who have checked it and confirmed the identity of the key holder. In terms of data protection, this is an aspect that users should be aware of. And as far as data sovereignty is concerned, there is a restriction for PGP users: once public keys have been uploaded to a key server, they can no longer be deleted. Since key servers synchronise globally with each other, uploaded keys can quickly be accessed everywhere (regardless of who uploaded them and regardless of whether they are in fact the owners of the keys). This means that the corresponding email address is published as well and can be found by anyone. After uploading to a key server, users in the web of trust consequently no longer have any influence on the dissemination of the data.

Decrypting messages with PGP

The encrypted emails are decrypted with the private key; this must only be known to its owner and must also be protected by a password. If the private key should fall into the hands of a third party, the entire communication for which this key was used is affected. This means not just one email or the correspondence with one contact partner, but everything.

Setting up PGP manually

PGP on your own system

In order to install and use PGP on your own system, the following steps must be completed:

• Install the appropriate PGP software (available for purchase or free of charge) for your operating system and email client
• Generate a public and a private key; the concrete design of this part differs depending on the operating system and sometimes requires some intermediate steps. For Linux, it is necessary to do the following:
  • Enter the corresponding command in the command line
  • Select the type of encryption
  • Specify the key length in bits
  • Specify the validity period of the keys as well as the name and email address for which the keys are to be valid
  • Define a so-called passphrase for the private key
• Upload the public key to a key server or forward it by email to all contacts with whom encrypted communication is to take place
• Keep the private key safe, i.e. store it locally on your device and protect it with a password (e.g. in a password manager).
• Ensure that all communication partners also use PGP and share their public key
• Check the trustworthiness of the public keys of contact partners

Online PGP tools

There is also the option of using online PGP tools. There, key pairs can be generated, and emails can be encrypted or decrypted. Free open-source services are available for this, which run in web browsers and do not require registration. Although the handling is somewhat simpler in comparison, there are also some steps to go through. The following parameters must be determined in order to set the appropriate keys:

• Name and email address for the keys to be applied
• Preferred key algorithm
• Key length
• Validity period of the keys
• Passphrase for the private key

Once all this has been determined, the keys can be generated and downloaded.

For tools that function as JavaScript programmes in web browsers, the data entry and the generation of the public and private keys do take place with a TLS connection. However, with JavaScript applications there is a risk that cyber criminals can still carry out attacks via security gaps in the online tool used – and ultimately gain access to user data such as the private key including the passphrase.

PGP in webmail services

Those who use webmail services can use PGP for email encryption as well. This works via corresponding browser extensions. One common method is a JavaScript implementation of the OpenPGP standard, which is available for several browser versions. Such extensions must be installed and can then be used as an add-on with an icon in the toolbar to manage the necessary keys.

Users of various webmail services, such as Web.de or GMX in Germany, can send emails and attached files using end-to-end encryption. This is based on Mailvelope, a free software for encryption in web browsers that can be integrated into webmail services.

In order to use this function, however, users must first set up encryption. For example, the following steps are necessary at Web.de:

• Download the browser extension from Mailvelope (free of charge)
• Assign a key password
• Set up the backup (to restore the key password and activate the encryption on other devices)

With Mailvelope, encrypted messages can be exchanged not only with other Mailvelope users but also with communication partners who use a different PGP encryption, such as Ggp4win or Thunderbird.

However, nothing works without PGP – all contacts who do not use PGP encryption software are left out. And there is a size limit of 50MB for the encryption of attached files, since you are still within the infrastructures of the email providers.

PGP for email encryption on mobile devices

For those who want to encrypt emails on their smartphone, the use of PGP is unfortunately also quite difficult – because here, too, there is no approach that fits all end devices or operating systems.

Further PGP adaptations

There are implementations that use the OpenPGP standard, such as the free open-source programme GnuPG mentioned earlier. Its advantage lies in being available for standard operating systems such as Windows, Linux, and MacOS X and that it also works on iOS and Android smartphones. While the broader application possibilities of GnuPG are a relief, they do not cover everything – for Windows Phones, for example, a different implementation is necessary. There are also other specialised products, such as Gpg4win for Windows, gpg4go for Outlook 2010, GPGtools for MacOS, or Enigmail for Thunderbird.

Over the years, PGP encryption has undoubtedly been repeatedly adapted to meet technical circumstances and requirements. For the user, however, none of this has translated into the same degree of usability: it is still rather complex and does not provide a great user experience, which is why PGP's successful breakthrough for widespread use has not happened.

PGP for email encryption – conclusion

Is there a simpler way? PGP solutions in enterprises

Manual setup

Taking the route of a manual setup would mean an enormous amount of work for the IT department of any company. After all, as the effort clearly shows, you can't just leave your own employees to set up PGP on their own. Rather, it is necessary to conduct training for the entire staff on the correct handling of this email encryption method and to accompany the implementation of PGP.

It is important to remember that the steps described above must be carried out for each individual email address of an enterprise! However, since PGP does not work if it is only used by one side, this is only half the battle. The external contacts with whom communication is to take place must also use PGP successfully – obviously, something that your own company's IT has no influence on.

What's more:

• Setting up PGP manually requires the purchase of additional software (often for a fee). In order to avoid potential security risks, it must therefore be ensured in advance that the additional software is from reputable providers
• In this case, it is necessary to calculate the time and costs involved in the installation as well as the training of the entire staff
• PGP is prone to user error due to its high complexity and poor usability. This is a high risk, especially for a company's data protection and compliance

PGP solutions in enterprises

Corporate solutions that rely on PGP for the encryption of email content do exist – but they are much less common than those based on S/MIME. With PGP in particular, despite further developments such as OpenPGP and gnupg, usability is still the biggest hurdle standing in the way of successful application in everyday business.

What is Efail and what does it mean for S/MIME and PGP?

In 2018, Efail revealed the possibility of successfully bypassing email encryption with S/MIME and PGP. Researchers found significant security vulnerabilities due to which emails encrypted with S/MIME and PGP could be decrypted and read by third parties. The starting point was the dependence on the way email clients work.

Starting point for hackers or intelligence agencies: email infrastructure allows man-in-the-middle attacks

The vulnerabilities that were uncovered in Efail were from man-in-the-middle attacks, which are mainly possible when effective transport encryption such as TLS (Transport Layer Security) is not in place. But even if the encryption takes place on the transmission path with TLS, emails are unencrypted on the mail servers en route. Emails are not transferred directly from sender to recipient, but via intermediate stations (mail servers) which are not easily traceable for communication partners. 

This circumstance makes it easier for third parties to intercept emails en route. Intelligence agencies, for example, can intercept emails in this way and store them. Decryption can then be tackled at a later point in time, for example by specifically trying to obtain the private key or when the computing power required for decryption is more readily available. 

Vulnerability: email clients

If an attacker had access to the encrypted email as well as the possibility to send an email (modified by themself) to the recipient, S/MIME and PGP could be successfully bypassed. Through encryption, the contents of emails are initially protected from foreign eyes. However, this protection could be undermined by the way an email client handles emails. In the case of Efail, the clients that usually executed active content by default and reloaded external content were exploited.

One possibility for a successful attack was for third parties to manipulate an encrypted email intercepted en route. This was done by supplementing it with HTML code, which, for example, loaded an image before the email went on to the recipient. On the recipient's end, this email was then decrypted as usual with the recipient's private key. In order to be able to load the image, the regularly configured client (meaning HTML is activated) then sent the decrypted text to the attacker. This vulnerability affected both PGP and S/MIME. Even though the problem with this vulnerability was not the encryption itself, emails were not protected from unauthorised third parties despite the use of S/MIME and PGP. This problem could initially be solved by switching off the loading of external images. However, the approach of switching off HTML as well would have been rather counterproductive, because many things in normal (i.e. unencrypted) emails could no longer be read due to the high HTML distribution.

Another security problem of S/MIME and PGP came to light when so-called "direct exfiltration" was used, which was based on an implementation error of the MIME standard in email clients. In technical terms, the exact procedure is very complex; simplified, it went as follows: intercepted emails were manipulated by implementing certain additions before and after the encrypted text of the email. After some intermediate steps, the decrypted text was finally copied by the recipient's email client into a URL and sent to a server controlled by the attacker. The attacker thus received the decrypted text of the email via the URL.

S/MIME and PGP – what’s the bottom line?

When taking a closer look at all the steps that must be undertaken to set up and use S/MIME and PGP, it instantly becomes clear why these two methods have not been able to establish themselves in email encryption for private use or for use in enterprises:

• For private use, they are too costly, too technical, and too complex for users
• For use in enterprises, they are time-consuming and cost-intensive, even in the form of encryption solutions from various providers, and their scope of services is limited

Secure communication can thus not take place ad hoc and with ease – and is in most cases reduced to those who also use S/MIME and PGP. In addition, the dependence on email infrastructure and the functioning of email clients not only restricts the scope of services, but can also directly affect security, as noted in Efail.

Email encryption with S/MIME or PGP are therefore not the most viable options for enterprises in practice and have therefore never been able to gain widespread acceptance. Nevertheless, there is still an urgent need for enterprises to have secure digital communication, especially since the requirements of the modern business world go beyond mere encryption.

Business communication requirements that S/MIME and PGP do not fulfil

With S/MIME and PGP, emails are encrypted and secured during transfer, with the exception having been pointed out in Efail. However, the use of S/MIME and PGP does not sufficiently fulfil the very important requirements for modern digital communication and thus does not meet the needs of modern enterprises. This has noticeable disadvantages:

Cryptshare provides companies with an alternative that combines security with usability – and goes far beyond what S/MIME and PGP can do.

As a secure digital transfer service, Cryptshare offers you encryption not only of emails but also of subject lines and file attachments. There is no size limit for your data exchanges, so you can send files with several gigabytes without any problems. All transfer processes are logged, ensuring traceability for your company's compliance.

Data sovereignty, not data graveyards

The retention period of transfers on the Cryptshare Server can be tailored company-specific through an individual configuration so that data graveyards are effectively prevented. This not only helps your compliance with data protection regulations but also saves you money.

Usability for everyone

What makes Cryptshare special is that, from the beginning, it was designed so truly anyone could use it – intuitively and without deep technical knowledge. Every IT administrator will confirm: effective security only works in combination with high usability!

However, usability does not end with your own staff but also extends to their communication partners: Cryptshare works bidirectionally, which means that all communication partners can not only receive messages and files from the sender, but also send them back. All of this works ad hoc and without any preconditions – internet access and a web browser are all you need to communicate digitally in a secure way.

With Cryptshare, there is no need to:

• Buy and renew certificates
• Exchange keys
• Create and manage user accounts
• Install software

Integrations into familiar work environments & via API connection to in-house tools

With Cryptshare, your employees continue to benefit from the ease and familiarity of email and can engage in ad hoc exchanges with third parties. Integrations for Outlook and HCL Notes allow staff to securely conduct business communication directly from their own work environment. Thanks to the Cryptshare API, it is also possible to connect Cryptshare directly to in-house tools or to send information generated automatically from system processes. For the recipient of a Cryptshare transfer, it does not matter whether the transfer was sent by a person or a system. 

Secure and simple, also on mobile devices

Communicating easily and securely from mobile devices? No problem! With Cryptshare, it doesn't matter whether it is an iPhone, iPad, Android or other end device. Again: no technical preconditions are necessary, and it can be used ad hoc.

More ease of use and saving time with QUICK

For the regular exchange of information with fixed communication partners, you can further increase usability with Cryptshare QUICK Technology. QUICK creates permanent secure connections and, after activation, takes care of all one-time passwords for future transfers between communication partners. Users do not need any help from the administrator and can easily activate QUICK on their own. Afterwards, they do not need to worry about passwords; they automatically communicate in encrypted form. QUICK is convenient security that will save your enterprise valuable time. 

Cryptshare.express – the flexible solution for small businesses

For companies with up to 50 employees who are looking for a communication solution that fits their needs, we have created Cryptshare.express: an online model that enables the secure digital exchange of messages and large files. It is ready for use as a service and set-up only takes a few minutes.  
 

Sign up & order now

This is how secure digital communication with Cryptshare works in practice

Selected the wrong recipient or wrong attachment and already sent the email? No problem!

But what if an employee suddenly realises that they have accidentally sent the wrong file or sent the transfer to the wrong recipient? After all, this is a mistake that has happened to almost everyone at some point – and can have very unpleasant consequences: this can mean a GDPR violation or even the loss of a company's intellectual property. Don't worry, because Cryptshare has a solution for this, too! With the revoke feature, this is no longer a risk: even after sending a transfer, the employee as the sender can retroactively block access to erroneously sent files. This allows them to quickly correct their mishap and prevent the accidental loss of data for their company.