[Duplicity-talk] Untrusted destination questions/issues

[Daniel Burdakov]

> Because duplicity uses GnuPG to encrypt and/or sign these archives, they will 
> be safe from spying and/or modification by the server.
I like this idea of "untrusted destination", but have some questions about it.

All data on server are:
- manifest (one per backup)
- volumes of content, "difftar"
- volumes of signatures, "sigtar"
Correct?

All these files are encrypted and signed with GnuPG, correct?
Server can not read any of these files, because they are encrypted.
Server can not modify any of these files or add some new files,
because it will broke GnuPG signature.

If server deletes some volumes of content then "duplicity restore"
will read manifest to enumerate volumes, and fail when trying to read
that volume, that's OK.
If server replaces some volumes of content with other volumes (the
GnuPG signature will be correct), "duplicity restore" will read
manifest with SHA1 hashes and complain "Invalid data - SHA1 hash
mismatch", that's OK.

What if server deletes some volumes of signatures?

If server replaces some volumes of signatures with other volumes...
GnuPG signatures will be still valid, but I have not found SHA1 hashes
for "sigtar" files in manifest, so it will not be detected?
I can not find exploit for it just now, but why "sigtar"-s are not
protected by storing their SHA1 hashes in manifest?

If server deletes some manifests with corresponding content and
signatures, then "duplicity collection-status" will help to detect it
by showing date of last backup in chain.

So, duplicity relies on names of manifests to build backup chain. But
these names are not protected from modification by the server.

What server can do with it?
Imagine three backups:
duplicity-full.A.manifest.gpg
duplicity-inc.A.to.B.manifest.gpg
duplicity-inc.B.to.C.manifest.gpg

Here A, B, C - are some timestamps.

Server can remove duplicity-inc.B.to.C.manifest.gpg (and all
associated volumes), and rename duplicity-inc.A.to.B.manifest.gpg to
duplicity-inc.A.to.C.manifest.gpg (and all associated volumes).

So the last diff, B.to.C, is lost.
But duplicity will never know about it: GnuPG signatures are OK, SHA1
hashes are OK, last backup date is OK, it is C as expected.

If someone will restore at this point, he will get undetectable data corruption.
I have tested it on duplicity 0.6.08b.

Conclusion.

I suggest:
- Add line with own filename inside manifest, so renaming file will
break GnuPG signature. Check this line every time when manifest is
read. This will prevent server from manipulating with backup dates.
- Add SHA1 hashes of "sigtar" volumes to manifest, to protect
"sigtar"-s from replacing.

Also, it will be great, to have a page with explanation of duplicity's
backups format with some proof of "safe from spying and/or
modification by the server". I didn't find one.

Correct me, if I misunderstood something.