Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: devel

[PATCH] Allow printing key digests in key edit

 

 

GnuPG devel RSS feed   Index | Next | Previous | View Threaded


christian at quelltextlich

Jan 29, 2012, 7:23 AM

Post #1 of 8 (355 views)
Permalink
[PATCH] Allow printing key digests in key edit

Hello,

Although SHA1 is considered to be broken by some, key-signing parties typically still rely on asserting validity of keys by comparing their fingerprints. The main obstacle being that programs as GnuPG do not provide an easy access to a more secure digest of a key.

The patch added below, adds a "digest" command in the --edit-keys menu, that allows to compute further digests of keys.

By getting easy access to SHA2 digests of their keys, participants of key-signing parties can assert validity of keys by comparing SHA2 digests, and can finally (manually) check whether a key obtained from a keyserver matches the SHA2 digests compared at the party.

Kind regards,
Christian

P.S.: Of course, this does not address the problems arising from the use of SHA1 in OpenPGP, or from (key) signatures made with SHA1. This patch just gives more options to the GnuPG user.

---
g10/keyedit.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 70 insertions(+), 1 deletions(-)

diff --git a/g10/keyedit.c b/g10/keyedit.c
index 26e05a0..d78c761 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -56,6 +56,8 @@ static void show_key_with_all_names (KBNODE keyblock, int only_marked,
int with_revoker, int with_fpr,
int with_subkeys, int with_prefs);
static void show_key_and_fingerprint (KBNODE keyblock);
+static void show_digest (KBNODE keyblock, int digest_algo);
+static int menu_digest (void);
static int menu_adduid (KBNODE keyblock, int photo, const char *photo_name);
static void menu_deluid (KBNODE pub_keyblock);
static int menu_delsig (KBNODE pub_keyblock);
@@ -1308,7 +1310,7 @@ enum cmdids
cmdEXPIRE, cmdBACKSIGN, cmdENABLEKEY, cmdDISABLEKEY, cmdSHOWPREF,
cmdSETPREF, cmdPREFKS, cmdNOTATION, cmdINVCMD, cmdSHOWPHOTO, cmdUPDTRUST,
cmdCHKTRUST, cmdADDCARDKEY, cmdKEYTOCARD, cmdBKUPTOCARD, cmdCHECKBKUPKEY,
- cmdCLEAN, cmdMINIMIZE, cmdNOP
+ cmdCLEAN, cmdMINIMIZE, cmdDIGEST, cmdNOP
};

static struct
@@ -1399,6 +1401,7 @@ static struct
N_("compact unusable user IDs and remove unusable signatures from key")},
{ "minimize", cmdMINIMIZE, KEYEDIT_NOT_SK,
N_("compact unusable user IDs and remove all signatures from key")},
+ { "digest", cmdDIGEST, 0, N_("compute a digest for the key")},

{ NULL, cmdNONE, 0, NULL}
};
@@ -1649,6 +1652,10 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
show_key_and_fingerprint (keyblock);
break;

+ case cmdDIGEST:
+ show_digest( keyblock, menu_digest() );
+ break;
+
case cmdSELUID:
if (strlen (arg_string) == NAMEHASH_LEN * 2)
redisplay = menu_select_uid_namehash (keyblock, arg_string);
@@ -2938,6 +2945,68 @@ show_key_and_fingerprint (KBNODE keyblock)
print_fingerprint (pk, 2);
}

+// Prints a digest of the public key in keyblock
+// using the digest_algo digest algorithm
+static void
+show_digest (KBNODE keyblock, int digest_algo)
+{
+ PKT_public_key *pk = NULL;
+ gcry_md_hd_t md;
+ const byte *dp;
+ int len;
+ int i;
+
+ assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY);
+ pk = keyblock->pkt->pkt.public_key;
+
+ tty_printf ("\n");
+
+ if (gcry_md_open (&md, digest_algo, 0))
+ BUG ();
+ hash_public_key(md,pk);
+ gcry_md_final( md );
+
+ dp = gcry_md_read( md, 0 );
+ len = gcry_md_get_algo_dlen (gcry_md_get_algo (md));
+ assert( len >=0 );
+ tty_printf(" %s digest of key = ", gcry_md_algo_name( digest_algo ) );
+ for ( i=0; i < len ; i++ )
+ tty_printf("%s%s%s%02X",
+ (i&15)?"":"\n ",
+ (i&7)?"":" ",
+ (i&1)?"":" ",
+ dp[i] );
+ gcry_md_close( md );
+
+ tty_printf ("\n");
+}
+
+static int
+menu_digest ( void )
+{
+ int i;
+ char *answer;
+ int digest_algo = 0;
+
+ // Showing the possible digests
+ tty_printf (_("Please select what kind of digest you want:\n"));
+ for(i=0; i <= 110; i++ )
+ if( !openpgp_md_test_algo(i) )
+ {
+ tty_printf( " (%d) %s\n", i, gcry_md_algo_name(i));
+ }
+
+ // User selects digest
+ while ( openpgp_md_test_algo( digest_algo ) )
+ {
+ answer = cpr_get( "keyedit.print_digest", _("Your selection? ") );
+ cpr_kill_prompt ();
+ digest_algo = *answer? atoi (answer) : DIGEST_ALGO_SHA512;
+ }
+
+ return digest_algo;
+}
+

/* Show a warning if no uids on the key have the primary uid flag
set. */
--
1.7.8.3
Attachments: signature.asc (0.48 KB)


wk at gnupg

Jan 30, 2012, 12:32 AM

Post #2 of 8 (344 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

On Sun, 29 Jan 2012 16:23, christian [at] quelltextlich said:

> Although SHA1 is considered to be broken by some, key-signing parties

That is plain nonsense. It is not yet possible to compute collisions,
let a anone a second preimage.

> The patch added below, adds a "digest" command in the --edit-keys menu, that allows to compute further digests of keys.

These are not defined by OpenPGP and thus I strongly advise against its
use. SHA-1 is an integral part of OpenPGP; it doesn't help if you come
up with a different way of computing a fingerprint.


Salam-Shalom,

Werner

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


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


christian at quelltextlich

Jan 30, 2012, 5:36 AM

Post #3 of 8 (343 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

Hello Werner,

on Mon, Jan 30, 2012 at 09:32:58AM +0100, Werner Koch wrote:
> On Sun, 29 Jan 2012 16:23, christian [at] quelltextlich said:
>
> > Although SHA1 is considered to be broken by some, [...]
>
> That is plain nonsense.

I suppose we all agree that among those who claim such "nonsense" are
for example renowned cryptographer Bruce Schneier [1]. For whatever
reason places like Apache.org also follow this nonsense [2].

Be things as they may, I haven't seen SHA-1 collisions growing on
trees since 2005 either :)

> > The patch added below, adds a "digest" command in the --edit-keys
> > menu, that allows to compute further digests of keys.
>
> These are not defined by OpenPGP and thus I strongly advise against its
> use. SHA-1 is an integral part of OpenPGP; it doesn't help if you come
> up with a different way of computing a fingerprint.

As written in the PS of my previous post [3], this patch is not to mangle
with OpenPGP business. It is not an attempt to replace the OpenPGP
fingerprint. It does not even touch any OpenPGP stuff within GnuPG.
It's solely about letting GnuPG (not general OpenPGP) users experiment.

Let the GnuPG users see, what the SHA2 digests look like.
Let them see how it feels to be "identified" by more bits.
This might help finding answers to questions like:
- Is it feasable to ask people to check printouts of SHA2 digests before
coming to key-signing parties?
- Is it feasable to hold key-signing parties where SHA2 digests are
compared live?
- Do people revolt against manually checking longer digests?

It is not about mangling with OpenPGP. OpenPGP and the patch do not
interfere.

It is about freedom; giving people access to further digests.
Letting people experiment.

Kind regards,
Christian


[1] http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
[2] http://www.apache.org/dev/openpgp.html#sha1
[3] Which you edited away for whatever reason.
Attachments: signature.asc (0.48 KB)


wk at gnupg

Jan 30, 2012, 6:44 AM

Post #4 of 8 (341 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

On Mon, 30 Jan 2012 14:36, christian [at] quelltextlich said:

> I suppose we all agree that among those who claim such "nonsense" are
> for example renowned cryptographer Bruce Schneier [1]. For whatever

You need to understand what crypto analysts understand under "broken":
It does not match the original design goals anymore. However, all
algorithms have a high security margin which allows them to be used
after that break.

Even the for many common usages actually broken MD5, still holds strong
when used as the digest in a HMAC. For SHA-1 we even don't known how to
compute a collision.

> Be things as they may, I haven't seen SHA-1 collisions growing on
> trees since 2005 either :)

In the case of a fingerprint we don't care too much about collision
resistance but about preimage attacks. Consider if someone is able to
create two keys with the same fingerprint. You don't need to care
because you sign his key+user_id. The fingerprint doesn't matter
anymore after you signed it. Only with a preimage attack a third person
would be able to create a key to impersonate the first one.

In any case the crypto community is well aware that algorithms wear out
that we need to prepare the migration to newer algorithms. This is the
hard job of protocol designing and product deployment.

> with OpenPGP business. It is not an attempt to replace the OpenPGP
> fingerprint. It does not even touch any OpenPGP stuff within GnuPG.
> It's solely about letting GnuPG (not general OpenPGP) users experiment.

New features will be used and may later force the protocol designers to
take a path they would haven't used if not many users had set a de-facto
standard. Fortunately the OpenPGP fingerprint is well defined and we
want to keep it this way and don't fall back to a de-facto method on how
to compute a fingerprint on an X.509 certificate.

> - Is it feasable to ask people to check printouts of SHA2 digests before
> coming to key-signing parties?

No.

[. And you should not use the key checking method you have in mind.
Exchanging paper slips is the only solid way to run a key signing
party. I am really sorry, that we came up with that crypto-cool key
signing scheme back at the Utrecht keyserver admins back in 2000. It
does not work in practice. ]


> - Is it feasable to hold key-signing parties where SHA2 digests are
> compared live?

No.

> - Do people revolt against manually checking longer digests?

No. Because may of them check only the begin and end of the fingerprint
- if at all.

> It is about freedom; giving people access to further digests.
> Letting people experiment.

You are about to weaken a good protocol to drive it into the X.509 mess.


Salam-Shalom,

Werner

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


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


rjh at sixdemonbag

Jan 30, 2012, 6:52 AM

Post #5 of 8 (344 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

On 1/30/12 8:36 AM, Christian Aistleitner wrote:
> I suppose we all agree that among those who claim such "nonsense"
> are for example renowned cryptographer Bruce Schneier [1]. For
> whatever reason places like Apache.org also follow this nonsense
> [2].

A guy I know is fond of saying that God may know absolute truth, but for
us mortals every truth has a context.

Schneier is a cryptographer. When he says something is broken, he means
in a cryptographer's sense: that it substantially fails to meet its
original design criteria. But to say that SHA-1 is "broken," full stop,
presents its brokenness as an absolute fact, when the truth is it just
ain't.

I know a ton of people who are still using MD5 as a collision-resistant
hash. This gives some people the heebie-jeebies, but the people who are
doing this include some of the smartest people I've ever known, and they
have good reasons for doing it.

> It's solely about letting GnuPG (not general OpenPGP) users
> experiment.

Then post your code as a diff against a 2.0.x tree and let interested
users apply the patch themselves. Why should an experimental,
let's-play-around feature be introduced into the trunk of GnuPG and have
*all* of GnuPG's users be exposed to it?

> This might help finding answers to questions like:

It might. It's a good idea. It's just not (IMO) a good idea to include
it in GnuPG-trunk.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


dshaw at jabberwocky

Jan 30, 2012, 7:10 AM

Post #6 of 8 (346 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

On Jan 30, 2012, at 8:36 AM, Christian Aistleitner wrote:

>> These are not defined by OpenPGP and thus I strongly advise against its
>> use. SHA-1 is an integral part of OpenPGP; it doesn't help if you come
>> up with a different way of computing a fingerprint.
>
> As written in the PS of my previous post [3], this patch is not to mangle
> with OpenPGP business. It is not an attempt to replace the OpenPGP
> fingerprint. It does not even touch any OpenPGP stuff within GnuPG.
> It's solely about letting GnuPG (not general OpenPGP) users experiment.

Experimentation is fine, but it is inappropriate to experiment in ways that affect core pieces of interoperability. This would make GnuPG users essentially have two types of fingerprint - the standard OpenPGP one, and the new GnuPG-specific longer hash one. When signing keys with people using other implementations (PGP being the big one here), we don't need the confusion of multiple strings to compare, only some of which are useful for a given implementation.

There will, no doubt, be a new fingerprint standard arriving someday. It probably won't be soon, but when it does, it will be something decided on by the OpenPGP WG after discussion and input. It's been discussed there before, and it's not a trivial task.

I don't mean that nobody should experiment, of course, but I do think that including such an experiment as a standard feature in GnuPG pushes it away from a mere experiment.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


rjh at sixdemonbag

Jan 30, 2012, 9:33 AM

Post #7 of 8 (347 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

On 1/30/12 9:44 AM, Werner Koch wrote:
> Even the for many common usages actually broken MD5, still holds strong
> when used as the digest in a HMAC. For SHA-1 we even don't known how to
> compute a collision.

It's also worth noting that "actually broken" might not mean broken at all.

In the United States, MD5 has been used in literally thousands of court
cases. Programs like md5sum and m5deep have been examined by state and
federal courts time and again, and have been judged to meet the courts'
standards for the admission of scientific evidence. Nowadays if you
want to introduce an MD5 checksum of a file as proof that the file
hasn't changed, the courts will accept that.

SHA-1 has less support from the courts. You probably won't get your
evidence thrown out for lack of proper process, but why take the risk
when MD5 can be used instead?

The SHA-2 family are almost unknown in the courts. If you're the first
person presenting a SHA512 or a WHIRLPOOL hash in a courtroom, suddenly
you're going to have a rough time of things as you repeat all the
challenges that MD5 went through when it first came out.

I know a few forensic investigators who use both SHA256 and MD5 in their
professional work. When they inventory a file system they compute and
store both sets of hashes. They might use SHA256 themselves, but when
it comes time to testify in court they present the MD5s. If and when
courts decide MD5 no longer is credible they'll have SHA256es to fall
back upon, but for now they play the game according to the rules the
courts have set up: and according to them, MD5 hasn't been broken.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


christian at quelltextlich

Jan 31, 2012, 12:02 PM

Post #8 of 8 (348 views)
Permalink
Re: [PATCH] Allow printing key digests in key edit [In reply to]

Hello,

on Mon, Jan 30, 2012 at 09:52:31AM -0500, Robert J. Hansen wrote:
> Then post your code as a diff against a 2.0.x tree and let interested
> users apply the patch themselves.

So be it :)
Those interested in trying out / toying around with digests in the
2.0 series find a patch against the current STABLE-BRANCH-2-0
attached below.

Kind regards,
Christian

---
g10/keyedit.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 70 insertions(+), 1 deletions(-)

diff --git a/g10/keyedit.c b/g10/keyedit.c
index 76830f0..a9c358e 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -52,6 +52,8 @@ static void show_names(KBNODE keyblock,PKT_public_key *pk,
static void show_key_with_all_names( KBNODE keyblock, int only_marked,
int with_revoker, int with_fpr, int with_subkeys, int with_prefs );
static void show_key_and_fingerprint( KBNODE keyblock );
+static void show_digest (KBNODE keyblock, int digest_algo);
+static int menu_digest (void);
static int menu_adduid( KBNODE keyblock, KBNODE sec_keyblock,
int photo, const char *photo_name );
static void menu_deluid( KBNODE pub_keyblock, KBNODE sec_keyblock );
@@ -1368,7 +1370,7 @@ enum cmdids
cmdEXPIRE, cmdBACKSIGN, cmdENABLEKEY, cmdDISABLEKEY, cmdSHOWPREF,
cmdSETPREF, cmdPREFKS, cmdNOTATION, cmdINVCMD, cmdSHOWPHOTO, cmdUPDTRUST,
cmdCHKTRUST, cmdADDCARDKEY, cmdKEYTOCARD, cmdBKUPTOCARD, cmdCLEAN,
- cmdMINIMIZE, cmdNOP
+ cmdMINIMIZE, cmdDIGEST, cmdNOP
};

static struct
@@ -1475,6 +1477,7 @@ static struct
N_("compact unusable user IDs and remove unusable signatures from key")},
{ "minimize", cmdMINIMIZE , KEYEDIT_NOT_SK,
N_("compact unusable user IDs and remove all signatures from key") },
+ { "digest", cmdDIGEST, 0, N_("compute a digest for the key")},
{ NULL, cmdNONE, 0, NULL }
};

@@ -1741,6 +1744,10 @@ keyedit_menu( const char *username, strlist_t locusr,
show_key_and_fingerprint( keyblock );
break;

+ case cmdDIGEST:
+ show_digest( keyblock, menu_digest() );
+ break;
+
case cmdSELUID:
if(strlen(arg_string)==NAMEHASH_LEN*2)
redisplay=menu_select_uid_namehash(cur_keyblock,arg_string);
@@ -3040,6 +3047,68 @@ show_key_and_fingerprint( KBNODE keyblock )
print_fingerprint( pk, NULL, 2 );
}

+// Prints a digest of the public key in keyblock
+// using the digest_algo digest algorithm
+static void
+show_digest (KBNODE keyblock, int digest_algo)
+{
+ PKT_public_key *pk = NULL;
+ gcry_md_hd_t md;
+ const byte *dp;
+ int len;
+ int i;
+
+ assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY);
+ pk = keyblock->pkt->pkt.public_key;
+
+ tty_printf ("\n");
+
+ if (gcry_md_open (&md, digest_algo, 0))
+ BUG ();
+ hash_public_key(md,pk);
+ gcry_md_final( md );
+
+ dp = gcry_md_read( md, 0 );
+ len = gcry_md_get_algo_dlen (gcry_md_get_algo (md));
+ assert( len >=0 );
+ tty_printf(" %s digest of key = ", gcry_md_algo_name( digest_algo ) );
+ for ( i=0; i < len ; i++ )
+ tty_printf("%s%s%s%02X",
+ (i&15)?"":"\n ",
+ (i&7)?"":" ",
+ (i&1)?"":" ",
+ dp[i] );
+ gcry_md_close( md );
+
+ tty_printf ("\n");
+}
+
+static int
+menu_digest ( void )
+{
+ int i;
+ char *answer;
+ int digest_algo = 0;
+
+ // Showing the possible digests
+ tty_printf (_("Please select what kind of digest you want:\n"));
+ for(i=0; i <= 110; i++ )
+ if( !openpgp_md_test_algo(i) )
+ {
+ tty_printf( " (%d) %s\n", i, gcry_md_algo_name(i));
+ }
+
+ // User selects digest
+ while ( openpgp_md_test_algo( digest_algo ) )
+ {
+ answer = cpr_get( "keyedit.print_digest", _("Your selection? ") );
+ cpr_kill_prompt ();
+ digest_algo = *answer? atoi (answer) : DIGEST_ALGO_SHA512;
+ }
+
+ return digest_algo;
+}
+

/* Show a warning if no uids on the key have the primary uid flag
set. */
--
1.7.8.3
Attachments: signature.asc (0.48 KB)

GnuPG devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.