3 ms·
From https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Technical_Overview https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php... I see the f
by chriswarbo 9y ago
From https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php/Technical_Overview https://tuleap.ring.cx/plugins/mediawiki/wiki/ring/index.php... I see the following under "Ring archive (export.gz)"
> Contains private account data.
> It's a JSON compressed and encrypted file.
> The JSON byte-stream is compressed using gzip algorithm.
> Then the gzip-stream is encrypted using AES-GCM-256 symmetric cipher with a 256-bits key.
Does this compress-then-encrypt combination introduce a security weakness? It's certainly a problem on the Web, since attackers can learn what's in an encrypted response by getting the server to insert their own strings; e.g. trying the same request many times with different query strings, and seeing which ones result in smaller responses, indicating that the given query string matches somewhere in the document.
It would require the attacker to be able to get their own strings in the payload, but since this JSON contains things like contact info that might be possible.
- yorwba 9y agoI'm not completely sure, since "Contact Request" is currently listed as TBD on the wiki, but since the JSON data is apparently limited to trusted user contacts, I assume that they have to be manually confirmed, which would limit the bandwidth of an attack. If the export also requires manual initiation (as the part about manually copying the PIN seems to suggest), this is likely not an issue.
- mnarayan01 9y agoThere might not be enough to get e.g. one of the private keys, but you could probably use it to check for someone else in the contact list. The CRL also seems like it might be possible to at least pivot off of, at least if the signing wasn't checked when writing the archive.