From bdc at topenergy.co.nz  Fri Feb  1 00:16:04 2008
From: bdc at topenergy.co.nz (Bruce Cowin)
Date: Fri, 01 Feb 2008 12:16:04 +1300
Subject: more than one recipient
Message-ID: <s7a30d94.031@GWKHESVR.topenergy.wan>

This is probably a dumb, basic question but is it possible to list more
than one key name for the -recipient option when encrypting a file?

Thanks.


Regards,

Bruce


From dshaw at jabberwocky.com  Fri Feb  1 01:20:17 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Thu, 31 Jan 2008 19:20:17 -0500
Subject: more than one recipient
In-Reply-To: <s7a30d94.031@GWKHESVR.topenergy.wan>
References: <s7a30d94.031@GWKHESVR.topenergy.wan>
Message-ID: <20080201002016.GB8814@jabberwocky.com>

On Fri, Feb 01, 2008 at 12:16:04PM +1300, Bruce Cowin wrote:
> This is probably a dumb, basic question but is it possible to list more
> than one key name for the -recipient option when encrypting a file?

Yes.  Most people encrypt to two (themselves and the intended
recipient) as a matter of course.  Just repeat -r for each one:

  gpg -r person-1 -r person-2 -r person-3 ...

David


From jmoore3rd at bellsouth.net  Fri Feb  1 01:54:11 2008
From: jmoore3rd at bellsouth.net (John W. Moore III)
Date: Thu, 31 Jan 2008 19:54:11 -0500
Subject: more than one recipient
In-Reply-To: <s7a30d94.031@GWKHESVR.topenergy.wan>
References: <s7a30d94.031@GWKHESVR.topenergy.wan>
Message-ID: <47A26DB3.6080803@bellsouth.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -------- Original Message  --------
Subject: more than one recipient
From: Bruce Cowin <bdc at topenergy.co.nz>
To: gnupg-users at gnupg.org
Date: Thursday, January 31, 2008 6:16:04 PM

> This is probably a dumb, basic question but is it possible to list more
> than one key name for the -recipient option when encrypting a file?

Dumb? NO...how else Ya gonna learn.  Answer = YES!

JOHN 8-)
Timestamp: Thursday 31 Jan 2008, 19:54  --500 (Eastern Standard Time)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9-svn4675: (MingW32)
Comment: Public Key at:  http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: Homepage:  http://tinyurl.com/9ubue

iQEcBAEBCgAGBQJHom2yAAoJEBCGy9eAtCsPKLMIAJeMxtKqr9KeLKCzBmeCX0W1
8Mv6Kz6Ha0klDgPT3x7ZAdm3i6Mb6dvAs9cthb65Io9AI64H5VOzZj/2d3ZRSJqd
IDRXRtdICZeQquoM656bZ4bLkFQ6INpIrOxF1biXft15GitQPYYplq1hUSdhP0GA
9neXTFhBuALGd0ZByXoBt8STkMprvmohteq/YYFuswvg+OBL2jITFcbt142GQjkc
k+8Qe7c4Vy7eVdQUvO0OssJc3CBcEAzsSikUP81x4hGGgu0KUG/Kkk66wC/7kGdA
UPRPl8y7r5hzey1+6tVHISyUwoV5ByEwq4XNItUSOW1jIKtr0bom6kawxBStyxU=
=cEzN
-----END PGP SIGNATURE-----


From sithtracy at yahoo.com  Fri Feb  1 01:48:33 2008
From: sithtracy at yahoo.com (Tracy D. Bossong)
Date: Thu, 31 Jan 2008 16:48:33 -0800 (PST)
Subject: more than one recipient
Message-ID: <620990.77309.qm@web56703.mail.re3.yahoo.com>

--recipeint user1 --recipient user2 (or -r for short)

----- Original Message ----
From: Bruce Cowin <bdc at topenergy.co.nz>
To: gnupg-users at gnupg.org
Sent: Thursday, January 31, 2008 5:16:04 PM
Subject: more than one recipient


This 
is 
probably 
a 
dumb, 
basic 
question 
but 
is 
it 
possible 
to 
list 
more
than 
one 
key 
name 
for 
the 
-recipient 
option 
when 
encrypting 
a 
file?

Thanks.


Regards,

Bruce

_______________________________________________
Gnupg-users 
mailing 
list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080131/95b12c87/attachment.htm>

From bdc at topenergy.co.nz  Fri Feb  1 03:15:50 2008
From: bdc at topenergy.co.nz (Bruce Cowin)
Date: Fri, 01 Feb 2008 15:15:50 +1300
Subject: more than one recipient
Message-ID: <s7a337c1.005@GWKHESVR.topenergy.wan>

Cool, thanks everyone for the responses.


Regards,

Bruce

>>> David Shaw <dshaw at jabberwocky.com> 1/02/2008 1:20:17 p.m. >>>
On Fri, Feb 01, 2008 at 12:16:04PM +1300, Bruce Cowin wrote:
> This is probably a dumb, basic question but is it possible to list
more
> than one key name for the -recipient option when encrypting a file?

Yes.  Most people encrypt to two (themselves and the intended
recipient) as a matter of course.  Just repeat -r for each one:

  gpg -r person-1 -r person-2 -r person-3 ...

David

_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org 
http://lists.gnupg.org/mailman/listinfo/gnupg-users


From kevhilton at gmail.com  Mon Feb  4 06:48:13 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Sun, 3 Feb 2008 23:48:13 -0600
Subject: Can you clarify when data compression is used?
Message-ID: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>

Is the data compression algorithm applied to the text prior to being
converted to ciphertext, or is the ciphertext compressed, or is it the
combination of the ciphertext and encrypted session key that is compressed?
I can't seem to find any documentation discussing this.

-- 
Kevin Hilton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080203/ead29c12/attachment.htm>

From rjh at sixdemonbag.org  Mon Feb  4 08:07:46 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 04 Feb 2008 01:07:46 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
Message-ID: <47A6B9C2.2000905@sixdemonbag.org>

Kevin Hilton wrote:
> Is the data compression algorithm applied to the text prior to being
> converted to ciphertext, or is the ciphertext compressed, or is it the
> combination of the ciphertext and encrypted session key that is
> compressed?

Prior.  Ciphertext from a strong algorithm cannot be compressed.



From kevhilton at gmail.com  Mon Feb  4 08:17:48 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Mon, 4 Feb 2008 01:17:48 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
Message-ID: <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>

On Feb 4, 2008 1:17 AM, Kevin Hilton <kevhilton at gmail.com> wrote:

> Although  not supported on all systems (and not included on ubuntu by
> default if you can believe it), does bzip2 offers the highest compression?
> I know that --personal-compress-preferences may be included in the
> gpg.conf file to take advantage of bzip2 or zlib if desired.  Does PGP
> still only recognize ZIP or no compression?
>



-- 
Kevin Hilton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080204/6b66d793/attachment.htm>

From rjh at sixdemonbag.org  Mon Feb  4 08:48:14 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 04 Feb 2008 01:48:14 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>	<47A6B9C2.2000905@sixdemonbag.org>	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
Message-ID: <47A6C33E.9010300@sixdemonbag.org>

Kevin Hilton wrote:
> Although  not supported on all systems (and not included on ubuntu
> by default if you can believe it), does bzip2 offers the highest
> compression?

The question is meaningless.  It's predicated on the assumption that
there exists a ranking scheme by which bzip2 will always beat zip for
compression, or vice-versa.  The reality is that compression algorithms
have certain tasks they're good at and certain tasks they're awful at.

E.g., try compressing ciphertext sometime with either bzip2 or zip.  You
won't see any meaningful difference; both are equally awful at this.
Compressing PE/COFF versus ELF binaries will give different results.
Etc., etc., etc.

I can give only two bits of very broad advice, and one piece of specific
advice.  The two generals:

  * In most categories people care about, bzip2 offers better
    compression but is much slower.
  * Bandwidth is cheap.  It's not worth introducing interoperability
    problems just to get a slightly smaller file.

The one specific piece of advice:

  * Unless you can articulate a clear need why the defaults will not
    work for your purpose, stick with the defaults.




From kevhilton at gmail.com  Mon Feb  4 14:35:11 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Mon, 4 Feb 2008 07:35:11 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <47A6C33E.9010300@sixdemonbag.org>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
Message-ID: <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>

>
>
> The one specific piece of advice:
>
>  * Unless you can articulate a clear need why the defaults will not
>    work for your purpose, stick with the defaults.

I think I've seen this piece of advice before, and for the most part I
agree with it.  The problem I have, is that no where in the
documentation are the defaults specified.  You want me to trust the
defaults, but my contention is, at least tell me what the defaults are
-- no explanation needed.  We had this discussion with the default
cipher and hash choices.  When you tell me that dsa2 is enabled by
default (in newer GnuPG versions), however in the man pages there is
still a --enable-dsa2 flag, I hope you understand my confusion.  I'm
still confused what default cipher is chosen automatically (for me its
AES).  Again the man pages should accurately represent the defaults,
and changes should be made to the documentation when changes to the
defaults are added or subtracted.  I don't think the current GnuPG
manual is complete in any way nor in any way conveys what are the
default settings.   Its disingenuous for the program creators to
expect me to trust the defaults without at least conveying them to me.

Rant over, I apologize to the community.


-- 
Kevin Hilton


From dshaw at jabberwocky.com  Mon Feb  4 15:36:00 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 4 Feb 2008 09:36:00 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
Message-ID: <20080204143600.GA27579@jabberwocky.com>

On Sun, Feb 03, 2008 at 11:48:13PM -0600, Kevin Hilton wrote:
> Is the data compression algorithm applied to the text prior to being
> converted to ciphertext, or is the ciphertext compressed, or is it the
> combination of the ciphertext and encrypted session key that is compressed?

Prior.  Ciphertext doesn't compress particularly well.  Plus, there is
a minor (as in "don't rely on it, but it's nice to have") security
improvement in encrypting already-compressed data.

> I can't seem to find any documentation discussing this.

RFC-4880 documents this.

David


From dshaw at jabberwocky.com  Mon Feb  4 15:44:18 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 4 Feb 2008 09:44:18 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
Message-ID: <20080204144418.GB27579@jabberwocky.com>

On Mon, Feb 04, 2008 at 01:17:48AM -0600, Kevin Hilton wrote:
> On Feb 4, 2008 1:17 AM, Kevin Hilton <kevhilton at gmail.com> wrote:
> 
> > Although  not supported on all systems (and not included on ubuntu by
> > default if you can believe it), does bzip2 offers the highest compression?

It depends on what you are compressing.  BZip2 tends to do better than
zip against straight text, for example.

> > I know that --personal-compress-preferences may be included in the
> > gpg.conf file to take advantage of bzip2 or zlib if desired.  Does PGP
> > still only recognize ZIP or no compression?

Current PGP handles BZip2, ZLIB, and Zip (and of course no
compression).

Even if you're communicating with a person whose program doesn't
support BZip2, it is safe to put BZip2 in your
personal-compress-preferences.  Those preferences are only used if all
parties agree, so you won't accidentally create an interoperability
problem.  This is true of all the personal-(whatever)-preferences
lists.

David


From dshaw at jabberwocky.com  Mon Feb  4 19:18:38 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 4 Feb 2008 13:18:38 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
Message-ID: <20080204181838.GA30533@jabberwocky.com>

On Mon, Feb 04, 2008 at 07:35:11AM -0600, Kevin Hilton wrote:
> >
> >
> > The one specific piece of advice:
> >
> >  * Unless you can articulate a clear need why the defaults will not
> >    work for your purpose, stick with the defaults.
> 
> I think I've seen this piece of advice before, and for the most part I
> agree with it.  The problem I have, is that no where in the
> documentation are the defaults specified.  You want me to trust the
> defaults, but my contention is, at least tell me what the defaults are
> -- no explanation needed.  We had this discussion with the default
> cipher and hash choices.  When you tell me that dsa2 is enabled by
> default (in newer GnuPG versions), however in the man pages there is
> still a --enable-dsa2 flag, I hope you understand my confusion.

DSA2 is not enabled by default.  It can be enabled with --openpgp or
--rfc4880 (or --enable-dsa2 of course).

> I'm still confused what default cipher is chosen automatically (for
> me its AES).

There isn't a straightforward answer.  Basically, there is a list of
ciphers that is put in each key by default.  Currently that list is
AES256, AES192, AES, CAST5, and 3DES, but it can be changed at key
generation time (via the --default-preference-list option), or any
time afterwards (via the --edit-key command "setpref").

At encryption time, the list of possible ciphers is retrieved from
each recipient key, and a cipher is chosen that all recipients can
handle.  This guarantees that you never send a message that your
recipient won't be able to read.

It isn't always AES for you - it's just that for that particular
message, AES happened to work for all the recipients.

David


From rjh at sixdemonbag.org  Mon Feb  4 19:57:34 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 04 Feb 2008 12:57:34 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>	
	<47A6B9C2.2000905@sixdemonbag.org>	
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>	
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>	
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
Message-ID: <47A7601E.8000107@sixdemonbag.org>

Kevin Hilton wrote:
> The problem I have, is that no where in the documentation are the
> defaults specified.

>From the first full paragraph of the manpage:  "[GnuPG] is a tool to
provide digital encryption and signing services using the OpenPGP
standard.  [GnuPG] features complete key management and all bells and
whistles you can expect from a decent OpenPGP implementation."

To me, that language is pretty clear about where you should look--the
OpenPGP standard, aka RFC4880, or its immediate predecessor RFC2440.

That said, just because I think it's clear doesn't necessarily means it
/is/ clear.  If it turns out that language is confusing or unclear, it
should definitely be changed to point people in the right direction.

I wonder who the GnuPG documentation czar is.  Hmm.  I don't know if
that's ever been mentioned on the list--David, Werner, who's responsible
for the docs?

> I'm still confused what default cipher is chosen automatically (for
> me its AES).

http://en.wikipedia.org/wiki/Stable_marriage_problem

Everyone has a ranked list of preferences.  The preferences of all
recipients are considered and the stable marriage problem solved.  The
outcome of that computation is what algorithm GnuPG will use.

3DES is implicitly in everyone's preference list, so it can be fairly
said that 3DES is the default cipher preference.  Even if everything
else goes to hell, 3DES will be available and will be selected.


From vedaal at hush.com  Mon Feb  4 20:07:45 2008
From: vedaal at hush.com (vedaal at hush.com)
Date: Mon, 04 Feb 2008 14:07:45 -0500
Subject: gnupg for file splitting and re-constituting
Message-ID: <20080204190745.9BFEDD005F@mailserver10.hushmail.com>

if someone has a large program, or file, (*any* file type)
and wants to split it,
send the fragments and reconstitute it,
it is a trivial (although minorly tedious) thing to do using gnupg

All that is necessary is to armor the program,
and then split the resulting textfile into smaller parts of 
suitable message size,
and send it as numbered inline e-mail texts,
and then concatenate the texts of all the fragments,
and then restore the program by de-armoring it. 

have put up an example of a 2.5 mb truecrypt container, containing 
two files, where the truecrypt container was armored signed and 
encrypted,
and the armored pgp ouput split into five parts, which when 
concatenated, decrypts back to the original truecrypt container

http://www.angelfire.com/pr/pgpf/pgpoddities.html

(scroll down to section [11], 
otherwise you may suffer hunger, thirst or incredible boredom 
if you try to read from the beginning ;-)) )

anyone interested in writing a short script in bash, python, perl  
etc. to automate the file splitting and reconstituting, using gnupg 
commandline?


TIA,

vedaal



any ads or links below this message are added by hushmail without 

--
Click to get 150,000 in student loans and find the lowest rates
http://tagline.hushmail.com/fc/Ioyw6h4d7FblA8fts9RldEtVjBZ67iel92xTbg7eHSTqWXVXLl5xd9/
my endorsement or awareness of the nature of the link



From vedaal at hush.com  Mon Feb  4 20:16:54 2008
From: vedaal at hush.com (vedaal at hush.com)
Date: Mon, 04 Feb 2008 14:16:54 -0500
Subject: gnupg for file splitting and re-constituting  // typo, sorry
Message-ID: <20080204191654.7F17FD005F@mailserver10.hushmail.com>

vedaal at hush.com vedaal at hush.com
wrote on Mon Feb 4 20:07:45 CET 2008:

>(scroll down to section [11], 

sorry, meant to type *section [10]* ;-((

vedaal


any ads or links below this message are added by hushmail without 

--
Click for  FHA loan, $0 lender fees, low rates & approvals nationwide
http://tagline.hushmail.com/fc/Ioyw6h4dOJ6o88XU5bd16tB8wnSBZ5mmHJiQTUxJgzchd7VwfKf1R1/
my endorsement or awareness of the nature of the link



From dshaw at jabberwocky.com  Mon Feb  4 21:24:21 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 4 Feb 2008 15:24:21 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <47A7601E.8000107@sixdemonbag.org>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
Message-ID: <20080204202421.GB30533@jabberwocky.com>

On Mon, Feb 04, 2008 at 12:57:34PM -0600, Robert J. Hansen wrote:
> Kevin Hilton wrote:
> > The problem I have, is that no where in the documentation are the
> > defaults specified.
> 
> >From the first full paragraph of the manpage:  "[GnuPG] is a tool to
> provide digital encryption and signing services using the OpenPGP
> standard.  [GnuPG] features complete key management and all bells and
> whistles you can expect from a decent OpenPGP implementation."
> 
> To me, that language is pretty clear about where you should look--the
> OpenPGP standard, aka RFC4880, or its immediate predecessor RFC2440.
> 
> That said, just because I think it's clear doesn't necessarily means it
> /is/ clear.  If it turns out that language is confusing or unclear, it
> should definitely be changed to point people in the right direction.

The RFC doesn't specify default algorithms, aside from requiring 3DES
as the algorithm of last resort.  All decisions about algorithm
ranking are made by the implementations and indirectly, the user.

It's hard to list default algorithms in the man page mainly because
there isn't a single answer.  Different people will get a different
default algorithm depending on who they are sending a message to, and
possibly even by the order in which they specify the recipients on the
command line (see below).  All of this would need many paragraphs of
explanation, and that's not really appropriate for a man page.  I do
agree it would be good for it to be documented somewhere, though.

> > I'm still confused what default cipher is chosen automatically (for
> > me its AES).
> 
> http://en.wikipedia.org/wiki/Stable_marriage_problem

GPG doesn't use the Stable Marriage Problem when picking algorithms,
as this gives too much "power" to the recipients in choosing which
algorithm is used.  Rather, the intersection of preferences for all
recipients is generated, leaving an unordered list of algorithms that
are possible contenders for use.  At this point, note that it would be
possible to pick an algorithm from the list randomly, as there is no
algorithm on the list that isn't usable for all recipients.

GPG uses the personal-(whatever)-preferences as the final decider.  It
works its way down the personal preferences list in ranked order,
consulting the personal preferences against the generated intersection
list of recipient algorithms.  This gives the user the power to decide
what algorithms he or she generates, which is putting the power in the
right place.  If there are no personal-foo-preferences in use, then
GPG uses the first key specified as the decider.  This key is
frequently the user's key, so is a reasonable choice to pick the
favored algorithm.

David


From rjh at sixdemonbag.org  Mon Feb  4 21:44:33 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 04 Feb 2008 14:44:33 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <20080204202421.GB30533@jabberwocky.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>	<47A6B9C2.2000905@sixdemonbag.org>	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>	<47A6C33E.9010300@sixdemonbag.org>	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>	<47A7601E.8000107@sixdemonbag.org>
	<20080204202421.GB30533@jabberwocky.com>
Message-ID: <47A77931.90609@sixdemonbag.org>

David Shaw wrote:
> GPG doesn't use the Stable Marriage Problem when picking algorithms,
> as this gives too much "power" to the recipients in choosing which
> algorithm is used.

It wasn't my intention to claim the SMP was used directly, but rather
that it was an analogous process.  It's a good introduction to the idea
of mathematical preference matching.  I apologize for any confusion
generated there.





From kevhilton at gmail.com  Tue Feb  5 04:26:14 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Mon, 4 Feb 2008 21:26:14 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <47A7601E.8000107@sixdemonbag.org>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
Message-ID: <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>

Im aware of the personal cipher preferences and personal hash
preferences, but when talking about the defaults I specifically asking
if gpg were installed from source -- no modifications made -- and gpg
keys were created - what default cipher and hash would be listed first
in the list with the keys?

Without any intervention
gpg-key-gen

It appears to manually choose a DSA signing key (DSA vs DSA2 --
ambiguous since the man pages contain a switch to --enable-dsa2 in the
gpg.conf file) with SHA1 hash -- or at least the SHA1 hash is ranked
first in the key preference list

For the encryption key - a ElGamal 2048 bit key is the default with
AES chosen as the first cipher contained in the key cipher preference.

Basically I'm aware of the --default-preference-list option in the
gpg.conf file that control preferences during key generation.  I know
how to use this option, but sadly I think the explanation is really
lacking:
--default-preference-list string
          Set  the list of default preferences to string.  This prefer-
          ence list is used for new keys and becomes  the  default  for
          "setpref" in the edit menu.

What I want to know is obviously GnuPG comes with a
--default-preference-list "built-in".  If I dont specify this setting
in the gpg.conf file, what string is used by default?  This would
basically reveal the order and list of all the defaults for ciphers,
hashes, and compression settings.


From dshaw at jabberwocky.com  Tue Feb  5 04:52:22 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 4 Feb 2008 22:52:22 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
Message-ID: <20080205035222.GD31603@jabberwocky.com>

On Mon, Feb 04, 2008 at 09:26:14PM -0600, Kevin Hilton wrote:
> Im aware of the personal cipher preferences and personal hash
> preferences, but when talking about the defaults I specifically asking
> if gpg were installed from source -- no modifications made -- and gpg
> keys were created - what default cipher and hash would be listed first
> in the list with the keys?
> 
> Without any intervention
> gpg-key-gen
> 
> It appears to manually choose a DSA signing key (DSA vs DSA2 --
> ambiguous since the man pages contain a switch to --enable-dsa2 in the
> gpg.conf file) with SHA1 hash -- or at least the SHA1 hash is ranked
> first in the key preference list

As I said earlier, DSA.  Trust me.  It's really DSA.

DSA doesn't have a particular hash (so it can't have SHA1 or anything
else as a hash).  It has a hash length.  Don't get hung up on the
DSA/DSA2 thing.  In actuality, there is no such algorithm as "DSA2".
Most people call DSA with a key larger than 1024 bits or a hash larger
than 160 bits "DSA2" for convenience.  All the --enable-dsa2 switch
does (and again, it's off by default in 1.4.8 and 2.0.8), is allow you
to generate a DSA key that is larger than 1024 bits or has a hash
larger than 160 bits.

> For the encryption key - a ElGamal 2048 bit key is the default with
> AES chosen as the first cipher contained in the key cipher preference.

No.  The first cipher is AES256.  AES and AES256 are not the same
cipher (AES in OpenPGP is AES128).
 
> What I want to know is obviously GnuPG comes with a
> --default-preference-list "built-in".  If I dont specify this setting
> in the gpg.conf file, what string is used by default?  This would
> basically reveal the order and list of all the defaults for ciphers,
> hashes, and compression settings.

As of 1.4.8 and 2.0.8, and subject to change in future versions:

Cipher:      AES256, AES192, AES, CAST5, 3DES
Hash:	     SHA1, SHA256, RIPEMD160
Compression: ZLIB, BZIP2, ZIP, None

You could see this for yourself: generate a key, and run "showpref" on
it (which is in the manual, by the way).

David


From kevhilton at gmail.com  Tue Feb  5 05:18:01 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Mon, 4 Feb 2008 22:18:01 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
Message-ID: <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>

>As of 1.4.8 and 2.0.8, and subject to change in future versions:
>
>Cipher:      AES256, AES192, AES, CAST5, 3DES
>Hash:	     SHA1, SHA256, RIPEMD160
>Compression: ZLIB, BZIP2, ZIP, None

You are absolutely correct about these settings.  Perhaps this should
be included in documentation (and changed when needed), since I would
consider these to be the default settings for cipher, hash, and
compression choice.


>All the --enable-dsa2 switch
>does (and again, it's off by default in 1.4.8 and 2.0.8), is allow you
>to generate a DSA key that is larger than 1024 bits or has a hash
>larger than 160 bits.

This seems peculiar to me.  Why is this setting turned off by default?
 I'm not at war with anyone in these forums, but many have
acknowledged the shortcomings of using 160 bit hashes -- at least with
the SHA1 hash.  In the same vain, aren't keys sizes larger than 1024
bits actually now recommended?

The default fallback allows the creation of a 1024 bit DSA key
utilizing the SHA-1 hash -- the preferred preference.  Again I know
nothing about cryptography but based on the links provided by users'
of this forum, it would seem that the choice or a larger DSA key and
different hash would be preferable?.


From rjh at sixdemonbag.org  Tue Feb  5 06:12:02 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 04 Feb 2008 23:12:02 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>	<47A6B9C2.2000905@sixdemonbag.org>	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>	<47A6C33E.9010300@sixdemonbag.org>	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>	<47A7601E.8000107@sixdemonbag.org>	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
	<96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>
Message-ID: <47A7F022.5030807@sixdemonbag.org>

Kevin Hilton wrote:
> In the same vain, aren't keys sizes larger than 1024
> bits actually now recommended?

As I understand it, it's largely due to engineering concerns than
mathematical concerns.

The RFC which specifies the OpenPGP protocol first came out in 1998.  It
began to receive revisions almost immediately (the -bis series:
RFC2440bis1, RFC2440bis2, etc.).  These -bis series were meant as
previews of the next official RFC, whenever it would be published.

However, the original RFC remained canonical.  That specified DSA-1024.
 In order to closely follow the RFC, GnuPG left the default as DSA-1024.
 This was probably the right call to make for interoperability reasons.

As an example of what happens when people decide to move beyond the RFC,
look at PGP 7.0.  Management at PGP Security decided that Twofish was
the likely winner of the AES competition, and so they put Twofish into
PGP.  This put pressure on GnuPG to put Twofish into GnuPG, in order to
interoperate with PGP.

Twofish is almost entirely abandoned nowadays, but it still exists in
PGP and GnuPG.  Once a bad decision is made in engineering, the
engineers are stuck supporting it forever.  Take a look through the
archives sometime and see how many people have bitterly complained about
TIGER192 no longer being supported, despite the fact it was part of
GnuPG for about three and a half milliseconds.

I suspect--although I do not know--that a similar motivation drove
GnuPG's decision to leave DSA-1024 as the standard.

Now that RFC4880 has come out, supplanting RFC2440, I imagine the way is
clear to make all new keys DSA-2048 or DSA-3072.  After all, now it's
part of the standard.



From philb328 at yahoo.co.uk  Tue Feb  5 15:29:01 2008
From: philb328 at yahoo.co.uk (Phil Brooke)
Date: Tue, 5 Feb 2008 14:29:01 +0000 (GMT)
Subject: Using notations on data signatures
Message-ID: <947421.45671.qm@web23005.mail.ird.yahoo.com>

Hi,

I'm a bit confused about --sig-notation.  Suppose I detach-sign a file; is it
reasonable to use notations to briefly comment on it? e.g., 
  --sig-notation user at some.domain="This loan application is approved."
(Not dealing with loans really, but needed some example....)

Is the notation part of the signed data (whereas the comment headers aren't)
so that tampering with the notation is evident?

Thanks,

Phil.


      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com




From dshaw at jabberwocky.com  Tue Feb  5 15:42:16 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 5 Feb 2008 09:42:16 -0500
Subject: Using notations on data signatures
In-Reply-To: <947421.45671.qm@web23005.mail.ird.yahoo.com>
References: <947421.45671.qm@web23005.mail.ird.yahoo.com>
Message-ID: <20080205144216.GA32503@jabberwocky.com>

On Tue, Feb 05, 2008 at 02:29:01PM +0000, Phil Brooke wrote:
> Hi,
> 
> I'm a bit confused about --sig-notation.  Suppose I detach-sign a file; is it
> reasonable to use notations to briefly comment on it? e.g., 
>   --sig-notation user at some.domain="This loan application is approved."
> (Not dealing with loans really, but needed some example....)

Yes, that is a reasonable use of a notation.  Notations (and
especially user notations) are basically the escape hatch in the
OpenPGP design: they're intended for adding stuff to signatures.  What
stuff if up to the adder.

See also --sig-policy-url for another, but more standard, way to add
information about a signature.

> Is the notation part of the signed data (whereas the comment headers aren't)
> so that tampering with the notation is evident?

Yes.

David


From dshaw at jabberwocky.com  Tue Feb  5 17:17:38 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 5 Feb 2008 11:17:38 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <47A7F022.5030807@sixdemonbag.org>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
	<96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>
	<47A7F022.5030807@sixdemonbag.org>
Message-ID: <20080205161738.GA2400@jabberwocky.com>

On Mon, Feb 04, 2008 at 11:12:02PM -0600, Robert J. Hansen wrote:

> I suspect--although I do not know--that a similar motivation drove
> GnuPG's decision to leave DSA-1024 as the standard.

That's basically the reason.  While GPG fully supports DSA2 signatures
today, there are a large installed base that cannot handle them.
Because of this, we decided to fully accept DSA2 keys and signatures
from elsewhere, but won't generate a new DSA2 key unless the user opts
in with --enable-dsa2.

> Now that RFC4880 has come out, supplanting RFC2440, I imagine the way is
> clear to make all new keys DSA-2048 or DSA-3072.  After all, now it's
> part of the standard.

The way is clear, and we'll get there eventually, but the installed
base is still pretty old.  Using --rfc4880 or --openpgp does enable
DSA2, but the default is still off.

David


From thurston at cs.queensu.ca  Tue Feb  5 18:02:48 2008
From: thurston at cs.queensu.ca (Adrian Thurston)
Date: Tue, 05 Feb 2008 12:02:48 -0500
Subject: can you see any problem with this?
Message-ID: <47A896B8.9070703@cs.queensu.ca>

Hi,

I'd like to serve messages that have been encrypted to a large number of
people, however I don't want to reveal the list of recipients so I'm
going to use --throw-keys.

But speed at the decryption end is a concern, so I thought I would break
up an encrypted message into packets and when a client requests it serve
up only the packet that corresponds to the session key encrypted to
them, then the content packet. I haven't tried it yet, but it seems as
though it should work. I'd like to know if there is any non-obvious
reason why it is a bad idea.

Thanks,
 Adrian


From program.spe at home.pl  Fri Feb  1 09:58:12 2008
From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=)
Date: Fri, 01 Feb 2008 09:58:12 +0100
Subject: Safe decryption with GnuPG?
Message-ID: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>

Dear friends:

I have a file that I encrypted for myself 
and I want to read some information from it.  
The file is a text file and I need to read several lines of it.

The following requirements must be met:

1. 
The decrypted information must not make it to any persistent medium 
(I understand gpg '-d' already guarantees it 
as long as it manages the decrypted text,
 but what happens after it leaves gpg?)

2. 
The decrypted text must not be stored in volatile memory 
any longer than it is needed.  
In particular, it should be converted to a human-viewable bitmap 
and the computer-readable representation must be immediately erased.

3. Only the information I need should be displayed.

4. 
The bitmap must not be updated automatically 
(the containing window must not display it 
when it is in the background, whatever it means).
(It would be best to forget the bitmap altogether 
and regenerate it upon request, 
but it seems to be a hard thing to do
because the gpg output stream is not scrollable backwards).

5.
The bitmap itself should not make it to any persistent medium
and it should be scrambled, if possible, in the volatile memory.

6. 
It should not be possible 
to make a snapshot of the graphic in the window 
with any programmatic means 
(you can of course make a picture of the screen with a camera).

7. 
If more information is requested, 
it should be displayed in small chunks.  
The program should be fully unaware 
of the content of the chunks that are not being displayed.

(That probably means a garbage-collected language cannot be used).

8. 
The application should be as lightweight as possible 
(for source code audit).

Can you direct me to some implementation meeting these requirements?

Best regards,
Chris





From nobody at mixmaster.it  Sat Feb  2 06:16:23 2008
From: nobody at mixmaster.it (George Orwell)
Date: Sat,  2 Feb 2008 06:16:23 +0100 (CET)
Subject: Anti-Tempest Fonts, Where?
Message-ID: <f133adc25fca4666419c2209a0282047@mixmaster.it>

man gpg

the above cmd mentions anti tempest fonts. what does this mean
exactly? where are the anti-tempest fonts? i've searched the
net for them and cannot find them. the only mention of soft
tempest fonts were within a .zip containing image files claimed
to be for example only.

do tempest resistant fonts exist?

Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente   |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore   |anonymous system
Per maggiori informazioni      |For more info
                  https://www.mixmaster.it


From rjh at sixdemonbag.org  Tue Feb  5 18:25:54 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 05 Feb 2008 11:25:54 -0600
Subject: can you see any problem with this?
In-Reply-To: <47A896B8.9070703@cs.queensu.ca>
References: <47A896B8.9070703@cs.queensu.ca>
Message-ID: <47A89C22.5090409@sixdemonbag.org>

Adrian Thurston wrote:
> But speed at the decryption end is a concern, so I thought I would break
> up an encrypted message into packets and when a client requests it serve
> up only the packet that corresponds to the session key encrypted to
> them, then the content packet. I haven't tried it yet, but it seems as
> though it should work. I'd like to know if there is any non-obvious
> reason why it is a bad idea.

At first blush it seems like a case of there being way too much hammer
for the nail you have in mind.

1.  Compose a single message: "the magic words are... [insert passphrase
here]".


2.  Write a script to encrypt each message to each recipient's key and
mail it to them.  If this takes more than 20 lines of Perl, something's
wrong.

3.  Compose your future traffic as normal, but symmetrically encrypt it
and send it on to your recipients.


... Admittedly, I don't know the particulars of your environment, so
this might be inappropriate for your needs.  But it's the first thing
that comes to mind as I read your description of what's happening.



From david at miradoiro.com  Tue Feb  5 18:29:16 2008
From: david at miradoiro.com (=?iso-8859-1?Q?David_Pic=F3n_=C1lvarez?=)
Date: Tue, 5 Feb 2008 18:29:16 +0100
Subject: Safe decryption with GnuPG?
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
Message-ID: <000501c8681c$a1ca1e90$0302a8c0@Nautilus>

Sorry, but what you're asking for is impossible.

> The decrypted information must not make it to any persistent medium
> (I understand gpg '-d' already guarantees it
> as long as it manages the decrypted text,
> but what happens after it leaves gpg?)

That's the business of the viewer.

> In particular, it should be converted to a human-viewable bitmap
> and the computer-readable representation must be immediately erased.

This doesn't buy you much, especially since there's OCR and the computer 
generated bitmap is likely to be very regular.

> 3. Only the information I need should be displayed.

How does the viewer know which information you need?

> The bitmap must not be updated automatically
> (the containing window must not display it
> when it is in the background, whatever it means).
> (It would be best to forget the bitmap altogether
> and regenerate it upon request,
> but it seems to be a hard thing to do
> because the gpg output stream is not scrollable backwards).

Updated automatically? Not sure I see what you mean here.

> The bitmap itself should not make it to any persistent medium
> and it should be scrambled, if possible, in the volatile memory.

Scrambling isn't of much use. If someone can read your memory they can read 
the key, which must lie somewhere in memory as well.

> It should not be possible
> to make a snapshot of the graphic in the window
> with any programmatic means
> (you can of course make a picture of the screen with a camera).

This is impossible, unless you have: 1) trusted hardware, DRM style, or 2) a 
specifically built OS to ensure it.

> The application should be as lightweight as possible
> (for source code audit).

Good luck, you're proposing an application that would have to take full 
control of video RAM to ensure noone can read it, that would have to do all 
sorts of graphical manipulation to generate a bitmap from a text, etc.


--David.



From rjh at sixdemonbag.org  Tue Feb  5 18:36:06 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 05 Feb 2008 11:36:06 -0600
Subject: Safe decryption with GnuPG?
In-Reply-To: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
Message-ID: <47A89E86.9010800@sixdemonbag.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Krzysztof ?elechowski wrote:
> The decrypted information must not make it to any persistent medium 

GnuPG is almost certainly the wrong tool for your job.  GnuPG has little
control over low-level operating systems details like swap files.  It is
possible for cleartext to be stored in some manner.

> (I understand gpg '-d' already guarantees it 
> as long as it manages the decrypted text,
>  but what happens after it leaves gpg?)

[many other requirements snipped]

Many of your requirements belong in the application stack alongside or
above GnuPG, but are pretty much unrelated to GnuPG.  After it leaves
GnuPG it's no longer GnuPG's problem.  Many of your requirements are
also impossible to meet.  I don't mean "impossible" as in "it would
require a lot of engineering", I mean "impossible" as in "it's like
violating the Second Law of Thermodynamics".

> Can you direct me to some implementation meeting these requirements?

There exists no such implementation.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkeonoYACgkQf2XByo0Cu7Or6ADcDcxgGCAxE2/Dp6NkFzwXBNg4
MI15KpzntdSaJADgkHHfzS/T0/3BnLSkZCVQ0OJ5OFYmxl1Nw4cypIkBHAQBAQgA
BgUCR6iehgAKCRC3APSC/q+BCS9PB/sEIUftJVfX2hYNijy+ml6IAPYhGhIl73eP
si/FvVWVP9WIYAOIz4Q68x1en+zXOncQc8cTUO8HB8hJeuWwe8Zoi/V2cB8nJ9Q1
+mwAcY7q7QuipRJhCpMG/pIS+BY6lDrDWDS1FOlWajDiZnO9Yo81PNCp85B+SC3B
d69h2f6PBJY45DWHfQR224k/hEx9C522FlyPJVN6ZIn7fHSZonb4iTUyZ7Gh5mqW
AOwBGPfyxYcAiXaBJPvOrdBV3b9kg0Gzf+rCRBDLpJsgmWssQOdGrRIXcOuW9n0C
L94jJamwjgpP4YdTuirG4IZDwdcOw5vBoqjNrLpkvK8aoPWnf2AN
=b/yU
-----END PGP SIGNATURE-----


From rjh at sixdemonbag.org  Tue Feb  5 18:43:11 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 05 Feb 2008 11:43:11 -0600
Subject: Anti-Tempest Fonts, Where?
In-Reply-To: <f133adc25fca4666419c2209a0282047@mixmaster.it>
References: <f133adc25fca4666419c2209a0282047@mixmaster.it>
Message-ID: <47A8A02F.3080808@sixdemonbag.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

George Orwell wrote:
> do tempest resistant fonts exist?

First, it's not "tempest resistant".  TEMPEST is the name of the NSA's
standard on Van Eck-resistant hardware.  What you're talking about is
Van Eck surveillance.  I know, I know, PGP Corporation calls it "Tempest
resistance".  They're wrong, too.

Anyway, taking off the pedantry hat...

I am unaware of any empirical evidence that suggests PGP's Van
Eck-resistant fonts really offer much, if any, security against Van Eck
surveillance.  If you're dealing with people who are willing to park a
van down the block and dedicate a crew of surveillance experts and a few
thousand bucks of directional antennas and custom-built FPGAs at you, my
best advice is to (a) run away and (b) build a Faraday cage.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkeooC4ACgkQf2XByo0Cu7M8WgDbBHkrkNUpHMFZfykVffOsaTFw
9E3JVJ1mXBHmPgDdEdXJcN3vftBtGKw3va7zIPmNgVS/GmVFShYAWYkBHAQBAQgA
BgUCR6igLgAKCRC3APSC/q+BCZ2ECACMdFOEH47rTF03Cm834FWFNnegnGs8UGXD
z/uBEtrO212nIBSKXqEfLxL0137dnx8Y9e6NmU4XfxS5DhbpWY2baqiuJcSGVx7S
VSQPHffe1QO31ehlWEChHysKQDZRC+TGpyg/d6JWx+QVn8iixq5qB4N9qIRUrLAK
SV1pV4kA8TCPVCh/V8VfR77wdTjE4y5/vIn1iXcVpIZyieZUF3/5yYxN9fLU4m8H
UJI7BZTd3KU5PnDmA0X/xPbQaf4fITq+BBc22omDsLu5UEdWpXxw/R92J+1+0op7
uoqxqh3Hq51GoIsItirFTGLvLElcYAKBZKHWeeauxktOcnrjwRrH
=3//e
-----END PGP SIGNATURE-----


From dshaw at jabberwocky.com  Tue Feb  5 19:00:54 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 5 Feb 2008 13:00:54 -0500
Subject: can you see any problem with this?
In-Reply-To: <47A896B8.9070703@cs.queensu.ca>
References: <47A896B8.9070703@cs.queensu.ca>
Message-ID: <20080205180054.GB2400@jabberwocky.com>

On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote:
> Hi,
> 
> I'd like to serve messages that have been encrypted to a large number of
> people, however I don't want to reveal the list of recipients so I'm
> going to use --throw-keys.
> 
> But speed at the decryption end is a concern, so I thought I would break
> up an encrypted message into packets and when a client requests it serve
> up only the packet that corresponds to the session key encrypted to
> them, then the content packet. I haven't tried it yet, but it seems as
> though it should work. I'd like to know if there is any non-obvious
> reason why it is a bad idea.

It's hard to really answer this as there isn't enough information to
say one way or another.

Speaking strictly to your question, and not the "is this wise"
question, if I understand it, you are proposing encrypting to a large
number of people, breaking the resultant encrypted message into many
PKESK packets (one per recipient) and one encrypted packet.  Then,
send each recipient their own PKESK plus the encrypted packet.

So, yes, that would work.  GPG even ships with the tools to make such
a message.  And it's safe to do so with the caveat that every user
will have the same encrypted message and be able to decrypt it.  On
the one hand, no big deal, becuase you sent everyone the same message,
so you clearly wanted them to have it.  On the other hand, it gives
Alice the ability to know that Baker got the same message that Alice
did.  Whether that is important or not depends on what you are doing.

Also, given that you are only sending each recipient their own PKESK,
why bother to use --throw-keyid ?  It might be easier to just encrypt
the whole message to each recipient individually rather than do all
the packet surgery.

David


From rjh at sixdemonbag.org  Tue Feb  5 19:14:59 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 05 Feb 2008 12:14:59 -0600
Subject: Safe decryption with GnuPG?
In-Reply-To: <1202235036.6608.29.camel@a1dmin.vola.spe.com.pl>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>	
	<47A89E86.9010800@sixdemonbag.org>
	<1202235036.6608.29.camel@a1dmin.vola.spe.com.pl>
Message-ID: <47A8A7A3.7010802@sixdemonbag.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Krzysztof ?elechowski wrote:
> GnuPG claims it locks memory pages so that they are never dumped.

On systems where that's supported, sure.  On systems where that's not
supported, it doesn't.  Ergo, tread carefully.

> (although I am quite surprised
> because the requirements are quite obvious to me; 
> for what is the benefit of encryption 
> when a bad robot can read over your shoulder?)

If your hardware is compromised then you are absolutely screwed, and
there is nothing you can do about it.  Bang, period, game over, end of
sentence, end of discussion.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkeop6MACgkQf2XByo0Cu7OxvwDfeijBBMNF/zNFxk+faY5nERLG
6pT/D0jGRqHUdADfWJNvfqN7oPk1vNRBiXeIyQ0AVoV1BJT9y91soYkBHAQBAQgA
BgUCR6inowAKCRC3APSC/q+BCefVB/9hzIe10SvQlTThBAEZoGvD4s4HrIEWyIOo
j45mAzB63Z6TZyWwozjQsK8IVN2+TNY4fkOfmZSqo2P3O7Oz3dQ+0VY9FcCV2n1g
FqBZ1WuxEYMYJ37cLLbhN2s3fYKoBPW4Cv0atScC9hjeDyB7lUO5Gdm3BVw1XhPd
KI8Ke6syImfx1niXgTs3J2ZkkQueUkKvz/yGKeevAP+u8fg9U9NymQnKMlbyxPaf
oNkOdm64eJc0NMbA/KLwOoFgEv9CZpbRoZ8LeS9nZ3zpTtA+vlv/kivzR/aTZnR5
t7ttR64NXq5lnQOuiUxq8XyBwWhlmscXPiOg7H6X4QmqF0L7Zqmf
=fDSZ
-----END PGP SIGNATURE-----


From thurston at cs.queensu.ca  Tue Feb  5 19:10:02 2008
From: thurston at cs.queensu.ca (Adrian Thurston)
Date: Tue, 05 Feb 2008 13:10:02 -0500
Subject: can you see any problem with this?
In-Reply-To: <47A89C22.5090409@sixdemonbag.org>
References: <47A896B8.9070703@cs.queensu.ca> <47A89C22.5090409@sixdemonbag.org>
Message-ID: <47A8A67A.1000703@cs.queensu.ca>

My system can be described as encrypted news feeds.

I considered that approach and I like it because it's doesn't require
taking apart PGP messages. The problem is that in my system I need the
ability to revoke access to any single user.

With a session key unique to each message I can just re-encrypt and drop
a user. If the session key comes separately I need to ensure that the
clients always have the current symmetric key. The easiest way to do
that is to just send it with each message. But then I've just got ...
well you see :)

Adrian

Robert J. Hansen wrote:
> Adrian Thurston wrote:
>> But speed at the decryption end is a concern, so I thought I would break
>> up an encrypted message into packets and when a client requests it serve
>> up only the packet that corresponds to the session key encrypted to
>> them, then the content packet. I haven't tried it yet, but it seems as
>> though it should work. I'd like to know if there is any non-obvious
>> reason why it is a bad idea.
> 
> At first blush it seems like a case of there being way too much hammer
> for the nail you have in mind.
> 
> 1.  Compose a single message: "the magic words are... [insert passphrase
> here]".
> 
> 
> 2.  Write a script to encrypt each message to each recipient's key and
> mail it to them.  If this takes more than 20 lines of Perl, something's
> wrong.
> 
> 3.  Compose your future traffic as normal, but symmetrically encrypt it
> and send it on to your recipients.
> 
> 
> ... Admittedly, I don't know the particulars of your environment, so
> this might be inappropriate for your needs.  But it's the first thing
> that comes to mind as I read your description of what's happening.
> 
> 


From thurston at cs.queensu.ca  Tue Feb  5 19:28:08 2008
From: thurston at cs.queensu.ca (Adrian Thurston)
Date: Tue, 05 Feb 2008 13:28:08 -0500
Subject: can you see any problem with this?
In-Reply-To: <20080205180054.GB2400@jabberwocky.com>
References: <47A896B8.9070703@cs.queensu.ca>
	<20080205180054.GB2400@jabberwocky.com>
Message-ID: <47A8AAB8.4030200@cs.queensu.ca>

My application is here:

http://www.cs.queensu.ca/~thurston/fif/

I'm encrypting messages and making them publicly available over static
HTTP. Anyone who knows the right URL can grab a message and I don't want
recipients to be identifiable.

Another issue is that the number of recipients and the size of messages
may both get very large. A single encrypted message is therefore very
attractive.

Thanks,
 Adrian

David Shaw wrote:
> On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote:
>> Hi,
>>
>> I'd like to serve messages that have been encrypted to a large number of
>> people, however I don't want to reveal the list of recipients so I'm
>> going to use --throw-keys.
>>
>> But speed at the decryption end is a concern, so I thought I would break
>> up an encrypted message into packets and when a client requests it serve
>> up only the packet that corresponds to the session key encrypted to
>> them, then the content packet. I haven't tried it yet, but it seems as
>> though it should work. I'd like to know if there is any non-obvious
>> reason why it is a bad idea.
> 
> It's hard to really answer this as there isn't enough information to
> say one way or another.
> 
> Speaking strictly to your question, and not the "is this wise"
> question, if I understand it, you are proposing encrypting to a large
> number of people, breaking the resultant encrypted message into many
> PKESK packets (one per recipient) and one encrypted packet.  Then,
> send each recipient their own PKESK plus the encrypted packet.
> 
> So, yes, that would work.  GPG even ships with the tools to make such
> a message.  And it's safe to do so with the caveat that every user
> will have the same encrypted message and be able to decrypt it.  On
> the one hand, no big deal, becuase you sent everyone the same message,
> so you clearly wanted them to have it.  On the other hand, it gives
> Alice the ability to know that Baker got the same message that Alice
> did.  Whether that is important or not depends on what you are doing.
> 
> Also, given that you are only sending each recipient their own PKESK,
> why bother to use --throw-keyid ?  It might be easier to just encrypt
> the whole message to each recipient individually rather than do all
> the packet surgery.
> 
> David
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 


From dshaw at jabberwocky.com  Tue Feb  5 19:50:56 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 5 Feb 2008 13:50:56 -0500
Subject: can you see any problem with this?
In-Reply-To: <47A8AAB8.4030200@cs.queensu.ca>
References: <47A896B8.9070703@cs.queensu.ca>
	<20080205180054.GB2400@jabberwocky.com>
	<47A8AAB8.4030200@cs.queensu.ca>
Message-ID: <20080205185056.GC2400@jabberwocky.com>

On Tue, Feb 05, 2008 at 01:28:08PM -0500, Adrian Thurston wrote:
> My application is here:
> 
> http://www.cs.queensu.ca/~thurston/fif/
> 
> I'm encrypting messages and making them publicly available over static
> HTTP. Anyone who knows the right URL can grab a message and I don't want
> recipients to be identifiable.
> 
> Another issue is that the number of recipients and the size of messages
> may both get very large. A single encrypted message is therefore very
> attractive.

In that case, doing something like this may work for you:

gpg -o output.gpg -R recipient1 -R recipient2 -e thefile.txt
gpgsplit output.gpg

for i in *.pk_enc
do
  cat $i *.encrypted > `echo $i | sed -e 's/\-001\.pk_enc//'`
done

You'll end up with a directory full of files, one per recipient, and
each a valid OpenPGP message, but all of them protected via
throw-keyid.  I'll leave it as an exercise for the reader to determine
which file goes with which recipient ;)

Caveats:
  If Alice and Baker both get a message, and Alice knows which file
  Baker got, Alice can decrypt Baker's message using her own session
  key, thus revealing to Alice that Baker got the same message that
  Alice did.

  The "non-identifiable" feature with -R (aka throw-keyid) is only as
  good as throw-keyid is, which is pretty good but not perfect.

You may or may not care about these caveats.

David


From dshaw at jabberwocky.com  Tue Feb  5 20:00:34 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 5 Feb 2008 14:00:34 -0500
Subject: Anti-Tempest Fonts, Where?
In-Reply-To: <f133adc25fca4666419c2209a0282047@mixmaster.it>
References: <f133adc25fca4666419c2209a0282047@mixmaster.it>
Message-ID: <20080205190034.GD2400@jabberwocky.com>

On Sat, Feb 02, 2008 at 06:16:23AM +0100, George Orwell wrote:
> man gpg
> 
> the above cmd mentions anti tempest fonts. what does this mean
> exactly? where are the anti-tempest fonts? i've searched the
> net for them and cannot find them. the only mention of soft
> tempest fonts were within a .zip containing image files claimed
> to be for example only.
> 
> do tempest resistant fonts exist?

No.  Or at least, not any longer.  There was a font package available
a few years ago that was an offshoot of some work done by Markus Kuhn
and Ross Anderson at the University of Cambridge.  More recently, they
improved the attack enough that the fonts were no longer effective.

See
  http://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html

I'll update the manual so it does not reference the fonts any longer.

David


From thurston at cs.queensu.ca  Tue Feb  5 20:24:15 2008
From: thurston at cs.queensu.ca (=?utf-8?B?QWRyaWFuIFRodXJzdG9u?=)
Date: Tue, 5 Feb 2008 19:24:15 +0000
Subject: can you see any problem with this?
In-Reply-To: <20080205185056.GC2400@jabberwocky.com>
References: <47A896B8.9070703@cs.queensu.ca>
	<20080205180054.GB2400@jabberwocky.com>
	<47A8AAB8.4030200@cs.queensu.ca><20080205185056.GC2400@jabberwocky.com>
Message-ID: <1285006927-1202239420-cardhu_decombobulator_blackberry.rim.net-704829373-@bxe008.bisx.prod.on.blackberry>

Yes I think I can live with those characteristics of the system. Thanks for your analysis!

-Adrian  
-----Original Message-----
From: David Shaw <dshaw at jabberwocky.com>

Date: Tue, 5 Feb 2008 13:50:56 
To:Adrian Thurston <thurston at cs.queensu.ca>
Cc:gnupg-users at gnupg.org
Subject: Re: can you see any problem with this?


On Tue, Feb 05, 2008 at 01:28:08PM -0500, Adrian Thurston wrote:
> My application is here:
> 
> http://www.cs.queensu.ca/~thurston/fif/
> 
> I'm encrypting messages and making them publicly available over static
> HTTP. Anyone who knows the right URL can grab a message and I don't want
> recipients to be identifiable.
> 
> Another issue is that the number of recipients and the size of messages
> may both get very large. A single encrypted message is therefore very
> attractive.

In that case, doing something like this may work for you:

gpg -o output.gpg -R recipient1 -R recipient2 -e thefile.txt
gpgsplit output.gpg

for i in *.pk_enc
do
  cat $i *.encrypted > `echo $i | sed -e 's/\-001\.pk_enc//'`
done

You'll end up with a directory full of files, one per recipient, and
each a valid OpenPGP message, but all of them protected via
throw-keyid.  I'll leave it as an exercise for the reader to determine
which file goes with which recipient ;)

Caveats:
  If Alice and Baker both get a message, and Alice knows which file
  Baker got, Alice can decrypt Baker's message using her own session
  key, thus revealing to Alice that Baker got the same message that
  Alice did.

  The "non-identifiable" feature with -R (aka throw-keyid) is only as
  good as throw-keyid is, which is pretty good but not perfect.

You may or may not care about these caveats.

David



From hidekis at gmail.com  Wed Feb  6 02:30:01 2008
From: hidekis at gmail.com (Hideki Saito)
Date: Tue, 5 Feb 2008 17:30:01 -0800
Subject: Anti-Tempest Fonts, Where?
In-Reply-To: <20080205190034.GD2400@jabberwocky.com>
References: <f133adc25fca4666419c2209a0282047@mixmaster.it>
	<20080205190034.GD2400@jabberwocky.com>
Message-ID: <f49fc4840802051730u4e37ba40jc4f8146d847542cf@mail.gmail.com>

Makes me curious, how relevant is it these days, especially with age
of (presumably) lower emission LCD screen?

On Feb 5, 2008 11:00 AM, David Shaw <dshaw at jabberwocky.com> wrote:
> On Sat, Feb 02, 2008 at 06:16:23AM +0100, George Orwell wrote:
> > man gpg
> >
> > the above cmd mentions anti tempest fonts. what does this mean
> > exactly? where are the anti-tempest fonts? i've searched the
> > net for them and cannot find them. the only mention of soft
> > tempest fonts were within a .zip containing image files claimed
> > to be for example only.
> >
> > do tempest resistant fonts exist?
>
> No.  Or at least, not any longer.  There was a font package available
> a few years ago that was an offshoot of some work done by Markus Kuhn
> and Ross Anderson at the University of Cambridge.  More recently, they
> improved the attack enough that the fonts were no longer effective.
>
> See
>   http://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html
>
> I'll update the manual so it does not reference the fonts any longer.
>
> David
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>



-- 
Hideki Saito


From rjh at sixdemonbag.org  Wed Feb  6 02:59:29 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 05 Feb 2008 19:59:29 -0600
Subject: Anti-Tempest Fonts, Where?
In-Reply-To: <f49fc4840802051730u4e37ba40jc4f8146d847542cf@mail.gmail.com>
References: <f133adc25fca4666419c2209a0282047@mixmaster.it>	<20080205190034.GD2400@jabberwocky.com>
	<f49fc4840802051730u4e37ba40jc4f8146d847542cf@mail.gmail.com>
Message-ID: <47A91481.9080907@sixdemonbag.org>

Hideki Saito wrote:
> Makes me curious, how relevant is it these days, especially with age
> of (presumably) lower emission LCD screen?

An unshielded monitor cable puts out a lot of RF, regardless of what 
kind of monitor it's plugged into.  LCDs can be Van Ecked, just as can CRTs.



From kevhilton at gmail.com  Wed Feb  6 05:36:41 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Tue, 5 Feb 2008 22:36:41 -0600
Subject: Any plans for GnuPG to implement decrypting to RAM?
Message-ID: <96c450350802052036idffa463r6620bfde704f6eca@mail.gmail.com>

Just wonder if GnuPG, similar to PGP, would implement decrypting files
to RAM rather than swap, or to allow user to pick location.

-- 
Kevin Hilton


From dshaw at jabberwocky.com  Wed Feb  6 05:44:59 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 5 Feb 2008 23:44:59 -0500
Subject: Any plans for GnuPG to implement decrypting to RAM?
In-Reply-To: <96c450350802052036idffa463r6620bfde704f6eca@mail.gmail.com>
References: <96c450350802052036idffa463r6620bfde704f6eca@mail.gmail.com>
Message-ID: <20080206044459.GB3782@jabberwocky.com>

On Tue, Feb 05, 2008 at 10:36:41PM -0600, Kevin Hilton wrote:
> Just wonder if GnuPG, similar to PGP, would implement decrypting files
> to RAM rather than swap, or to allow user to pick location.

What does decrypt to swap mean?  For that matter, what does decrypt to
RAM mean?

Decryption:

  gpg -o /pick/your/own/destination -d file-to-decrypt.gpg

  gpg -d file-to-decrypt.gpg > redirect-to-a-file

  gpg -d file-to-decrypt.gpg | pipe-to-whatever-you-want

It's in the manual.

David


From pg at futureware.at  Wed Feb  6 02:22:09 2008
From: pg at futureware.at (Philipp =?iso-8859-1?q?G=FChring?=)
Date: Wed, 6 Feb 2008 02:22:09 +0100
Subject: Safe decryption with GnuPG?
In-Reply-To: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
Message-ID: <200802060222.10599.pg@futureware.at>

Hi,

> 1.
> The decrypted information must not make it to any persistent medium
> (I understand gpg '-d' already guarantees it
> as long as it manages the decrypted text,
>  but what happens after it leaves gpg?)

Use a full-disc encryption system for all your persistent media.

> 2.
> The decrypted text must not be stored in volatile memory
> any longer than it is needed.

You can use TaintedBochs or TaintedQemu to investigate that.

> In particular, it should be converted to a human-viewable bitmap
> and the computer-readable representation must be immediately erased.

Doesn?t help much to try that, I would say. But feel free to try ...

> 3. Only the information I need should be displayed.

You need a Do-What-I-Mean system for that.

> 4.
> The bitmap must not be updated automatically
> (the containing window must not display it
> when it is in the background, whatever it means).
> (It would be best to forget the bitmap altogether
> and regenerate it upon request,
> but it seems to be a hard thing to do
> because the gpg output stream is not scrollable backwards).

Use Overlay mode to display it.

>
> 5.
> The bitmap itself should not make it to any persistent medium
> and it should be scrambled, if possible, in the volatile memory.

Implement the viewer in the graphic card, with the CUDA SDK or something 
similar.

> 6.
> It should not be possible
> to make a snapshot of the graphic in the window
> with any programmatic means
> (you can of course make a picture of the screen with a camera).

Overlay mode does that.

> 7.
> If more information is requested,
> it should be displayed in small chunks.
> The program should be fully unaware
> of the content of the chunks that are not being displayed.

> (That probably means a garbage-collected language cannot be used).

I don?t understand why you need that. 
I would suggest that you seperate the small chunks into seperated encrypted 
files, to ensure that the reader only gets those chunks that you actually 
decrypted.

> 8.
> The application should be as lightweight as possible
> (for source code audit).

Agreed.

> Can you direct me to some implementation meeting these requirements?

I think your specification isn?t complete yet. You forgot about half of the 
requirements.

I guess that:

* You want a machine that seperates code from data (to be secure against  
trojans, virii and other malware)

* You want secure documents, that can?t change dynamically, or otherwise 
contain invisible contents

* You want a secure path to the user

(and some more requirements that I forgot at the moment)

What?s your budget for this small project?

Best regards,
Philipp G?hring



From steve at srevilak.net  Wed Feb  6 16:27:13 2008
From: steve at srevilak.net (Steve Revilak)
Date: Wed, 6 Feb 2008 10:27:13 -0500 (EST)
Subject: Safe decryption with GnuPG?
Message-ID: <alpine.OSX.1.00.0802061026001.344@fchq.ybpny>

> I have a file that I encrypted for myself and I want to read some information 
> from it. The file is a text file and I need to read several lines of it.
> 
> The following requirements must be met:

I was going to suggest

   gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null

but I'll try to be more serious. :)

Out of curiosity, what kind of a threat vector are you anticipating?
By reading your list of requirements, the ones I've extracted are

  * Access to sensitive data via system memory is a threat.

  * Access to sensitive data via the file system (i.e. by examining
    swap space) is a threat.

  * Access to sensitive data via the graphics system framebuffer is a
    threat.

  * Access to sensitive data via visual observation (someone sees the
    text on the screen, or takes a picture of the text on the screen)
    is a threat.

As someone else mentioned, this brings up a lot of issues in the area
of trusting the hardware, trusting the operating system and so fourth.
Granted, they are interesting issues, but my gut instinct tells me
that this problem might be easier to solve with physical security.

For example, the first three threats imply that the data has to leave
the system where it is being viewed.  Removing network access to that
system (unplug the ethernet cable, remove any wireless/bluetooth
hardware), would mitigate those threats, no?

As for threat #4, if you're viewing the data in a small, bare-walled,
locked room, you'd be able to tell (a) whether someone else was in the
room looking over your shoulder or (b) whether there was a camera
being pointed at your screen.

And if you don't trust the isolated computer in the small locked room,
you could even go as far as removing its hard drive -- you'd walk in
with a bootable CD that contained your encrypted file, boot up, read
what you needed, then halt.

Steve




> From: Philipp G?hring <pg at futureware.at>
> Date: Wed, 6 Feb 2008 02:22:09 +0100
> Subject: Re: Safe decryption with GnuPG?
> Message-ID: <200802060222.10599.pg at futureware.at>
> To: gnupg-users at gnupg.org
> Cc: Krzysztof ?elechowski <program.spe at home.pl>
> 
> Hi,
> 
>> 1.
>> The decrypted information must not make it to any persistent medium
>> (I understand gpg '-d' already guarantees it
>> as long as it manages the decrypted text,
>>  but what happens after it leaves gpg?)
> 
> Use a full-disc encryption system for all your persistent media.
> 
>> 2.
>> The decrypted text must not be stored in volatile memory
>> any longer than it is needed.
> 
> You can use TaintedBochs or TaintedQemu to investigate that.
> 
>> In particular, it should be converted to a human-viewable bitmap
>> and the computer-readable representation must be immediately erased.
> 
> Doesn?t help much to try that, I would say. But feel free to try ...
> 
>> 3. Only the information I need should be displayed.
> 
> You need a Do-What-I-Mean system for that.
> 
>> 4.
>> The bitmap must not be updated automatically
>> (the containing window must not display it
>> when it is in the background, whatever it means).
>> (It would be best to forget the bitmap altogether
>> and regenerate it upon request,
>> but it seems to be a hard thing to do
>> because the gpg output stream is not scrollable backwards).
> 
> Use Overlay mode to display it.
> 
>> 
>> 5.
>> The bitmap itself should not make it to any persistent medium
>> and it should be scrambled, if possible, in the volatile memory.
> 
> Implement the viewer in the graphic card, with the CUDA SDK or something
> similar.
> 
>> 6.
>> It should not be possible
>> to make a snapshot of the graphic in the window
>> with any programmatic means
>> (you can of course make a picture of the screen with a camera).
> 
> Overlay mode does that.
> 
>> 7.
>> If more information is requested,
>> it should be displayed in small chunks.
>> The program should be fully unaware
>> of the content of the chunks that are not being displayed.
> 
>> (That probably means a garbage-collected language cannot be used).
> 
> I don?t understand why you need that.
> I would suggest that you seperate the small chunks into seperated encrypted
> files, to ensure that the reader only gets those chunks that you actually
> decrypted.
> 
>> 8.
>> The application should be as lightweight as possible
>> (for source code audit).
> 
> Agreed.
> 
>> Can you direct me to some implementation meeting these requirements?
> 
> I think your specification isn?t complete yet. You forgot about half of the
> requirements.
> 
> I guess that:
> 
> * You want a machine that seperates code from data (to be secure against
> trojans, virii and other malware)
> 
> * You want secure documents, that can?t change dynamically, or otherwise
> contain invisible contents
> 
> * You want a secure path to the user
> 
> (and some more requirements that I forgot at the moment)
> 
> What?s your budget for this small project?
> 
> Best regards,
> Philipp G?hring
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

From steve at srevilak.net  Wed Feb  6 16:03:09 2008
From: steve at srevilak.net (Steve Revilak)
Date: Wed, 6 Feb 2008 10:03:09 -0500 (EST)
Subject: Safe decryption with GnuPG?
In-Reply-To: <200802060222.10599.pg@futureware.at>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
	<200802060222.10599.pg@futureware.at>
Message-ID: <alpine.OSX.1.00.0802060935040.253@fchq.ybpny>

> I have a file that I encrypted for myself 
> and I want to read some information from it. 
> The file is a text file and I need to read several lines of it.
> 
> The following requirements must be met:

I was going to suggest

   gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null

but I'll try to be more serious. :)

Out of curiosity, what kind of a threat vector are you anticipating?
By reading your list of requirements, the ones I've extracted are

  * Access to sensitive data via system memory is a threat.

  * Access to sensitive data via the file system (i.e. by examining
    swap space) is a threat.

  * Access to sensitive data via the graphics system framebuffer is a
    threat.

  * Access to sensitive data via visual observation (someone sees the
    text on the screen, or takes a picture of the text on the screen)
    is a threat.

As someone else mentioned, this brings up a lot of issues in the area
of trusting the hardware, trusting the operating system and so fourth.
Granted, they are interesting issues, but my gut instinct tells me
that this problem might be easier to solve with physical security.

For example, the first three threats imply that the data has to leave
the system where it is being viewed.  Removing network access to that
system (unplug the ethernet cable, remove any wireless/bluetooth
hardware), would mitigate those threats, no?

As for threat #4, if you're viewing the data in a small, bare-walled,
locked room, you'd be able to tell (a) whether someone else was in the
room looking over your shoulder or (b) whether there was a camera
being pointed at your screen.

And if you don't trust the isolated computer in the small locked room,
you could even go as far as removing its hard drive -- you'd walk in
with a bootable CD that contained your encrypted file, boot up, read
what you needed, then halt.

Steve




> From: Philipp G?hring <pg at futureware.at>
> Date: Wed, 6 Feb 2008 02:22:09 +0100
> Subject: Re: Safe decryption with GnuPG?
> Message-ID: <200802060222.10599.pg at futureware.at>
> To: gnupg-users at gnupg.org
> Cc: Krzysztof ?elechowski <program.spe at home.pl>
> 
> Hi,
>
>> 1.
>> The decrypted information must not make it to any persistent medium
>> (I understand gpg '-d' already guarantees it
>> as long as it manages the decrypted text,
>>  but what happens after it leaves gpg?)
>
> Use a full-disc encryption system for all your persistent media.
>
>> 2.
>> The decrypted text must not be stored in volatile memory
>> any longer than it is needed.
>
> You can use TaintedBochs or TaintedQemu to investigate that.
>
>> In particular, it should be converted to a human-viewable bitmap
>> and the computer-readable representation must be immediately erased.
>
> Doesn?t help much to try that, I would say. But feel free to try ...
>
>> 3. Only the information I need should be displayed.
>
> You need a Do-What-I-Mean system for that.
>
>> 4.
>> The bitmap must not be updated automatically
>> (the containing window must not display it
>> when it is in the background, whatever it means).
>> (It would be best to forget the bitmap altogether
>> and regenerate it upon request,
>> but it seems to be a hard thing to do
>> because the gpg output stream is not scrollable backwards).
>
> Use Overlay mode to display it.
>
>>
>> 5.
>> The bitmap itself should not make it to any persistent medium
>> and it should be scrambled, if possible, in the volatile memory.
>
> Implement the viewer in the graphic card, with the CUDA SDK or something
> similar.
>
>> 6.
>> It should not be possible
>> to make a snapshot of the graphic in the window
>> with any programmatic means
>> (you can of course make a picture of the screen with a camera).
>
> Overlay mode does that.
>
>> 7.
>> If more information is requested,
>> it should be displayed in small chunks.
>> The program should be fully unaware
>> of the content of the chunks that are not being displayed.
>
>> (That probably means a garbage-collected language cannot be used).
>
> I don?t understand why you need that.
> I would suggest that you seperate the small chunks into seperated encrypted
> files, to ensure that the reader only gets those chunks that you actually
> decrypted.
>
>> 8.
>> The application should be as lightweight as possible
>> (for source code audit).
>
> Agreed.
>
>> Can you direct me to some implementation meeting these requirements?
>
> I think your specification isn?t complete yet. You forgot about half of the
> requirements.
>
> I guess that:
>
> * You want a machine that seperates code from data (to be secure against
> trojans, virii and other malware)
>
> * You want secure documents, that can?t change dynamically, or otherwise
> contain invisible contents
>
> * You want a secure path to the user
>
> (and some more requirements that I forgot at the moment)
>
> What?s your budget for this small project?
>
> Best regards,
> Philipp G?hring
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

From SeidlS at schneider.com  Wed Feb  6 22:28:49 2008
From: SeidlS at schneider.com (SeidlS at schneider.com)
Date: Wed, 6 Feb 2008 15:28:49 -0600
Subject: SMIME vs PGP
Message-ID: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>


I am not a encryption expert, and need some help from the GnuPG user group.

We have a new software product that has the capability of encrypting
documents using SMIME.  How common is SMIME and used outside of email
clients?  Is it compatible with the OpenPGP standard, and thus GnuPG?  Is
there a good website discussing the differences between the two standards?


Thanks
Scott
Enterprise Integration Services
This document, and any attachments therein, contains proprietary and
confidential information that may not be disclosed without the prior
written permission of Schneider National, Inc. and its subsidiaries.
Unauthorized use or misuse of this information and its contents is strictly
prohibited. Schneider National, Inc. vigorously protects its rights.



From rjh at sixdemonbag.org  Wed Feb  6 23:18:29 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 06 Feb 2008 16:18:29 -0600
Subject: SMIME vs PGP
In-Reply-To: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
References: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
Message-ID: <47AA3235.3090905@sixdemonbag.org>

SeidlS at schneider.com wrote:
> I am not a encryption expert, and need some help from the GnuPG user
> group.

While you can probably get some good pointers here, if you're looking
for an answer you can rely on you will either need to do a fair bit of
homework or else contract with an outside information security
consultant.  Information security is a subtle subject and many people
who claim to know things actually know very little about those things.

I, of course, am no exception.

> We have a new software product that has the capability of encrypting 
> documents using SMIME.  How common is SMIME and used outside of email
> clients?

S/MIME support (note the slash) is built into virtually every
proprietary email client as a standard feature, and is present in many
of the open-source ones.  Outlook, Thunderbird, Lotus Notes, Apple's
Mail.app, and more, all support it out-of-the-box.

S/MIME integration with mail clients is substantially better than
OpenPGP's integration with mail clients.

> Is it compatible with the OpenPGP standard, and thus GnuPG?

On some level, theoretically, sure, given that S/MIME uses X.509
certificates, and X.509 certificates can be finessed into the Web of
Trust.  However, you will need a lot of elbow grease and a really big
crowbar, and the resulting Frankenstein's Monster will not be pretty.

I have never seen this done in practice.  S/MIME and OpenPGP
interoperability is, AFAIK, a theoretical chimera.

> Is there a good website discussing the differences between the two 
> standards?

I can't answer this without knowing what level of detail you're
interested in, difference-wise.  From an end-user perspective S/MIME and
OpenPGP provide essentially identical capabilities.  Slightly more
involved than that, S/MIME and OpenPGP use many of the same algorithms.
  More involved than that, they handle all manner of internal things
differently.

If you want to come to a fairly comprehensive understanding of both, I
would recommend reading RFC3852 ( http://tools.ietf.org/html/rfc3852 )
and RFC4880 ( http://tools.ietf.org/html/rfc4880 ).  S/MIME is based
upon the former, and OpenPGP is defined by the latter.



From alex at bofh.net.pl  Wed Feb  6 23:32:46 2008
From: alex at bofh.net.pl (Janusz A. Urbanowicz)
Date: Wed, 6 Feb 2008 23:32:46 +0100
Subject: SMIME vs PGP
In-Reply-To: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
References: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
Message-ID: <20080206223246.GC3595@hell.pl>

On Wed, Feb 06, 2008 at 03:28:49PM -0600, SeidlS at schneider.com wrote:

> I am not a encryption expert, and need some help from the GnuPG user group.

That's why we are here.

> We have a new software product that has the capability of encrypting
> documents using SMIME.  How common is SMIME and used outside of email
> clients?  Is it compatible with the OpenPGP standard, and thus GnuPG?  Is
> there a good website discussing the differences between the two standards?

S/MIME is a PKI (as in X.509 standard) counterpart of some subset of
OpenPGP standard (as defined in RFC 4880). 

OpenPGP defines a way to sign, encrypt and then format data for
transmission or storage. Another standard, PGP/MIME, defines a way to
ue OpenPGP capabilities within e-mail. OpenPGP uses its own format of
keys with its own way how to decide to trust them.

S/MIME is based on X.509 certificates (with its hierarchy of trust),
and specifies only a way to sign and/or encrypt data within e-mail
based MIME structure. A counterpart just to encrypt random data is
called CMS (Cryptographic Message Syntax). S/MIME was based on PKCS#7,
now is based on CMS (which was developed after first version of
S/MIME), which now positions CMS as PKI counterpart to OpenPGP.

To muddy waters further, there are other PKI based-standards, like
XML-DSIG which aren't compatible with CMS or OpenPGP.

GNU Privacy Guard 1.x talks only OpenPGP. GNU Privacy Guard 2.x talks
OpenPGP and S/MIME, I'm not sure if it talks plain CMS.

> This document, and any attachments therein, contains proprietary and
> confidential information that may not be disclosed without the prior
> written permission of Schneider National, Inc. and its subsidiaries.
> Unauthorized use or misuse of this information and its contents is strictly
> prohibited. Schneider National, Inc. vigorously protects its rights.

This is a stupid footer to attach while posting to public mailing list.

Alex
-- 
JID: alex at hell.pl
PGP: 0x46399138
od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze
 -- Czerski


From JPClizbe at tx.rr.com  Wed Feb  6 23:48:08 2008
From: JPClizbe at tx.rr.com (John Clizbe)
Date: Wed, 06 Feb 2008 16:48:08 -0600
Subject: SMIME vs PGP
In-Reply-To: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
References: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
Message-ID: <47AA3928.9090609@tx.rr.com>

SeidlS at schneider.com wrote:
> I am not a encryption expert, and need some help from the GnuPG user group.
> 
> We have a new software product that has the capability of encrypting
> documents using SMIME.  How common is SMIME and used outside of email
> clients?  Is it compatible with the OpenPGP standard, and thus GnuPG?  Is
> there a good website discussing the differences between the two standards?

S/MIME is common in a majority of email clients
(http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients#Features ), much more
so than its use. The Wikipedia S/MIME article summarizes some of the more common
obstacles to S/MIME adoption as well as a few caveats.

S/MIME itself is not used outside of email apps, however the certificates
(keys), sometimes referred to as X.509 certificates, S/MIME uses are able to be
used by other apps, eg for digital signatures in applications such as Open
Office, MS Office and Adobe Acrobat, and for encryption in IM programs such as AIM.

The creation and management of the certificates themselves, the Certificate
Authority (CA), is usually the major task of establishing an enterprise PKI.

Regards.
-- 
John P. Clizbe                   Inet:   JPClizbe (a) tx DAWT rr DAHT com
Ginger Bear Networks             hkp://keyserver.gingerbear.net
"Be who you are and say what you feel because those who mind don't matter
and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 658 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20080206/e2026059/attachment.pgp>

From pg at futureware.at  Thu Feb  7 00:11:25 2008
From: pg at futureware.at (Philipp =?utf-8?q?G=C3=BChring?=)
Date: Thu, 7 Feb 2008 00:11:25 +0100
Subject: SMIME vs PGP
In-Reply-To: <47AA3928.9090609@tx.rr.com>
References: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
	<47AA3928.9090609@tx.rr.com>
Message-ID: <200802070011.26393.pg@futureware.at>

Hi,

> S/MIME itself is not used outside of email apps, however the certificates
> (keys), sometimes referred to as X.509 certificates, S/MIME uses are able
> to be used by other apps, eg for digital signatures in applications such as
> Open Office, 

OpenOffice uses XML-DSig, not S/Mime. 

> and Adobe Acrobat, 

The PDF Format uses PKCS#7, not S/Mime. 

XML-DSig, PKCS#7 and S/Mime are all using X.509 certificates.
(And even CMS, but I haven?t seen that one in practice yet)

Best regards,
Philipp G?hring



From wk at gnupg.org  Thu Feb  7 16:03:38 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Feb 2008 16:03:38 +0100
Subject: SMIME vs PGP
In-Reply-To: <200802070011.26393.pg@futureware.at> ("Philipp =?utf-8?Q?G?=
	=?utf-8?Q?=C3=BChring=22's?=
	message of "Thu, 7 Feb 2008 00:11:25 +0100")
References: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
	<47AA3928.9090609@tx.rr.com> <200802070011.26393.pg@futureware.at>
Message-ID: <87tzkklsfp.fsf@wheatstone.g10code.de>

On Thu,  7 Feb 2008 00:11, pg at futureware.at said:

> OpenOffice uses XML-DSig, not S/Mime. 

Oh dear.

> XML-DSig, PKCS#7 and S/Mime are all using X.509 certificates.
> (And even CMS, but I haven?t seen that one in practice yet)

CMS is the same as PKCS#7, it is just a new name with some minor
semantic changes.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Thu Feb  7 16:05:54 2008
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Feb 2008 16:05:54 +0100
Subject: SMIME vs PGP
In-Reply-To: <20080206223246.GC3595@hell.pl> (Janusz A. Urbanowicz's message
	of "Wed, 6 Feb 2008 23:32:46 +0100")
References: <OF1B83A478.21830DFD-ON862573E7.0073FF2F-862573E7.0075FEE1@schneider.com>
	<20080206223246.GC3595@hell.pl>
Message-ID: <87prv8lsbx.fsf@wheatstone.g10code.de>

On Wed,  6 Feb 2008 23:32, alex at bofh.net.pl said:

> GNU Privacy Guard 1.x talks only OpenPGP. GNU Privacy Guard 2.x talks
> OpenPGP and S/MIME, I'm not sure if it talks plain CMS.

GnuPG (gpgsm) support plain CMS and no S/MIME.  S/MIME requires all that
MIME stuff.  It is the same as with OpenPGP vs. PGP/MIME; GnuPG (gpg or
gpg2) does not directly support PGP/MIME.


Salam-Shalom,

   Werner

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



From vedaal at hush.com  Thu Feb  7 17:03:02 2008
From: vedaal at hush.com (vedaal at hush.com)
Date: Thu, 07 Feb 2008 11:03:02 -0500
Subject: OT // truecrypt 5  // whole disk encryption 
Message-ID: <20080207160303.19B651A0039@mailserver8.hushmail.com>

truecrypt 5 was released Feb/5
http://www.truecrypt.org/docs/?s=version-history

it offers whole disk encryption,
(except for the boot partition with the mbr or grub)

have not yet tried it with grub and dual booting,
but it looks 'promising'

(now if they could get it to work with a blackberry ...


vedaal


any ads or links below this message are added by hushmail without 

--
Click to get 150,000 in student loans and find the lowest rates
http://tagline.hushmail.com/fc/Ioyw6h4d7FbHSnjUBiaNcF6fn0lDWVMsxILIjCtH390RCflBga3x51/
my endorsement or awareness of the nature of the link



From bruno.capeleto at free.fr  Fri Feb  8 02:49:04 2008
From: bruno.capeleto at free.fr (Bruno CAPELETO)
Date: Fri, 08 Feb 2008 02:49:04 +0100
Subject: passphrase works ONLY with enigmail
Message-ID: <47ABB510.3060002@free.fr>

Dear all,

I'm becoming crazy and begging for help.

I generated a pair of key one month ago with gpg command line, I use GPG
with Thunderbird/Enigmail.

Everything fine until I tried gpg with gajim : my passphrase was
systematically refused.

As my passphrase contains accent (eg "? la ville, j'y vais de suite"), I
thought I should try to change it to remove the accent (eg "a la ville,
j'y vais de suite").

Then I realized that my passphrase is also refused on the command line !

I tried to change the locale (UTF-8, ISO-8859-1...) with no success.
I also tried gpa with no success.

As a conclusion, I can't change my passphrase, because it is accepted
ONLY in Enigmail !

Please help...

Bruno



From bruno.capeleto at free.fr  Fri Feb  8 03:38:39 2008
From: bruno.capeleto at free.fr (Bruno CAPELETO)
Date: Fri, 08 Feb 2008 03:38:39 +0100
Subject: passphrase works ONLY with enigmail
Message-ID: <47ABC0AF.3070200@free.fr>

I found the solution.

I had a carefull look at Enigmail Debug Console.

I found out some weird characters, that were only reproducible in a
console in X mode when default locale was ISO-8859-1. In addition, the
option --charset utf8 was used with gpg.

I fixed to this locale, restarted X, and use gpg --charset utf8 in a
console in X (didn't work outside X!) to change my passphrase.

Maybe this can help someone else...


Bruno CAPELETO a ?crit :
> Dear all,
>
> I'm becoming crazy and begging for help.
>
> I generated a pair of key one month ago with gpg command line, I use GPG
> with Thunderbird/Enigmail.
>
> Everything fine until I tried gpg with gajim : my passphrase was
> systematically refused.
>
> As my passphrase contains accent (eg "? la ville, j'y vais de suite"), I
> thought I should try to change it to remove the accent (eg "a la ville,
> j'y vais de suite").
>
> Then I realized that my passphrase is also refused on the command line !
>
> I tried to change the locale (UTF-8, ISO-8859-1...) with no success.
> I also tried gpa with no success.
>
> As a conclusion, I can't change my passphrase, because it is accepted
> ONLY in Enigmail !
>
> Please help...
>
> Bruno
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>   





From rodhash at gmail.com  Fri Feb  8 15:30:13 2008
From: rodhash at gmail.com (Rodrigo Hashimoto)
Date: Fri, 8 Feb 2008 12:30:13 -0200
Subject: Key Server
Message-ID: <a04587060802080630ndb5cd1dq58934103a618958f@mail.gmail.com>

Hello everybody,

Which key-server can I use??

And how?

Thanks


-- 
Rodrigo Hashimoto

*"...amar n?o ? olhar um para o outro, mas olharem ambos na mesma dire??o".
Vivam juntos um belo ideal.

Saint Exup?ry, Livro: "Pequeno Pr?ncipe" *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080208/a85e0f54/attachment.htm>

From rjh at sixdemonbag.org  Fri Feb  8 16:55:57 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 08 Feb 2008 09:55:57 -0600
Subject: Key Server
In-Reply-To: <a04587060802080630ndb5cd1dq58934103a618958f@mail.gmail.com>
References: <a04587060802080630ndb5cd1dq58934103a618958f@mail.gmail.com>
Message-ID: <47AC7B8D.7020302@sixdemonbag.org>

Rodrigo Hashimoto wrote:
> Which key-server can I use??

Add "keyserver x-hkp://pool.sks-keyservers.net" to your gpg.conf file.




From sinux at fsfe.org  Fri Feb  8 21:07:21 2008
From: sinux at fsfe.org (Sebastien Chassot)
Date: Fri, 08 Feb 2008 21:07:21 +0100
Subject: How know who is a file encrypted for ?
Message-ID: <1202501241.1029.22.camel@dell.sinux.seb>

Hi,

I can't find how list who's a file encrypted for ? I've encrypt several
files with different recipients, but I don't remember which.

In general how can I make difference between file encrypted for one
user, several user ? symmetric encrypted, asymmetric ?


Thank you.


-- 

     Sebastien



From dshaw at jabberwocky.com  Fri Feb  8 21:23:02 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Fri, 8 Feb 2008 15:23:02 -0500
Subject: How know who is a file encrypted for ?
In-Reply-To: <1202501241.1029.22.camel@dell.sinux.seb>
References: <1202501241.1029.22.camel@dell.sinux.seb>
Message-ID: <20080208202301.GB17716@jabberwocky.com>

On Fri, Feb 08, 2008 at 09:07:21PM +0100, Sebastien Chassot wrote:
> Hi,
> 
> I can't find how list who's a file encrypted for ? I've encrypt several
> files with different recipients, but I don't remember which.
> 
> In general how can I make difference between file encrypted for one
> user, several user ? symmetric encrypted, asymmetric ?

Just run 'gpg' on the file, and don't give a passphrase.  It prints
all the possible recipients.

David


From jeandavid8 at verizon.net  Sat Feb  9 18:54:44 2008
From: jeandavid8 at verizon.net (Jean-David Beyer)
Date: Sat, 09 Feb 2008 12:54:44 -0500
Subject: How true can this be?
In-Reply-To: <20080128115827.GB9019@hell.pl>
References: <15112665.post@talk.nabble.com> <20080127183904.GA9019@hell.pl>
	<479CF63A.9050402@bellsouth.net> <20080128115827.GB9019@hell.pl>
Message-ID: <47ADE8E4.70603@verizon.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Janusz A. Urbanowicz wrote:
> On Sun, Jan 27, 2008 at 04:23:06PM -0500, John W. Moore III wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> - -------- Original Message  --------
>> Subject: Re: How true can this be?
>> From: Janusz A. Urbanowicz <alex at bofh.net.pl>
>> To: Raygene <netanswers at gmail.com>
>> Cc: gnupg-users at gnupg.org
>> Date: Sunday, January 27, 2008 1:39:04 PM
>>
>>
>>> if a), then b) would land him in jail, quickly
>> More likely a fatal traffic accident or victim of a street mugging with
>> similar outcome.  People communicate in and from Jails.
> 
> Blabbering about classified stuff is a breach of security procedures and
> NDA-s, that leads to administrative action, prosecution and usually jail
> sentence (or a hefty fine).

Long ago I had a secret security clearance. The secrets were laughable, but
I have never disclosed them. Mine had nothing to do with encryption.

When getting the clearance, I had to read some of the laws that pertained.
In addition to jail and fines, another punishment option was death. But I
imagine it would be done officially.
> 
> The approach you mention would be probably used on someone who would like to
> play the game (as in sell the info to another country), not for some random
> blabberer.
> 
> Alex


- --
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 12:50:01 up 16 days, 2:36, 2 users, load average: 5.02, 5.03, 4.68
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFHrejkPtu2XpovyZoRAgC9AJ9DknvNBSUr0NU7jxdHUr3PGWHKYACgg2Lo
eVMtegDw54+UQDnlz+fGK+8=
=YzkQ
-----END PGP SIGNATURE-----


From kfitzner at excelcia.org  Sun Feb 10 00:45:22 2008
From: kfitzner at excelcia.org (Kurt Fitzner)
Date: Sat, 09 Feb 2008 15:45:22 -0800
Subject: GPGee development restarted - need bugs
Message-ID: <47AE3B12.9060301@excelcia.org>

After almost two years of neglect, I've got time enough to start working 
on GPGee again.  I was informed some time ago that work is underway to 
replace it.  I don't see a replacement yet, so I'm going to put out a 
release that fixes some bugs and incorporates a French translation I was 
given.  This can act as a stop-gap until the replacement is completed. 
If the replacement is going to be some time yet, I'll also entertain 
requests for new features.

Bugs I've fixed so far include:
- Disappearing keys (requires GnuPG >= 1.4 to fix)
- Verifications of signatures made with expired subkeys not showing the 
correct expiry date of the subkey and giving incorrect warnings of 
signatures being made after the key expired
- Password requests not showing correct data (type & size) for the 
subkey identified
- SHA224 signatures not being correctly identified

If you are still using GPGee (or want to) and have experienced bugs not 
mentioned above, please respond here, on a thread I've made in the GPGee 
forums 
(http://www.excelcia.org/modules.php?name=Forums&file=viewforum&f=1), or 
by personal e-mail to me.

I apologize for any previous e-mails that haven't been replied to.

Regards,

     Kurt Fitzner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20080209/3dcf2c18/attachment.pgp>

From kevhilton at gmail.com  Sun Feb 10 06:29:08 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Sat, 9 Feb 2008 23:29:08 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <47A7F022.5030807@sixdemonbag.org>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>
	<47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
	<96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>
	<47A7F022.5030807@sixdemonbag.org>
Message-ID: <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com>

>Twofish is almost entirely abandoned nowadays, but it still exists in
>PGP and GnuPG.  Once a bad decision is made in engineering, the
>engineers are stuck supporting it forever.

Is this statement really true or just opinion?  Bruce Schneier is one
of my favorite cryptoanalysts.


From rjh at sixdemonbag.org  Sun Feb 10 08:35:46 2008
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 10 Feb 2008 01:35:46 -0600
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com>
References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com>	<47A6B9C2.2000905@sixdemonbag.org>	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>	<47A6C33E.9010300@sixdemonbag.org>	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>	<47A7601E.8000107@sixdemonbag.org>	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>	<96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>	<47A7F022.5030807@sixdemonbag.org>
	<96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com>
Message-ID: <47AEA952.2070206@sixdemonbag.org>

Kevin Hilton wrote:
> Is this statement really true or just opinion?  Bruce Schneier is one
> of my favorite cryptoanalysts.

Bruce recommends against using Twofish for crypto applications.

He has never backed off from either of two claims:

	1.  Twofish is a secure cipher that would have made an
	    excellent AES.
	2.  People should use AES for symmetric crypto needs.

He has said #1 many times and keeps a page on his site devoted to the
most recent research into Twofish.  He has said #2 many times,
particularly in his book _Practical Cryptography_.



From dshaw at jabberwocky.com  Sun Feb 10 15:32:27 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 09:32:27 -0500
Subject: Can you clarify when data compression is used?
In-Reply-To: <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com>
References: <47A6B9C2.2000905@sixdemonbag.org>
	<96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com>
	<96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com>
	<47A6C33E.9010300@sixdemonbag.org>
	<96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com>
	<47A7601E.8000107@sixdemonbag.org>
	<96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com>
	<96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com>
	<47A7F022.5030807@sixdemonbag.org>
	<96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com>
Message-ID: <20080210143227.GA11807@jabberwocky.com>

On Sat, Feb 09, 2008 at 11:29:08PM -0600, Kevin Hilton wrote:
> >Twofish is almost entirely abandoned nowadays, but it still exists in
> >PGP and GnuPG.  Once a bad decision is made in engineering, the
> >engineers are stuck supporting it forever.
> 
> Is this statement really true or just opinion?  Bruce Schneier is one
> of my favorite cryptoanalysts.

It's basically true, at least in the context of OpenPGP.  Note that
the statement doesn't say that Twofish is insecure.  It's just that
when AES came along, it eclipsed many/most of the ciphers with similar
capabilities.

>From the perspective of the researcher who wants to attack a cipher,
they'll attack AES because lots of people use it.  From the
perspective of the user of crypto, they'll use AES because of all the
research on it.  Repeat this cycle enough times, and you can see why
Twofish isn't used much.

David


From program.spe at home.pl  Tue Feb  5 19:10:35 2008
From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=)
Date: Tue, 05 Feb 2008 19:10:35 +0100
Subject: Safe decryption with GnuPG?
In-Reply-To: <47A89E86.9010800@sixdemonbag.org>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
	<47A89E86.9010800@sixdemonbag.org>
Message-ID: <1202235036.6608.29.camel@a1dmin.vola.spe.com.pl>


Dnia 05-02-2008, Wt o godzinie 11:36 -0600, Robert J. Hansen pisze:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Krzysztof ?elechowski wrote:
> > The decrypted information must not make it to any persistent medium 
> 
> GnuPG is almost certainly the wrong tool for your job.  GnuPG has little
> control over low-level operating systems details like swap files.  It is
> possible for cleartext to be stored in some manner.

GnuPG claims it locks memory pages so that they are never dumped.

> 
> > (I understand gpg '-d' already guarantees it 
> > as long as it manages the decrypted text,
> >  but what happens after it leaves gpg?)
> 
> [many other requirements snipped]
> 
> Many of your requirements belong in the application stack alongside or
> above GnuPG, but are pretty much unrelated to GnuPG.  After it leaves
> GnuPG it's no longer GnuPG's problem.  

I just thought the answer would be quick, straightforward and positive, 
and that there should exist such highly confidential software 
on top of GnuPG.  
Since nothing of this sort was mention on the Web page, I dared ask.

> Many of your requirements are
> also impossible to meet.  I don't mean "impossible" as in "it would
> require a lot of engineering", I mean "impossible" as in "it's like
> violating the Second Law of Thermodynamics".

Well, it seems it is impossible to prohibit taking a screen shot;
hopefully a user mode application 
cannot do this without a kernel driver.

> 
> > Can you direct me to some implementation meeting these requirements?
> 
> There exists no such implementation.

Thanks a lot, mine is going to be the first :-) 
(although I am quite surprised
because the requirements are quite obvious to me; 
for what is the benefit of encryption 
when a bad robot can read over your shoulder?)

For the time being, I am inclined to implement the following scheme:
1. Open a new console session.
2. Run gpg '-d' | fgrep
3. Read the result.
4. Close the session.

This obviously does not meet the requirements 
because the text mode console driver 
stores the content of the console in a character buffer 
and does not do all the funny things with scrambling and all.
The mitigating factor is, as always, that the session is short-lived.

Chris



From program.spe at home.pl  Wed Feb  6 09:14:58 2008
From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=)
Date: Wed, 06 Feb 2008 09:14:58 +0100
Subject: Safe decryption with GnuPG?
In-Reply-To: <200802060222.10599.pg@futureware.at>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
	<200802060222.10599.pg@futureware.at>
Message-ID: <1202285698.6645.17.camel@a1dmin.vola.spe.com.pl>

Thanks a lot for the keywords, the hints and the missing parts.  

Indeed, I hoped that such an application 
did not need a custom implementation 
because IMHO encrypting information is useless 
if you cannot view the information 
without exposure to eavesdropping or tracing.
I have to review what is available and what is needed 
before I can come up with a budget.

Specific comments below.
Thx, Chris


Dnia 06-02-2008, ?r o godzinie 02:22 +0100, Philipp G?hring pisze:
> Hi,
> 
> > 1.
> > The decrypted information must not make it to any persistent medium
> > (I understand gpg '-d' already guarantees it
> > as long as it manages the decrypted text,
> >  but what happens after it leaves gpg?)
> 
> Use a full-disc encryption system for all your persistent media.

That is overkill if it only can be avoided.

> 
> > 2.
> > The decrypted text must not be stored in volatile memory
> > any longer than it is needed.
> 
> You can use TaintedBochs or TaintedQemu to investigate that.
> 
> > In particular, it should be converted to a human-viewable bitmap
> > and the computer-readable representation must be immediately erased.
> 
> Doesn?t help much to try that, I would say. But feel free to try ...
> 
> > 3. Only the information I need should be displayed.
> 
> You need a Do-What-I-Mean system for that.

In this particular case, Do-What-I-Mean 
means displaying only matching information ? la fgrep.  
The keywords are not secret.

> > 7.
> > If more information is requested,
> > it should be displayed in small chunks.
> > The program should be fully unaware
> > of the content of the chunks that are not being displayed.
> 
> > (That probably means a garbage-collected language cannot be used).
> 
> I don?t understand why you need that. 
> I would suggest that you seperate the small chunks into seperated encrypted 
> files, to ensure that the reader only gets those chunks that you actually 
> decrypted.

I shall consider that but I do not like this idea at the first glance; 
I am afraid there would be some maintenance overhead.

> 
> > 8.
> > The application should be as lightweight as possible
> > (for source code audit).
> 
> Agreed.
> 
> > Can you direct me to some implementation meeting these requirements?
> 
> I think your specification isn?t complete yet. You forgot about half of the 
> requirements.
> 
> I guess that:
> 
> * You want a machine that seperates code from data (to be secure against  
> trojans, virii and other malware)
> 
> * You want secure documents, that can?t change dynamically, or otherwise 
> contain invisible contents

I thought GnuPG-encrypted files are immutable, aren't they?

> 
> * You want a secure path to the user
> 
> (and some more requirements that I forgot at the moment)
> 
> What?s your budget for this small project?
> 
> Best regards,
> Philipp G?hring
> 



From program.spe at home.pl  Wed Feb  6 16:48:17 2008
From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=)
Date: Wed, 06 Feb 2008 16:48:17 +0100
Subject: Safe decryption with GnuPG?
In-Reply-To: <alpine.OSX.1.00.0802060935040.253@fchq.ybpny>
References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl>
	<200802060222.10599.pg@futureware.at>
	<alpine.OSX.1.00.0802060935040.253@fchq.ybpny>
Message-ID: <1202312897.6645.46.camel@a1dmin.vola.spe.com.pl>


Dnia 06-02-2008, ?r o godzinie 10:03 -0500, Steve Revilak pisze:
> > I have a file that I encrypted for myself 
> > and I want to read some information from it. 
> > The file is a text file and I need to read several lines of it.
> > 
> > The following requirements must be met:
> 
> I was going to suggest
> 
>    gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null
> 
> but I'll try to be more serious. :)

Yep, that is my current workaround, sort of, 
in a dedicated xterm.

> 
> Out of curiosity, what kind of a threat vector are you anticipating?
> By reading your list of requirements, the ones I've extracted are
> 
>   * Access to sensitive data via system memory is a threat.
> 
>   * Access to sensitive data via the file system (i.e. by examining
>     swap space) is a threat.
> 
>   * Access to sensitive data via the graphics system framebuffer is a
>     threat.
> 
>   * Access to sensitive data via visual observation (someone sees the
>     text on the screen, or takes a picture of the text on the screen)
>     is a threat.
> 

That is basically what I had in mind.

> As someone else mentioned, this brings up a lot of issues in the area
> of trusting the hardware, trusting the operating system and so fourth.
> Granted, they are interesting issues, but my gut instinct tells me
> that this problem might be easier to solve with physical security.

That requires a specialised hardware device; 
I am more interested in a software solution for the time being 
because I think it is more convenient and versatile.

Of course, 
if I would have to guard something really dangerous, 
like ICBM launcher codes, 
I would choose a hardware solution 
(and I would not ask the members of this mailing list).

> 
> For example, the first three threats imply that the data has to leave
> the system where it is being viewed.  Removing network access to that
> system (unplug the ethernet cable, remove any wireless/bluetooth
> hardware), would mitigate those threats, no?

Certainly, but it is not always possible temporarily, 
and it is almost always impossible once and for all.
And unplugging everything for a short time does not really help.

> 
> As for threat #4, if you're viewing the data in a small, bare-walled,
> locked room, you'd be able to tell (a) whether someone else was in the
> room looking over your shoulder or (b) whether there was a camera
> being pointed at your screen.

I did not intend to address this problem at all.

> 
> And if you don't trust the isolated computer in the small locked room,
> you could even go as far as removing its hard drive -- you'd walk in
> with a bootable CD that contained your encrypted file, boot up, read
> what you needed, then halt.

Good point, it can even be a Free DOS floppy disk 
with a RAM disk driver.  
I have not thought of that.

Thanks,
Chris



From texaskilt at yahoo.com  Wed Feb  6 20:35:14 2008
From: texaskilt at yahoo.com (Texaskilt)
Date: Wed, 6 Feb 2008 11:35:14 -0800 (PST)
Subject: Corporate use of gnupg
Message-ID: <15312177.post@talk.nabble.com>


Apologies if this has already been asked.  Honestly, I did my homework and
looked in the archives!

I am wanting to setup up users to use GnuPG for encrypting email, mainly for
internal e-mail.

Unfortunately, the "powers-that-be" want everyone that encrypts an email to
also encrypt it to the "corporate secret key".  Their reasoning is that if a
person leaves, they want to have access to the old emails in case there is a
"business critical" email in there.

Is there a way to "force" users to encrypt to a corporate key, in addition
to the receipient's key?

Thanks,

TK
-- 
View this message in context: http://www.nabble.com/Corporate-use-of-gnupg-tp15312177p15312177.html
Sent from the GnuPG - User mailing list archive at Nabble.com.



From Juha.Tuomala at iki.fi  Thu Feb  7 17:36:55 2008
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Thu, 7 Feb 2008 18:36:55 +0200
Subject: Kmail/gnupg fails to encrypt on F8
Message-ID: <200802071836.55497.Juha.Tuomala@iki.fi>



Any glues which might cause this?

  https://bugzilla.redhat.com/show_bug.cgi?id=427500


Br,

Tuju


PS: I'm not subscribing the list.
-- 
Varo hattup?isi? autoilijoita.


From dshaw at jabberwocky.com  Sun Feb 10 20:57:26 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 14:57:26 -0500
Subject: Corporate use of gnupg
In-Reply-To: <15312177.post@talk.nabble.com>
References: <15312177.post@talk.nabble.com>
Message-ID: <20080210195726.GC12706@jabberwocky.com>

On Wed, Feb 06, 2008 at 11:35:14AM -0800, Texaskilt wrote:
> 
> Apologies if this has already been asked.  Honestly, I did my homework and
> looked in the archives!
> 
> I am wanting to setup up users to use GnuPG for encrypting email, mainly for
> internal e-mail.
> 
> Unfortunately, the "powers-that-be" want everyone that encrypts an email to
> also encrypt it to the "corporate secret key".  Their reasoning is that if a
> person leaves, they want to have access to the old emails in case there is a
> "business critical" email in there.

This is essentially the rationale behind the "ADK" (additional
decryption key) feature of PGP.

> Is there a way to "force" users to encrypt to a corporate key, in addition
> to the receipient's key?

It depends on how strong the term "force" is.  Even in PGP, the ADK
system can be circumvented if the person tries hard enough.

If you trust your employees to not hack you, then you can just stick a
"encrypt-to (the keyid)" in everyone's gpg.conf file and give everyone
a copy of the corporate public key.

Note that this isn't safe because of the crypto math.  It's "safe"
because you can fire people that don't do it ;)

David


From Lance at TheHaverkamps.net  Sun Feb 10 21:47:38 2008
From: Lance at TheHaverkamps.net (Lance W. Haverkamp)
Date: Sun, 10 Feb 2008 20:47:38 +0000
Subject: Signing Multiple Files
Message-ID: <47AF62EA.1080503@TheHaverkamps.net>

Having looked through much documentation & some trial and error; it 
seems there is no way to sign (detached) multiple files.  I need to sign 
dozens (or hundreds) of photos at a time.  I am *not* a programmer.

I did coble together a (Linux) script:

#!/bin/bash
for i in $( ls ); do
gpg -b $i
done


There must be a better way, but this will sign everything in a folder. 
I don't code enough to be able to tell the file browser to sign multiple 
selected files recursively.

Am I missing something obvious here?
-- 


Thanks!

Lance W. Haverkamp
Lance at TheHaverkamps.net
Contact & encryption info:
http://thehaverkamps.net/?Lance:Contact_Me
<>< <>< <><




***
This email has been stamped using Penny Post. Stamping email helps 
combat spam.
Find out more about stamping your email at: http://pennypost.sourceforge.net


From kevhilton at gmail.com  Sun Feb 10 23:47:37 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Sun, 10 Feb 2008 16:47:37 -0600
Subject: Are DSA2 signing keys backwards compatible?
Message-ID: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>

Are DSA2 signing keys (or simply DSA keys that are larger than 1024
bits) backwards compatible with older GnuPG versions prior to 1.48?

-- 
Kevin Hilton


From JPClizbe at tx.rr.com  Mon Feb 11 01:15:42 2008
From: JPClizbe at tx.rr.com (John Clizbe)
Date: Sun, 10 Feb 2008 18:15:42 -0600
Subject: Signing Multiple Files
In-Reply-To: <47AF62EA.1080503@TheHaverkamps.net>
References: <47AF62EA.1080503@TheHaverkamps.net>
Message-ID: <47AF93AE.5060608@tx.rr.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lance W. Haverkamp wrote:
> Having looked through much documentation & some trial and error; it 
> seems there is no way to sign (detached) multiple files.  I need to sign 
> dozens (or hundreds) of photos at a time.  I am *not* a programmer.
> 
> I did coble together a (Linux) script:
> 
> #!/bin/bash
> for i in $( ls ); do
> gpg -b $i
> done
> 
> 
> There must be a better way, but this will sign everything in a folder. 
> I don't code enough to be able to tell the file browser to sign multiple 
> selected files recursively.
> 
> Am I missing something obvious here?

That will sign everything in a given directory, but won't recurse.
'ls -R' will recurse, but won't give you filenames in a usable format to pass
It will also attempt to sign everything in addition to the images

find . -name "*.jpeg" -print

is probably more along the lines of what you're looking for instead of ls above

for i in $(find . -name "*.jpeg" -print \;)
do
  gpg -b $i -o ${i}.sig
done

You may wish to use one of the --passphrase options,eg
'--passphrase-file <file>' or '--passphrase <string>', or temporarily remove the
passphrase from the signing key to spare yourself the 'joy' of typing the
passphrase potentially 100s of times.

Some reason you moved the thread to GnuPG-Users from PGP-Basics?

- --
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?"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (WinXP Pent3)
Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG
Comment: Be part of the ?33t ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkevk6cACgkQvh+YERi7NzrAJwP+L9RfQp371S7a+0bfRECYclf0
5cZKVcK2GlYrLbKTooAFMEnA4hAy8tFYnASQiOgIG/b3a3N2dp71zjrwhbOWq30I
uECx85/KN79ibeDbkbeF3c2M36c2XX3vT12v2zqh+o6NKbFZoEd3RYG+GqC7keXd
VhMuTUod8sESX8Tr/K2IRgQBEQIABgUCR6+TpwAKCRAdBKxKYI0qEBlDAJkBoh4g
yXxfxg59pPg9Owmu+MOWLACgzLyPuL8wjpZr7tpDt8MIXpRH//g=
=6N+0
-----END PGP SIGNATURE-----


From dshaw at jabberwocky.com  Mon Feb 11 02:15:49 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 20:15:49 -0500
Subject: Are DSA2 signing keys backwards compatible?
In-Reply-To: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
Message-ID: <20080211011549.GD12706@jabberwocky.com>

On Sun, Feb 10, 2008 at 04:47:37PM -0600, Kevin Hilton wrote:
> Are DSA2 signing keys (or simply DSA keys that are larger than 1024
> bits) backwards compatible with older GnuPG versions prior to 1.48?

Basically, no.  It's the main reason why --enable-dsa2 is off by
default.

David


From kevhilton at gmail.com  Mon Feb 11 03:30:24 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Sun, 10 Feb 2008 20:30:24 -0600
Subject: Are DSA2 signing keys backwards compatible?
In-Reply-To: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
Message-ID: <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>

Just to clarify for some other users,

What version of GnuPG were the DSA2 keys (or longer DSA signing keys)
and the additional SHA hashes introduced?

A little of topic, but I'm predicting a future foreseeable bump in the
road when the Secure Hash Standard is named in 2011 (or whenever the
recent NIST hash analysis is concluded).  I guess however the
personal-hash-preferences would bypass this problem and default to
SHA1 if a new hash (or series of new hashes) is introduced.
Hopefully md5 support is abandoned, however I guess for historical
purposes this would be unlikely to happen.

Even more challenging will be when longer DSA keys become the de-facto
standard.  I would guess there is not any similar workaround.  I guess
users of older GnuPG versions would simply have to upgrade.


From kevhilton at gmail.com  Mon Feb 11 03:48:13 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Sun, 10 Feb 2008 20:48:13 -0600
Subject: Authenticate capability of DSA or RSA signing keys
Message-ID: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com>

When I perform a

gpg --expert --gen-key

Im given the following options:

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (3) DSA (set your own capabilities)
   (5) RSA (sign only)
   (7) RSA (set your own capabilities)
Your selection?

If I select either 3 or 7, Im given the choice similar to below (note
the following was produced with option #3):
Possible actions for a DSA key: Sign Certify Authenticate
Current allowed actions: Sign Certify

   (S) Toggle the sign capability
   (A) Toggle the authenticate capability
   (Q) Finished

I believe I'm aware of the signing capabilities, but how does Certify
differ from Authenticate?  Obviously I'm confused on the meaning of
Certify vs Authenticate.  I thought the public DSA signing key did
certification/authentication whereas the private DSA key performed the
signing.

Thanks for any explanation!

-- 
Kevin Hilton


From dshaw at jabberwocky.com  Mon Feb 11 04:01:42 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 22:01:42 -0500
Subject: Are DSA2 signing keys backwards compatible?
In-Reply-To: <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>
References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
	<96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>
Message-ID: <20080211030142.GE12706@jabberwocky.com>

On Sun, Feb 10, 2008 at 08:30:24PM -0600, Kevin Hilton wrote:
> Just to clarify for some other users,
> 
> What version of GnuPG were the DSA2 keys (or longer DSA signing keys)
> and the additional SHA hashes introduced?

They were not introduced at the same time.  As you said in your
earlier mail, DSA2 was introduced in 1.4.8.  The new SHA hashes were
introduced in the 1.3.x development series.  All 1.4 and later GPGs
(including the 2.x series) have them.

> A little of topic, but I'm predicting a future foreseeable bump in the
> road when the Secure Hash Standard is named in 2011 (or whenever the
> recent NIST hash analysis is concluded).  I guess however the
> personal-hash-preferences would bypass this problem and default to
> SHA1 if a new hash (or series of new hashes) is introduced.

It doesn't work that way.  SHA-1 doesn't even work with DSA2 keys.
DSA2 doesn't mean "a bigger DSA key".  It means "a bigger hash with a
bigger DSA key".  DSA2 allows for any hash size that is equal to or
greater than the hash size that was used when generating the key.
Thus, for example, it is legal (albeit silly) to use SHA-512 with a
old DSA key (which uses a 160-bit hash).  We just truncate to fit.

There is no special magic with the new hashes - once they exist, we'll
use them.

> Hopefully md5 support is abandoned, however I guess for historical
> purposes this would be unlikely to happen.

Have you tried using MD5 recently?

> Even more challenging will be when longer DSA keys become the de-facto
> standard.  I would guess there is not any similar workaround.  I guess
> users of older GnuPG versions would simply have to upgrade.

This is not how it works.  There is nothing becoming de-facto here.
Longer DSA keys are the de-jure standard today, and people are just
going to have to upgrade.

David


From dshaw at jabberwocky.com  Mon Feb 11 04:08:46 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 22:08:46 -0500
Subject: Authenticate capability of DSA or RSA signing keys
In-Reply-To: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com>
References: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com>
Message-ID: <20080211030846.GF12706@jabberwocky.com>

On Sun, Feb 10, 2008 at 08:48:13PM -0600, Kevin Hilton wrote:
> When I perform a
> 
> gpg --expert --gen-key
> 
> Im given the following options:
> 
> Please select what kind of key you want:
>    (1) DSA and Elgamal (default)
>    (2) DSA (sign only)
>    (3) DSA (set your own capabilities)
>    (5) RSA (sign only)
>    (7) RSA (set your own capabilities)
> Your selection?
> 
> If I select either 3 or 7, Im given the choice similar to below (note
> the following was produced with option #3):
> Possible actions for a DSA key: Sign Certify Authenticate
> Current allowed actions: Sign Certify
> 
>    (S) Toggle the sign capability
>    (A) Toggle the authenticate capability
>    (Q) Finished
> 
> I believe I'm aware of the signing capabilities, but how does Certify
> differ from Authenticate?  Obviously I'm confused on the meaning of
> Certify vs Authenticate.  I thought the public DSA signing key did
> certification/authentication whereas the private DSA key performed the
> signing.

The public/private question is not relevant here.

Sign = sign some data
Certify = sign a key
Authenticate = prove you are you

Authenticate is used for things like using an OpenPGP key for ssh.

David


From dshaw at jabberwocky.com  Mon Feb 11 04:10:59 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 22:10:59 -0500
Subject: Are DSA2 signing keys backwards compatible?
In-Reply-To: <20080211030142.GE12706@jabberwocky.com>
References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
	<96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>
	<20080211030142.GE12706@jabberwocky.com>
Message-ID: <20080211031058.GG12706@jabberwocky.com>

On Sun, Feb 10, 2008 at 10:01:42PM -0500, David Shaw wrote:
> On Sun, Feb 10, 2008 at 08:30:24PM -0600, Kevin Hilton wrote:
> > Just to clarify for some other users,
> > 
> > What version of GnuPG were the DSA2 keys (or longer DSA signing keys)
> > and the additional SHA hashes introduced?
> 
> They were not introduced at the same time.  As you said in your
> earlier mail, DSA2 was introduced in 1.4.8.  The new SHA hashes were
> introduced in the 1.3.x development series.  All 1.4 and later GPGs
> (including the 2.x series) have them.

I should clarify this.  DSA2 was enabled as part of standard OpenPGP
in 1.4.8.  We knew it was coming, though, so it exists as far back as
1.4.4 (June 2006).

David


From kevhilton at gmail.com  Mon Feb 11 05:13:11 2008
From: kevhilton at gmail.com (Kevin Hilton)
Date: Sun, 10 Feb 2008 22:13:11 -0600
Subject: Are DSA2 signing keys backwards compatible?
In-Reply-To: <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>
References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
	<96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>
Message-ID: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com>

>It doesn't work that way.  SHA-1 doesn't even work with DSA2 keys.
>DSA2 doesn't mean "a bigger DSA key".  It means "a bigger hash with a
>bigger DSA key".  DSA2 allows for any hash size that is equal to or
>greater than the hash size that was used when generating the key.
>Thus, for example, it is legal (albeit silly) to use SHA-512 with a
>old DSA key (which uses a 160-bit hash).  We just truncate to fit.

So just to clarify --
A 3096 bit DSA signing key could only be used with the SHA-512 hash?

Thanks for the explanation!


From dshaw at jabberwocky.com  Mon Feb 11 05:33:59 2008
From: dshaw at jabberwocky.com (David Shaw)
Date: Sun, 10 Feb 2008 23:33:59 -0500
Subject: Are DSA2 signing keys backwards compatible?
In-Reply-To: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com>
References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com>
	<96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com>
	<96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com>
Message-ID: <20080211043359