On Wed, Dec 5, 2012 at 1:39 PM, Ben Staude <[email protected]> wrote:
> Am 05.12.2012 18:59, schrieb Max Parmer: > >> On Tue, Dec 4, 2012 at 12:03 PM, sben1783 <[email protected]> wrote: >> >>> Yes, I meant to use the MD5 checksum of the original file, not its >>> original name. I'm still interested whether this would be "insecure"? >>> >> > If by insecure you mean, "could lead to exposing the contents of the file" >> or "could reveal my passphrase" that would depend (in part) on the size >> and >> contents of the file (i.e. very short files would less time consuming to >> brute force, files with very regular formats would be quicker to brute >> force, etc.) and the symmetric cipher used. >> > > Yes, that's exactly what I meant with "insecure". So I learn from your > statement to better not use the md5 hashes. > > > Revealing the plaintext of some files could be fairly significant with the >> default symmetric cipher for GPG is CAST-128 which is potentially subject >> to key recovery via a chosen plaintext attack. AES doesn't have any >> presently known vulnerability of that sort. >> > > While browsing for recommandations on what algorithm to use, I didn't come > across the "vulerability" you mention above. I don't really understand what > you're saying, but anyway plan to use AES because it a) seems to be the > algorithm "more state of the art" and b) uses MDC by default. Here's my cite on the CAST weakness: http://www.schneier.com/paper-relatedkey.html > If you just need a unique key to refer to the file, you're already storing >> the source path in the "summary" file your tool generates. If you just >> need >> a guaranteed unique identifier for each file (because, say, you're storing >> them all flatly in a single directory), I would just hash the path (which >> is apparently not sensitive data, as you seem to be storing it in >> plaintext >> in the summary file) as it's guaranteed to be unique per-system. >> > > Well I do *not* want to reveal my private paths/filenames in the remote > backup location. I won't upload the summary file as plaintext, but maybe > encrypted as contents.gpg or the like. So I need another identifier for > each file and some sort of mapping. That's why I came up with the md5sum of > the files contents in the first place - I already have the mapping table > (the summary file). If that's no good idea, I will probably just use a GUID > for each file and create a separate mapping table (which also won't get > uploaded without encryption:) > If you're going to encrypt the summary file then you can store anything as sensitive as the rest of your backup data in it... -- Max Parmer 5D99 D929 93FE EE79 1645 D77A D771 E875 20CB D918
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
