Re: message digest for signed emails

[Werner Koch]

On Wed, 11 Sep 2013 11:27, s-...@gmx.net said:

> IMHO mutt is just using gpg's CLI to sign the message. 

Depends on whether you use 

  set crypt_use_gpgme


Salam-Shalom,

   Werner

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


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

Re: Confirmation of cipher?

[Werner Koch]

On Wed, 11 Sep 2013 22:46, j...@jack-brennan.com said:

> When one signs a message GnuGPG will add "Hash:SHA1" or your preferred
> hash at the start of the message.

Only if you use --clearsign. This is here required so that we can
implement one pass verification.  We need to know in advance which hash
algorithm is used.  Thus this header line.  Now when it comes to the
signature block, the same information is there and gpg cross-checks that
they match (it is a bit more complicated in reality, though).

> However a similar line of text isn't available with an encrypted text
> block. Is the reason for this to hide as much

We sign and the encrypt.  Thus the hashing algorithm for the signature
is only available after decryption.

> Is there any way to confidently identify the encryption algorithm used
> with a GPG encrypted text block?

Yes.  For a quick inspection use --verbose (or -v):

  $ fortune | gpg2 -er alpha --always-trust 2>/dev/null| gpg2 -v
[...]
  gpg: encrypted with 1024-bit ELG key, ID DB2405A5, created 1998-09-30
"Heinrich Heine (alpha test key)"
  gpg: using subkey C193565B instead of primary key 1E42B367
  gpg: encrypted with 2048-bit RSA key, ID C193565B, created 2011-11-07
"Werner Koch "
  gpg: 3DES encrypted data
  gpg: original file name=''
  He was part of my dream, of course -- but then I was part of his dream too.
  -- Lewis Carroll

For scripting etc use --status-fd:

  $ fortune | gpg2 -er alpha --always-trust 2>/dev/null| gpg2 --status-fd 2 
[...]
  [GNUPG:] ENC_TO F7849FD4DB2405A5 16 0
  [GNUPG:] ENC_TO DF7B7722C193565B 1 0
  gpg: encrypted with 1024-bit ELG key, ID DB2405A5, created 1998-09-30
"Heinrich Heine (alpha test key)"
  [GNUPG:] NO_SECKEY F7849FD4DB2405A5
  gpg: encrypted with 2048-bit RSA key, ID C193565B, created 2011-11-07
"Werner Koch "
  [GNUPG:] BEGIN_DECRYPTION
  [GNUPG:] DECRYPTION_INFO 0 2
  [GNUPG:] PLAINTEXT 62 1378982325 
  [GNUPG:] PLAINTEXT_LENGTH 96
  Q:  What's the difference between a duck and an elephant?
  A:  You can't get down off an elephant.
  [GNUPG:] DECRYPTION_OKAY
  gpg: WARNING: message was not integrity protected
  [GNUPG:] END_DECRYPTION

Here the status line

  [GNUPG:] DECRYPTION_INFO 0 2

returns the info about the used symmetric algorithm:

  DECRYPTION_INFO  
Print information about the symmetric encryption algorithm and the
MDC method.  This will be emitted even if the decryption fails.

Thus is our case we don't use an MDC (this is becuase the alpha test key
is very old and does not have a preference for this.  The symmetric
encryption algorithnm is 2 which is the OpenPGP id for TripeDES.

Note, that GPGME has currently no way to return that info.


Shalom-Salam,

   Werner

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


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

Re: Decrypt Issue

[Paul R. Ramer]

On 09/10/2013 06:41 AM, Diaz, John, A wrote:
> Spoke too soon.  The wrong path was part of the problem, but I’m still having 
> the issue:
> 
> 
> Mainframe calls .bat file that calls C# application that calls second .bat 
> file to call GnuPG to decrypt a file. Once decrypted, other stuff happens, 
> e-mails are sent, blah, blah, blah.
> 
> Here's the issue: When the mainframe calls the .bat file to start the 
> process, the decryption returns:
> Decrypt error :gpg: armor header: Version: GnuPG v1.4.9 (AIX)
> gpg: public key is 07F7097A
> gpg: encrypted with ELG-E key, ID 07F7097A
> gpg: decryption failed: secret key not available
[snip]

You need to determine which user account and system that you are running
the script from and which account and system that gpg is running under.
 It is mostly likely gpg is running under the wrong user or system.
Determine where the secret key that you are using is located (i.e. which
directory holds the GnuPG home directory). And If you can edit the
script, make it print out the value of the GNUPGHOME environment
variable and compare that against what the correct home directory is
supposed to be.

Hope that helps.

Cheers,

--Paul  


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

Re: Is it possible to remove capabilities from an existing key?

[Philip Jägenstedt]

On Thu, Sep 12, 2013 at 12:16 AM, Hauke Laging
 wrote:
> Am Mi 11.09.2013, 23:42:30 schrieb Philip Jägenstedt:
>> My public key has the default capabilities sign and certify. I've seen
>> that some people have only the certify capability in order to be able to
>> keep the main key offline most of the time.
>
> It's of limited use to make a former online mainkey an offline mainkey. You
> should create a completely new key (on a secure system).

Certainly, I can't take the master key offline and then pretend it has
never seen a computer with a network connection. I could have used
other terminology, what I'm actually considering is how to remove the
private master key from my laptop, so that if it's lost/stolen I only
need to revoke the subkeys.

>> Is it technically possible to change the capabilities of an existing
>> key, even if there's no way to do it via --edit-key?
>
> May be possible (it surely would be with patching GnuPG) but is not necessary.
> It makes perfect sense to have signing (and even encryption) capability on an
> offline mainkey.
>
>> If it's not possible, what would be the consequence of adding a subkey
>> with the sign capability, which key would be used when both are
>> available?
>
> If there is a subkey then it is used always. I do not know though whether this
> is a direct effect (defined that way) or an indirect one: The creation date
> (and the selfsig date) of a subkey should always be after the creation date of
> the mainkey.

On Thu, Sep 12, 2013 at 12:07 AM, Daniel Kahn Gillmor
 wrote:
>
> i believe GnuPG uses the most-recently-updated subkey that it believes
> to have signing capability, unless you force the subkey in question via
> --local-user or --default-key with a ! suffix (see the "By key Id."
> section in gpg(1)).

You're both right, I've tested simply adding a subkey with the sign
capability, and that's the one that gpg used, even with the master key
available. In other words, it's perfectly possible to do what I wanted
without modifying the existing keys.

-- 
Philip Jägenstedt

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

Re: Is it possible to remove capabilities from an existing key?

[Hauke Laging]

Am Do 12.09.2013, 14:53:29 schrieb Philip Jägenstedt:

> what I'm actually considering is how to remove the
> private master key from my laptop, so that if it's lost/stolen I only
> need to revoke the subkeys.

gpg --armor --export-secret-keys "$mykeyid" > key.secret-mainkey.asc
gpg --armor --export-secret-subkeys "$mykeyid" > key.secret-subkeys.asc
gpg --delete-secret-key "$mykeyid"
gpg --import key.secret-subkeys.asc


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


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

Re: Why trust gpg4win?

[Jan]

Hello everybody,

thank you for the many answers. Actually this thread should have been called 
"Save use of gnuPG for everybody". From what I've learned here so far I come 
to the following conclusions:


1. It should be to hard for the average user to configure windows such that 
it is a secure system. Hence a linux/unix distribution which is trustworthy, 
easy to use and very secure is needed. To me debian seems like a good choice 
because it seems to be watched by many people and runs on almost any PC.


2.1 Most people have only one PC and windows as operating system, so the 
linux/unix distribution should be installed on an USB device. This device 
must not be plugged into the PC if windows is running, in order to avoid a 
manipulation. Further I would uninstall the network drivers on the USB 
device, so it is almost an offline PC. If the user receives an encrypted 
file via email, he saves it to hard disk. Then he turns off the PC, plugs in 
the USB drive and boots off it. He copies the file from the hard disk to the 
USB drive (this should cause no trouble). Only if the file is of a simple 
file format (jpg, RTF, mp3, PDF(?), etc.(?)) he accepts it and opens it with 
a secure minimalistic tool. He might even first run a program like an anti 
virus software(?) in order to check whether the structure of the file agrees 
with the official definition of the sated file format.


2.2 If the user has two PCs, he might install the linux/unix distribution on 
his offline PC. Files would be transferred between the two PCs by means of 
CD-RWs(?), not by means of insecure USB devices. Auto-Play for CDs would be 
disabled.


Do you see any reasonable attack vectors? What do you think?

Kind regards,
Jan

- Original Message - 
From: "NdK" 

To: 
Sent: Thursday, September 12, 2013 8:43 AM
Subject: Re: Why trust gpg4win?



Il 11/09/2013 11:48, Pete Stephenson ha scritto:


Actually, I was thinking of something that was the exact opposite:
some device (which I don't think exists) that would allow one to
connect a USB flash drive to the device, and have the device convert
that into RS232 serial data for the computer, thus avoiding any USB
interaction with the computer itself. The computer would then need to
process the serial data to read or write files on the drive. As far as
I know, nothing like that exists and I'm not sure if it'd be possible
to do. Even if it was possible, it'd be immensely slower than normal
USB connections.

Actually such a module exists, and is used to add flash disk access to
small microcontrollers: it's VDrive2 (VNC1L module) by Vinculum
http://www.ftdichip.com/Documents/DataSheets/Modules/DS_VDRIVE2.pdf

I don't think it adds anything to security, but at least it's doable :)

If you are *so* concerned about key security, it's better to use an HSM.

BYtE,
Diego.

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



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

OpenPGP presence on the web

[Hauke Laging]

Hello,

I'd like to motivate you to do something (at least passively) I have started 
doing:

There are some (both private and commercial) web sites which have a statement 
and link like this on their contact page: "And here you can download my PGP 
key."

Most of them (at least of the German ones) do not contain any information 
about OpenPGP though. Neither as text nor as links. This doesn't make sense.

Thus I have started searching such pages and asking their webmasters (who are 
usually interested in more people using OpenPGP) to add links to both 
informative sites and such with teaching events (this, of course, is probably 
much easier in Germany than elsewhere with the Cryptoparty movement having 
taken off that stongly here). A relevant share of them does that.

(The immoral part is, of course, that I give them two example links, one of 
them to my site ;-) )

This way we both get more people (who have not searched for them) to good 
OpenPGP resources and improve the search engine ranking of them (which helps 
those who actively search for information).


Thus: Write a short text for such cases so that you can just C&P it if you 
happen to encounter such a page. And if you spend some time searching for such 
pages – even better.

Below you find my (German) text. Feel free to copy or change it.


Hauke


###

Dein Beitrag zur höheren Verbreitung von OpenPGP


Moin,

es ist löblich, dass Du auf Deiner Kontaktseite darauf hinweist, dass man die 
Kommunikation mit Dir über OpenPGP sichern kann. Es sollte deshalb in Deinem 
Interesse liegen, dass sehr viel mehr Leute als bisher sich diese Technik 
aneignen. Du kannst mit vernachlässigbarem Aufwand einen dauerhaften Beitrag 
dazu leisten:

Ergänze den Verweis auf Dein OpenPGP-Zertifikat um einen oder mehrere Links 
auf Seiten, die sich als Anlaufstelle für Leute eignen, die nicht wissen, was 
das ist. Für solche Leute sind nicht nur reine Informationsseiten nützlich, 
sondern auch solche von Schulungsangeboten, insbesondere den kostenlosen der 
Cryptoparty-Bewegung.

Linkbeispiele:
Informationen: http://www.openpgp-schulungen.de/fuer/alle/
Schulungsangebote: https://www.cryptoparty.in/location#germany

Weitere Anregungen, wie Du mit mehr oder weniger Aufwand OpenPGP unterstützen 
kannst, findest Du hier:
http://www.openpgp-schulungen.de/fuer/unterstuetzer-personen/

Wenn Du diesen Vorschlag aufgreifst, freue ich mich über eine entsprechende 
Rückmeldung. Auch für eine Diskussion dieser Problematik stehe ich natürlich 
gern zur Verfügung.


CU

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


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

Re: Attacking an offline system

[NdK]

Il 12/09/2013 19:07, Peter Lebbing ha scritto:

> The filesystem is also still there with this USB-via-serial-port thingy. And 
> on
> the CD.
Nope. W/ Vinculum module you send it commands like "open mickey.txt" and
then "read 1024". The filesystem driver is in the module and your
interface only receives expected data.

You really should define your "security perimeter". Start by asking
yourself how much an attacker is willing to spend to access the data
you're handling. Once you have an answer to this question you can choose
how much you are willing to spend to defend your data.
Plain old password protecting a file is usually enough.
FST-01 token could be useful to have your key easily portable and (w/ a
little work) even add a button to confirm signing.
Smartcards are another good alternative if you need some "certification".
An HSM is much less portable but needed if you need both certification
and speed.

And this just to keep your keys safe. Keeping the whole system safe is a
careful compromise between functionality and security. But all depends
on the answer to the first question.

But rubberhose cryptoanalysis is usually *way* more effective :)

BYtE,
 Diego.

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

Attacking an offline system (was: Why trust gpg4win?)

[Peter Lebbing]

On 12/09/13 15:55, Jan wrote:
> Do you see any reasonable attack vectors? What do you think?

The moment someone plugs in a mass storage device and we're talking about
attacking his computer, I think of a manipulated file system, exploiting an
error in the file system driver of the kernel (which runs at a nice privilege
level too). I missed that vector in the discussion so far, which focussed on
manipulated files.

The filesystem is also still there with this USB-via-serial-port thingy. And on
the CD.

You can avoid a filesystem by just storing a tar archive on the storage. I don't
think that's very helpful under Windows, but under Linux, using a block device
as tar input/output is easy. Hell, it's what tar was originally made for (tape
devices) :).

That only helps for the filesystem vector, though.

Anybody still using laplink cables? ;)

(I once blew up part of a mainboard with a laplink cable. Was on a different
phase of the mains electricity than the other PC and not grounded. Gave a nice
spark.)

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Why trust gpg4win?

[Marko Randjelovic]

On Thu, 12 Sep 2013 15:55:24 +0200
"Jan"  wrote:
> 2.1 Most people have only one PC and windows as operating system, so
> the linux/unix distribution should be installed on an USB device.
> This device must not be plugged into the PC if windows is running, in
> order to avoid a manipulation. Further I would uninstall the network
> drivers on the USB device, so it is almost an offline PC. If the user
> receives an encrypted file via email, he saves it to hard disk. Then
> he turns off the PC, plugs in the USB drive and boots off it. He
> copies the file from the hard disk to the USB drive (this should
> cause no trouble). Only if the file is of a simple file format (jpg,
> RTF, mp3, PDF(?), etc.(?)) he accepts it and opens it with a secure
> minimalistic tool. He might even first run a program like an anti
> virus software(?) in order to check whether the structure of the file
> agrees with the official definition of the sated file format.  

All the time I read suggestions on using USB sticks and I must say
people are crazy about USB sticks. It is more convenient to use optical
media then USB stick because they are read only. Boot from Live CD, not
from USB stick and use USB stick only for data. In a desktop PC you can
put two CD devices and boot Live CD from CD1 and write your data to
CD2. You can use write-once media or rewritable media so you do not
waste to much plastic.

If you write your data to CDROM, then it is much more safer to transfer
data to another PC. It is much more complicated to make a virus that
will insert itself into a CDROM then into a USB stick. Furthermore,
such action would be odd and could be blocked by a security software
like SELinux.

-- 
Marko Ranđelović, B.Sc.
Software Developer
Niš, Serbia
marko...@eunet.rs

Note: If you see a nonsense enclosed between lines

BEGIN PGP SIGNATURE
END PGP SIGNATURE

then this message is digitally signed using OpenPGP compliant software.
You need an appropriate plugin for your email client or other OpenPGP
compliant software in order to verify the signature. However, the concept
of computer insecurity implies digital signature is not absolute proof of
identity.

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

lsign produces exportable signatures when used for self-sigs

[Daniel Kahn Gillmor]

GnuPG is currently not able to create a non-exportable self-sig.  If you
try to do this, it gives an error:

  WARNING: the signature will not be marked as non-exportable.

But: some people might never want their keys to be published to the public
keyservers, or have some User IDs that they keep locally that they do
not want to be transmitted via the keyserver network.

AIUI, keyservers should reject keys that do not have a self-signature.
Keyservers should also honor the "non-exportable" marker by rejecting
OpenPGP certification packets that have the "exportable" subpacket
included and set to 0.

So the sensible thing for a keyholder who wants their key to stay off
the keyservers would be to issue a non-exportable self-signature.

The attached patch (against the 1.4.x branch, since that's what i'm in a
good position to test) allows a user comfortable with --expert mode to
add a non-exportable self-sig.

so the creation of such a key is possible with:

 --gen-key
 --expert --edit-key
   uid 1 # select uids that you do not want distributed
   lsign
   delsig # remove all signatures not marked non-exportable

this obviously isn't a great workflow, but with this patch it is at
least possible.

  --dkg

commit 28de238a44205cb7ede822da2aac509f472386b5
Author: Daniel Kahn Gillmor 
Date:   Thu Sep 12 18:29:52 2013 -0400

enable the creation of non-exportable self-sigs

This supports (only via --expert mode at the moment) the use case of
someone who does not want a particular User ID (or an entire key) to
be shared on the public keyservers.

Note that this change modifies the expected parameter that is passed
to keygen_add_std_prefs.  This was modified everywhere it is used.

diff --git a/g10/keyedit.c b/g10/keyedit.c
index c47fd0f..031f7b3 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -98,13 +98,6 @@ static int update_trust=0;
 #define NODFLG_SELKEY (1<<9)  /* indicate the selected key */
 #define NODFLG_SELSIG (1<<10) /* indicate a selected signature */
 
-struct sign_attrib {
-int non_exportable,non_revocable;
-struct revocation_reason_info *reason;
-byte trust_depth,trust_value;
-char *trust_regexp;
-};
-
 
 #ifdef ENABLE_CARD_SUPPORT
 /* Given a node SEC_NODE with a secret key or subkey, locate the
@@ -959,8 +952,7 @@ sign_uids( KBNODE keyblock, STRLIST locusr, int *ret_modified,
   {
 tty_printf("\n");
 tty_printf(
-			 _("WARNING: the signature will not be marked "
-			   "as non-exportable.\n"));
+		 _("The signature will be marked as non-exportable.\n"));
   }
 
 	if( nonrevocable )
@@ -1025,6 +1017,7 @@ sign_uids( KBNODE keyblock, STRLIST locusr, int *ret_modified,
 		PACKET *pkt;
 		PKT_signature *sig;
 		struct sign_attrib attrib;
+	 	struct std_prefs_data data;
 
 		assert( primary_pk );
 		memset( &attrib, 0, sizeof attrib );
@@ -1040,14 +1033,16 @@ sign_uids( KBNODE keyblock, STRLIST locusr, int *ret_modified,
  * subpacket with v3 keys and the signature becomes
  * exportable */
 
-		if(selfsig)
+		if(selfsig) {
+  data.pk = primary_pk;
+  data.attrib = &attrib;
 		  rc = make_keysig_packet( &sig, primary_pk,
 	   node->pkt->pkt.user_id,
 	   NULL,
 	   sk,
 	   0x13, 0, force_v4?4:0, 0, 0,
-	   keygen_add_std_prefs, primary_pk);
-		else
+	   keygen_add_std_prefs, &data);
+		} else
 		  rc = make_keysig_packet( &sig, primary_pk,
 	   node->pkt->pkt.user_id,
 	   NULL,
@@ -2965,6 +2960,7 @@ menu_adduid( KBNODE pub_keyblock, KBNODE sec_keyblock,
 KBNODE node;
 KBNODE pub_where=NULL, sec_where=NULL;
 int rc;
+struct std_prefs_data data;
 
 for( node = pub_keyblock; node; pub_where = node, node = node->next ) {
 	if( node->pkt->pkttype == PKT_PUBLIC_KEY )
@@ -3027,8 +3023,10 @@ menu_adduid( KBNODE pub_keyblock, KBNODE sec_keyblock,
 if( !uid )
 	return 0;
 
+data.pk = pk;
+data.attrib = NULL;
 rc = make_keysig_packet( &sig, pk, uid, NULL, sk, 0x13, 0, 0, 0, 0,
-			 keygen_add_std_prefs, pk );
+			 keygen_add_std_prefs, &data );
 free_secret_key( sk );
 if( rc ) {
 	log_error("signing failed: %s\n", g10_errstr(rc) );
diff --git a/g10/keygen.c b/g10/keygen.c
index 8353f36..7df8442 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -688,13 +688,24 @@ keygen_upd_std_prefs( PKT_signature *sig, void *opaque )
 int
 keygen_add_std_prefs( PKT_signature *sig, void *opaque )
 {
-PKT_public_key *pk = opaque;
+struct std_prefs_data *data = opaque;
+PKT_public_key *pk = data->pk;
+byte buf[1];
 
 do_add_key_flags (sig, pk->pubkey_usage);
 keygen_add_key_expire( sig, opaque );
 keygen_upd_std_prefs (sig, opaque);
 keygen_add_keyserver_url(sig,NULL);
 
+/* we only support the non_exportable attribute at the moment.  If
+   there are other attributes we'd like to support, they should be
+   added here.
+*/
+   

Re: message digest for signed emails

[Doug Barton]

For the OP, try with and without spaces around the = sign as well. I 
have heard reports that can make a difference. So try all of the following:


n...@exaxmple.com = key1 key2 key3
 = key1 key2 key3
n...@exaxmple.com=key1 key2 key3
=key1 key2 key3

hth,

Doug

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