[TD-4] Encrypt tasks stored by Task Server

[taskwarrior]

trafficstars

Kosta Harlan on 2013-11-22T14:04:50Z says:

A person's tasks can tell you a lot about their life; protecting this information is important.

Task Server uses encryption when syncing data, but the tasks are then stored in plain text on the server.

In the past, ideas about encryption have been discussed with regards to Taskwarrior here (http://taskwarrior.org/issues/166 and http://taskwarrior.org/boards/6/topics/104).

I would like to know if it is possible to implement encryption such that:

• Tasks may be stored in plain text or encrypted on the user's local .task database
• Tasks are stored only in encrypted format in the Task Server databases

This would allow a user to: (1) maintain a task database on one machine, (2) sync to a task server, (3) and access their tasks on a second machine, but the Task Server admin would have no access to unencrypted tasks.

I'm not sure how much of this is possible with the current Task Server protocol but thought it would be putting out there any way.

[taskwarrior]

Migrated metadata:

Created: 2013-11-22T14:04:50Z
Modified: 2017-06-09T18:17:10Z

[taskwarrior]

Paul Beckingham on 2013-11-22T17:15:06Z says:

While we always had this in mind, it's important to capture the issue so we can assign and track it.

Let's keep the encryption of local data separate from the encryption of server data, so local encryption should be a different feature request.

Taskserver 1.0.0 will not store encrypted tasks, but this is important for a future release.

[taskwarrior]

Renato Alves on 2014-06-25T19:34:59Z says:

This request focuses on protection of data on the server, which I read as one of two situations:

1. You don't trust the server administrator
2. You trust the server administrator but want to be sure that if the server gets hacked your data remains private or at least, not easily accessible.

For 1. encryption could never be done server-side. The server could be easily modified (open-source) to bypass encryption. The only possibilities I see for this situation are:

1a. Use another server that you trust. 1b. Run your own server. 1c. Have the encryption happen on the client prior to sending to the server.

For both 1a. and 1b. there's nothing to be done in taskd.

In the case of 1c, encryption would have to happen on the client side. The way I currently see it, it will make syncing (merging changes) impossible. The server would receive a blob and wouldn't be able to tell apart what changed. Syncing would be equivalent to "Here are my changes, treat these as the most recent" which somewhat defeats the purpose of synchronization. In this situation the job of the taskd server would also be reduced to that of a database with permissions/groups.

So that leaves us with 2. A possibility would be to include the exchange of a passphrase as part of taskd's protocol. The phrase is introduced at the time of sync, either manually by the user or redirected from a file or keychain and known by the client and server only during sync and forgotten afterwards. The passphrase would allow the server to decrypt the existing database, execute the syncronization, re-encrypt and replace the old database with the new blob.

As for the value that this feature adds, I leave this provocation: How much security do we gain by implementing this mechanism when compared with having encryption at the partition or filesystem level?

[taskwarrior]

Kosta Harlan on 2014-06-26T00:37:54Z says:

Thanks for the review and synopsis Renato.

For 1C, what do you think about the option noted in [TW-1245|https://bug.tasktools.org/browse/TW-1245?focusedCommentId=10265&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-10265] of encrypting on a per-field basis? Instead of encrypting the entire file (or an entire task), you would encrypt description, project, tags, UDAs, etc.

[taskwarrior]

Paul Beckingham on 2014-06-26T01:34:25Z says:

Per-field encryption sounds inefficient, in some cases encrypting single words.

[taskwarrior]

Renato Alves on 2014-06-26T10:34:30Z says:

Adding to what Paul said, even if we do per-field encryption, It is not clear how syncing would be achieved once the field is turned into a blob. I need to increase the test-suite on the sync mechanism in order to be able to answer that with more confidence.

Maybe Paul knows best. Apart from the inefficiency and the possible loss of security due to "guessability" of the content if done per-field, do you see any problem arising in the sync protocol once we have blobs instead of sensible text?

The points I see as possibly problematic are:

• Same content may have different blob representation due to salting.
• Some fields cannot be encrypted (UUID, parent, imask, mask) others may be better decrypted (status).
• Some fields may require encryption of the field name or a change of format (annotations)

[taskwarrior]

Kosta Harlan on 2014-06-26T12:50:12Z says:

Ok, maybe instead trying to encrypt all fields, project, description, annotation (the contents, not the timestamp) would be enough.

[taskwarrior]

pepa65 on 2016-09-26T07:57:30Z says:

I think 1c is very worthwhile. I don't know how large some people's storage gets, but for me, even if it uploads all my data for every 'sync' in encrypted form, that would be great. And it shouldn't be very hard to implement it this way.

For larger amounts of data, there are also ways to encrypt the data and still be able to benefit from deduplication, but I don't think it's necessary to go there. For people that want/need encryption, they will contend themselves with having a backup of their data rather than an actual sync of changed items.

[taskwarrior]

Tim Ruffing on 2017-06-04T14:45:34Z says:

I've been using taskwarrior for a few months now and I really like it. The only feature I'm missing is sync (also with Android) because I don't want to give away my data in plain.

I'm an applied crypto researcher and I'm willing to give something back. So I can offer a little bit of my time for designing and helping to implement an encrypted sync mechanism.

Picking up the discussion here: Could you explain why syncing is not possible in 1c? What if the server really just stores an encrypted blob and the clients care about merging. (Maybe similar to the old merge command?)

[taskwarrior]

Paul Beckingham on 2017-06-06T23:38:19Z says:

A task is not just a blob on the server, it is a collection of attributes, each of which can be merged during syncing. To move merging to the clients would require a different sync algorithm. The current algorithm is documented online.

[taskwarrior]

Tim Ruffing on 2017-06-07T06:18:00Z says:

You mean this here, right? https://taskwarrior.org/docs/design/sync.html

Is there a fundamental reason why this algorithm cannot be performed by the client instead? I don't see one. In such a model, the client will be responsible for pushing the merged state back to the server.

Even if there is no fundamental issue with this model, it is of course annoying, because you want many client implementations and just one server implementation. Having as much logic as possible at the server side is a good idea obviously, and I could imagine that this was the reason to change to the current sync model. Or were there other issues with the old model?

Sorry for asking these naive questions, I'm not familiar with the code base and still trying to understand what's going on...

[taskwarrior]

Paul Beckingham on 2017-06-08T12:51:18Z says:

I would love to take advantage of your crypto experience to achieve this. However, encrypting/decrypting blobs on the client is not the first step.

You question essentially boils down to "Can the merge occur on the client?". The answer is probably yes, but obviously with a different protocol. This reduces the question to "Can it all be reimplemented?" Of course, but not while maintaining compatibility, and not without a proven protocol. This means we need a protocol.

I agree that putting a more complex protocol in the client, guarantees that clients will implement it wrong. It's already happened with the simple client protocol.

[taskwarrior]

Tim Ruffing on 2017-06-09T07:51:45Z says:

Thanks.

bq. This reduces the question to "Can it all be reimplemented?" Sure, and of course my intention is not to be the random guy on the bugtracker that appears out of the blue and says "Oh, the current stuff does not work, just throw it away." The goal is to understand the actual underlying problem, ignoring what's currently implemented in a first step. And your answers helped a lot here with that. I'll think about this further.

[taskwarrior]

Paul Beckingham on 2017-06-09T18:12:15Z says:

Now you're making me think about this, which is a good thing. I appreciate the questions. I think I have an idea.

Tim: Would you be willing to continue a long-form chat with me over email? I have questions, and would like to post only something fully baked online, if possible. Also, Jira is not the best way to do this.

[multimeric]

So, where are we at with this task? I'm happy to help, but it seems that there's a bit of disagreement on how to even implement encryption

[multimeric]

It looks like the two contenders are:

a) Encrypt in the client, but only encrypt the actual fields, not the entire message, allowing the server to understand the structure of the message b) Encrypt the whole message, so the server only sees and encrypted blob, then perform the actual merging in the client

[coffebar]

It's absolutely must have feature

[msm-code]

I'm hosting a small taskwarrior server for me and my friends. I absolutely don't want to see their tasks, but encryption is not supported yet. I am (similarly to @multimeric) happy to help with this if help is welcome, as soon as I know which design is preferred.

(Personally i'd prefer a - encrypt some fields, not entire message. Just because it's easier to implement and good enough to solve my problem).