The ProtonCalendar security model

illustration of ProtonCalendar security model

This article documents ProtonCalendar’s security model and illustrates how our product protects calendar-related sensitive data. We examine the advantages and limitations of our approach.

This document is somewhat technical, discussing how encryption protects the different layers of data. Still, it is meant to be accessible to a general audience and attempts to explain how ProtonCalendar works in plain language.

The ProtonCalendar beta is now available for users with paid ProtonMail plans. To access the calendar, log in at and click on the calendar icon in the top left.


ProtonCalendar is an online calendar that is integrated within the Proton suite of products. It is designed to deliver the convenience of a calendar app with the security and privacy of a Proton product. When developing ProtonCalendar, we knew it had to support the following features:

  • Send and receive event invitations, both from other ProtonCalendar users and non-Proton users
  • Send and receive event updates
  • Add attendees to an event
  • Add reminders to an event
  • Support multiple calendars
  • Share an event between multiple calendars
  • Share calendars

Threat model

The goal is to prevent the server or any adversary that gains access to the server from accessing sensitive user data. They must not be able to:

  • Access the private content of events
  • Modify the public content of events undetected
  • Forge an event on behalf of an existing member of a calendar
  • Add a member to a calendar.

Calendar model

At its most basic, a calendar is just a collection of events. It would be a relatively easy task to secure such a calendar app with encryption. However, to be useful, a calendar should let you share an event with other users and across multiple calendars. You may also want to share your calendar with other users. These interactions are what make encrypting ProtonCalendar so tricky.

When you start using ProtonCalendar, you will join or create a calendar using one of your ProtonMail email addresses. You will become a member of that calendar, and your email address will be used as your identity within it. Any action you take, like creating, editing, or deleting an event, will be digitally signed using a primary address key that is linked to the ProtonMail address you used to join the calendar.

Each member will have a set of permissions that allow them to edit events, view event details, check availability, see the list of members, and invite new members.

For every calendar, we will generate a calendar key (for those interested, it will be an ECC Curve25519 PGP key). This calendar key will be used to encrypt the event data. (To see more details about the event encryption, skip down to the “Event encryption” section.)

This calendar key will then be symmetrically encrypted (PGP standard) using a 32-byte passphrase that is randomly generated on your device. Once it is encrypted, your calendar key will be stored on the ProtonCalendar backend server.

Each member of a calendar will have a copy of the same passphrase that is encrypted and signed using their primary address key. The signature ensures that no one, not our server or any third-party adversary, changed the passphrase. This is crucial because if an attacker could change a member’s passphrase, they could then modify the calendar key without the calendar members’ knowledge. This would allow the attacker to decrypt any new event created by the calendar’s members.

Thus a calendar is composed of:

  • A Calendar Key with the corresponding passphrase
  • Members
  • Events

A member is a user, represented by an email address that is linked to the calendar and is composed of:

  • An encrypted and signed passphrase
  • A permission set
Calendar model

This allows multiple members to be part of the same calendar and share the same events without having to encrypt them with multiple keys.

Calendar invitation

You can share your ProtonCalendar with multiple Proton users. We implemented a secure invitation protocol that cryptographically guarantees that the user inviting you is who they say they are.

The calendar invitation cryptosystem

To invite a new member to your calendar, you need to grant them access to the calendar private key and make sure that they can decrypt it. This is the only way they would be able to decrypt and read the calendar’s events.

If you invite a new member, ProtonCalendar first has to fetch the invited member’s public key that is linked to their email address. Your ProtonCalendar client will then encrypt the calendar’s passphrase on your device using the invited member’s public key. The passphrase is then signed using your email address key.

The invited member, if they decide to join the calendar, can decrypt the passphrase using their address key. They can also verify that the signature on the passphrase belongs to your email address key. This lets the invited member cryptographically verify that you invited them. To accept the invitation, ProtonCalendar will then pin the passphrase for the invited member by replacing your signature with one created using their own email address key. This signature will later be used by the invited member to verify the passphrase at each application start.

Event encryption

A member with write-access can add a new event to a calendar.

Event splitting

Events have three types of data. They are:

  • Shared event data, which is shared with all calendars that have that event
  • Calendar data, which is specific to a calendar but shared with all a calendar’s members
  • Member data, which is specific to a unique calendar and member

This division allows the main properties of an event to be shared between all calendars, while each calendar can have different comments for the same event. Furthermore, each member can set their own personalized alarms.

Event splitting

The shared event data that is the same on multiple calendars includes:

  • Unique event identifier
  • Start and end date of the event, repetition rule and date/time exclusions
  • Description, summary (title), location
  • Attendees

The calendar data that can be customized on each calendar includes:

  • Comments

And the member data that each member can customize includes:

  • Alarms

All event data can also be split into two categories:

  • Encrypted and signed properties
  • Signed-only properties

Our server needs to be able to access some properties of an event so that it can retrieve and index the events efficiently. The properties that our server must access are the signed-only properties, which include:

  • The start/end time of an event, along with its time zone information
  • The repetition rule and the date/time exclusions
  • The unique event identifier
  • Time information for alarms

All the remaining properties will be encrypted and signed on your device before they are stored on our servers. In other words, all of an event’s critical information, like the title, description, location, and attendees, will be stored securely and privately with end-to-end encryption.

The event cryptosystem

An event’s encrypted data will be encrypted as a PGP message using the calendar private key. This data will also be signed as a PGP message using the author’s primary address key.

An event’s signed-only data will be signed as a PGP message using the author’s primary address key.

The signature of the data cryptographically ensures that each type of data was created and edited by the specified author and guarantees that nobody (not even ProtonMail) has tampered with your events.

When you create a new event, ProtonCalendar automatically takes the following actions to encrypt it:

  1. It generates two session keys. A session key is a random binary string of 32 bytes.
  2. Using the first session key, it encrypts the encrypted category of the shared event data. This session key is called the Shared Session Key.
  3. Using the second session key, it encrypts the encrypted category of the calendar and member data. This session key is called the Calendar Session Key.
  4. It then encrypts the Shared Session Key using the calendar private key. The result is called the Shared Key Packet.
  5. Next, it encrypts the Calendar Session Key using the calendar private key. The result is called Calendar Key Packet.
  6. Finally, the encrypted Shared Session Key and the encrypted Calendar Session Key are stored on the server along with the encrypted event data.
Event cryptosystem

Sharing an event

As a ProtonCalendar user, you can invite anyone, including non-Proton users, to your event. 

If you accept an event invitation from another user’s ProtonCalendar, then the event will automatically be added to your calendar and linked to the original event of the organizer. This way, if you or the organizer of the event update a shared component of the event (like the start time or location), the other user’s calendar will automatically be updated. They will be able to decrypt the new event data and verify the digital signature to ensure that the event modification was made by the claimed author.

The diagram below represents a single event. Some properties are shared across the calendars to which the event is linked, others are calendar level, and finally, some are member level as described in the “Event splitting” section.

Sharing an event

Shared event encryption

Sharing an event with a different calendar is done by sharing the shared event data and shared event session key. Both calendars will access the same shared event data that is encrypted using the shared session key. Thus, if you want to share an event from your calendar to someone else’s calendar, you will have to send your shared session key (decrypted shared key packet) to the other user. The other user will use this shared session key to access the shared event data.

When the other user adds the shared event data into their calendar, their device will generate a new Calendar Session Key. It will use that new Calendar Session Key to encrypt any calendar data or member data from their calendar. The Shared Session Key received in the event invitation will be encrypted using the private key of the user’s calendar key and will be stored as a new Shared Key Packet.

Shared event encryption

Or, as this illustration shows, Shared Key Packet B will be different from Shared Key Packet A as Calendar Key A and B will be different. But the unencrypted Shared Key Packet A and unencrypted Shared Key Packet B will be identical and equal to the Shared Session Key.


The ability to send invitations to an event is an essential feature for every calendar. ProtonCalendar will support it with an added security layer. We decided to partially encrypt an event’s attendee list so that the email addresses of attendees cannot be accessed by ProtonMail or by any eavesdropper. This significantly enhances the anonymity of the participants.

To be interoperable with other email and calendar services, ProtonCalendar needs to allow external participants to respond to event invitations. We designed a system that enables RSVP updates from external users without the need to decrypt or sign any data. (This would be impossible as external users don’t have address keys or access to the calendar key.)

For each external attendee, ProtonCalendar generates a unique random token (a string of 40 random characters). This token is encrypted and stored along with the attendee’s email and attendee role. The user’s token is also stored unencrypted and unsigned along with their RSVP status to allow external updates.


This ensures that the attendee can respond to their invitation, even if they are an external user, and that the attendee list cannot be read from the event data.


At Proton, we’re committed to maintaining the highest levels of security and privacy through rigorously applied cryptography, while retaining a high level of usability. We are cognizant of the heightened security needs of many of our users who have entrusted their lives to us, and your protection and safety will always be our first priority. 

To members of the Proton community, thank you for your patience and for affording us the time to properly build ProtonCalendar to meet the highest standards of security. We welcome all comments and feedback about ProtonCalendar’s security model via the bug report feature inside the app. ProtonCalendar is also eligible for our bug bounty program. Additionally, you can always reach us at Thank you for your support!

Best Regards,
The Proton Team

This post was authored by Valentin Bonneaud and Daniel Huigens from the Proton team.

Interested in building products like this? Join us.

You can get a free secure email account from ProtonMail here.

We also provide a free VPN service to protect your privacy.

ProtonMail and ProtonVPN are funded by community contributions. If you would like to support our development efforts, you can upgrade to a paid plan or donate. Thank you for your support.

About the Author


We are scientists, engineers, and developers drawn together by a shared vision of protecting civil liberties online. Ensuring online privacy and security are core values for the ProtonMail team, and we strive daily to protect your rights online.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

46 comments on “The ProtonCalendar security model

  • Wow. Well done! I honestly thought version 1.0 would be way more basic than this and you’d add in sharing later. I cannot wait for the beta version. You guys are amazing and doing an unbelievable service to your customers and also to improving and making the world a better place.

  • Hi there,

    This is a solid write-up and I’m super glad to get some information on the security model ahead of the beta release.

    Now, I don’t mind what the answer is either way, but I’d love to know if ProtonCalendar will interoperate with .ics. The key items I’m interested in hearing more about are:
    – subscribing to iCal, Google Calendar, or event management calendars from services like EventBrite, etc.
    – RSVP’ing to an iCal, Google Calendar, or other similar service’s calendar event invites

    It seems like this may be included, but isn’t clearly spelt out in the article above. I’d also be interested to hear how that affects the security model, understanding that the answer will likely be “not secure at all.”

    Thanks for your time,


    • Thanks, Rylan! During the beta, you won’t be able to import or export your calendar or events. But we’re working on this feature, and it will be available in future releases.

  • I don’t see a way to publish free/busy information without sharing details of the calendar event. I may be missing something. Letting people know times you might be available to accept a meeting is an important feature.

  • A vast amount of work must have gone into developing this product. I can’t wait to start using ProtonCalendar and ditch one more Google product.

  • Tank you so much for this. This is the feature that is going to allow me to finally quit Gmail altogether and fully switch to Proton.

  • Hello ProtonMail team,

    I’d like to know if it’ll be possible to ad attachment, I mean exactly picture to your calendar. Like for example LG G8 calendar can do that.
    Thanks for your hard work, you are the best.

  • Great, but protonmail still can access time of events…This means that protonmail can now what days and what time and for how long we will be doing something right?

    This is the only sad part of it…

    Do you really need to have access to this information? I believe that would be better to encrypt this information in the user’s phone with end-to-end encryption like all the other informations.

    In my opinion if protonmail have access only to the unique event identifier would be enough.

    In my personal opinion a secure, private and encrypted calendar (emails,and everything else), is when I know that the company behind it and everyone else will be unable to “access any information” about what you “did,created,changed,uploaded etc…”.

  • You should focus in further articles on the benefits of your calendar solution with Google’s. Encryption is great and I appreciate what proton is doing but only if there are striking advantages to your calendar solution would I consider using it.

  • Sending the shared session key unencrypted to the invitee may be a security risk. If the invitee is a member of ProtonMail it will be encrypted mail. But what if it’s external? Encryption with the Calendar PUBLIC key may solve this problem.

    • Nice question 🙂 The shared session key will not be sent to external participants. Sharing the session key is only used to make encrypted events possible between multiple ProtonCalendar users in a scalable and easy way. This key is not intended to be shared outside of ProtonMail so there is no risk of sending the shared session key unencrypted.

  • VERY interesting! I can hardly wait to see our new calendar program. I SO want to get away from GoogleCalendar. My calendar/events are noone else’ business but mine.

  • I really hope calendar actually makes it to the market. I as well as others, really want this to be an offering. Especially a paid version.

    • I don’t believe this is planned. For this to work, you would have to add your contacts’ birthdays to your encrypted contacts manually since we don’t have that information about users.

  • How do I import all of my events from my current calendar(s)? I currently use both Google calendars and my iPhone calendar app. Thanks!

  • Qué lástima que todo esté en inglés. Nosotros los hispanohablantes también existimos
    ¿No se le pueden poner colores al calendario?

    • Les vemos! Estamos trabajando en traducciones para todas nuestras aplicaciones, y otros colores vienen pronto. Gracias por su paciencia.

  • Love the beta release!
    I do notice that viewing the Calendar in month view that my events I have populated on certain dates show up as just (1 more)

    Is this the way it will look all the time or will you be able to see a block that is colored according to your calendar profile color.

  • I was so sick of having to chose between being tracked by google and having a working calendar. Glad to see another product coming up. I have high hopes for this calendar and am going to start using it right away.

  • 2 brief questions if I may.
    1. Can I import events from another calendar I have been using?
    2. Will I be able to view birth dates from contacts in Calendar?

    • Good questions.

      1. We’re working on import functionality, and we’ll post an update with this is ready in a later version of the application.

      2. We don’t know your contacts’ birthdays, of course, but you’re welcome to add them to your Calendar. 😉

  • This is a great project, thank you!

    An earlier question asked a good one regarding you (and therefore a potential attacker) from having access to meeting times & dates, plus timezone it says in your article. This does seem like an exposure as the attacker can likely infer a lot from from this information.

    My suggestion is to make the sending reminders optional or let the app do it locally (most calendar apps do this already without needing servers). Also for the timezone just use GMT/UTC time or again have the app translate to local time.

  • Thanks for working on this, as many others I have been waiting for an encrypted calendar for a long time.

    But I don’t really understand your decision to have event time and timezone unencrypted. To me it’s the most important thing to have all the information I enter into my calendar be completely private and encrypted. Surely many other users feel the same way.

    Is this something you would consider making private?

    • For the time being, the event time and timezone will not be encrypted. Without access to the event time, we would not be able to send reminders before events since those must be generated from the back end. However, everything else is end-to-end encrypted.