Encrypting specification elements

[niccokunzmann]

I would like to add encryption for this reason:

Some URLs must be private because they contain sensitive data.

These are requirements:

• encrypted URLs must not be reproducible
• only one server can decrypt the url
• migration MUST be possible

A solution that would fit the case:

value to encrypt

The value to encrypt will be a JSON:
With an optional password (can contain all Base64 values).

{
    "value": JSON-VALUE,
    "pass": ["...", ...]
}

The resulting string can be generated:

>>> import json, cryptocode
>>> v = json.dumps({'value': True, 'pass': []})
>>> cryptocode.encrypt(v, 'server key')
'QzXg03hRbiZ/YsJqLFCbj7vfspbRs5jzohpcQCrq2g==*LgyHGOznl+Cs5pUpDJwEfQ==*4TBcbK75VoFfkH+SlClBeA==*7G84p/ru2nVRaYRNYyOksA=='

This value can be stored anywhere in the specification as a 'decrypt://...' string. If the value can be decoded, it will replace the string.

The server key originates from an environment variable.
If this variable is not set, encryption must not be possible.

How to encrypt

You can encrypt values by posting/getting from the server, also via XMLHTTPRequest and JSON.
The result you get is the string.
You can encrypt as many values as you like.

How to decrypt

A decrypted value MUST not be included in the specification that is sent back to the client.
We can make this sure by:

• subclassing to make the value NOT JSON serializable + according tests
• using a to_json() method on the value which then results in the original value

test:

• json serialization / not being able to do that
• not sending to other places like event JSON or .ics feed

How to migrate

The values might have a 'session' in them. This session identified who is allowed to read the value as plain text.
If a calendar contains encrypted content, the web page shows this text:

This calendar contains encrypted content. If you would like to see all the content, please enter the passwords here:

GET /calendar.spec?password=...&...usual url...

{
  ... JSON with all content that contains the password decrypted and included
}

This will allow encrypting the content that is OK to decrypt and migrating the calendar.
Multiple session ids are allowed so that we can make sure that the same value can be retrieved from encrypting and editing and encypting by adding the session ids.

Encryption in the UI

Since URLs can contain sensitive data, the user should be made aware of this. There should be a checkbox next to the URL allowing encryption and showing the decrypt:// string in case the password is wrong.

Advantages of this approach

This allows migration.
This also allows migration to another instance using the original OWC instance with an encrypted URL, fetching the content from there.
The server key is never shared.

Disadvantages

Users have to remember a password to decrypt the calendar. They could use this again and again and they cannot change it.
The server has to run with the same key the whole time.

How to merge servers

If one want to merge several OWC instances (close two, open one with both keys), the server key must be a list of possible values, separated by comma.

See also:

• CALDAV synchronization #189

---

We're using Polar.sh so you can upvote and help fund this issue. We receive the funding once the issue is completed & confirmed by you. Thank you in advance for helping prioritize & fund our work.

[niccokunzmann]

NF-008 — This is generally safe to do. However:

• If you let users choose the passwords, they are potentially unsafe
• To solve: A server cannot change its secret without losing the ability to decrypt content previously encrypted with an older key

See also #595