Is it safe to rename file.gpg to `md5sum file`?

Max Parmer maxp at
Thu Dec 6 00:10:19 CET 2012

On Wed, Dec 5, 2012 at 1:39 PM, Ben Staude <sben1783 at> wrote:

> Am 05.12.2012 18:59, schrieb Max Parmer:
>> On Tue, Dec 4, 2012 at 12:03 PM, sben1783 <sben1783 at> 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:

>  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121205/07dca332/attachment.htm>

More information about the Gnupg-users mailing list