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

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


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

> Am 05.12.2012 18:59, schrieb Max Parmer:
>
>> On Tue, Dec 4, 2012 at 12:03 PM, sben1783 <sben1783 at yahoo.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121205/07dca332/attachment.htm>


More information about the Gnupg-users mailing list