Re: auto-key-retrieve usefulness/annoyance

[Werner Koch]

On Wed,  4 Oct 2017 20:01, tliko...@iki.fi said:

> The result: There's a delay of several seconds every time I open the
> message and in the end my email client (Gnus) says:

I have exactly the same problem but I do it anwyat - there is not much
we can do about it.  The default timeout for such lookups are 2 seconds.
You can lower this to one second using

  connect-quick-timeout 1

in dirmngr.conf.  A bit more annoying keyserver DNS entries with service
records, which will all be tried in turn until one is found.  That can
multiply the timeout.


Salam-Shalom,

   Werner

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


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

Re: 1024 key with large sub key

[Werner Koch]

On Wed,  4 Oct 2017 22:29, r...@sixdemonbag.org said:

> I know this wasn't addressed to me, but what the heck.  I won't share my
> preferences, but this is some modestly-accurate history.

Thanks for sharing the history; here are some of my remarks.

> Twofish became part of the suite of ciphers with PGP 7, and GnuPG had to

Back in 1998/1999 we were keen to have a 128 bit block cipher in
OpenPGP.  The PGP folks and me discussed this and our bets were on
Twofish as a very promising candidate for the AES competition.  Thus we
went for that before we added AES 1.5 years later.

> (I have heard it said Blowfish was introduced to the spec as a fallback
> in case CAST5 turned out to have flaws.  Given how similar CAST5 and

Blowfish used to be the only freely available cipher when I started with
gpg.  Thus it was a natural choice for free software.  The patent state
of CAST5 was not fully clear back then and thus gpg used Blowfish up
until the OpenPGP WG agreed on CAST5 (which was used by PGP-5) and
removed the uncertainty on the patent state.  Blowfish was kept as an
optional algorithm because it was used by gpg.  The OpenPGP preference
system allowed us to do this without running into interop problems.

> I won't bore you with my list of preferred algos, though.  :)

The default algorithms of GnuPG should be a good choice in any case.


Shalom-Salam,

   Werner

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


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

Re: 1024 key with large sub key

[Robert J. Hansen]

> Back in 1998/1999 we were keen to have a 128 bit block cipher in
> OpenPGP.  The PGP folks and me discussed this and our bets were on
> Twofish as a very promising candidate for the AES competition.  Thus we
> went for that before we added AES 1.5 years later.

I was unaware GnuPG had a role in this decision: thank you for the
clarification.  :)

> Blowfish used to be the only freely available cipher when I started with
> gpg.

... wait, 3DES was patent-encumbered?

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

Re: 1024 key with large sub key

[Werner Koch]

On Thu,  5 Oct 2017 18:39, r...@sixdemonbag.org said:

>> Blowfish used to be the only freely available cipher when I started with
>> gpg.
>
> ... wait, 3DES was patent-encumbered?

Not that I know.  But it was old and Blowfish was everywhere (in
particular due to Schneier's book Applied Crypto).  The task was to
replace the patented IDEA cipher and (single-)DES had a bad repudiation
due to the EFF's DES cracker.


Shalom-Salam,

   Werner

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


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

Re: auto-key-retrieve usefulness/annoyance

[Teemu Likonen]

Werner Koch [2017-10-05 09:00:18+02] wrote:

> I have exactly the same problem but I do it anwyat - there is not much
> we can do about it.  The default timeout for such lookups are 2 seconds.
> You can lower this to one second using
>
>   connect-quick-timeout 1
>
> in dirmngr.conf.

Thanks. That helps noticeably. And yes, I use auto-key-retrieve anyway.
It's a nice feature. I have sometimes persuaded people to upload their
key to the server pool.

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


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

Re: GnuPG-card works in the Ubuntu smartphone

[Werner Koch]

Hi!

Matthias wrote a HOWTO for the GnuPG blog:

 <https://gnupg.org/blog/20171005-gnupg-ccid-card-daemon-UbuntuPhone.html>



Shalom-Salam,

   Werner

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


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

Re: auto-key-retrieve usefulness/annoyance

[Daniel Kahn Gillmor]

On Thu 2017-10-05 09:00:18 +0200, Werner Koch wrote:
> I have exactly the same problem but I do it anwyat - there is not much
> we can do about it.  The default timeout for such lookups are 2 seconds.
> You can lower this to one second using
>
>   connect-quick-timeout 1

A more user-friendly approach (setting aside current architecture and
privacy concerns) would be to fire off a retrieval in the background and
to return immediately with seomthing like "unknown key, retrieval
attempted…"

Even better would be to have some sort of asynchronous callback that
happens after the key is effectively retreived, so that whatever user
interface displays the response could update when (if) the key comes in.

gpg isn't currently constructed to do this kind of asynchronous user
interaction, however.

 --dkg


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

Re: auto-key-retrieve usefulness/annoyance

[NdK]

Il 05/10/2017 21:06, Daniel Kahn Gillmor ha scritto:

> gpg isn't currently constructed to do this kind of asynchronous user
> interaction, however.
But the mail client could flag the message "key retrieval failed". Then,
the delay is only on the first attempt. Unless the user un-flags that
message.

BYtE,
 Diego


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