So on & so forth

[Richard Outerbridge]

Still waiting for my email address, yet my blackphone is already in
my hands.  Keep up the good work.

I’m not going to bother with 2.1 until the Mac guyz come to their
senses about not forking the crypto.  Could be a long wait.

On 2014-08-14 (226), at 11:57:06, Werner Koch  wrote:
__outer

> Hello!
> 
> I just released the sixth *beta* version of GnuPG *2.1*.  It has been
> released to give you the opportunity to check out new features and to
> help fixing bugs.


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

Re: ICMP

[Aaron Toponce]

On Fri, Aug 15, 2014 at 12:54:29PM -0400, Robert J. Hansen wrote:
> >Blocking ICMP is not a network misconfiguration at all.
> 
> Whether it's a misconfiguration depends entirely on whether the
> administrator intends this behavior.

I meant "Blocking ICMP" is a deliberate act by the administrator, not a
misconfiguration.

Anyway, sorry for going OT.

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


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

Re: ICMP

[Robert J. Hansen]

I agree with everything Doug wrote except this.  I may be insisting on
usual semantics...


Yow, did I actually write that?  Time to go drink coffee directly from 
the pot.


s/usual/unusual/

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

Re: (OT) Re: ICMP

[Robert J. Hansen]

Okay. So an administrator willingly creates a PMTU blackhole?...




You'll notice I'm not disagreeing with you on anything.  :)

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

(OT) Re: ICMP

[Peter Lebbing]

On 15/08/14 19:27, Robert J. Hansen wrote:
> I may be insisting on usual semantics for "misconfiguration," 
> though.

Okay. So an administrator willingly creates a PMTU blackhole? He *wants*
the people trying to communicate through his firewall to fail on
connections where the PMTU is smaller than the MTU of the networks at
the endpoint? That is, only failing as soon as they send big packets. So
for instance, an SMTP session will correctly authenticate. Both peers
are completely happy. Then, when it's time for the mail to pass, all
suddenly inexplicably falls silent. Hard to debug if you don't know
about PMTU blackholes!

The iptables man page calls it this (TCP MSS clamping target):

> This  target  is  used  to overcome criminally braindead ISPs or 
> servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet
> Too Big" packets.

That is a direct quote, not my words.

But I most bloody emphatically agree. Criminally braindead. Should not
be allowed to touch network equipment. You don't let your the brakes in
your sometimes mentioned sweet car be serviced by the cleaning lady, do
you? In a similar vein, I wished network administration were left to
people who are not criminally braindead.

> I am generally of the opinion that when someone deliberately 
> configures something in a foolish way, well -- that's folly, not a 
> misconfiguration.

I would only agree when the one doing the configuration actually thought
through the consequences. At least the big consequences.

Blocking all ICMP is incredibly stupid.

You might have noticed I feel very strongly about this. I hate meddling
with packets at routers that shouldn't be touching them and completely
violating the layering of the network to deal with f***ing idiots.

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: ICMP

[Robert J. Hansen]

Blocking all ICMP has always been a misconfiguration.


I agree with everything Doug wrote except this.  I may be insisting on 
usual semantics for "misconfiguration," though.  I am generally of the 
opinion that when someone deliberately configures something in a foolish 
way, well -- that's folly, not a misconfiguration.


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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[NdK]

Il 15/08/2014 12:31, Peter Lebbing ha scritto:

> So if you had a smartcard with a lot of storage, you could copy the key
> material of your old keys, taken from your secure backup, to the card
> and keep on using a card to work with the keys.
That's what I was doing with MyPGPid: a 144k Javacard can host the
applet and many keys.
The "trick" is that it accepts the standard OpenPGPCard commands, plus
some extended commands to handle extra keys (like selecting current
enc/dec key, or safely export keys only towards user-certified devices).
This way you only need the standard GnuPG plus an helper program (can be
a simple script using opensc) if/when you need the extra functions.

BYtE,
 Diego.

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

Re: ICMP (was: Re: keys.gnupg.net - Refresh all public keys never completes in) Enigmail, some servers down?

[Doug Barton]

On Aug 15, 2014, at 8:46 AM, Aaron Toponce  wrote:

> On Thu, Aug 14, 2014 at 05:13:08PM +0100, OmegaPhil wrote:
>> Fair point, although that would be a network misconfiguration as
>> ping/ICMP is required for network troubleshooting, packet fragmentation
>> stuff etc (for reference I'm testing from a dedicated line that I control).
> 
> Blocking ICMP is not a network misconfiguration at all. ICMP echo requests are
> intentionally blocked to prevent a number of ICMP-related attacks:
> 
>* ICMP floods
>* ICMP nukes
>* ICMP smurfs
>* ICMP "ping of death"
> 
> Also, most Cisco routers do not put priority on ICMP packets. It's very common
> for Cisco to drop ICMP while processing other protocols on very busy networks.
> 
> The best way to troubleshoot a problem to a network server, is to use the
> protocol you're having issues with, check BGP routes, ARP entries, DNS, etc.
> While ping(1) is certainly a great tool to have, it should be only one of the
> many tools in your network troubleshooting toolbox.

Blocking all ICMP has always been a misconfiguration. As “OmegaPhil” pointed 
out there are several types of ICMPv4 that are required for the proper 
operation of the network. The most important is PMTUD, but there are others 
that are also important, and are not DOS vectors (and never have been). 

In IPv6 ICMP is required, period. There is no RFC-compliant configuration with 
ICMP disabled, and disabling it will severely break your network. Of course a 
lot more thought has gone into not building the DOS vectors into the protocol 
design in the first place, so it’s a very different animal. :)

Of course this is wildly off-topic, and I apologize if anyone is unappreciative 
of my little rant. But the whole “we must block ICMP, for the security!” thing 
has been a sore point for me going on 20 years now. 

Doug


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

Re: ICMP

[Robert J. Hansen]

Blocking ICMP is not a network misconfiguration at all.


Whether it's a misconfiguration depends entirely on whether the
administrator intends this behavior.

It *is*, however, non-RFC-compliant.  Not that I think this matters much.

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

ICMP (was: Re: keys.gnupg.net - Refresh all public keys never completes in) Enigmail, some servers down?

[Aaron Toponce]

On Thu, Aug 14, 2014 at 05:13:08PM +0100, OmegaPhil wrote:
> Fair point, although that would be a network misconfiguration as
> ping/ICMP is required for network troubleshooting, packet fragmentation
> stuff etc (for reference I'm testing from a dedicated line that I control).

Blocking ICMP is not a network misconfiguration at all. ICMP echo requests are
intentionally blocked to prevent a number of ICMP-related attacks:

* ICMP floods
* ICMP nukes
* ICMP smurfs
* ICMP "ping of death"

Also, most Cisco routers do not put priority on ICMP packets. It's very common
for Cisco to drop ICMP while processing other protocols on very busy networks.

The best way to troubleshoot a problem to a network server, is to use the
protocol you're having issues with, check BGP routes, ARP entries, DNS, etc.
While ping(1) is certainly a great tool to have, it should be only one of the
many tools in your network troubleshooting toolbox.

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


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

Why does Enigmail keep asking for a passphrase for a secret key?

[J. Tinsby]

Hello,

I hope the group gets this message/question I am not used to using email 
groups, so correct me if I am making a mistake please.

I have GPG4 Win installed on Win 7 with Thunderbird and Enigmail. Lately I get 
a message asking for " a passphrase to unlock a secret key" ( not to decrypt a 
message ) when I type in the phrase for the secret key it tells me it's not 
correct. I have no phrase other than the one I use for that key since it was 
created 12 years ago. I'm not sure what phrase it's looking for, repeated 
attempts fail and I had to remove and reinstall GPG4Win to solve the message 
problem but I'm sure it will return.

What phrase is the program asking for?

I have used PGP for years and it never asked me for another phrase other than 
the one that I use to decrypt a message, so this is confusing to me.

Thank you,

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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[Peter Lebbing]

On 15/08/14 13:10, Andreas Schwier wrote:
> I'd recommend it the other way around: Generate your keys on a smart
> card and have it securely exported into your backup.

> [...]

> So what is that assumption based on ? If you are using a hardware device
> that is certified as Secure Signature Creation Device under the Common
> Criteria scheme, then the quality of the random number generation is an
> important criteria in the evaluation (see for example AIS31 under the
> German CC scheme on the BSI website).

Please note I was specifically talking about the OpenPGP card as it is
now, not about smartcards or HSMs in general.

Obviously an HSM *can* have a really great hardware RNG. But they are
complex devices.

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: what is "correct" for users' Preferred keyserver ?

[MichaelQuigley]

"Gnupg-users"  wrote on 08/14/2014 02:19:20 
PM:
> - Message from David Shaw  on Thu, 14 Aug
> 2014 07:47:36 -0400 -
> 
> 
> Subject:
> 
> Re: what is "correct" for users' Preferred keyserver ?
> 
  .  .  .
  .  .  .
  .  .  .
> 
> Perhaps the problem here is not the option, but the behavior on 
> failure.  If querying the preferred keyserver does not return a 
> response during a refresh (for whatever reason), maybe GPG should 
> continue on and try to get the key from the standard --keyserver 
location.
> 
> After all, it's a "preferred" keyserver.  Not an "exclusive" keyserver.
> 
> David
> 

How about triggering a prompt to ask the user if they want to try the 
standard --keyserver location?

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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[Andreas Schwier]

On 08/15/2014 12:31 PM, Peter Lebbing wrote:
> On 15/08/14 09:57, NdK wrote:
>> Currently you have to generate your encryption key on the PC and copy it
>> to the card. So you have a copy to reuse.
> 
> I don't think you *have* to, but it is certainly something I'd
> recommend. If the only existing copy is on one smartcard[1], and that
> smartcard breaks... for signature keys, not a problem at all. For
> primary keys pretty inconvenient. For encryption keys... data loss of
> all your encrypted data: huge.
> 
> But you choose a smartcard for the properties that make it different
> than an on-disk key. If you then start keeping all your previous,
> expired encryption subkeys as on-disk keys, you defeat the purpose to a
> large extent.
> 
> So if you had a smartcard with a lot of storage, you could copy the key
> material of your old keys, taken from your secure backup, to the card
> and keep on using a card to work with the keys.
I'd recommend it the other way around: Generate your keys on a smart
card and have it securely exported into your backup. We do that with the
SmartCard-HSM using the Device Key Encryption Key (DKEK) for export and
import of sensitive material. Because there is a key management
procedure around the DKEK (key shares, n-of-m threshold scheme) you can
backup the encrypted keys wherever you find convenient.

Restoring your keys starts with establishing a new smart card with the
same DKEK and then import required key material into it.
> 
> Hope that clarifies it,
> 
> Peter.
> 
> [1] Additionally, for on-card generated keys, the built-in hardware
> random number generator is used as the only source of randomness. I've
> understood that the quality of that RNG isn't up to par with GnuPG on a PC.
So what is that assumption based on ? If you are using a hardware device
that is certified as Secure Signature Creation Device under the Common
Criteria scheme, then the quality of the random number generation is an
important criteria in the evaluation (see for example AIS31 under the
German CC scheme on the BSI website).

> 


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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[Peter Lebbing]

On 15/08/14 09:57, NdK wrote:
> Currently you have to generate your encryption key on the PC and copy it
> to the card. So you have a copy to reuse.

I don't think you *have* to, but it is certainly something I'd
recommend. If the only existing copy is on one smartcard[1], and that
smartcard breaks... for signature keys, not a problem at all. For
primary keys pretty inconvenient. For encryption keys... data loss of
all your encrypted data: huge.

But you choose a smartcard for the properties that make it different
than an on-disk key. If you then start keeping all your previous,
expired encryption subkeys as on-disk keys, you defeat the purpose to a
large extent.

So if you had a smartcard with a lot of storage, you could copy the key
material of your old keys, taken from your secure backup, to the card
and keep on using a card to work with the keys.

Hope that clarifies it,

Peter.

[1] Additionally, for on-card generated keys, the built-in hardware
random number generator is used as the only source of randomness. I've
understood that the quality of that RNG isn't up to par with GnuPG on a PC.

-- 
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: keys.gnupg.net - Refresh all public keys never completes in Enigmail, some servers down?

[OmegaPhil]

On 13/08/14 22:13, Kristian Fiskerstrand wrote:
> On 08/12/2014 09:21 PM, OmegaPhil wrote:
>> Please CC me in etc, I'm not subscribed to the list.
> 
>> Haven't been able to 'refresh all public keys' on keys.gnupg.net
>> in Enigmail for a while now (only have two keys), so I had a look
>> at the servers responsible (host keys.gnupg.net) - the following
>> appear to be bad for me accessing from the UK:
> 
>> 131.155.141.70: No response to pings 63.230.134.161: Destination
>> Host Unreachable 173.175.198.28: No response to pings
> 
> Using ping is not a reliable way to check availability, the icmp
> protocol is often blocked by the firewall, you should do a HTTP get
> request.
> 
> As for your issues, try using --keyserver
> hkp://p80.pool.sks-keyservers.net:80 to rule out any firewall blocking
> 11371 etc.

Fair point, although that would be a network misconfiguration as
ping/ICMP is required for network troubleshooting, packet fragmentation
stuff etc (for reference I'm testing from a dedicated line that I control).

I can confirm that all hosts at least appear to respond (i.e. not stall
gpg), when queried direct, but a number don't seem to be maintaining the
same pool of keys:

gpgkeys: key 7977070A723C6CCB696C0B0227A5AC5A01937621
gpgkeys: key E76095ECDACD5DEC7653A99617D23C7DFDC2F38F

Cant be retrieved hosts:

hkp://144.76.120.109:80
hkp://194.97.110.154:80
hkp://213.206.252.51:80

Not found on keyserver hosts:

hkp://46.38.236.74:80
hkp://178.63.21.4:80
hkp://109.239.48.152:80


hkp://109.239.48.152:80 was particularly bad:

=

gpg: refreshing 2 keys from hkp://109.239.48.152:80
gpg: requesting key 01937621 from hkp server 109.239.48.152
gpg: requesting key FDC2F38F from hkp server 109.239.48.152
gpg: packet(2) with unknown version 71
gpg: read_block: read error: invalid packet
gpg: Total number processed: 0
gpg: no valid OpenPGP data found.
gpgkeys: key 7977070A723C6CCB696C0B0227A5AC5A01937621 not found on keyserver
gpgkeys: key E76095ECDACD5DEC7653A99617D23C7DFDC2F38F not found on keyserver

=

The stalling I guess is an Enigmail screwup (more commandline experience
for me is fine ;))



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

Re: keys.gnupg.net - Refresh all public keys never completes in Enigmail, some servers down?

[OmegaPhil]

On 14/08/14 19:19, Kristian Fiskerstrand wrote:
> On 08/14/2014 06:13 PM, OmegaPhil wrote:
>> On 13/08/14 22:13, Kristian Fiskerstrand wrote:
>>> On 08/12/2014 09:21 PM, OmegaPhil wrote:
 Please CC me in etc, I'm not subscribed to the list.
>>>
>>>
> 
> ...
> 
> 
>> gpgkeys: key 7977070A723C6CCB696C0B0227A5AC5A01937621 gpgkeys: key
>> E76095ECDACD5DEC7653A99617D23C7DFDC2F38F
> 
>> Cant be retrieved hosts:
> 
>> hkp://144.76.120.109:80 hkp://194.97.110.154:80
>> hkp://213.206.252.51:80
> 
>> Not found on keyserver hosts:
> 
>> hkp://46.38.236.74:80
> 
> pgpkey.org is not listed with port 80 support and part of that pool,
> so it is only included in the main pool on port 11371
> 
> https://sks-keyservers.net/status/info/pgpkey.org
> 
>> hkp://178.63.21.4:80
> 
> curl --resolve "p80.pool.sks-keyservers.net:178.63.21.4:80"
> "http://p80.pool.sks-keyservers.net:80/pks/lookup?op=get&options=mr&search=0x7977070A723C6CCB696C0B0227A5AC5A01937621";
> 
> Key is found, but server has not configured the reverse proxy to
> respond on IP only on port 80, but needs to be part of the pool as
> Host header
> 
>> hkp://109.239.48.152:80
> 
> Not part of p80 subpool:
> https://sks-keyservers.net/status/info/pgp.freiwuppertal.de same as
> 1st one


Thanks for all your help - sounds overly complicated so clearly I'm not
going to be able to go further here. Assuming the servers work, I ran
the gpg query and then triggered the same thing in Enigmail while
running wireshark listening for HTTP traffic - gpg clearly showed up,
whilst Enigmail did nothing!!!

So it was Enigmail all along... I will post a bug now.

Thanks again.



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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[Andreas Schwier]

The SmartCard-HSM allows you to store as many RSA/ECC keys as memory can
hold. And we are splitting management of keys from application data, so
that you can store keys for any application on the same device.

So far this works for gpgsm / PKCS#11 / Minidriver / Java / Android,
however you can't have your gnupg keys on a SmartCard-HSM yet.

We'd love to implement that support, however currently the code in gnupg
supports only cards conforming to the OpenPGP card spec (which we feel
is too restrictive for a general key storing device).

Andreas

On 08/15/2014 09:57 AM, NdK wrote:
> Il 15/08/2014 02:18, Peter Lebbing ha scritto:
> 
>> The problem is expiring a encryption-capable subkey on an OpenPGP
>> smartcard, replacing it with a new one.
>> Currently, the OpenPGP smartcard only allows a single
>> en-/decryption-capable key.
> That's exactly why I started MyPGPid project. Too bad I've had no time
> to develop it further :(
> Hope I'll be able to return on it soon... Unless another (paid) project
> steps in...
> 
>> Suppose after some time I decide an old key has seen it's useful
>> lifetime. I'd like to create a new encryption-capable key. However, I
>> definitely need to keep the old key, or I won't be able to see anything
>> encrypted to me in the past.
> Currently you have to generate your encryption key on the PC and copy it
> to the card. So you have a copy to reuse.
> Or just use multiple cards 
> 
>> The current OpenPGP smart card restricts me to a single key for
>> encryption, a single key for signatures, and a single key for
>> authentication. If it were possible to tell the card, on uploading the
>> key, what that key's usage will be, I would be able to have a separate
>> smartcard that decrypted the 3 OpenPGP subkeys I used for encryption
>> previously. This instead of being forced to use 3 separate smartcards. I
>> get the impression this is a relatively small change to the firmware of
>> the smartcard, but a larger change to the software running on the PC.
> On a 144K javacard, IIRC, I've been able to store 13 RSA-2048 encryption
> keys. Plus master, signature and two auth keys (one reserved for
> contactless auth).
> 
> 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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[NdK]

Il 15/08/2014 02:18, Peter Lebbing ha scritto:

> The problem is expiring a encryption-capable subkey on an OpenPGP
> smartcard, replacing it with a new one.
> Currently, the OpenPGP smartcard only allows a single
> en-/decryption-capable key.
That's exactly why I started MyPGPid project. Too bad I've had no time
to develop it further :(
Hope I'll be able to return on it soon... Unless another (paid) project
steps in...

> Suppose after some time I decide an old key has seen it's useful
> lifetime. I'd like to create a new encryption-capable key. However, I
> definitely need to keep the old key, or I won't be able to see anything
> encrypted to me in the past.
Currently you have to generate your encryption key on the PC and copy it
to the card. So you have a copy to reuse.
Or just use multiple cards 

> The current OpenPGP smart card restricts me to a single key for
> encryption, a single key for signatures, and a single key for
> authentication. If it were possible to tell the card, on uploading the
> key, what that key's usage will be, I would be able to have a separate
> smartcard that decrypted the 3 OpenPGP subkeys I used for encryption
> previously. This instead of being forced to use 3 separate smartcards. I
> get the impression this is a relatively small change to the firmware of
> the smartcard, but a larger change to the software running on the PC.
On a 144K javacard, IIRC, I've been able to store 13 RSA-2048 encryption
keys. Plus master, signature and two auth keys (one reserved for
contactless auth).

BYtE,
 Diego

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