Re: File Encryption

[Robert J. Hansen]

> Steve Gibson [0] has a slightly different opinion of the code:-
> 
> "It is truly lovely. It is beautifully constructed. It is amazing
> work to be deeply proud of."

I do not personally find Gibson to be a credible commentator.  He's made
a lot of really embarrassing brainos over the years -- like when he
predicted that TCP raw sockets would be the coming of the Information
Apocalypse.  There have been lots of other examples.  Check out his
Wikipedia page under "Controversies"; these have all been errors of such
magnitude that I'd be wearing a paper bag over my head.

I know a lot of people listen to him, but ... frankly, I do not have a
high opinion of his skills and commentary.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: File Encryption

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Saturday 27 December 2014 at 4:28:42 AM, in
, Robert J. Hansen wrote:


> The
> code is a mess, yes

Steve Gibson [0] has a slightly different opinion of the code:-

  "It is truly lovely. It is beautifully constructed. It is
  amazing work to be deeply proud of."


Maybe he read a different audit report than I found at [1].


[0] 

[1]



- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

If you are afraid to speak against tyranny, then you are already a slave.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJUnq55XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbxYH/RyI00dob4WzLPooylTzNte6
qXAL571Lvx8b02jv22O6qplNaRCpYV0UatlVW4IzxoOUFeyjPSGTWP5hXtOPPqBJ
OXh9YhOvRhLyaModEaETxCwna0vDIQUw4IqjOnzKdHwr+2V7gWzPliUGZmUh0cMq
b7wrWtOyJ4387iSzcmPs862DDozrkdXM93Jrv/6823ugqaZPZHSNMME36qLfZMUG
Kaxxt3m4u8mzAAk1hGjOgK1bC9UuUIR20SRNXYAVhlDRLxyk1z/pwsZ8iiGNRH59
3YjnLyKsKPE3nu8wg6qgsg6/uL43RAgRx3RXPe6PS9sfAcVInSBs/CWtUqJ9oxmI
vgQBFgoAZgUCVJ6ugl8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45B32AQC2fmmiE+caapEygHYivHJtXe/+
ds6aOc21EGqrJgdtqQEAlxgiCnD0CmPXyXKzGXgiJJCZLS31BeOlirltt/yd3Ag=
=Cbkb
-END PGP SIGNATURE-


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

Re: File Encryption

[Robert J. Hansen]

> Robert: In spite of the fud about TC, do you still like it?

First, please don't respect my opinion on it -- I don't think I know
enough to have an opinion on it!

TrueCrypt has published source and a lot of people looking at it.  Prior
versions of TrueCrypt sometimes had appalling failures (what was it, in
5.3 it actually stored passphrases in RAM in cleartext), but current
versions seem credible.  I'm unaware of any published attacks on the
latest TrueCrypt, nor am I aware of any research indicating there are
numerous problems.  The code is a mess, yes -- but that's not by itself
evidence of a major problem.

Please don't read this as a recommendation.  It's more of a, "if you
need free software disk encryption for Windows then it's your only real
choice, and it doesn't appear to be an obviously stupid one."

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

Re: File Encryption

[Stefan Caunter]

On Sat, Dec 20, 2014 at 7:32 PM, Robert J. Hansen  wrote:
>> I'm a home user of Linux. I'm looking for an encryption utility for
>> my personal password file, preferably one with a graphical user
>> interface.
>
> Have you considered either encrypting your /home directory (with
> dm-crypt, LUKS, pick your poison) and/or using an encrypted folder
> (TrueCrypt, etc.)?  Either of those would possibly be a much more
> user-friendly experience.

Robert: In spite of the fud about TC, do you still like it? I respect
your opinion on this.

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

Re: File Encryption

[Stefan Caunter]

On Sat, Dec 20, 2014 at 7:32 PM, Robert J. Hansen  wrote:
>> I'm a home user of Linux. I'm looking for an encryption utility for
>> my personal password file, preferably one with a graphical user
>> interface.
>
> Have you considered either encrypting your /home directory (with
> dm-crypt, LUKS, pick your poison) and/or using an encrypted folder
> (TrueCrypt, etc.)?  Either of those would possibly be a much more
> user-friendly experience.

Do you subscribe the the FUD about TrueCrypt? I haven't read anything
objective lately about it.

/S

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

Re: File Encryption

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Tuesday 23 December 2014 at 7:28:32 PM, in
,
Ryan Sawhill wrote:



> I have no idea how much work it would require. No one's
> ever expressed an interest, myself included.

It was more idle curiosity really.




- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

Always forgive your enemies; nothing annoys them so much
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJUmeIfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw6o8IALdDsSw5UN7+to5jjZONRUAt
DUGHzWrY2xBa6/LMK/CVtpCCPuOIJ1rTj2qVpuohnMyBp/+y7ED81DUA0wWqxz9i
c1Azvzt9LKWKobQ7VavmYC972TZbqXi4q7b0Sqc0Q9PZP6s8P4nmIedBIm47NXBg
M9tPKhI6SbU62Wfa79/FsHKY6bEn6Hsam+stGjhINBddtO0Pc0sgD2ginfhz5ntU
SJxhA/sNeLogaNNMfIYYgfL3bgumz3kKcXhcsP6TXj/vedIXmbW1H9gP944WVX8A
auDVkwvb527O/q3MRj8sA0Lz6Z9PIU0cDMWkWhhZ6xfyOvSATZLnRvbznGnl+xKI
vgQBFgoAZgUCVJniKl8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45CMCAQB2b+kZCS+g0/uo1TDdLXeGXg3y
KGlCNo9ztrWl968g0AEANOB6wjLMouGPs3v2CdwdRcB+CYvE7JK7FLE2Y+Z/lAA=
=J6Jp
-END PGP SIGNATURE-


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

Re: File Encryption

[Ryan Sawhill]

On Tue, Dec 23, 2014 at 2:18 PM, MFPA <
2014-667rhzu3dc-lists-gro...@riseup.net> wrote:

> Since Python and GTK can both be used on Windows, does Pyrites work on
> Windows as well? And/or could it be converted to a standalone Windows
> executable using something like Py2exe or cx_Freeze?
>

I have no idea how much work it would require. No one's ever expressed an
interest, myself included.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: File Encryption

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Tuesday 23 December 2014 at 5:45:04 AM, in
,
Ryan Sawhill wrote:


> GUI, pyrite (
> http://softwarerecs.stackexchange.com/questions/11254/gnupg-aware-gui-to-encrypt-decrypt-pgp-ascii-on-linux


Since Python and GTK can both be used on Windows, does Pyrites work on
Windows as well? And/or could it be converted to a standalone Windows
executable using something like Py2exe or cx_Freeze?




- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

It's better to feed one cat than many mice
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJUmcAKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwcm8H/i1wt8vOW6S1duOseQhqdZb/
QUYDtqSnqPKz4PDpaLQErGI11nxA+hwleqWOEXRdAe2krUnExPbjCgLxVaWWzkGf
TkhihH8QJUotbfw3uz6xufSnpF1i7xnbN9LX5eb4t/8XmyPvCpjUsN2OFzUPyunc
hsmRAYOOz2oih32wbavNY9QlYuRFoNObPOM9I+7LRCvVcZnWX0Le/TPsLxphddge
y9JCzwUikImpsHNbqblEOeGK3Lli63FLoesyZSGwmQYzySbtCzvLgfaKMePlUKY8
Pmlu/PPtgpgRhcMnwwRwpkRhlPkqgUe4B3EjP4C6A0lLzxpo9lgTQmA2djVZyyKI
vgQBFgoAZgUCVJnAIF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45HUiAQAf5jZYhfXTkSWd3tJKysbS5QJx
FplX3eyXq966VKwd4gEAp6LGRxOWBqFy+5uiChzYcg3kwEkk9kRIbG5GXP7Qhgs=
=sEJv
-END PGP SIGNATURE-


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

Re: File Encryption

[Ryan Sawhill]

@Gus:
I recommend you follow up on the suggestions about password managers;
however, if you are dead-set on managing your own encrypted flat file and
you want a GUI, pyrite (
http://softwarerecs.stackexchange.com/questions/11254/gnupg-aware-gui-to-encrypt-decrypt-pgp-ascii-on-linux
) is by far your best choice.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: File Encryption

[Samir Nassar]

On Friday, 2014-12-19 22:20:14 Gus Zernial wrote:
> With what program and/or how can I do this?

This is off topic, but here are some good introductory materials on password 
management, strong passwords, and using either Keepass or KeepassX

Security in-a-Box:
https://securityinabox.org/chapter-3
https://securityinabox.org/keepass_main

Surveillance Self-Defence Guide:
https://ssd.eff.org/en/module/creating-strong-passwords
https://ssd.eff.org/en/module/how-use-keepassx

-- 
Samir Nassar
sa...@samirnassar.com
https://samirnassar.com
PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: File Encryption

[C. Rossberg]

On Fr, 19 Dez 2014, Gus Zernial wrote:

> I'm a home user of Linux. I'm looking for an encryption utility for my 
> personal password file, preferably one with a graphical user interface.
[...snip...]
> With what program and/or how can I do this?

General Description:
https://en.wikipedia.org/wiki/KeePass

On GNU/Linux:
https://www.keepassx.org/


 - > gentoo http://gpo.zugaina.org/app-admin/keepassx
 - > debian 
https://packages.debian.org/search?keywords=keepassx&suite=all§ion=all&searchon=names


Keepass is not "for [your] personal password file", instead it allows
you to build and manage your own password database.

Perhaps it fits your use case.


Yours


//c

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

Re: File Encryption

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Friday 19 December 2014 at 10:20:14 PM, in
,
Gus Zernial wrote:


> I'm a home user of Linux. I'm looking for an encryption
> utility for my personal password file, preferably one
> with a graphical user interface.

> After initial encryption of the file with a master
> password, I'd like to be able to decrypt and display
> the cleartext file, using my master password, without
> destroying the underlying encrypted file. Accordingly,
> when I close the cleartext version it ceases to exist,
> leaving only the pre-existing encrypted file.

> With what program and/or how can I do this? Thx, Gus


There are several password managers available that would seem to have
most of your required bases covered. Search for "password manager" to
find a whole slew. Several are listed on Wikipedia:-

.



- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

Learning without thought is naught;
 thought without learning is dangerous.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJUlszJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwTIYIAKRrhvXLwoKYghrilE0Tb6vH
VdwLSzTTtG6f32k6uRufRyRoJsUNr6rkTm/5D28ZRmGZT5kWo7MGVHrL96m6t3Zn
PxAujXZpzONLAe0xjMBSurhe5xN45DmVBqu/Frh4F5Ys0TZJ0NHYSEM5lpQ0ShFu
WNtAJEq+MGVoYX+ruoKUIqnvXorTqSJMHgqA+z4vEiOXJ6uLeUce0KnzRrzpUHDj
7zqlW114pYntIgvYdlMGMy2NWSD9D40kPoyVTxqiD+GNJqOX8k/L4s4GOt3984vs
Lt0fFZ9bTHMC5JqiKePJKEgF6OeLxiR5whNnJ4I2sd2A5yo3f4lA50SfDnBH/H6I
vgQBFgoAZgUCVJbM0F8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45JKQAQA24V/FNaVyfBpBMAwd2viYBBQf
skjhTKuxvXsKy9DSyAEAkeqtof5RmCcwxfS4nA2+tUtxlo7MAEObzx2rP47g1go=
=15rs
-END PGP SIGNATURE-


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

Re: File Encryption

[Robert J. Hansen]

> I'm a home user of Linux. I'm looking for an encryption utility for
> my personal password file, preferably one with a graphical user
> interface.

Have you considered either encrypting your /home directory (with
dm-crypt, LUKS, pick your poison) and/or using an encrypted folder
(TrueCrypt, etc.)?  Either of those would possibly be a much more
user-friendly experience.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: File Encryption

[Dave Pawson]

Hi Gus. Using symmetrical encryption I do just that
on Linux, without the GUI?

With a small bash script, you could filter out just the entry you want too.
  I currently do it with Python and their encryption, but want it for
my windows box and Linux, hence gpg.

e.g. unlock is

source lockp.sh # parameters
#usage="Usage $0  #  creates $plnfile.txt"

if [[ ! -f ${target}/${encfile} ]]
then
echo Unable to find  $1
exit 2
fi

# File $1 exists, has .gpg extension, create .txt
echo "Decrypt CAST5 encrypted file $1"
echo gpg --output ${target}/${plnfile}  --decrypt ${target}/${encfile}
gpg --output ${target}/${plnfile}  --decrypt ${target}/${encfile}
ckexit gpg

echo "Created ${target}/${plnfile}"
more ${target}/${plnfile}


with params shared (encrypt / decrypt) as
# params for lock.sh and unlock.sh
source ~/bin/dpFunctions.sh
target=/apps/Dropbox/fp
plnfile=test.txt
encfile=test.gpg

nb dpfunctions are pure bash.

Let me know if you want more.

HTH

On 19 December 2014 at 22:20, Gus Zernial  wrote:
> I'm a home user of Linux. I'm looking for an encryption utility for my
> personal password file, preferably one with a graphical user interface.
>
> After initial encryption of the file with a master password, I'd like to be
> able to decrypt and display the cleartext file, using my master password,
> without destroying the underlying encrypted file. Accordingly, when I close
> the cleartext version it ceases to exist, leaving only the pre-existing
> encrypted file.
>
> With what program and/or how can I do this?
>
> Thx, Gus
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

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

File Encryption

[Gus Zernial]

I'm a home user of Linux. I'm looking for an encryption utility for my personal 
password file, preferably one with a graphical user interface.

After initial encryption of the file with a master password, I'd like to be 
able to decrypt and display the cleartext file, using my master password, 
without destroying the underlying encrypted file. Accordingly, when I close the 
cleartext version it ceases to exist, leaving only the pre-existing encrypted 
file.

With what program and/or how can I do this?
Thx, Gus
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Error on GPG file encryption

[Hauke Laging]

Am Di 04.11.2014, 15:14:55 schrieb Kanchan Gobari:

> Urgent help required.

Then you should have subscribed to the list before writing. Would have 
saved you 12 hours...


> I have create a UNIX script for encryption but while executing the
> script got the below error:
> 
> gpg: cannot open tty `/dev/tty': No such device or address

What is the command line in the script causing the error?

What is the output of the following command?

ls -l /dev/tty


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Error on GPG file encryption

[Kanchan Gobari]

Hi,

Urgent help required.

I have create a UNIX script for encryption but while executing the
script got the below error:

gpg: cannot open tty `/dev/tty': No such device or address

 

As got input from multiple sites - google; I found to add the '--no-tty'
in the command line.

But after adding the same in command line, I am getting the another
error:

gpg: Sorry, no terminal at all requested - can't get input

 

Please help to resolve this quickly...

 

 

Thanks & Regards

Kanchan

 

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

Re: Looking for simple wrapper for symmetric key file encryption

[Mr. Clif]

Hi Ryan,

Yes that is exactly the kind of front end I was looking for, and it 
looks very nice. Thanks for writing it. :-) Though now I have finished 
the stab I took at solving the problem myself, which is a much simpler 
command line script. You can find the two versions of it here:


https://www.eugenemakerspace.com/wiki/Sites/Cryptsym

If folks have the time, I would appreciate any feed back on how they 
like it.


Ciao!
Clif

On 01/21/2014 09:28 AM, Ryan Sawhill wrote:

As already mentioned, you could decrypt the file to a ram disk -- the
/dev/shm directory should already be there, but if you're trying to
bypass creating an unnecessary file altogether, you need something
else.

I actually wrote a GUI frontend for this purpose (among others) a
while back. It's called pyrite and available at:
https://github.com/ryran/pyrite

It's extremely versatile and can do everything but manage keys --
basically you can do any kind of signing & verifying with or without
any kind of encryption/decryption (including symmetric).

Your workflow with it could look like this:

1.)  Run pyrite /path/to/encrypted/file
   [GUI opens up with text-input populated by encrypted text]

2.) Decrypt text
   [Cipher-text is replaced with decrypted version; never saved to disk]

3.) Make your edits/changes

4.) Re-encrypt

5.) Click save-to-disk button


On Sun, Jan 19, 2014 at 4:48 PM, Mr. Clif  wrote:

Hi Doug,

Thanks for the comments. Yes the threat model is mostly the worry of having
old temp files or even the original cleartext files left behind on the HD,
or even worse having them backed up. ;-) At the very least I want something
that tries to protect me from stupid mistakes. Yep the RAM disk idea was
part of the solution I'm heading towards.

So do you or does anyone know of a nice front end that helps with that? An
example of behavior that doesn't seem helpful is that when I use GPA to
decrypt a file it defaults to saving it on the HD. I'm not trying to knock
GPA here but wouldn't it be better to display the contents in a window? Well
I realize that might be just what I want, and others have use cases that it
works fine for. ;-)

 Clif


On 01/19/2014 01:23 PM, Doug Barton wrote:

On 01/19/2014 08:56 AM, Mr. Clif wrote:

So I'm trying to get a sense from the users here if they feel that the
process of using gpg for symmetric encryption is safe enough, and they
are not worried about leaving clear text behind.


I think you're misunderstanding a few things. First, the problem of the
plain text file is not exclusive to symmetric encryption. In fact there is
no difference between that, and the plain text file that's left behind after
public key encryption.

Second, you haven't defined your threat model. You have given us a vague
sense of wanting to have a "secure" system, but you haven't said what you're
trying to secure it against. Thus it's hard to respond intelligently to your
query.

That said, I would suggest that you consider using a RAM disk to do your
work on. It can be created to do the work, then deleted after you're done,
with no risk of leaving a file behind on disk. Of course you'd want to make
sure your RAM disk was not swap-backed.

hope this helps,

Doug



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



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

Re: Looking for simple wrapper for symmetric key file encryption

[Ryan Sawhill]

As already mentioned, you could decrypt the file to a ram disk -- the
/dev/shm directory should already be there, but if you're trying to
bypass creating an unnecessary file altogether, you need something
else.

I actually wrote a GUI frontend for this purpose (among others) a
while back. It's called pyrite and available at:
https://github.com/ryran/pyrite

It's extremely versatile and can do everything but manage keys --
basically you can do any kind of signing & verifying with or without
any kind of encryption/decryption (including symmetric).

Your workflow with it could look like this:

1.)  Run pyrite /path/to/encrypted/file
  [GUI opens up with text-input populated by encrypted text]

2.) Decrypt text
  [Cipher-text is replaced with decrypted version; never saved to disk]

3.) Make your edits/changes

4.) Re-encrypt

5.) Click save-to-disk button


On Sun, Jan 19, 2014 at 4:48 PM, Mr. Clif  wrote:
> Hi Doug,
>
> Thanks for the comments. Yes the threat model is mostly the worry of having
> old temp files or even the original cleartext files left behind on the HD,
> or even worse having them backed up. ;-) At the very least I want something
> that tries to protect me from stupid mistakes. Yep the RAM disk idea was
> part of the solution I'm heading towards.
>
> So do you or does anyone know of a nice front end that helps with that? An
> example of behavior that doesn't seem helpful is that when I use GPA to
> decrypt a file it defaults to saving it on the HD. I'm not trying to knock
> GPA here but wouldn't it be better to display the contents in a window? Well
> I realize that might be just what I want, and others have use cases that it
> works fine for. ;-)
>
> Clif
>
>
> On 01/19/2014 01:23 PM, Doug Barton wrote:
>>
>> On 01/19/2014 08:56 AM, Mr. Clif wrote:
>>>
>>> So I'm trying to get a sense from the users here if they feel that the
>>> process of using gpg for symmetric encryption is safe enough, and they
>>> are not worried about leaving clear text behind.
>>
>>
>> I think you're misunderstanding a few things. First, the problem of the
>> plain text file is not exclusive to symmetric encryption. In fact there is
>> no difference between that, and the plain text file that's left behind after
>> public key encryption.
>>
>> Second, you haven't defined your threat model. You have given us a vague
>> sense of wanting to have a "secure" system, but you haven't said what you're
>> trying to secure it against. Thus it's hard to respond intelligently to your
>> query.
>>
>> That said, I would suggest that you consider using a RAM disk to do your
>> work on. It can be created to do the work, then deleted after you're done,
>> with no risk of leaving a file behind on disk. Of course you'd want to make
>> sure your RAM disk was not swap-backed.
>>
>> hope this helps,
>>
>> Doug
>>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

Re: Looking for simple wrapper for symmetric key file encryption

[Mr. Clif]

Hi Doug,

Thanks for the comments. Yes the threat model is mostly the worry of 
having old temp files or even the original cleartext files left behind 
on the HD, or even worse having them backed up. ;-) At the very least I 
want something that tries to protect me from stupid mistakes. Yep the 
RAM disk idea was part of the solution I'm heading towards.


So do you or does anyone know of a nice front end that helps with that? 
An example of behavior that doesn't seem helpful is that when I use GPA 
to decrypt a file it defaults to saving it on the HD. I'm not trying to 
knock GPA here but wouldn't it be better to display the contents in a 
window? Well I realize that might be just what I want, and others have 
use cases that it works fine for. ;-)


Clif

On 01/19/2014 01:23 PM, Doug Barton wrote:

On 01/19/2014 08:56 AM, Mr. Clif wrote:

So I'm trying to get a sense from the users here if they feel that the
process of using gpg for symmetric encryption is safe enough, and they
are not worried about leaving clear text behind.


I think you're misunderstanding a few things. First, the problem of 
the plain text file is not exclusive to symmetric encryption. In fact 
there is no difference between that, and the plain text file that's 
left behind after public key encryption.


Second, you haven't defined your threat model. You have given us a 
vague sense of wanting to have a "secure" system, but you haven't said 
what you're trying to secure it against. Thus it's hard to respond 
intelligently to your query.


That said, I would suggest that you consider using a RAM disk to do 
your work on. It can be created to do the work, then deleted after 
you're done, with no risk of leaving a file behind on disk. Of course 
you'd want to make sure your RAM disk was not swap-backed.


hope this helps,

Doug




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

Re: Looking for simple wrapper for symmetric key file encryption

[Doug Barton]

On 01/19/2014 08:56 AM, Mr. Clif wrote:

So I'm trying to get a sense from the users here if they feel that the
process of using gpg for symmetric encryption is safe enough, and they
are not worried about leaving clear text behind.


I think you're misunderstanding a few things. First, the problem of the 
plain text file is not exclusive to symmetric encryption. In fact there 
is no difference between that, and the plain text file that's left 
behind after public key encryption.


Second, you haven't defined your threat model. You have given us a vague 
sense of wanting to have a "secure" system, but you haven't said what 
you're trying to secure it against. Thus it's hard to respond 
intelligently to your query.


That said, I would suggest that you consider using a RAM disk to do your 
work on. It can be created to do the work, then deleted after you're 
done, with no risk of leaving a file behind on disk. Of course you'd 
want to make sure your RAM disk was not swap-backed.


hope this helps,

Doug


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

Re: Looking for simple wrapper for symmetric key file encryption

[Mr. Clif]

On 01/19/2014 03:53 AM, Johan Wevers wrote:

On 19-1-2014 7:50, Mr. Clif wrote:


Does anyone use symmetric file encryption?

Yes, but only for encrypting files for personal use. Not in
communication with others.



Same here. This is why I wrote that perl script, so I wouldn't have to 
remember to delete the plaintext file after I encrypted it. Are there 
other front ends or wrappers that help the work flow in this way?




What is the best practice here?

As always, that depends on your use case and threat model.


I heard of another solution which was to mount an encrypted
directory with fuser to drop files into.

Possible, I use TrueCryot containers for that but that's similar
(although more portable and usable on "that other  OS").


I think I would wounder how
safe the passphrase was for mounted filesystems,

Are you asking how long it would take to brute-force the pasword, how
difficult it is to snoop it or if there are known vulnarabilities in the
symmetric encryption used by gnupg, fuser or others?


though I know of some techniques for protecting them.

Remember the weakest link in all encryption: https://xkcd.com/538/
Yes I suppose that's true. Though I was just thinking about ways I heard 
of to hide the key material in RAM. As I mentioned below, I'd rather not 
have to resort to an encrypted filesystem just to handle the occasional 
private file unless the conventional wisdom says that it's the only good 
way to do it.


So I'm trying to get a sense from the users here if they feel that the 
process of using gpg for symmetric encryption is safe enough, and they 
are not worried about leaving clear text behind.


Thanks,
Clif


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

Re: Looking for simple wrapper for symmetric key file encryption

[Johan Wevers]

On 19-1-2014 12:12, Andy Ruddock wrote:

> I wouldn't like to make any claims about "best practice", for the most
> part I rely on defaults provided by more knowledgeable folks than myself.

Although trust in that approach has gotten some drawback since the
actions of RSA Inc. became public knowledge.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Re: Looking for simple wrapper for symmetric key file encryption

[Andy Ruddock]

I use ecryptfs, as packages are available for my distro (Debian) which
make it easy to install and use.

I wouldn't like to make any claims about "best practice", for the most
part I rely on defaults provided by more knowledgeable folks than myself.


Mr. Clif wrote:
> So no one got back to me.
> 
> Does anyone use symmetric file encryption? What is the best practice
> here? I heard of another solution which was to mount an encrypted
> directory with fuser to drop files into. I think I would wounder how
> safe the passphrase was for mounted filesystems, though I know of some
> techniques for protecting them.
> 
> Any pointers regarding best practices for  symmetric file encryption
> would be much appreciated.
> 
> Thanks,
> Clif
> 
> On 01/17/2014 01:15 PM, Mr. Clif wrote:
>> Greetings!
>>
>> I've been happily using pgp and gpg off and on for decades. One thing
>> I never quite figured out was what the best way to use it for
>> encrypting sensitive files on disk. After doing that one has to
>> remember to cleanup after themselves and delete all the leftover
>> plaintext versions of the file, or it kind of defeats the whole
>> purpose, and its pretty easy to make a mistake when doing it manually.
>> I always felt that GPG should help you a bit more in that regard. Now
>> I know that full disk encryption might be a way around this, but it
>> seems like overkill if you just have a couple of files to protect.
>>
>> I have searched high and low and checked out GnuPG Shell, GPA,
>> Seahorse, XAP, and some other misc wrappers but nothing seemed to fit
>> my use case. So I wrote a simple wrapper in perl. Basically it just
>> lets you toggle a file between plaintext and encrypted forms without
>> letting the plaintext version touch/remain on the disk, unless that is
>> what you want.
>>
>> #! /usr/bin/perl -U
>> #   This Perl script is a wrapper around GPG to decrypt or encrypt
>> a file.
>> #It's goal is to try to prevent plaintext from touching, or remaining
>> #on the disk, something GPG fails to do. If there is a new file
>> created
>> #It will be in the same directory as the original unless you
>> specify a new
>> #path in a second arg.
>> #
>> #By Clif 12/05/13
>> #
>>
>> # External utilities
>> $GPG   = "/usr/bin/gpg";  # GnuPG 1.4.15
>> $SHRED = "/usr/bin/shred";  # secure file deleter
>> (GNU coreutils) 8.13
>>
>> # Arguments
>> ($arg, $dest) = @ARGV;
>>
>> # Break down the pathname
>> $path = $1 if $arg  =~ /^(.*?)(\/[^\/]*)$/;
>> $file = $1 if $arg  =~ /([^\/]+)\/?$/;
>> $base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/;
>> $ext  = $1 if $file =~ /\.([^. ]*)\s*$/;
>>
>> # Get destination
>> if ($dest) {
>>  $destp = 1;
>>  $dest .= "/$base" if (-d $dest);
>>  $dest =~ s/\.asc\s*$//;
>> } else { $dest = $path ? "$path/$base" : $base }
>>
>> # Is this a planetext or an encrypted file?
>>
>> if (-r $arg) {
>> if ($ext eq "asc") {# Encrypted
>> if ($destp) { system("$GPG -o $dest $arg") }
>> else{ system("$GPG -o - $arg") }
>> } else {# Plaintext
>> unlink "${dest}.asc";
>> $err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256
>> $arg");
>> if ($err) { print "ERROR = $err\n" }
>> else  { system("$SHRED -un9 $arg") }
>> }
>> } else { warn "No such file: $arg\n" }
>> # All done
>>
>>
>> Obviously it could be much more thorough but I just wanted to get the
>> idea across. I was also thinking about adding a RAM based editing
>> feature but I didn't want to reinvent the wheel if someone knows of a
>> similar project.
>>
>> Thanks for any comments you might have,
>> Clif
>>
>>
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


-- 
Andy Ruddock

andy.rudd...@rainydayz.org (OpenPGP Key ID 0xB0324245)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Looking for simple wrapper for symmetric key file encryption

[Johan Wevers]

On 19-1-2014 7:50, Mr. Clif wrote:

> Does anyone use symmetric file encryption?

Yes, but only for encrypting files for personal use. Not in
communication with others.

> What is the best practice here?

As always, that depends on your use case and threat model.

> I heard of another solution which was to mount an encrypted
> directory with fuser to drop files into.

Possible, I use TrueCryot containers for that but that's similar
(although more portable and usable on "that other  OS").

> I think I would wounder how
> safe the passphrase was for mounted filesystems,

Are you asking how long it would take to brute-force the pasword, how
difficult it is to snoop it or if there are known vulnarabilities in the
symmetric encryption used by gnupg, fuser or others?

> though I know of some techniques for protecting them.

Remember the weakest link in all encryption: https://xkcd.com/538/

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Re: Looking for simple wrapper for symmetric key file encryption

[Mr. Clif]

So no one got back to me.

Does anyone use symmetric file encryption? What is the best practice 
here? I heard of another solution which was to mount an encrypted 
directory with fuser to drop files into. I think I would wounder how 
safe the passphrase was for mounted filesystems, though I know of some 
techniques for protecting them.


Any pointers regarding best practices for  symmetric file encryption 
would be much appreciated.


Thanks,
Clif

On 01/17/2014 01:15 PM, Mr. Clif wrote:

Greetings!

I've been happily using pgp and gpg off and on for decades. One thing 
I never quite figured out was what the best way to use it for 
encrypting sensitive files on disk. After doing that one has to 
remember to cleanup after themselves and delete all the leftover 
plaintext versions of the file, or it kind of defeats the whole 
purpose, and its pretty easy to make a mistake when doing it manually. 
I always felt that GPG should help you a bit more in that regard. Now 
I know that full disk encryption might be a way around this, but it 
seems like overkill if you just have a couple of files to protect.


I have searched high and low and checked out GnuPG Shell, GPA, 
Seahorse, XAP, and some other misc wrappers but nothing seemed to fit 
my use case. So I wrote a simple wrapper in perl. Basically it just 
lets you toggle a file between plaintext and encrypted forms without 
letting the plaintext version touch/remain on the disk, unless that is 
what you want.


#! /usr/bin/perl -U
#   This Perl script is a wrapper around GPG to decrypt or encrypt 
a file.

#It's goal is to try to prevent plaintext from touching, or remaining
#on the disk, something GPG fails to do. If there is a new file 
created
#It will be in the same directory as the original unless you 
specify a new

#path in a second arg.
#
#By Clif 12/05/13
#

# External utilities
$GPG   = "/usr/bin/gpg";  # GnuPG 1.4.15
$SHRED = "/usr/bin/shred";  # secure file deleter 
(GNU coreutils) 8.13


# Arguments
($arg, $dest) = @ARGV;

# Break down the pathname
$path = $1 if $arg  =~ /^(.*?)(\/[^\/]*)$/;
$file = $1 if $arg  =~ /([^\/]+)\/?$/;
$base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/;
$ext  = $1 if $file =~ /\.([^. ]*)\s*$/;

# Get destination
if ($dest) {
 $destp = 1;
 $dest .= "/$base" if (-d $dest);
 $dest =~ s/\.asc\s*$//;
} else { $dest = $path ? "$path/$base" : $base }

# Is this a planetext or an encrypted file?

if (-r $arg) {
if ($ext eq "asc") {# Encrypted
if ($destp) { system("$GPG -o $dest $arg") }
else{ system("$GPG -o - $arg") }
} else {# Plaintext
unlink "${dest}.asc";
$err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256 
$arg");

if ($err) { print "ERROR = $err\n" }
else  { system("$SHRED -un9 $arg") }
}
} else { warn "No such file: $arg\n" }
# All done


Obviously it could be much more thorough but I just wanted to get the 
idea across. I was also thinking about adding a RAM based editing 
feature but I didn't want to reinvent the wheel if someone knows of a 
similar project.


Thanks for any comments you might have,
Clif





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

Looking for simple wrapper for symmetric key file encryption

[Mr. Clif]

Greetings!

I've been happily using pgp and gpg off and on for decades. One thing I 
never quite figured out was what the best way to use it for encrypting 
sensitive files on disk. After doing that one has to remember to cleanup 
after themselves and delete all the leftover plaintext versions of the 
file, or it kind of defeats the whole purpose, and its pretty easy to 
make a mistake when doing it manually. I always felt that GPG should 
help you a bit more in that regard. Now I know that full disk encryption 
might be a way around this, but it seems like overkill if you just have 
a couple of files to protect.


I have searched high and low and checked out GnuPG Shell, GPA, Seahorse, 
XAP, and some other misc wrappers but nothing seemed to fit my use case. 
So I wrote a simple wrapper in perl. Basically it just lets you toggle a 
file between plaintext and encrypted forms without letting the plaintext 
version touch/remain on the disk, unless that is what you want.


#! /usr/bin/perl -U
#   This Perl script is a wrapper around GPG to decrypt or encrypt a file.
#   It's goal is to try to prevent plaintext from touching, or remaining
#   on the disk, something GPG fails to do. If there is a new file created
#   It will be in the same directory as the original unless you specify a 
new
#   path in a second arg.
#
#   By Clif 12/05/13
#

# External utilities
$GPG   = "/usr/bin/gpg";  # GnuPG 1.4.15
$SHRED = "/usr/bin/shred";  # secure file deleter (GNU 
coreutils) 8.13

# Arguments
($arg, $dest) = @ARGV;

# Break down the pathname
$path = $1 if $arg  =~ /^(.*?)(\/[^\/]*)$/;
$file = $1 if $arg  =~ /([^\/]+)\/?$/;
$base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/;
$ext  = $1 if $file =~ /\.([^. ]*)\s*$/;

# Get destination
if ($dest) {
 $destp = 1;
 $dest .= "/$base" if (-d $dest);
 $dest =~ s/\.asc\s*$//;
} else { $dest = $path ? "$path/$base" : $base }

# Is this a planetext or an encrypted file?

if (-r $arg) {
if ($ext eq "asc") {  # Encrypted
if ($destp) { system("$GPG -o $dest $arg") }
else{ system("$GPG -o - $arg") }
} else {# Plaintext
unlink "${dest}.asc";
$err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256 
$arg");
if ($err) { print "ERROR = $err\n" }
else  { system("$SHRED -un9 $arg") }
}
} else { warn "No such file: $arg\n" }
# All done


Obviously it could be much more thorough but I just wanted to get the 
idea across. I was also thinking about adding a RAM based editing 
feature but I didn't want to reinvent the wheel if someone knows of a 
similar project.


Thanks for any comments you might have,
Clif



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

Re: future proof file encryption

[David Shaw]

On Mar 2, 2009, at 9:19 AM, Mark H. Wood wrote:


On Fri, Feb 27, 2009 at 08:37:53PM -0500, Robert J. Hansen wrote:
For long-term photographic storage, make a print from photographic  
film

on archival-quality print stock.  Also, I'm given to understand that
black and white photographs survive the aging process much better  
than

color.


Silver chemistry is (or, at least, it used to be) much more resistant
to decay than color dyes.  You still have to be sure that the print
has been archivally processed (mainly to wash out all traces of hypo,
which otherwise will continue doing the job it has in the process and
eat away at the silver grains).  You still need to keep it away from
atmospheric contaminants when not in use.  You can plate the grains
using a bath of gold chloride to protect them a little longer.  You
can use vesicular film rather than silver, if you can still find it,
for even longer storage.  (Huh, *silver* chemistry is getting harder
to find.)

Used to be that color photos which had to be preserved for a long time
were stored as separation sets:  three silver images were made to
capture the three primary colors from the image, to be reassembled
later and reconstitute the color image using the ordinary dye
process.  Dunno if it's still done.


I thought it was more or less dead, but then a new company popped up  
to do silver YCM separations *generated from a digital scan*.   
(Speaking about movies here - obviously anyone can generate  
separations for stills with Photoshop or the like).  It's less crazy  
that it seems on the face of it.  The separations have longer life  
than a backup tape, and you don't need to remaster separations every  
few years.  I still think I'd regard such a thing much as I regard the  
paper key backups from paperkey: the backup of last resort.



 I'd put my trust in a
well-maintained redundant set of digital scans, these days.


Me too.  I think most people do, these days.  The only issue here is  
that every few years, the scanning technology improves to the point  
where re-scanning the original (chemical) image becomes worthwhile.   
So you do need to keep the original around.



Most photos won't really need all this fancy treatment; you enjoy 'em
while they last, and keep making new ones.  The problem is, often we
don't understand which ones *should* have special preservation, until
it's too late.


Indeed.  There is an interesting debate over whether digital photos  
are too easy to erase.  Every now and then, the "unimportant" photo  
turns out to be needed.  For example: http://digitaljournalist.org/issue9807/editorial.htm


David


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

Re: future proof file encryption

[Mark H. Wood]

On Fri, Feb 27, 2009 at 08:37:53PM -0500, Robert J. Hansen wrote:
> For long-term photographic storage, make a print from photographic film
> on archival-quality print stock.  Also, I'm given to understand that
> black and white photographs survive the aging process much better than
> color.

Silver chemistry is (or, at least, it used to be) much more resistant
to decay than color dyes.  You still have to be sure that the print
has been archivally processed (mainly to wash out all traces of hypo,
which otherwise will continue doing the job it has in the process and
eat away at the silver grains).  You still need to keep it away from
atmospheric contaminants when not in use.  You can plate the grains
using a bath of gold chloride to protect them a little longer.  You
can use vesicular film rather than silver, if you can still find it,
for even longer storage.  (Huh, *silver* chemistry is getting harder
to find.)

Used to be that color photos which had to be preserved for a long time
were stored as separation sets:  three silver images were made to
capture the three primary colors from the image, to be reassembled
later and reconstitute the color image using the ordinary dye
process.  Dunno if it's still done.  I'd put my trust in a
well-maintained redundant set of digital scans, these days.

Most photos won't really need all this fancy treatment; you enjoy 'em
while they last, and keep making new ones.  The problem is, often we
don't understand which ones *should* have special preservation, until
it's too late.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Mama don't take my Kodachrome away!


pgpF5FRmVobj4.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: future proof file encryption

[peter]

I've been amazed by the variety of thoughtful comments since I posted.
I've read all those - and a bit more besides. I'm ashamed at my
ignorance when I contacted the list last Thursday. I comfort myself with
the thought that it's only from ignorance that you can ever feel
complete knowledge could be in your grasp. The more you learn, the more
it recedes.

I'm distrustful of the reliability of anything that has moving parts and
paranoid of the Internet (but I suspect some level of paranoia is a
prerequisite for hanging out here). Despite that I've become completely
reliant on computers. I've also got two children - three and five who
absorb my time like sponges. As their childhood slips by I try and
capture the odd moment as naturally as I can (I'm no fan of the cheesy
grin). The images are raw format from a Nikon. Much as my instincts are
for simple, low tech solutions, they're the digital equivalent of
negatives. Printing them out isn't really a solution.  For the moment, I
have no time to work on them. How they look when they come out of the
camera is what I use. One day I hope to revisit them - I'm sure I can
extract more value from this afternoon's dingy shot of B. peering out of
the porthole in the side of a flying boat. The long term safety of these
negatives is important to me.

My distrust of the reliability of things with moving parts means I run
two computers. I can work from either. They're almost mirrors (except
one is Suse the other Fedora, one KDE, the other Gnome - [you need a bit
of variety to spice things up]). I rsync from one to the other at the
end of the day.  If I make a mistake on one, then rysync will do its
duty and replicate the mistake. The copy on S3 protects me from my own
stupidity (and fire, theft...) My paranoia of the Internet makes me want
to encrypt these copies (once something's out there, you can never get
it back). For the moment I prefer the notion that I don't have to store
the key anywhere - just a passphrase in my head - hence the use of
symmetric keys. 

Anyway thanks for your patience and your ideas. When you hear from me
again, I hope to be better informed!



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

Re: future proof file encryption

[Werner Koch]

On Fri, 27 Feb 2009 17:25, r...@sixdemonbag.org said:

> After a little thought, it occurred to me that perhaps Sven meant there
> are three errors and it's not known where.  This turns into a slightly
> more complex case, but still within the realm of possibility: just over
> twenty-two million possible combinations (2.7 million combinations, with

I would simply go and store several copies of the first, say, 4k of the
encrypted archive on the backup media.  This allows to recover the
encrypted session key with a high probability.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


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

Re: future proof file encryption

[Sven Radde]

Hi!

Robert J. Hansen schrieb:
> After a little thought, it occurred to me that perhaps Sven meant there
> are three errors and it's not known where.

I also meant something like some 512 bytes of the file being unreadable
because of failure of the corresponding disc sector.

But I agree that single or few bit errors are probably not as
catastrophic as I first thought.

cu, Sven

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

Re: future proof file encryption

[David Shaw]

On Feb 27, 2009, at 8:37 PM, Robert J. Hansen wrote:

For long-term photographic storage, make a print from photographic  
film

on archival-quality print stock.  Also, I'm given to understand that
black and white photographs survive the aging process much better than
color.


It's because black and white photographs and negatives contain actual  
silver (another reason why old films are lost - they were melted down  
for their silver content to make more film).  Color photographs and  
negatives contain inks and dyes which can be very long lasting, but  
still don't have the longevity and environmental resistance of the  
silver.  For very long term storage, store it in the cold and in the  
dark.  Don't display your only copy on the wall, or at least pay the  
extra bit for UV blocking glass.  Really, though, if you have color  
film you want to preserve "indefinitely", scan the negative to digital  
and keep both the original negative in dark storage *and* the digital  
copy (remastering it as needed).


If your color photos were shot on Kodachrome, incidentally, you're in  
luck.  It has dark-storage capabilities that are vastly better than  
any color negative film.


Drifting a bit from crypto here, I'm afraid.  We should wind this  
subthread up.


David


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

Re: [OT]future proof file encryption

[Christopher J. Walters]

John Clizbe wrote:
> Christopher J. Walters wrote:
>> I know quite enough about the field without your snide and foolish remarks.  
>> I
>> refuse to engage in a battle of wits with an unarmed opponent.
> 
> Statement one: I'll ignore as other readers may make their own opinions
> as to the quality of knowledge demonstrated.
> 
> All too often we see folks too overly invested in a creation to accept
> objective criticism of the idea.
> 
> statement two: Rob seems actually quite well-armed to discuss these
> topics, wit capacity being left unjudged. But then, I know about his PhD
> study concentration and work in the security field from our mutual
> Enigmail work: Black Hat 2005 on SQL injection; DEF CON 2006 on
> electronic voting security; CodeCon 2006 and OSCON 2006 on non-security
> topics.

Statement one, and all of its children, I shall ignore, since they are only
ignorance masked as arrogance and "superior knowledge and intellect".  You
don't know me well enough to judge either, so do this list and yourself a favor
and stay out of it.  It reeks of Ad Hominum, without quite getting there.  I am
sure others will.

Statement two, two words: Straw man.

Statement three: Faulty use of (assumed) Authority, Post Hoc.  Therefore, 
ignored.

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

Re: future proof file encryption

[Robert J. Hansen]

(Replying to David, but it's really for Joseph)

David Shaw wrote:
> On Feb 27, 2009, at 6:25 PM, Joseph Oreste Bruni wrote:
>
>> Since we're talking about photos, what would be wrong with PRINTING
>> them? I think a printed photo would last a lot longer than any
>> computer-based technology. And, you could store them in shoeboxes.

Depends a lot on the paper and dye you use.  Most consumer-grade inkjet
prints will begin fading after only a few years.  Even if they don't,
they react with the atmosphere and their color palette changes.

If you've ever seen an old Polaroid that makes you think the 1970s were
an era of muddy-looking colors, well -- that's what's happened to it.
The original photo was vibrant, but light and atmospheric oxygen has
changed it.

For long-term photographic storage, make a print from photographic film
on archival-quality print stock.  Also, I'm given to understand that
black and white photographs survive the aging process much better than
color.

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

Re: future proof file encryption

[Robert J. Hansen]

John Clizbe wrote:
> All too often we see folks too overly invested in a creation to accept
> objective criticism of the idea.

There also seems to be a tendency to misread what I think are very
neutral statements as being very dry snark.

E.g., when I said I didn't see the reasoning, and having reread it I
still didn't, it wasn't meant to be insulting: it was meant quite
literally.  If there was a line of reasoning there, I missed it on both
the first and second reads-through.  Maybe that means there was no
reasoning, maybe that means I wasn't astute enough to read it.

With all that said, I have discovered it is generally best to read
people's statements in a way that gives them the benefit of the doubt.

W.r.t. my experiences, I'll just quote Rodney Whitaker again: "Do not
fall into the error of the artisan who boasts of twenty years experience
in his craft while in fact he has only one year of experience -- twenty
times."  I make errors as easily as anyone else.

E.g., I was wrong a couple of weeks ago about why there was no choice #3
in the subkey generation menu; I said that if memory served it belonged
to Elgamal signing keys, which have since been removed -- bzzt, wrong.

A couple of months ago David Shaw and I had a very vigorous argument
about some of the engineering choices in the OpenPGP specification.
After mulling it over for a couple of weeks, I've come around: David's
arguments were more persuasive than mine.  I'm not sure if I was wrong,
per se -- we were arguing about a matter of personal opinion -- but I
certainly had the weaker arguments.

Beware of all experts.  Experts are wrong as much as anybody else.
Experts are just wrong with much greater authority.


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

Re: future proof file encryption

[David Shaw]

On Feb 27, 2009, at 6:25 PM, Joseph Oreste Bruni wrote:

Okay, I've resisted getting into this discussion long enough, and I  
can't stands no more!


Since we're talking about photos, what would be wrong with PRINTING  
them? I think a printed photo would last a lot longer than any  
computer-based technology. And, you could store them in shoeboxes.


Obviously, I'm a big fan of paper (exhibit A: http://www.jabberwocky.com/software/paperkey/ 
 ), but the problem with prints is that you lose something when/if  
you scan them back into the digital space.  It's a bit like a lossy  
compression.  That said, I'd take a somewhat-degraded image over no  
image at all.


It's not completely relevant to your example, but speaking of recovery  
from paper: a lot of the early cinema was thought to be gone forever  
because the negatives and all prints were lost or had decayed over the  
years (early film was printed on a guncotton base - needless to say it  
was highly flammable and degraded quickly).  It turns out that for  
copyright reasons, some of the film companies had deposited paper  
copies (essentially a photo print of each film frame) of the films  
with the US Library of Congress.  The archivists re-photographed these  
paper prints back onto film, and managed to reconstruct the original  
movies.  See, for example, http://rs6.loc.gov/papr/nychome.html


David

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

Re: future proof file encryption

[Michel Messerschmidt]

On Fri, Feb 27, 2009 at 07:22:56PM -0500, Robert J. Hansen wrote:
> Hard drives tend not to crash or overheat when they're powered down,
> properly mothballed, and put in long-term storage.

Unless your photos are made for your grandchildren only, I don't believe 
in a personal "dead" long-term storage. Most people I know just want to 
keep files that they use at least occasionally.
While I like your proposal for long-term storage, I rather stick with 
harddisks or flash drives for personal data. That way the files remain 
usable while being archived.
But I wouldn't recommend more than two harddrives. With current hardrives
I regard it as sufficient to use just one dedicated backup disk or even 
two copies on different computers. As long as the backups are verified, 
the probability of two simultaneous drive failures is low enough to make 
the risk acceptable. 
And if the house burns down ...the shoebox wasn't fireproof either.

Back to encryption, I see no problem to simply use crypto filesystems 
with this scenario.



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

Re: future proof file encryption

[John Clizbe]

Christopher J. Walters wrote:
> I know quite enough about the field without your snide and foolish remarks.  I
> refuse to engage in a battle of wits with an unarmed opponent.

Statement one: I'll ignore as other readers may make their own opinions
as to the quality of knowledge demonstrated.

All too often we see folks too overly invested in a creation to accept
objective criticism of the idea.

statement two: Rob seems actually quite well-armed to discuss these
topics, wit capacity being left unjudged. But then, I know about his PhD
study concentration and work in the security field from our mutual
Enigmail work: Black Hat 2005 on SQL injection; DEF CON 2006 on
electronic voting security; CodeCon 2006 and OSCON 2006 on non-security
topics.

-- 
John P. Clizbe  Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=help

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: future proof file encryption

[Christopher J. Walters]

Robert J. Hansen wrote:
> I said 'about'.  JPEG was standardized in 1994; PNG in 1996; SVG in 2001.
> 
>> So tell me, what compression software are *you* talking about?
> 
> Wavelets.  Fractals.  Arithmetic coding.  The data compression field is
> alive and well and constantly getting better.  Check out the literature.
> 
> Some of these have already been incorporated into newer graphics
> standards.  E.g., JPEG has no support for wavelet encoding, but JPEG2000
> does.

I know quite enough about the field without your snide and foolish remarks.  I
refuse to engage in a battle of wits with an unarmed opponent.

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

Re: future proof file encryption

[Robert J. Hansen]

Christopher J. Walters wrote:
> I did, later in my message.

I didn't see it.  Looking over it, I still don't.

> I come from the early days of Fidonet, and BBS's.  It is possible for
> a CRC32c checksum to show "OK" when there have been changes.  Has
> always been this way. If you use an archiver to "archive" 200 files
> around 2 mb in length, then encrypt the archive, you could easily
> lose all 200 files, if the session key is lost.  Keeping the files
> separate and hashing them, would be a way to tell if there are any
> problems.

There are a lot of different kinds of CRC32 -- some designed in an ad
hoc manner and others designed to the standards of engineering.  You're
using one right now, probably: Ethernet frames incorporate a CRC32.  If
it's good enough for Ethernet, it's good enough for me.

You're also missing the part about how GnuPG includes a hash of the data
in its symmetric encryption.  You don't need public key encryption to
get a hash on the data.

> The F.B.I. could recover data from your hard drive, as well - even if
> it crashes.  Hard drive can crash within 1 or 2 years, especially if
> they get too hot.

Hard drives tend not to crash or overheat when they're powered down,
properly mothballed, and put in long-term storage.

> And just why is it overkill?  With the costs of hard drives coming
> down, as they are, you can call it an upgrade.

If you're seriously advocating spending $300 for hard drives alone to
back up your data, then you've just priced your scheme beyond the reach
of most people.  I make good money at my day job and let me tell you, I
wouldn't /think/ of spending $300 on backups.  What happens in two
years?  You think I should be out another $300 in backups alone?  An
amortized cost of $150/year for backups is probably about 150 times too
much.

My suggestion is, IMO, at the edge of practicability -- and it costs
under $100 of outlay for enough equipment to do about 100 long-term
nitrogen-purged backups.  ($50 for a 10 cu. ft. cylinder of argon, $20
for 100 antistat heat-sealable bags, $20 for a big stack of DVD-Rs.)

As a rule of thumb, the more complex and expensive your backup system
becomes, the less likely it is that anyone will actually follow the
protocol.

> Actually JPEG is older than 10 years, IIRC

I said 'about'.  JPEG was standardized in 1994; PNG in 1996; SVG in 2001.

> So tell me, what compression software are *you* talking about?

Wavelets.  Fractals.  Arithmetic coding.  The data compression field is
alive and well and constantly getting better.  Check out the literature.

Some of these have already been incorporated into newer graphics
standards.  E.g., JPEG has no support for wavelet encoding, but JPEG2000
does.



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

Re: future proof file encryption

[Christopher J. Walters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Robert J. Hansen wrote:
> Christopher J. Walters wrote:
>> That's why it would be a good idea, in my opinion, to use a public
>> key pair, and a weaker cipher than AES to encrypt data like family
>> photos.
> 
> I cannot for the life of me see what's leading you to give this counsel.
> Would you care to share your reasoning?

I did, later in my message.

>> I would also hash every file using a good hash algorithm, like SHA2,
>> RIPEMD160, etc.
> 
> Why?  A good archiver will keep a running CRC, allowing you to identify
> which files are good and/or bad.  Fuzzy hashing will potentially narrow
> it down to a few bytes within the file, making it possible for a good
> archivist to recover/restore most of the damaged area.

I come from the early days of Fidonet, and BBS's.  It is possible for a CRC32c
checksum to show "OK" when there have been changes.  Has always been this way.
If you use an archiver to "archive" 200 files around 2 mb in length, then
encrypt the archive, you could easily lose all 200 files, if the session key is
lost.  Keeping the files separate and hashing them, would be a way to tell if
there are any problems.

>> Additionally, I would keep at least 3 copies on HDD media, and
>> replace your HDD every 2 years or so, and copy everything to the new
>> one (after testing it for bad blocks, etc.), as well as storing it on
>> optical media.
> 
> Needless overkill for most purposes.  The lifespan of HD media is
> surprisingly long: you can fairly easily recover data off a 30-year-old
> hard drive.  You might have trouble finding an MFM or RLL bus, but once
> you find it you're in pretty good shape -- especially if basic archival
> protections were taken.

The F.B.I. could recover data from your hard drive, as well - even if it
crashes.  Hard drive can crash within 1 or 2 years, especially if they get too
hot.  And just why is it overkill?  With the costs of hard drives coming down,
as they are, you can call it an upgrade.
[snip]

>> One last thing, I would recommend against compressing the image files
>> into .ZIP, or other archives - for JPG and PNG files, they are
>> already compressed and compression will likely only make them larger.
> 
> Yes, no -- it certainly can't hurt them.  Also, image formats are
> usually about ten years in the past -- it's the nature of the beast, the
> image industry wants very stable formats -- which means they're also
> generally behind the curve on compression.  Compare this to compression
> software, which is getting better by the day.

Actually JPEG is older than 10 years, IIRC, but it is still lossy compression
followed by lossless compression.  ZIP is much older than 10 years old, and
offers far from the best compression.  JPEG-2000 is newer and can have better
compression than the original...  So far, even using experimental archivers, I
have not been able to reduce the size of a raw image file or raw music file to
the size of a JPEG (even set to almost no compression at all), or MP3 (set to
the highest bit rate).

So tell me, what compression software are *you* talking about?

Regards,
Chris
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJJqH9EAAoJEE8J0h3nbis21eIQALDtUVLuR+mISWrY+GNomryO
wf7wyl2Pa1VRGqNc3CJXm1FCF/xI1kMurLI4/qnjoYrZwWybbb4KLz+fBSwYIlad
R9UjxbQuDVT+110ealM/4m9TutY/WZTEP0Y0b/RUnhtzEC2/Q6nkONM29grgvvx/
r91NKs762ggevVeNVTbjUmQN79NZJJa5EpQ1iQofQstpgAzeT+KRgLMySrSM6THf
yo0vDZInECr384LCMhxrNp7zvDrwws2k0NyIaKHYkYyQhaZb4SdEWDyhpW11SOD6
ohG/ejLfKmaaXHmhOxtia7ku15qGoEC0X5EqNRRf+m/6kdyzVkLv8W7hZ+yJA9km
1xlH/GWXROfUILbDSM5GW/fyzRsd0jsyxIj3iFOpJVM7435/uKcnuSu4GYd6b32P
dwWp9b1HHGxb8SjKNEh+7b4FmDrrQwgqLsNvMwoTz3aIqH887ca2uYm212O7Ezni
ZEdZNsF5716+gL85x/bGmSo+DCsnpSBixaY/C73/hm5IhhCFJCJI6wVjEJ5RI+GQ
LhQL6TOjEs7wChlTYHApghq8rZCvEB0UzOgYy2fuCqaMRPCpmndHwvXGEcnPYnXX
eVpPphtmbKUygxSql7sbgPjamQNp4HDYcI0aY6Y/jopnZvbRneLEgvtYticVDM/U
AKmsrwHF2MSW/ckqkuzr
=UKKZ
-END PGP SIGNATURE-

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

Re: future proof file encryption

[Joseph Oreste Bruni]

Okay, I've resisted getting into this discussion long enough, and I can't 
stands no more!

Since we're talking about photos, what would be wrong with PRINTING them? I 
think a printed photo would last a lot longer than any computer-based 
technology. And, you could store them in shoeboxes.



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

Re: future proof file encryption

[Robert J. Hansen]

Christopher J. Walters wrote:
> That's why it would be a good idea, in my opinion, to use a public
> key pair, and a weaker cipher than AES to encrypt data like family
> photos.

I cannot for the life of me see what's leading you to give this counsel.
Would you care to share your reasoning?

> I would also hash every file using a good hash algorithm, like SHA2,
> RIPEMD160, etc.

Why?  A good archiver will keep a running CRC, allowing you to identify
which files are good and/or bad.  Fuzzy hashing will potentially narrow
it down to a few bytes within the file, making it possible for a good
archivist to recover/restore most of the damaged area.

> Additionally, I would keep at least 3 copies on HDD media, and
> replace your HDD every 2 years or so, and copy everything to the new
> one (after testing it for bad blocks, etc.), as well as storing it on
> optical media.

Needless overkill for most purposes.  The lifespan of HD media is
surprisingly long: you can fairly easily recover data off a 30-year-old
hard drive.  You might have trouble finding an MFM or RLL bus, but once
you find it you're in pretty good shape -- especially if basic archival
protections were taken.

(For instance, don't vacuum-seal hard drives.  Put them in heavy-duty
antistatic bags, purge with very dry nitrogen, and seal it up.  You
could now store the hard drive underwater for years and still expect it
to work when you hooked it up.  Imagine how much better it will work
kept in a safe deposit box.)

Optical media can also be high reliability.  I'm not sure I'd trust a CD
that had been sitting on my dashboard for six weeks, but a CD stored in
a lightproof envelope kept in a dry nitrogen environment will be good
for decades.

> One last thing, I would recommend against compressing the image files
> into .ZIP, or other archives - for JPG and PNG files, they are
> already compressed and compression will likely only make them larger.

Yes, no -- it certainly can't hurt them.  Also, image formats are
usually about ten years in the past -- it's the nature of the beast, the
image industry wants very stable formats -- which means they're also
generally behind the curve on compression.  Compare this to compression
software, which is getting better by the day.


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

Re: future proof file encryption

[Christopher J. Walters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sven Radde wrote:
> Hi!
> 
> It is probably one of the best choices for the purpose, however, in
> general, long-term archival and encryption don't go together nicely.
> Neither does compression or similar. Many algorithms or encryption modes
> are rather 'sensitive' to single bit-errors, lost bits and the like.
> Imagine the session-key part of an OpenPGP message be destroyed.
> Commonly, this will be far less than 1% of the actual data, but even
> with 99% intact, you won't have a chance of recovering *anything* from it.
> When using encrypted backups, 100% data integrity plays a much greater
> role than when just storing unencrypted data.
> 
> With a directory full of .bmp files, you have a fair chance not to
> notice a bit flip at all or you might notice a single out-of-color pixel.
> With a directory of .jpgs, you might notice a corrupted 8x8 pixels block
> or, worst case, have one unusable image.
> With a single images.zip.gpg file, a bit flip may mean that the whole
> archive is unreadable (which is the worst case... no idea what an
> average case might look like).
> 
> cu, Sven

Hi Sven,

I agree with you, especially with cryptography, but with compression, as well.
 I am assuming that you are talking about filesystem errors and the degradation
of data on magnetic media.  This can mess a person up with image files -
especially compressed formats like JPEG and PNG, even without encryption added
to the mix.

That's why it would be a good idea, in my opinion, to use a public key pair,
and a weaker cipher than AES to encrypt data like family photos.  I would also
hash every file using a good hash algorithm, like SHA2, RIPEMD160, etc.
Additionally, I would keep at least 3 copies on HDD media, and replace your HDD
every 2 years or so, and copy everything to the new one (after testing it for
bad blocks, etc.), as well as storing it on optical media.  A good backup
schedule is essential for all data.  One last thing, I would recommend against
compressing the image files into .ZIP, or other archives - for JPG and PNG
files, they are already compressed and compression will likely only make them
larger.  For BMP files, I would suggest compressing each one separately with a
RAR format, with a recovery record.  If you use GnuPG, it will compress by
default and with the key pair suggestion, you can encrypt+sign each one
separately, so at most, you'll lose one or two files, rather than all of them.

Personally, I'd just keep them on removable media (like ZipDisks, CD/DVD+-R,
USB port hard disk drives, etc.), and view them from there.  It is not like
we're talking about information vital to national security, here...  I only
encrypt things I absolutely don't want others to see (personal financial,
medical, etc. information).

As for your worst case, you can end up with a file you cannot decrypt, if the
first part of the encrypted file is destroyed.  If the error is in the data
packet, most of the time, it will be detected, especially so if you sign it
with a your secret key.  In that case, the normal or average case will be that
you'll either lose one or more files, or they will be corrupted - possibly
still readable.  You would have to run some form of zipfix on the archive to
read it, though.

Regards,
Chris
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJJqGiNAAoJEE8J0h3nbis2JeoQAJ64Lvp0iboOUmWAlypNJTC/
UWIcfmbQ+KpnfXjQnjpPW10ggRbegG3648/f1xMsWAoyUWdYJ4LBMb1KvnrOR+Hi
ABV8DD3ImXcCZ8/+/20wdcAJqH6Z2lpiIJY240ppQmN3Jr7tBhz/+kt6tvvcRrIB
VwcOxMeNrYFGAmIDulreaKEEyG4CefK1CJiY7DH5R11fRoukkF1HSRVTIMNcTV/v
4YqWTWD+y6wPq4KcCyNRAMvGCW597ZekjYaS0wUtxjZvo64L0X3KFY52hk9f+B7l
kX07gMP9p7K0zy+HCav+PRCaK2Q4yQED0iKk6SUrENsxZCRWa5hUHGF/f94mSbvK
qyaXFEiA8NehVOK1IQTdREvCmmqUbmgwy0Y3+7qeeTx49POtCSe1UJWZJ5x+nW+l
aeNsnLVuqLUv9Kp2ZVXLoNxd/ehiXCeRueW396Vhd+8p1MRdcHLDGt6uN/mCaq7t
4VN5B1Le7KyEP2dwCgEzowNykkefugUPMpIFhsG3MYDHnR0IMT9lT9QGx+A4w1Cj
6UuavG1JKM1SwFZXJGf1oQgJRXjg/AwCHa0ByosnU7g6MjZ9nFsRkPM67X6sXEFM
YyB7A8WG3vqeE1+xri2pm5k5u4q3DVZWxkb34ZnzGku7/wh/f5vwHqKc/Dtew68a
m+2AdycB9EOBIQ5crIk4
=avn5
-END PGP SIGNATURE-

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

Re: future proof file encryption

[Robert J. Hansen]

Robert J. Hansen wrote:
> With a 256-bit cipher, if you're missing 3 bits, there are only eight
> possible keys.  This is not an obstacle.

After a little thought, it occurred to me that perhaps Sven meant there
are three errors and it's not known where.  This turns into a slightly
more complex case, but still within the realm of possibility: just over
twenty-two million possible combinations (2.7 million combinations, with
each set of three bits possessing eight possible states).


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

Re: future proof file encryption

[Robert J. Hansen]

Sven Radde wrote:
> Imagine the session-key part of an OpenPGP message be destroyed.
> Commonly, this will be far less than 1% of the actual data, but even
> with 99% intact, you won't have a chance of recovering *anything* from it.

Err.  What?

With a 256-bit cipher, if you're missing 3 bits, there are only eight
possible keys.  This is not an obstacle.

> With a single images.zip.gpg file, a bit flip may mean that the whole
> archive is unreadable (which is the worst case... no idea what an
> average case might look like).

The moral of the story is not to avoid encrypting your backups, but to
keep multiple copies of your backed-up data.


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

Re: future proof file encryption

[vedaal]

Sven Radde email at sven-radde.de
wrote on Fri Feb 27 14:55:39 CET 2009 :

>When using encrypted backups, 100% data integrity plays a much 
greater
>role than when just storing unencrypted data.


for really long term encryption,
would guess that it is more likely that there would be a problem 
with the durability of the storage medium, 
than with the availability of gnupg and the platforms and hardware 
to run it ;-)


fwiw,
my $0.02 suggestion :

[1] armor encrypt the files so that it can be published in text form

[2] hash the final encrypted .asc text with 2 (or as many more as 
you wish) different hash algorithms, and append the hashes, also in 
text form, to the end of the encrypted .asc text

[3] put the whole thing on microfilm
(don't know which specific type of microfilm. but this can be 
researched by finding out which ones are most preferred by 
libraries, museums, govt. archivals,  etc.)

[4] retrieve it from the microfilm and check that the hashes verify 
and that the file decrypts

[5] (weakest point of this scheme ;-) )
make sure your really secure passphrase is somehow remembered in 
the future when it is time to decrypt ... ;-))


vedaal

any ads or links below this message are added by hushmail without 
my endorsement or awareness of the nature of the link

--
Become a Medical Transcriptionist. Click here to find schedules designed to fit 
your life.
 
http://tagline.hushmail.com/fc/BLSrjkqfMmfY78QCiStowDKIGBJhRTxgAJUymH13l1pdyqILz0dL2ERXhK4/


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

Re: Re: future proof file encryption

[Sven Radde]

Hi!

Robert J. Hansen schrieb:
> GnuPG conforms to the OpenPGP standard for cryptography.  That means
> there are ... what ... 14 or so compatible implementations.  You don't
> have to rely on GnuPG; there are a lot of other options out there.  This
> is very good for purposes of long-term storage.
It is probably one of the best choices for the purpose, however, in
general, long-term archival and encryption don't go together nicely.
Neither does compression or similar. Many algorithms or encryption modes
are rather 'sensitive' to single bit-errors, lost bits and the like.
Imagine the session-key part of an OpenPGP message be destroyed.
Commonly, this will be far less than 1% of the actual data, but even
with 99% intact, you won't have a chance of recovering *anything* from it.
When using encrypted backups, 100% data integrity plays a much greater
role than when just storing unencrypted data.

With a directory full of .bmp files, you have a fair chance not to
notice a bit flip at all or you might notice a single out-of-color pixel.
With a directory of .jpgs, you might notice a corrupted 8x8 pixels block
or, worst case, have one unusable image.
With a single images.zip.gpg file, a bit flip may mean that the whole
archive is unreadable (which is the worst case... no idea what an
average case might look like).

cu, Sven

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

Re: future proof file encryption

[Robert J. Hansen]

peter wrote:
> Is it true to say then, that if you wanted someone to be able to
> decrypt a (symmetrically encrypted) file, they'd need to know the
> algorithm used, the key and they'd also have to use the same program
> to decrypt as used to encrypt the file?

Let's not use words like "algorithm" and "program", since they have
fairly precise technical meanings and I don't think you want to get
bogged down in jargon.

You need to know the key, and you need a decrypter that's compatible
with whatever you used to encrypt.

GnuPG conforms to the OpenPGP standard for cryptography.  That means
there are ... what ... 14 or so compatible implementations.  You don't
have to rely on GnuPG; there are a lot of other options out there.  This
is very good for purposes of long-term storage.


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

Re: future proof file encryption

[Moritz Schulte]

> Is it true to say then,
> that if you wanted someone to be able to decrypt a
> (symmetrically encrypted) file, they'd need to know the algorithm used,
> the key and they'd also have to use the same program to decrypt as used
> to encrypt the file?

Not quite. In general: you shouldn't base the security on the secrecy of
the methods used (algorithm, implementation, ...).  Besides, when using
a program which implements a documented standard, it doesn't matter what
actual implementation of the standard you (or the attacker) use(s). The
security should depend on the secrecy of your key.

mo



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: future proof file encryption

[peter]

Thanks for all your responses - and the speed of them.

The shoe  box works fine for my pre-digital snaps - not so good for the
post digital ones! Currently, I dump my camera into my computer, sort
out the interesting images, archive them and dump the archive into
Amazon's S3. Then I feel safe from my own stupidity, hardware failures
or whatever - I can always get back to the image as it came out of the
camera. I'm going to add encryption using GPG to the mix.

I don't expect to fully understand cryptography - but I should have an
"operational" understanding. I feel a bit closer to that. Is it true to
say then, that if you wanted someone to be able to decrypt a
(symmetrically encrypted) file, they'd need to know the algorithm used,
the key and they'd also have to use the same program to decrypt as used
to encrypt the file?

Thanks again

Mark H. Wood wrote:
> Staggering off-topic a bit, this also points out that, for a variety
> of reasons, if you want to store data for the long term, you need to
> establish a periodic review of every single item in your archive.
>
> You need to be aware of obsolescent medium types and file formats and
> suchlike, and recode at-risk items using then-current best practice.
>
> You need to be aware of media volumes that are degrading, and copy
> at-risk items to fresh volumes before they become unrecoverable.  You
> should copy older volumes from time to time anyway, at intervals
> appropriate to the medium, to evade trouble before it starts.  This is
> a good opportunity to switch to a newer medium if there is one you like.
>
> You also need to archive things you might need to recover your items.
> File format documentation, useful software, and the like.
>
> If you do all that, your archive should be usable in toto for hundreds
> of years, which is probably longer than you need.  Much of it can be
> automated, requiring your attention only briefly.
>
> Or you can stash it all in an old shoebox, like the rest of us do. :-/
>
>   


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

Re: future proof file encryption

[Mark H. Wood]

Staggering off-topic a bit, this also points out that, for a variety
of reasons, if you want to store data for the long term, you need to
establish a periodic review of every single item in your archive.

You need to be aware of obsolescent medium types and file formats and
suchlike, and recode at-risk items using then-current best practice.

You need to be aware of media volumes that are degrading, and copy
at-risk items to fresh volumes before they become unrecoverable.  You
should copy older volumes from time to time anyway, at intervals
appropriate to the medium, to evade trouble before it starts.  This is
a good opportunity to switch to a newer medium if there is one you like.

You also need to archive things you might need to recover your items.
File format documentation, useful software, and the like.

If you do all that, your archive should be usable in toto for hundreds
of years, which is probably longer than you need.  Much of it can be
automated, requiring your attention only briefly.

Or you can stash it all in an old shoebox, like the rest of us do. :-/

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Friends don't let friends publish revisable-form documents.


pgpAptRdlqqSL.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: future proof file encryption

[Werner Koch]

On Thu, 26 Feb 2009 13:54, s...@intertivity.com said:

> i'm not aware of all file formats but you should stick with PKCS#12 format
> for symmetric encryption.
> It's an open standard, so I'm sure openssl and windows encryption can handle

Well kind of.  PKCS#12 is likely the most ugly encryption standard ever
written (or actually not written as it used to be an ad-hoc format).

Better stick with OpenPGP which dates back to the ~18 years old PGP2.

There are several OpenPGP implementations available and if you use GnuPG
you can always copy the sources onto the backup medium as well.  GnuPG
1.4 is highly portable and it is more likely that you won't be able to
read your backup medium in 10 or 20 years than you won't be able to
build GnuPG then.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


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

Re: future proof file encryption

[gerry_lowry (alliston ontario canada)]

Encryption is unnecessary with this low tech solution:  burn them to DVDs,
make at least two copies, put one copy in a safe deposit box at your bank.
Perhaps give the other in a do not open envelope to your lawyer or someone
that you can trust 100%.

This is still a problem because who knows if DVDs will be available in the 
future.

Solution to changing technology is to remember to recreate
your backup in the new technoligies of the future during the
brief transition periods while both technologies still exist.


Regards,
Gerry (Lowry)

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

RE: future proof file encryption

[Sascha Kiefer]

Hi peter,

i'm not aware of all file formats but you should stick with PKCS#12 format
for symmetric encryption.
It's an open standard, so I'm sure openssl and windows encryption can handle
it.
Gnugp uses OpenPGP file formats.

Cheers,
Sascha

-Original Message-
From: gnupg-users-boun...@gnupg.org [mailto:gnupg-users-boun...@gnupg.org]
On Behalf Of peter
Sent: Donnerstag, 26. Februar 2009 15:24
To: gnupg-users@gnupg.org
Subject: future proof file encryption

Hi,

I back-up my photos to remote storage. At the moment I don't encrypt
them - I don't understand encryption and I'm nervous of using something
I don't understand. They're just family snaps, but I'd prefer they
stayed private. Symmetric encryption seems a good route - all I have to
remember is a single password (the only risk seems to be senility).
However, who knows what OS or tools I'll be using in the future? I ran a
few tests encrypting and decrypting using the same algorithm/password
but different tools (gpg, openssl, mcrypt). They were unsuccessful. My
question is do I always have to use the same tool to decrypt as I used
to encrypt? Are the file formats tool specific? Is the way the tool
derives a key from the "key" I input variable? Probably there are other
issues I'm unaware of. I'd feel more comfortable knowing that recovery
of my data wasn't dependent on the availability of a specific tool (or
even worse a specific version of a tool).

Hope this is clear,

Thanks

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


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

future proof file encryption

[peter]

Hi,

I back-up my photos to remote storage. At the moment I don't encrypt
them - I don't understand encryption and I'm nervous of using something
I don't understand. They're just family snaps, but I'd prefer they
stayed private. Symmetric encryption seems a good route - all I have to
remember is a single password (the only risk seems to be senility).
However, who knows what OS or tools I'll be using in the future? I ran a
few tests encrypting and decrypting using the same algorithm/password
but different tools (gpg, openssl, mcrypt). They were unsuccessful. My
question is do I always have to use the same tool to decrypt as I used
to encrypt? Are the file formats tool specific? Is the way the tool
derives a key from the "key" I input variable? Probably there are other
issues I'm unaware of. I'd feel more comfortable knowing that recovery
of my data wasn't dependent on the availability of a specific tool (or
even worse a specific version of a tool).

Hope this is clear,

Thanks

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

Re: Secret key holder identity (was: Local file encryption)

[NikNot]

On 2/20/07, Janusz A. Urbanowicz <[EMAIL PROTECTED]> wrote:
> * without having recipient pubkey it is impossible to determine the recipient
> of the message (assuming the subkey ID is not widely known)
...
If the system was designed for the real world, the encrypted message
would, by default, consist of a binary data set, indistingushable from a
random stream, until and unless decrypted using the recipient's private key.

NikNot

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

Re: Secret key holder identity (was: Local file encryption)

[vedaal]

Janusz A. Urbanowicz alex at bofh.net.pl wrote on
Tue Feb 20 15:24:40 CET 2007 :

>* it is possible to hide recipient's completely ID by using --
throw-keyid


well, not 'completely'

running gpg-list-packets or pgpdump on the encrypted message,
lists the key-type (dh or rsa), key size, and symmetric algorithm 
used

so, for people who prefer 8092 rsa keys and use blowfish
[ you know who you are ;-)) ]
using throw keyid won't help much ...


vedaal


--
Click to get 125% of your home's value, super fast, no lender fees
http://tagline.hushmail.com/fc/CAaCXv1QaK0r1IT1ABMgmz21Tf3y9WCZ/


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

re: Secret key holder identity (was: Local file encryption)

[vedaal]

vedaal at hush.com vedaal at hush.com
Tue Feb 20 18:16:52 CET 2007 wrote:

> running gpg-list-packets or pgpdump on the encrypted message,
lists the key-type (dh or rsa), key size, and symmetric algorithm 
used

sorry,
my mistake ;-((

pgpdump doesn't list which symmetric algo, 
only lists that an mdc was or wasn't used

the actual symmetric algo type used is encrypted with the session 
key to the public key


is there a way to tell though,
(without decrypting)
which symmetric algo was used?

tia,

vedaal


--
Click to consolidate your debt and lower your monthly expenses
http://tagline.hushmail.com/fc/CAaCXv1QPxbwBGTnei9j0EserPyHAirc/


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

Re: Secret key holder identity (was: Local file encryption)

[Sven Radde]

NikNot schrieb:
> Unfortunately, the whole GPG, with WebOfTrust construct, makes the
> assumption that there is no need whatsoever to protect the identity of
> the secret key holder
You have, however, the possibility of using pseudonyms as UID. Only the
signers of your key would have to know about your true identity.
Another option against traffic analysis is to drop the Key-IDs of the
recipients of encrypted mail (-throw-key-ids IIRC?!).

cu, Sven

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

Re: Secret key holder identity (was: Local file encryption)

[NikNot]

On 2/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> pgpdump doesn't list which symmetric algo,
> only lists that an mdc was or wasn't used

The attacker performing large-scale traffic uses his own software that
is - so it must be presumed - capable of distilling all (to him)
usefull information from the flow of messages. Consequently, the
question should not be what pgpdump will or will not produce, the
question should be what information is or is not contained in the
message previous to its decryption.

NikNot

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

Re: Secret key holder identity (was: Local file encryption)

[Janusz A. Urbanowicz]

On Mon, Feb 19, 2007 at 10:54:17AM -0800, NikNot wrote:
> On 2/19/07, Adam Funk <[EMAIL PROTECTED]> wrote:
> >Is there any reason to physically secure your *public* keyring in
> >...  (Well, I suppose you might want to hide your secret identity!)
> 
> Unfortunately, the whole GPG, with WebOfTrust construct, makes the
> assumption that there is no need whatsoever to protect the identity of
> the secret key holder (and, by extension, that traffic analysis - as
> opposed to the secret content analysis - is not something to be
> concerned with).

That statement is definitely not true. 

* PGP was the first cryptosystem to hide sender's ID (when signing+encrypting), 
  compare PEM to see the difference;

* one can issue himself a key pair with pseudonym User ID the same way
  as with RL identity and use it normally;

* without having recipient pubkey it is impossible to determine the recipient 
of the message
  (assuming the subkey ID is not widely known)

* it is possible to hide recipient's completely ID by using --throw-keyid

Alex
-- 
JID: [EMAIL PROTECTED]
PGP: 0x46399138
od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze
 -- Czerski

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

Re: Secret key holder identity (was: Local file encryption)

[NikNot]

On 2/19/07, Joseph Oreste Bruni <[EMAIL PROTECTED]> wrote:

> It's funny you mention this: I got into an argument with a
> "consultant" about how X.509 certificates are a privacy violation
> because your identity is encoded into the "subject" field. I kept
> asking him, "How would you know whose cert. it is without it?" At any
> rate, there are lot of bozos in the world posing as "security
> experts" who shouldn't be taken seriously.

(Its not clear (to me) from the above what was "the bozo" saying: that
the certificates _are_ or _are not_ a privacy violation?)

I find it very interesting that Phil Zimmemann, who invented WOT,
apparently realizes that times are changing, and that WOT has
outlived its usefullness; specifically because - unlike perhaps at
the time of birth of PGP - trafic analysis is a threat that may be
naively ignored only in geek kindergartens, but not in the real life.

NikNot

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

Re: Local file encryption

[John Clizbe]

Adam Funk wrote:
> On 2007-02-19, John Clizbe wrote:
> 
>> The passphrase is only one protection on your keypair and it's
>> pretty much the protection of last resort - given an easily
>> guessable/brute-forced passphrase, it's "Game-Over." if an attacker
>> gets access to the keyring files. Another protection is to
>> physically secure your keyring files (or at the minimum, the secret
>> ring) by storing it on removable media of some sort:
> 
> Is there any reason to physically secure your *public* keyring in
> normal use?  

Convenience of having all the files together in one place and mitigating the
need to sync keys between public keyrings are only reasons that come to mind.

Outside of convenience factors, there is no real need to secure public keyrings;
that's why the keys are public.

-- 
John P. Clizbe  Inet:   John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A
"what's the key to success?"/ "two words: good decisions."
"what's the key to good decisions?" /  "one word: experience."
"how do i get experience?"  / "two words: bad decisions."

"Just how do the residents of Haiku, Hawai'i hold conversations?"



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Secret key holder identity (was: Local file encryption)

[Joseph Oreste Bruni]

On Feb 19, 2007, at 11:54 AM, NikNot wrote:


On 2/19/07, Adam Funk <[EMAIL PROTECTED]> wrote:

Is there any reason to physically secure your *public* keyring in
...  (Well, I suppose you might want to hide your secret identity!)


Unfortunately, the whole GPG, with WebOfTrust construct, makes the
assumption that there is no need whatsoever to protect the identity of
the secret key holder (and, by extension, that traffic analysis - as
opposed to the secret content analysis - is not something to be
concerned with).

NikNot

___


It's funny you mention this: I got into an argument with a  
"consultant" about how X.509 certificates are a privacy violation  
because your identity is encoded into the "subject" field. I kept  
asking him, "How would you know whose cert. it is without it?" At any  
rate, there are lot of bozos in the world posing as "security  
experts" who shouldn't be taken seriously.


Joe



smime.p7s
Description: S/MIME cryptographic signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Secret key holder identity (was: Local file encryption)

[NikNot]

On 2/19/07, Adam Funk <[EMAIL PROTECTED]> wrote:
> Is there any reason to physically secure your *public* keyring in
> ...  (Well, I suppose you might want to hide your secret identity!)

Unfortunately, the whole GPG, with WebOfTrust construct, makes the
assumption that there is no need whatsoever to protect the identity of
the secret key holder (and, by extension, that traffic analysis - as
opposed to the secret content analysis - is not something to be
concerned with).

NikNot

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

Re: Local file encryption

[Adam Funk]

On 2007-02-19, John Clizbe wrote:

> The passphrase is only one protection on your keypair and it's
> pretty much the protection of last resort - given an easily
> guessable/brute-forced passphrase, it's "Game-Over." if an attacker
> gets access to the keyring files. Another protection is to
> physically secure your keyring files (or at the minimum, the secret
> ring) by storing it on removable media of some sort:

Is there any reason to physically secure your *public* keyring in
normal use?  (Well, I suppose you might want to hide your secret
identity!)


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

Re: Local file encryption

[Janusz A. Urbanowicz]

On Mon, Feb 19, 2007 at 09:21:56AM -0500, [EMAIL PROTECTED] wrote:
> I have been using gpg to encrypt/decrypt files on my computer "for my
> eyes only".  I have been using my public/private keypair on my keyring
> to do so.   I just discovered that I can use encrypt/decrypt local
> files using a symmetric cipher--i.e., you enter one secret passphrase
> to encrypt and then enter the same secret passphrase to decrypt.
> Since my encryption is only for files for myself, do you think using a
> symmetric cipher would be a better idea, or doesn't it matter?Or
> is choice of a passphrase a bigger issue than the type of cipher --
> symmetric vs. public/private keypair ?

It doesnt matter, in both cases the files are symmetrically encrypted,
only keying method changes.

I prefer to use pubkey encryption anyway, , one passphrase less to remember.

-- 
JID: [EMAIL PROTECTED]
PGP: 0x46399138
od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze
 -- Czerski

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

Re: Local file encryption

[John Clizbe]

[EMAIL PROTECTED] wrote:
> I have been using gpg to encrypt/decrypt files on my computer "for my
> eyes only".  I have been using my public/private keypair on my keyring
> to do so.   I just discovered that I can use encrypt/decrypt local
> files using a symmetric cipher--i.e., you enter one secret passphrase
> to encrypt and then enter the same secret passphrase to decrypt.
> Since my encryption is only for files for myself, do you think using a
> symmetric cipher would be a better idea, or doesn't it matter?Or
> is choice of a passphrase a bigger issue than the type of cipher --
> symmetric vs. public/private keypair ?

If your GnuPG keyring files reside on the computer, then either approach is
equivalent -- your protection is ultimately determined by the strength of the
chosen passphrase protecting the secret key or the encrypted file.

Either method will encrypt the file using a symmetric cipher. The difference is
that in OpenPGP, a random session key is generated and that is used to
symmetrically encrypt the file. Then, the session key is encrypted using the
chosen public key(s).

The passphrase is only one protection on your keypair and it's pretty much the
protection of last resort - given an easily guessable/brute-forced passphrase,
it's "Game-Over." if an attacker gets access to the keyring files. Another
protection is to physically secure your keyring files (or at the minimum, the
secret ring) by storing it on removable media of some sort: floppy, PCMCIA flash
card, USB dongle,... and removing that media when you leave the computer. Now,
an attacker must have both the media with the secret keyring as well as the
secret key's passphrase.

If removable media is not an option, or for additional security on removable
media, you may use a disk encryption product such as TrueCrypt to create an
encrypted volume to store your keyring files. (Hint: Use a new key and 
passphrase.)




-- 
John P. Clizbe  Inet:   John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A
"what's the key to success?"/ "two words: good decisions."
"what's the key to good decisions?" /  "one word: experience."
"how do i get experience?"  / "two words: bad decisions."

"Just how do the residents of Haiku, Hawai'i hold conversations?"



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Local file encryption

[eemaestro]

I have been using gpg to encrypt/decrypt files on my computer "for my
eyes only".  I have been using my public/private keypair on my keyring
to do so.   I just discovered that I can use encrypt/decrypt local
files using a symmetric cipher--i.e., you enter one secret passphrase
to encrypt and then enter the same secret passphrase to decrypt.
Since my encryption is only for files for myself, do you think using a
symmetric cipher would be a better idea, or doesn't it matter?Or
is choice of a passphrase a bigger issue than the type of cipher --
symmetric vs. public/private keypair ?

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

Re: file encryption and integrity check

[Simon H. Garlick]

On 2/22/06, Vladimir Doisan <[EMAIL PROTECTED]> wrote:
> 512 MB backup file
>  GnuPG-64 | GnuPG-32
> ---
> twofish (256)33.5s (15.3 mbps) | 32.2s (15.9 mbps)
> aes (128)33.3s (15.4 mbps) | 34.5s (14.8 mbps)
> aes192   35.0s (14.6 mbps) | 33.8s (15.1 mbps)
> aes256   37.5s (13.7 mbps) | 36.8s (13.9 mbps)
> blowfish 52.3s (9.8 mbps)  | 52.7s (9.7 mbps)
> CAST526.9s (19.0 mbps) | 25.0s (20.5 mbps)
> 3DES 48.3s (10.6 mbps) | 47.0s (10.9 mbps)



Whoa. Blowfish slower than 3DES?




shg

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

Re: file encryption and integrity check

[Vladimir Doisan]

Yes, I did exactly the same for my encrypted backups, only I chose
Twofish due to speed advantage (TW256 - 16.2 mbps vs. AES256 - 12.6
mbps). With compression enabled - encryption speed was within 0.5 mbps
across all ciphers at around 12 mbps.
I did switch over to public key encryption last month.

Some benches
(this is on single Xeon 2.8 EM64T, 1 Gig RAM with RAID5 running Gentoo
in two separate 64 and 32 bit installs)
GnuPG 1.4.2 Benchmarks (symmetric encryption, no compress)

512 MB backup file
  GnuPG-64 | GnuPG-32
---
twofish (256)33.5s (15.3 mbps) | 32.2s (15.9 mbps)
aes (128)33.3s (15.4 mbps) | 34.5s (14.8 mbps)
aes192   35.0s (14.6 mbps) | 33.8s (15.1 mbps)
aes256   37.5s (13.7 mbps) | 36.8s (13.9 mbps)
blowfish 52.3s (9.8 mbps)  | 52.7s (9.7 mbps) 
CAST526.9s (19.0 mbps) | 25.0s (20.5 mbps)
3DES 48.3s (10.6 mbps) | 47.0s (10.9 mbps)


4.0 Gig backup file
  GnuPG-64|   GnuPG-32
---
twofish (256)253s (16.2 mbps) | 257s (15.9 mbps)
aes (128)310s (13.2 mbps) | 278s (14.7 mbps)
aes192   318s (12.8 mbps) | 288s (14.2 mbps)
aes256   325s (12.6 mbps) | 311s(13.2 mbps)



OpenSSL 0.9.7-r2 Benchmarks (probably for another topic - it blows GnuPG
out of the water in terms of speed)

512MB backup file
OpenSSL-64 | OpenSSL-32
-
aes (128)14.0s (36.6 mbps) | 17.9s (28.6 mbps)
aes192   15.1s (33.9 mbps) | 19.2s (26.7 mbps)
aes256   16.8s (30.5 mbps) | 18.0s (28.4 mbps)
blowfish 13.3s (38.5 mbps) | 13.0s (39.4 mbps) 
CAST520.5s (25.0 mbps) | 16.8s (30.5 mbps)
3DES 39.5s (13.0 mbps) | 32.2s (15.9 mbps) 


4.0 Gig backup file
   OpenSSL-64 | OpenSSL-32
---
aes (128)164s (25.0 mbps) | 163s(25.1 mbps)
aes192   166s (33.9 mbps) | 168s(24.4 mbps)
aes256   173s (23.5 mbps) | 179s (22.9 mbps)






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

Re: file encryption and integrity check

[Vladimir Doisan]

Yes, I did exactly the same for my encrypted backups, only I chose
Twofish due to speed advantage (TW256 - 16.2 mbps vs. AES256 - 12.6
mbps). With compression enabled - encryption speed was within 0.5 mbps
across all ciphers at around 12 mbps.
I did switch over to public key encryption last month.

Some benches
(this is on single Xeon 2.8 EM64T, 1 Gig RAM with RAID5 running Gentoo
in two separate 64 and 32 bit installs)
GnuPG 1.4.2 Benchmarks (symmetric encryption, no compress)

512 MB backup file
  GnuPG-64 | GnuPG-32
---
twofish (256)33.5s (15.3 mbps) | 32.2s (15.9 mbps)
aes (128)33.3s (15.4 mbps) | 34.5s (14.8 mbps)
aes192   35.0s (14.6 mbps) | 33.8s (15.1 mbps)
aes256   37.5s (13.7 mbps) | 36.8s (13.9 mbps)
blowfish 52.3s (9.8 mbps)  | 52.7s (9.7 mbps) 
CAST526.9s (19.0 mbps) | 25.0s (20.5 mbps)
3DES 48.3s (10.6 mbps) | 47.0s (10.9 mbps)


4.0 Gig backup file
  GnuPG-64|   GnuPG-32
---
twofish (256)253s (16.2 mbps) | 257s (15.9 mbps)
aes (128)310s (13.2 mbps) | 278s (14.7 mbps)
aes192   318s (12.8 mbps) | 288s (14.2 mbps)
aes256   325s (12.6 mbps) | 311s(13.2 mbps)



OpenSSL 0.9.7-r2 Benchmarks (probably for another topic - it blows GnuPG
out of the water in terms of speed)

512MB backup file
OpenSSL-64 | OpenSSL-32
-
aes (128)14.0s (36.6 mbps) | 17.9s (28.6 mbps)
aes192   15.1s (33.9 mbps) | 19.2s (26.7 mbps)
aes256   16.8s (30.5 mbps) | 18.0s (28.4 mbps)
blowfish 13.3s (38.5 mbps) | 13.0s (39.4 mbps) 
CAST520.5s (25.0 mbps) | 16.8s (30.5 mbps)
3DES 39.5s (13.0 mbps) | 32.2s (15.9 mbps) 


4.0 Gig backup file
   OpenSSL-64 | OpenSSL-32
---
aes (128)164s (25.0 mbps) | 163s(25.1 mbps)
aes192   166s (33.9 mbps) | 168s(24.4 mbps)
aes256   173s (23.5 mbps) | 179s (22.9 mbps)








David Shaw wrote:
> On Wed, Feb 22, 2006 at 05:49:40PM +1030, Alphax wrote:
>   
>> Francesco Turco wrote:
>> 
>> 
>>> i have disabled compression becouse files i have to encrypt are already
>>> compressed, and compression takes much more time then encryption.
>>>
>>> do you think it is a good choice?
>>>
>>>   
>> IIRC GnuPG will detect if data is compressed before it tries to compress
>> it; if so, it won't try to.
>> 
>
> This is correct.  Of course, it's possible that GnuPG doesn't
> recognize a particular kind of compression.  If I recall, it looks for
> bzip, gzip, and zip.
>
> David
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>   



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

Re: file encryption and integrity check

[Johan Wevers]

David Shaw wrote:

>This is correct.  Of course, it's possible that GnuPG doesn't
>recognize a particular kind of compression.  If I recall, it looks for
>bzip, gzip, and zip.

A simple default test would be of course to check if the used compression
algorithm could decrease the file size: this would also prevent compression
being used from files like jpeg and mpeg. However, I don't see how to use
this method in streaming mode.

-- 
ir. J.C.A. Wevers //  Physics and science fiction site:
[EMAIL PROTECTED]   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

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

Re: file encryption and integrity check

[David Shaw]

On Wed, Feb 22, 2006 at 05:49:40PM +1030, Alphax wrote:
> Francesco Turco wrote:
> 
> > i have disabled compression becouse files i have to encrypt are already
> > compressed, and compression takes much more time then encryption.
> > 
> > do you think it is a good choice?
> > 
> 
> IIRC GnuPG will detect if data is compressed before it tries to compress
> it; if so, it won't try to.

This is correct.  Of course, it's possible that GnuPG doesn't
recognize a particular kind of compression.  If I recall, it looks for
bzip, gzip, and zip.

David

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

Re: file encryption and integrity check

[Alphax]

Francesco Turco wrote:

> i have disabled compression becouse files i have to encrypt are already
> compressed, and compression takes much more time then encryption.
> 
> do you think it is a good choice?
> 

IIRC GnuPG will detect if data is compressed before it tries to compress
it; if so, it won't try to.

-- 
Alphax  |   /"\
Encrypted Email Preferred   |   \ / ASCII Ribbon Campaign
OpenPGP key ID: 0xF874C613  |X   Against HTML email & vCards
http://tinyurl.com/cc9up|   / \


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: file encryption and integrity check

[Francesco Turco]

Roscoe ha scritto:


Sure will.

gpg -c is what you want.

Make sure you are using a MDC, which means either using one of the
128bit blocksize ciphers (your gpg will probably use AES256 by
default, which is good - gpg -vc to find out) or passing the
--force-mdc option.



so no need to hash files (md5/crc32) before encryption?

anyway, after reading some man page and experimenting, i ended up with 
the following settings:


encrypt: gpg --symmetric --cipher-algo aes256 --compress-algo none 
decrypt: gpg --decrypt 

i avoided 3des,cast5,blowfish becouse they have 64bits blocksize.
i preferred aes over twofish, both 128bits blocksize, becouse the first 
one seems more "standarized" then the second one.
last, i preferred aes256 over aes128/aes192 becouse it is more secure 
and encryption times are quite the same.


i have disabled compression becouse files i have to encrypt are already 
compressed, and compression takes much more time then encryption.


do you think it is a good choice?

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

Re: file encryption and integrity check

[Eric]

On Mon, 2006-02-20 at 17:46 +0100, Francesco Turco wrote:
> i'd like to know if gnupg is a good choice for encrypting files with a 
> password and if it is possible to check if an encrypted file is 
> corrupted or not (integrity check). my goal is to burn some files on cds 
> and protect them both from other people and from physical corruption of 
> the media.

If you want to check if an encrypted file is corrupted or not, MDC will
do that for you.

If you want to protect the files from physical corruption of the media,
you'll need to use some kind of error correction system.


Eric


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: file encryption and integrity check

[David Shaw]

On Mon, Feb 20, 2006 at 05:46:29PM +0100, Francesco Turco wrote:
> hello,
> 
> i am very new with gnupg and cryptography in general.
> 
> i'd like to know if gnupg is a good choice for encrypting files with a 
> password and if it is possible to check if an encrypted file is 
> corrupted or not (integrity check). my goal is to burn some files on cds 
> and protect them both from other people and from physical corruption of 
> the media.

You want passphrase encryption (not public key) and integrity
protection?

  gpg --force-mdc --symmetric (thefile)

David

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

Re: file encryption and integrity check

[Roscoe]

Sure will.

gpg -c is what you want.

Make sure you are using a MDC, which means either using one of the
128bit blocksize ciphers (your gpg will probably use AES256 by
default, which is good - gpg -vc to find out) or passing the
--force-mdc option.


If you want protection in the way of recovering from random bit errors
rather than just detecting them, running par2 against the encrypted
archive might be the way to go.



On 2/21/06, Francesco Turco <[EMAIL PROTECTED]> wrote:
> hello,
>
> i am very new with gnupg and cryptography in general.
>
> i'd like to know if gnupg is a good choice for encrypting files with a
> password and if it is possible to check if an encrypted file is
> corrupted or not (integrity check). my goal is to burn some files on cds
> and protect them both from other people and from physical corruption of
> the media.
>
> thanks.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

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

file encryption and integrity check

[Francesco Turco]

hello,

i am very new with gnupg and cryptography in general.

i'd like to know if gnupg is a good choice for encrypting files with a 
password and if it is possible to check if an encrypted file is 
corrupted or not (integrity check). my goal is to burn some files on cds 
and protect them both from other people and from physical corruption of 
the media.


thanks.

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