Truecrypt volume on ftp server inferior to sftp?
 

If one uses a free ftp account to store private data such as bookmarks, they might prevent any eavesdropping by using ssh for the transfer (ftps), or alternatively sftp. However, they would still have to trust the ftp hosting provider, because the data is stored unencrypted in the server.

Someone suggested putting all bookmarks in a small truecrypt volume instead and synchronizing this with the ftp server.

Performance issues aside, given that the plaintext only changes a little in each resync (only a bookmark is added usually), is the use of the truecrypt volume introducing a means for an eavesdropper to break the code?

The amount of changes made to the plaintext should be irrelevant to the resilience of the ciphertext. In other words, assuming everything is kosher (no weak/broken algorithms, bad guys don't have access to the key, etc.), the bad guys shouldn't be able to know how much has changed between each version of the file (or make any other determinations about the plaintext, for that matter).

EDIT: When I wrote this reply, I wasn't thinking about TrueCrypt. I was mainly thinking about an encrypted gzipped-tarball, which is what I use when I need to store sensitive data at remote locations. In my case, the bad guys wouldn't be able to tell whether I changed a few characters or megabytes of data (since I'm re-uploading the entire thing any time I change something). Obviously, the same doesn't apply to volumes, as certain observations can be made and conclusions reached by bad guys who are able to monitor the encrypted traffic to/from the data store (statistical analysis of encrypted traffic isn't anything new). But still, this should not in any way hinder the actual strength of the encryption, which I believe is your main concern. If it did, then that would mean something was terribly, terribly wrong.

What if the bad guys have all the versions of the encrypted gzipped-tarball you have ever saved? Btw, do the versions differ in just as few bytes or are they entirely different? And what if the bad guys have all the versions of the truecrypt volume?

Edit: Let's say the bad guys guess you are saving bookmarks, therefore they know you only add a bookmark's worth of plaintext at the end of each version.

It wouldn't make any difference.

The assumption is, from the start, that the bad guys will have complete access to the ciphertext.

The difference between the plaintext in one version and the next could be a single character, and the bad guys wouldn't know it. In fact, they wouldn't even know if there weren't any changes at all made to the data. This is because a new key is used for every upload, making it extremely difficult (cryptographically speaking) for the bad guys to analyze the relationship between one version and the next (the ciphertext will be completely different).

I'm assuming that a remote TrueCrypt volume doesn't provide this kind of feature/benefit, but I may be mistaken. Honestly, I don't use TrueCrypt (and I'm not familiar with it) so it would be unfair for me to comment on its inner-workings. All I can say is that it would be really, really weird if the TrueCrypt developers haven't thought about the scenario you're presenting.

Hopefully, someone knowledgeable with TrueCrypt can shed light on the particulars involved.

Again, any cryptographic solution will need to assume (from as early as the design phase) that the bad guys have access to all the ciphertext, so that doesn't change anything.

In the gzipped-tarball scenario, this wouldn't be computationally feasible, so I'm gonna assume you're referring to TrueCrypt, in which case all I can really say is that there's nothing wrong with them making an educated guess (see my previous point about statistical analysis).

Aha, you were thinking of changing the key every time, in which case it is obvious the extent of changes in the plaintext is irrelevant. But I was thinking of a constant key in all versions. This is what a truecrypt volume would do (unless you remember to change the key before every transfer to the ftp server).

Does the fixed key in all versions of this archive introduce the possibility for the eavesdropper to work out the key from the small differences between versions of the encrypted text? Especially given the knowledge of the changes (they contain http://, they might end in .com and a newline, they might be a link the eavesdropper suspects, etc).

There's a difference between the key you choose, and the key that is applied to the data (depending on the algorithm). Google for 'key schedule' and you'll get an overload of information on the subject. The basic idea is that every bit of data should modify the sub-keys enough to allow the data to continue to appear "random".

So the entire 10 MB truecrypt volume would change when the last 20 bytes of the plaintext change while the key you choose stays constant?