Article is light on the details, but ProtonMail has published some here: <a href="https://protonmail.com/blog/protoncalendar-security-model/" rel="nofollow">https://protonmail.com/blog/protoncalendar-security-model/</a><p>> 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.<p>32-byte passphrase: might be fine, depending on what those bytes are; the interesting question is how much entropy it got generated from.<p>> 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.<p>This is where it gets weird. Why do both? The obvious way to encrypt with an ECC key comes with authentication for free. Signing mostly has negative privacy implications. (I think the answer is "we incorrectly decided PGP was a good idea a long time ago and now we are stuck with its problems, which include being wrong about authenticators".)<p>> 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.<p>Again, with designs less than twenty years old you can do that without a signature.<p>> 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.<p><i>what</i><p>I'm reviewing the attendee scheme next, but I need more coffee first.