[Standards] Encrypted Storage (Was: off-server archives with MAM)
georg at op-co.de
Sat Apr 18 09:42:10 UTC 2015
* Peter Saint-Andre - &yet <peter at andyet.net> [2015-04-18 04:59]:
> [MAM privacy concerns]
I wholeheartedly agree with you here, but I would like to see another
solution to this - use of asymmetric crypto storage on the server, a la
1. When a user logs in for the first time, an asymmetric keypair is
created (I was thinking of Curve25519, where key creation is almost
free). The private key is encrypted with a key derived from the user
password / SASL state (https://www.zash.se/mod_storage_encfs.lua.html is
a PoC for that).
2. All data that is stored for the user is encrypted with their public
key and appended to their "container".
3. When the user logs in, the private key is unlocked for the duration
of the user session, allowing them to access/modify the container (i.e.
retrieve MAM / offline storage).
I am aware that such a mechanism will not protect against malicious
admins or live access to the server, but off-server archives provide
the same level of security, just with slightly better detectability of
OTOH, such a storage mechanism can be created without modifying the XEP,
and it can be adapted/extended to improve the privacy of other things as
well, like private xml, roster, etc. For this, we just need to group the
different elements stored on the server by their access patterns, i.e.:
* offline storage / MAM: append-only when user offline (solvable with
* roster: append for subscriptions, check of existence (i.e. solvable
with unencrypted storage of hashed JID)
> Using Carbons (XEP-0280) [the off-server storage] could obtain copies
> of all the messages I send and receive.
I really dislike (ab)using carbons as a MAM pseudo-subscription. We need
to (at least) provide an atomic operation for MAM retrieval and MAM
subscription (a.k.a. carbons) to prevent race conditions at the
beginning of a session. My gut feeling is that there are some more
corner stones when using Carbons as a MAM subscription, but I haven't
looked into the possible implications yet.
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards