Autocrypt internal data in Akonadi

Sandro Knauß sknauss at kde.org
Thu Sep 24 02:26:04 BST 2020


Hi Ingo,

it took me a while, as I was busy with other stuff. But now I started to 
implement autocrypt *YEAH*:
https://invent.kde.org/knauss/messagelib/-/tree/autocrypt
 
> Do you know about GnuPG's plans for automated encryption?
> https://wiki.gnupg.org/AutomatedEncryption

A little bit ;) Do you have any tasks that describe your planned work any 
further?

> > The data I need to store is per email address [1]:
> > * last_seen (timestamp)
> > * autocrypt_timestamp (timestamp)
> > * public_key (public key material)
> > * prefer_encrypt (boolean)
> > * gossip_timestamp (timestamp)
> > * gossip_key (public key material)
> > 
> > All those data need to be updated, when a new email is processed.
> 
> I'm wondering whether it wouldn't be better if this data was stored by GnuPG
> rather than by the client. I think, the last_seen timestamp is already
> stored by GnuPG as part of TOFU.

I don't think that it makes it easier, if we place some data into gnupg and 
some we store outside. As the autocrypt keys should not enter the normal 
keyring, as those keys can be replaced everytime by purpose. So if we would 
store them in the normal keyring, we would break current encrypted 
communication.

> Since this data can be highly sensitive, I think, that the synchronization
> must be end-to-end encrypted. Therefore, I'm skeptical about using Akonadi
> for synching this data using normal Akonadi synchronization features that
> do not guarantee confidentiality.

Well all the data that Autocrypt is storing are non confidential so I see no 
privacy breach in storing those data in Akonadi. And we already have filters to 
store decrypted mails in Akonadi, so we trust Akonadi to not give those data 
to an untrusted source. Autocrypt data is only about public key material and 
some timestamps when those keys were seen, so I see them a less critical than 
decrypted mails.

> See above. Did you consider GnuPG? Did you talk to Andre Heinecke who will
> need the same for GpgOL? I'd appreciate if we joined forces on this.

> Independent of the possibility for joining forces I'm wondering whether
> using Akonadi as datastore for this data is a good idea.
> 
> I'd prefer to let GnuPG handle the storage. I may be able to help with this.
> If using GnuPG is not an option, then I'd prefer a storage that is
> independent of Akonadi. A future end-to-end-encrypted synchronization could
> still be implemented using Akonadi at a later point in time.

GnuPG is not a datastore where I can save random data (like gossip_timestamp, 
prefer_encrypt, gossip_key), so how you think I could use GnuPG as a 
datastore?
I'm currently in favor of do an easy solution and just use a directory with 
json files to store those data. I think for the first implementation this would 
be enough. But maybe if you have better ideas...

Anyways I'm always up for joining forces. 

hefee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200924/bd6cfc00/attachment.sig>


More information about the kde-pim mailing list