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

2012-12-06 Thread Werner Koch
On Wed,  5 Dec 2012 22:39, sben1...@yahoo.de said:

 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

   --set-filename string

  Use string as the filename which is stored inside
  messages.  This overrides the default, which is to use the
  actual filename of the file being encrypted.

If you want later want gpg to output to this file, you may use

   --use-embedded-filename
   --no-use-embedded-filename

  Try to create a file with a name as embedded in the
  data. This can be a dangerous option as it allows to
  overwrite files. Defaults to no.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-05 Thread Max Parmer
On Tue, Dec 4, 2012 at 12:03 PM, sben1783 sben1...@yahoo.de wrote:

 On Tue, 4 Dec 2012 14:40:22 +0200, yyy y...@yyy.id.lv wrote:

 There isn't enough entropy in a filename for an MD5 checksum to give
 much in the way of secrecy.


 It seems that MD5 checksum is computed from file contents, not name.


 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.

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.

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.

If you just need file integrity checking, the algorithm more-or-less takes
care of that.

I wouldn't use the md5 hash of the file's contents, if the contents are
sensitive.


 I found a discussion on this list in 2011, where user atom wrote:

  just make sure you're hashing the file-NAME, not it's contents.
 of course, if you don't lose your db, then there's nothing wrong
 with hashing the contents, or even a counter or random string. hashing
 the file-NAME is just an idea that makes recovery of the db possible if
 you know the format and range of the file-names (and any secret that
 may be used). the real trick is to just do something secure and
 consistent... sha1 does the job.


 (http://www.mail-archive.com/**gnupg-users@gnupg.org/**msg15110.htmlhttp://www.mail-archive.com/gnupg-users@gnupg.org/msg15110.html
 )

 He states it's not a problem to hash the files contents, but it seems
 to be thought of no different than counter and random string - this
 are completely different things IMHO.

 And, by the way, how could the hash of a filename be used to reconstruct
 the filename (as atom says ... makes recovery of the db possible ...)
 There is no such thing as inverse-md5sum, is there? You'd still need
 brute force to find the original name?

 Thanks
 Ben



 __**_
 Gnupg-users mailing list
 Gnupg-users@gnupg.org
 http://lists.gnupg.org/**mailman/listinfo/gnupg-usershttp://lists.gnupg.org/mailman/listinfo/gnupg-users




-- 
Max Parmer
5D99 D929 93FE EE79 1645  D77A D771 E875 20CB D918
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-05 Thread Ben Staude

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


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

2012-12-05 Thread Max Parmer
On Wed, Dec 5, 2012 at 1:39 PM, Ben Staude sben1...@yahoo.de wrote:

 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.


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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-05 Thread Robert J. Hansen
On 12/5/2012 6:10 PM, Max Parmer wrote:
 Here's my cite on the CAST weakness:
 http://www.schneier.com/paper-relatedkey.html

This falls squarely into the range of theoretical breaks.  Notice that
the attack requires 2**17 chosen plaintexts to all be encrypted with the
same symmetric key.  Since GnuPG uses disposable session keys, this is
pretty much completely irrelevant to GnuPG usage.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-05 Thread vedaal
Ben Staude sben1783 at yahoo.de wrote on
Wed Dec 5 22:39:04 CET 2012 :

 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 don't mind *really. really long* entries  ;-)  in your re-naming table, 
you can do something like the following, and never have to worry about the 
mapping table getting lost.

Encrypt the actual filename symmetrically,  add the resulting ciphertext to the 
end of the file, and then save the resultant encrypted file with encrypted 
ciphertext as fn1.asc and the ciphertext of the filename in the mapping table 
for fn1.asc

i.e.

after doing 
gpg --cipher-algo AES256 -c -a real_filename

resulting in something like:

-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.12 (Cygwin)

LONG/ASCII/Armored/CIPHERTEXT
=checksum
-END PGP MESSAGE-


do

$ printf real_filename | gpg --cipher-algo AES256 -c -a

Resulting in

-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.12 (Cygwin)

jA0ECQMCMu4SzytLjoFg0kIBlWVEKygTWNEjNi/sc/Anvc10SokQC9X6k2GZz1py
a+GzL+/HcUkg8P97d197FGyqpPghYMqEcp6CtYpn6zYkVew=
=Yv5u
-END PGP MESSAGE-

(passphrase; sss)

Add the above ciphertext, with the header and footer intact,  to the bottom of 
the ciphertext of the encrypted actual file, 

i.e.

-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.12 (Cygwin)

LONG/ASCII/Armored/CIPHERTEXT
=checksum
-END PGP MESSAGE-

-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.12 (Cygwin)
Comment: encrypted real filename of above encrypted file

jA0ECQMCMu4SzytLjoFg0kIBlWVEKygTWNEjNi/sc/Anvc10SokQC9X6k2GZz1py
a+GzL+/HcUkg8P97d197FGyqpPghYMqEcp6CtYpn6zYkVew=
=Yv5u
-END PGP MESSAGE-

and save the whole thing as fn1.asc, and similarly, for the rest, as fn2.asc, 
fn3.asc, ... ,  fnn.asc .

In your mapping table, 
fn1.ascwould be   
jA0ECQMCMu4SzytLjoFg0kIBlWVEKygTWNEjNi/sc/Anvc10SokQC9X6k2GZz1py
a+GzL+/HcUkg8P97d197FGyqpPghYMqEcp6CtYpn6zYkVew=
=Yv5u

If your mapping table ever gets lost, you can easily recover the filename by 
decrypting the added ciphertext at the end of each encrypted file.


vedaal


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-04 Thread yyy



There isn't enough entropy in a filename for an MD5 checksum to give
much in the way of secrecy.



It seems that MD5 checksum is computed from file contents, not name.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-04 Thread sben1783

On Tue, 4 Dec 2012 14:40:22 +0200, yyy y...@yyy.id.lv wrote:

There isn't enough entropy in a filename for an MD5 checksum to give
much in the way of secrecy.



It seems that MD5 checksum is computed from file contents, not name.


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?

I found a discussion on this list in 2011, where user atom wrote:


just make sure you're hashing the file-NAME, not it's contents.
of course, if you don't lose your db, then there's nothing wrong
with hashing the contents, or even a counter or random string. 
hashing
the file-NAME is just an idea that makes recovery of the db possible 
if

you know the format and range of the file-names (and any secret that
may be used). the real trick is to just do something secure and
consistent... sha1 does the job.


(http://www.mail-archive.com/gnupg-users@gnupg.org/msg15110.html)

He states it's not a problem to hash the files contents, but it seems
to be thought of no different than counter and random string - this
are completely different things IMHO.

And, by the way, how could the hash of a filename be used to 
reconstruct

the filename (as atom says ... makes recovery of the db possible ...)
There is no such thing as inverse-md5sum, is there? You'd still need
brute force to find the original name?

Thanks
Ben


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-04 Thread Robert J. Hansen
On 12/4/2012 3:03 PM, sben1783 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?

Let's not even use the word insecure, since that word is wholly
subjective: there's no agreed-upon definition for what it means.
Instead, let me ask a different question: what, precisely, are you
trying to accomplish?

 And, by the way, how could the hash of a filename be used to reconstruct
 the filename (as atom says ... makes recovery of the db possible ...)
 There is no such thing as inverse-md5sum, is there? You'd still need
 brute force to find the original name?

Sure, of course there's inverse-md5sum -- after a fashion.  Many files
bear names that are just a couple of short words: Tuesday report.doc,
for instance.  So you go through a dictionary and compile a list of
every one and two--word filename, separating by underscores and spaces,
and using the top 100 file extensions.

There are about 5,000 words in common usage in English.  (A native
speaker will have a larger vocabulary, but you can get by quite well on
5,000 words.)  Every possible one and two-word combo from this list
would amount to about 25 million entries in the database: multiply by,
say, four, to represent different conventions for capitalization and
spacing and whatnot, brings you to 100 million.  Multiply by the top 100
file extensions and you get 10 billion.  Each of those records would
require about 100 bytes of storage, or 1 trillion bytes.

You could easily store it on a $100 hard drive.

This is what's called a dictionary attack.  There are other much
better ways to attack it: rainbow tables, for instance.  But this is
enough to show you that MD5 is nowhere near as hard to reverse as you
might think.  If you're creating filenames based on the MD5 hash of the
entire file, that would be (probably) nontrivial to reverse: if you're
creating filenames based on the MD5 hash of the original filename,
you're playing with fire.

That said: please don't use MD5.  Please use a better, stronger hash
algorithm like SHA-256, SHA-512 or SHA-3 instead.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

2012-12-03 Thread Ben Staude

Hi all,

I'm thinking about a scenario for remote backup with gpg-encrypted files 
(--symmetric, one by one). In addition to encrypting the files contents, 
I'd like to hide their names also.


My backup tool can do the gpg-part for me (i.e. encrypt every file when 
backing it up) and it creates a summary file with the source path of 
every file, some stat() details and (for deduplication purposes), the 
md5sum of the original file. Now one simple and convenient approach to 
hide the file names would be a small script that iterates over the 
summary file and renames each gpg'ed file with it's own (unencrypted) 
md5sum. That way, I could use the summary file as a lookup table to find 
an encrypted, md5sum-named file by its original name/path.


Is this a sane way to go? I'm wondering whether the md5sum leaks too 
much information about the original file contents, so that the 
encryption (--cipher-algo AES256 would be my current choice) isn't 
really safe any more?


Thanks in advance
Ben

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users