Am 05.12.2012 18:59, schrieb Max Parmer:
On Tue, Dec 4, 2012 at 12:03 PM, sben1783 <sben1...@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.
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 I wanted to have a fallback for loosing the mapping table, would
there be a sane way to encrypt the filename with gpg? That way I could
decrypt it in case I loose the mapping table (which isn't possible with
the GUID solution). I tried
echo '/path/to/original/filename' | gpg --armor -c
but the result contains newlines and slashes which isn't good for use as
filenames. There's no option like "--armor-only-alphanumeric"...?
Thank you very much
Ben
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
