Re: gpg 2.0.27 is updating the trustdb constantly, and taking minutes to do it

[Werner Koch]

On Fri, 27 Mar 2015 17:07, j...@jcea.es said:

> My problem is that any change to the pubring, like downloading a new
> key, refreshing, adding a new local signature with "--lsign", etc., will
> force a trustdb update (in the next execution. For instance, decrypting

A new key signature may chnage rthe entire WoT thus it needs to be
re-computed.  I have

  no-auto-check-trustdb

in my gpg.conf and 

  30   1 * * *   /usr/local/bin/gpg --batch --check-trustdb 2>/dev/null

in my crontab.  Thus tehre will be only one re-computation a day.

> As I said, my pubring.gpg is 34MB long. With gnupg 1.4.x it would take a
> few seconds only.

Which 1.4 version is this?


> PS: Bonus: how to get rid of
>
> """
> gpg: DBG: armor-keys-failed (KEY 0x010D6F3A BEGIN

Sorry for this.  It has already been fixed in the repo, see below.


Shalom-Salam,

   Werner


--8<---cut here---start->8---
commit 936416690e6c889505d84fe96983a66983beae5e
Author: Werner Koch 
Date:   Thu Feb 26 09:38:58 2015 +0100

gpg: Remove left-over debug message.

* g10/armor.c (check_input): Remove log_debug.

Modified   g10/armor.c
diff --git a/g10/armor.c b/g10/armor.c
index 6c0013d..de1726d 100644
--- a/g10/armor.c
+++ b/g10/armor.c
@@ -534,9 +534,6 @@ check_input( armor_filter_context_t *afx, IOBUF a )
 /* This is probably input from a keyserver helper and we
have not yet seen an error line.  */
 afx->key_failed_code = parse_key_failed_line (line+4, len-4);
-log_debug ("armor-keys-failed (%.*s) ->%d\n",
-   (int)len, line,
-   afx->key_failed_code);
   }
if( i >= 0 && !(afx->only_keyblocks && i != 1 && i != 5 && i != 6 )) {
hdr_line = i;
--8<---cut here---end--->8---


-- 
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: Enabling and using ECC keys (any reason not to?)

[Johan Wevers]

On 27-03-2015 14:21, Martin Behrendt wrote:

> So especially when introducing new algorithms which might be tampered
> with, using e.g. an old style RSA Key as one layer and ECC as a second
> should help against this. Or am I missing something here?

Why would you want to use a suspect algorithm if the RSA alone is secure
enough?

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


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

Re: One alternative to SMTP for email: Confidant Mail

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 26 March 2015 at 11:57:43 PM, in
, Mike Ingle wrote:



> That's more or less what it does. When you get an email
> from  j...@somewhere.com, it fetches that key id and
> adds it to your keyring. If you get an email from a
> different key claiming j...@somewhere.com, it also
> fetches that key id and adds it, but now messages from
> both users show a key collision until you go delete one
> of those keys.


Why should the user need to delete one, rather than just be told there
were two and the one with such-and-such a fingerprint (or the one
highlighted) signed this message? If it is just a string in a key UID
rather than a functional email address, it will not necessarily be
unique.



> Likewise,  while you have a key
> collision, you cannot email that user by typing his
> email address. You have to type or click the key id. In
> that way it  forces you to deal with it when and if you
> get a collision.

I guess a future UI enhancement might be the ability to specify a key
id in a contact list entry. Or something akin to Enigmail's
Per-recipient rules.



> Think I should rephrase that like, "SMTP-style
> addresses can be used to look up keys"?

I think it is a good idea to re-phrase it so that you are not stating
the user can keep their existing SMTP email address, and also to make
it clear this identifier is used only for key look-up and not for
message delivery.


> It is true that
> people can always keep and use their existing address,
> but others can potentially generate fake keys for that
> address.

It is also true that some email providers recycle email addresses that
have fallen out of use. Out of seven yahoo addresses I used for
consecutive periods between 2004 and 2009, six are currently available
to be registered. (The odd-one-out is from 2006.) I have left each one
active with an auto-forward to the next.



> The celebrity will not be blocked because there is no
> central key  directory. It's possible some impostor
> will start using a celebrity's  email address on CM.
> Then when the real celebrity wants to use it, he  will
> tweet "My real CM key id is (some hash), please ignore
> those  impostors" and hopefully that will resolve it.

That is re-assuring to hear. See also my first comment, above.



> It's similar to regular PGP keyservers in that it will
> accept any key someone wants to post. The main
> difference is keys expire after a month or so if they
> are not  re-posted.

In a similar way to a file that has not been requested for a
relatively long time dropping off a peer-to-peer filesharing network?



> The only person who will see a key collision is one who
> previously  received a message from the impostor.

Or subsequently received a message from the imposter, then goes back
to look at the message that was not from the imposter, presumably.



> Yes I am worried about the bogus keys problem. Just not
> sure how to  handle it in a peer to peer system.

Is there a way to incorporate some sort of challenge/response at key
creation time before the key is uploaded to the peer-to-peer system?
Or could the challenge/response be handled by a number of
"verification agents" incorporated into the peer-to-peer network?



> Anyone can run
> a provider and I expect them to range  from strictly
> business to the dodgy darknet variety.

Using "darknet" services to enhance privacy does not equate to
"dodgy". A person's communications are none of anybody else's
business, apart from whoever they choose to communicate with.


- --
Best regards

MFPA  

Oven mitt: A partially charred grease stain that fits over the hand.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVFsHZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwa/EH/iv0O00KWyhNB4hg6eHEgeZM
xRIZj2ZuKqM7nAB9sjSAkHuqBMYUyOK1ax/E27oxC7nCV0STPA8f7SYU5BD/Mgyw
6AJaDeHf78iS9DpMf3ffbKRZQAK2Nv4Sh4NzTzi7eOKIc2Q/vTezWD9NZSvmlAWQ
2+1aVoYHjGFcqeb73FVssQNJfExjnkCeK4RdngEoDFbwwAAb1TZ+Riggv5EqhPrv
WntSpz0UyBoult1oAkhut0UIdsfdUZeCUBMYss8EVFaGD0JPPkZRj55QdtUaMGhF
vo59Pi1Yvwh6lXgcSIubp5HgEDvKjAZf5nyAHjemk4pNuLTvFWjsBjhXBnGxDSGI
vgQBFgoAZgUCVRbB318UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45JQCAQDpDKWBL+9PUZsY8wZt2X1f1KVN
STpTVBfz4Bve7y/0swEAXCBuKgk0objXBzFT5WQqwP+KKhWYZYqTGVFOmuNPdg8=
=ugkT
-END PGP SIGNATURE-


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

Re: One alternative to SMTP for email: Confidant Mail

[Peter Lebbing]

On 28/03/15 15:59, MFPA wrote:
> Using "darknet" services to enhance privacy does not equate to
> "dodgy".

No, but nobody said the adjective was used tautological.

It's like someone says "they're doing shady business in a dark alley"
and you protest "Hey, I know plenty proper businesses that are just
upstanding people making sales! In fact, I also know plenty alleys that
let in a lot of sunlight..."

:)

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: gpg 2.0.27 is updating the trustdb constantly, and taking minutes to do it

[Doug Barton]

On 3/28/15 3:48 AM, Werner Koch wrote:

Sorry for this.  It has already been fixed in the repo,


Just out of curiosity, do you have an ETA on a new release?

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




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

Iceland mirror not working

[ljbp1csyfud6ixyyflzyq9hrg0]

Hi,
Notice that Iceland mirror are not working:
ftp://ftp.hi.is/pub/mirrors/gnupg/

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

Re: Enabling and using ECC keys (any reason not to?)

[Stephan Beck]

Am 27.03.2015 um 14:21 schrieb Martin Behrendt:
> On 26.03.2015 18:40, Pete Stephenson wrote:
>>
>> People have raised concerns about the NIST curves, but they are part
>> of the RFC 6637 standard so compliant programs must implement P-256,
>> may implement P-384, and should implement P-521.
>>
>> To address potential concerns with the NIST curves, GnuPG also
>> supports the Brainpool curves which are similar in structure to the
>> NIST curves but use parameters chosen from nothing-up-my-sleeve
>> numbers and so should be reasonably trustworthy. Still, the structure
>> of such curves leaves a bit to be desired (see
>> http://safecurves.cr.yp.to/ for details, I'm hardly an expert).
>>
> 
> I just did a quick search but didn't find anything.
[...]

A very recent (Feb 2015) "historical" analysis of the surreptitious weakening of
cryptographic systems, incl. a description of the NIST (or Dual EC-DRBG) curves'
pecularities "detected" in 2005 can be found at (1):

(1) https://www.schneier.com/paper-weakening.html (p. 2,7).

Cheers,
Stephan






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