Re: Smartcard working completely with GPG2 and incompletely with GPG1.4

[NIIBE Yutaka]

Hello,

Thank you for your report in detail.

chris.p...@gmx.de wrote:
> The commands gpg --card-status and gpg2 --card-status seem to display
> mainly the same things, the only strange line is "Key Attributes" at
> GPG 1.4:

gpg 1.4 can use gpg-agent by the option use-agent.  I think that you
enable this option in .gnupg/gpg.conf.

Yes, gpg 1.4 can be used with the gpg-agent of GnuPG 2.0, this usage is
supported well.

scdaemon in GnuPG 2.1 has been enhanced to support ECC, and the particular
protocol of KEY-ATTR has been changed.  This is the cause of the issue.

While I'm sure scdaemon 2.1 doesn't work well with gpg 1.4 by protocol
incompatibility, I'm not sure how gpg 1.4 can be used with the gpg-agent
of 2.1, in general.  In my opinion, I don't think this usage is
well supported in the current development of GnuPG.

Let us see.

Are there any reason why the combination of gpg 1.4 and gpg-agent 2.1 is
useful?
-- 

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

Re: gnupg website

[Glenn Rempe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I would also like to note that gnupg.org does not appear to work on
the latest versions of Apple iOS or macOS  Safari due to TLS cert
issues. It fails to load in Safari on either platform (but Chrome and
Firefox do work on macOS, Safari is the only browser on iOS).

I believe this may be due to Apple's App Transport Security (ATS)
rules. You can find an overview of those rules and a link to more
details here:

http://stackoverflow.com/questions/31231696/ios-9-ats-ssl-error-with-sup
porting-server

It seems that iOS/macOS cannot negotiate a strong connection with TLS
1.2 and one of the allowed cipher suites using forward secrecy when
talking to gnupg.org.

The accepted TLS 1.2 ciphers for Apple ATS are:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

And gnupg.org only provides:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 2048 bits   FS 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 2048 bits   FS 256
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112

As you can see, there appears to be no overlap with the suites that
ATS expects for a strong connection and those that gnupg.org offers.

For comparison sake, here are the cipher suites that cloudflare
advertises with its CDN services:

Preferred TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve P-256
DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256 Curve P-256
DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHACurve P-256
DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve P-256
DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384 Curve P-256
DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHACurve P-256
DHE 256

Here is the full list of TLS suites that I used to compare:

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls
- -parameters-4

SSLlabs tests for gnupg.org seem to show that it cannot negotiate a
connection with forward security with gnupg.org which is a requirement
for ATS.

https://www.ssllabs.com/ssltest/analyze.html?d=gnupg.org&s=217.69.76.60

Every load of gnupg.org in Safari results in a total failure to load
anything. Running one of the suggested diagnostics shows the following
error:

*
$ nscurl --ats-diagnostics https://gnupg.org
Starting ATS Diagnostics

...
Default ATS Secure Connection
- ---
ATS Default Connection
2017-01-25 16:13:17.674 nscurl[38742:199753]
NSURLSession/NSURLConnection HTTP load failed
(kCFStreamErrorDomainSSL, -9824)
Result : FAIL
- ---
*

The error is also showing in the system console application with an
entry such as:

NSURLSession/NSURLConnection HTTP load failed
(kCFStreamErrorDomainSSL, -9824)


While I am not certain it would fix it, it seems that gnupg.org might
be able to fix by changing its config to advertise a more extensive
set of TLS 1.2 suites that support forward secrecy and that match the
supported list provided by Apple over TLS 1.2 connections.

I am happy to test this again after such a change. For now, if my
testing on my own devices is representative you may be shutting out
all iOS users and Safari on macOS users as well from being able to
load your site at all. If others don't see that same behavior I would
be interested to hear that too.

Cheers,

Glenn



On 1/25/17 4:16 PM, Andrew Gallagher wrote:
> On 2017/01/25 21:07, sivmu wrote:
>> Anyways ssllabs shows a warning that the website will be degraded
>>  from A to C in a month. Not sure that matters all that much, but
>> if there is an oppertunity to change the available ciphers at
>> some point...
> 
> I've looked into this and I'm not sure why ssllabs is degrading
> from A- to C. There is a link to the blog post in the results page,
> but the post appears to say that the grade will *not* be reduced. I
> quote:
> 
>> we’ll be modifying our grading criteria to penalise sites that 
>> negotiate 3DES with TLS 1.1 and newer protocols. Such sites will 
>> have their scores capped at C. Sites that continue to support
>> 3DES and keep it at the end of their ordered list of suites will
>> not be affected (for now).
> 
> gnupg.org *does* keep 3DES at the end of the supported suites, so
> surely it should not be affected. I'm tempted to write this off as
> a mistake by ssllabs.
> 
> A
> 
> 
> 
> ___ Gnupg-users mailing
> list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEHYo11lajUTmaOI4vCiVDbdRDnGwFAliJTesACgkQCiVDbdRD
nGyKog//YCy1Vb9qSSB8EeVdRTddIXcFiqjeMbID

Re: gnupg website

[Andrew Gallagher]

On 2017/01/25 21:07, sivmu wrote:
> Anyways ssllabs shows a warning that the website will be degraded 
> from A to C in a month. Not sure that matters all that much, but if 
> there is an oppertunity to change the available ciphers at some 
> point...

I've looked into this and I'm not sure why ssllabs is degrading from A-
to C. There is a link to the blog post in the results page, but the post
appears to say that the grade will *not* be reduced. I quote:

> we’ll be modifying our grading criteria to penalise sites that 
> negotiate 3DES with TLS 1.1 and newer protocols. Such sites will
> have their scores capped at C. Sites that continue to support 3DES
> and keep it at the end of their ordered list of suites will not be 
> affected (for now).

gnupg.org *does* keep 3DES at the end of the supported suites, so surely
it should not be affected. I'm tempted to write this off as a
mistake by ssllabs.

A



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

Re: gnupg website

[Antony Prince]

On 1/25/2017 4:36 PM, sivmu wrote:
> Basically if you can collect a few hundred GB of data, it is trivial to
> calculate the key. There is a prove of concept for https connections,
> although I believe this is especially relevant for VPN connections
> (openvpn uses a 64 bit ciphers (blowfish) by default)
>

Thanks for bringing up the point about OpenVPN. I use it myself. I
already had it set to AES-128-CBC, but I upgraded to the git 2.5 master
version and set it to AES-256-GCM. This is one of the settings they
recommend in their response to the issue [0] since GCM support was added
in 2.4.

[0]https://community.openvpn.net/openvpn/wiki/SWEET32

--
Antony



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

sha1 pgp fingerprint

[sivmu]

I have been wondering for a while about the use of sha1 in pgp fingerprints.

Although sha1 may not be easily broken in practise, there are
theoreticall collosion attacks that are feasible for well funded
organisations.
Cryptographers, like Bruce Schneier, have been recommending for years to
migrate to a new hash algorithm for all sorts of reasons.

New versions of gpg do not use sha1 in any encryption operation if I am
not mistaken. But we still use sha1 fingerprints to compare of our keys.

The question I have not yet found any clear answer for, is why is nobody
talking about this and should pgp keys be identified by a stronger hash
alogrithm in the future?

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

Re: Mail address to account conversion (keybase.io)

[ankostis]

Maybe that's an opportunity to put to use "notations
, and self-sign the keybase-uidusing --cert-notation.

Of course, nobody would care to check that,
but would there be any other issue down this road?

Kind Regards,
  Kostis

On 25 January 2017 at 23:39, Felix Van der Jeugt <
felix.vanderje...@gmail.com> wrote:

> Excerpts from Andrew Gallagher's message of 2017-01-25 18:10:56 +:
> > True, people might try to email you on that ID, but the worst that
> > will happen is they get a bounce (and you have other, usable IDs on
> > the same pubkey I assume).
>
> I indeed do have those, but I'm not sure keybase will bounce. I tried
> mailing myself there earlier (with a third address) and all I got in
> return was silence.
>
> > If the ID still "belongs" to you (in some meaningful sense) then
> > there's no need to revoke it just because it is unusable for the
> > purposes of email. It is merely a convention that IDs correspond to
> > email addresses. If your keybase account still exists, has a 1-to-1
> > mapping with that ID, and is still under your control, then IMO it's
> > legitimate to keep the ID - particularly if it is used as a reference
> > point for other things. The presence of an ID on a public key makes no
> > claim as to whether the ID is usable for a particular purpose.
>
> Thanks for the opinion, I find myself agreeing. I should probably stop
> collecting signs on that uid on keysigning parties, though, I shouldn't
> bother people with sending signed keys an unconventional (and manual)
> method.
>
> Sincerely,
> Felix
>
>
> ___
> 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: Mail address to account conversion (keybase.io)

[Felix Van der Jeugt]

Excerpts from Andrew Gallagher's message of 2017-01-25 18:10:56 +:
> True, people might try to email you on that ID, but the worst that
> will happen is they get a bounce (and you have other, usable IDs on
> the same pubkey I assume).

I indeed do have those, but I'm not sure keybase will bounce. I tried
mailing myself there earlier (with a third address) and all I got in
return was silence.

> If the ID still "belongs" to you (in some meaningful sense) then
> there's no need to revoke it just because it is unusable for the
> purposes of email. It is merely a convention that IDs correspond to
> email addresses. If your keybase account still exists, has a 1-to-1
> mapping with that ID, and is still under your control, then IMO it's
> legitimate to keep the ID - particularly if it is used as a reference
> point for other things. The presence of an ID on a public key makes no
> claim as to whether the ID is usable for a particular purpose.

Thanks for the opinion, I find myself agreeing. I should probably stop
collecting signs on that uid on keysigning parties, though, I shouldn't
bother people with sending signed keys an unconventional (and manual)
method.

Sincerely,
Felix



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

RE: gnupg website

[Robert J. Hansen]

> There are prove of concepts against TLS and openvpn https://sweet32.info/

Sure, but those proofs-of-concept require *hundreds of GB of traffic*.

That's the sort of thing that causes a lot of crypto nerds to twitch and
mutter "rekey, rekey".



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

Re: Mail address to account conversion (keybase.io)

[Felix Van der Jeugt]

Excerpts from Christian Heinrich's message of 2017-01-26 09:19:42 +1100:
> On Thu, Jan 26, 2017 at 1:51 AM, Felix Van der Jeugt
>  wrote:
> > Recently, keybase.io stopped their email forwarding service. Now, my
> > noc...@keybase.io uid can no longer receive email. I'd normally revoke
> > the uid, but my account, keybase.io/noctua, can still receive messages
> > through the website.
> 
> Is this for their private key that keybase.io generates on your behalf
> when you sign up?

No, this is for my own PGP key of which I uploaded the public key to
them. I just added a uid with the keybase email to my key.

Sincerely,
Felix



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

Re: Mail address to account conversion (keybase.io)

[Christian Heinrich]

Felix,

On Thu, Jan 26, 2017 at 1:51 AM, Felix Van der Jeugt
 wrote:
> Recently, keybase.io stopped their email forwarding service. Now, my
> noc...@keybase.io uid can no longer receive email. I'd normally revoke
> the uid, but my account, keybase.io/noctua, can still receive messages
> through the website.

Is this for their private key that keybase.io generates on your behalf
when you sign up?


-- 
Regards,
Christian Heinrich

http://cmlh.id.au/contact

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

Re: gnupg website

[sivmu]

Am 25.01.2017 um 23:00 schrieb Robert J. Hansen:
>> The main problem would be its 64-bit block size. Apparently there's a
>> "practical" attack against 64-bit ciphers as used in TLS [1].
> 
> Quoting from the abstract:  "In our proof-of-concept demos, the attacker 
> needs to capture about 785GB of data."  I question the wisdom of any system 
> which sends 785Gb of data without ever rekeying.
> 
> This attack seems to fall into the realm of "stupid SSL mistakes lead to 
> exploitation. "
> 

There are prove of concepts against TLS and openvpn https://sweet32.info/

It is not quite that simple I think.

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

RE: gnupg website

[Robert J. Hansen]

> The main problem would be its 64-bit block size. Apparently there's a
> "practical" attack against 64-bit ciphers as used in TLS [1].

Quoting from the abstract:  "In our proof-of-concept demos, the attacker needs 
to capture about 785GB of data."  I question the wisdom of any system which 
sends 785Gb of data without ever rekeying.

This attack seems to fall into the realm of "stupid SSL mistakes lead to 
exploitation. "



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

Re: gnupg website

[sivmu]

Am 25.01.2017 um 22:25 schrieb Damien Goutte-Gattat:
> On 01/25/2017 02:41 PM, Robert J. Hansen wrote:
>> For that matter, I'm still in the dark as to what the big problem with
>> three-key 3DES is.  The best attack against it requires more RAM than
>> exists in the entire world and only reduces it to 112 bits.
> 
> The main problem would be its 64-bit block size. Apparently there's a
> "practical" attack against 64-bit ciphers as used in TLS [1].
> 
> That's probably reason enough to avoid 3DES whenever possible (when a
> 128-bit cipher is available).
> 
> [1] https://eprint.iacr.org/2016/798
> 

That would be the sweet32 attack https://sweet32.info/

Basically if you can collect a few hundred GB of data, it is trivial to
calculate the key. There is a prove of concept for https connections,
although I believe this is especially relevant for VPN connections
(openvpn uses a 64 bit ciphers (blowfish) by default)

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

Re: gnupg website

[Damien Goutte-Gattat]

On 01/25/2017 02:41 PM, Robert J. Hansen wrote:

For that matter, I'm still in the dark as to what the big problem with
three-key 3DES is.  The best attack against it requires more RAM than
exists in the entire world and only reduces it to 112 bits.


The main problem would be its 64-bit block size. Apparently there's a 
"practical" attack against 64-bit ciphers as used in TLS [1].


That's probably reason enough to avoid 3DES whenever possible (when a 
128-bit cipher is available).


[1] https://eprint.iacr.org/2016/798





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

Re: gnupg website

[sivmu]

Am 25.01.2017 um 12:14 schrieb Peter Lebbing:
> On 25/01/17 09:52, Werner Koch wrote:
>> OCSP is used as an alternative to CRLs and not directly related to
>> privacy.
> 
> The OP might have meant "OCSP Stapling" which includes the OCSP data in
> the data sent by the webserver during TLS session setup. That way, the
> OCSP data doesn't need to be fetched from an OCSP server, which would
> leak the fact a certain website certificate is being verified to the
> OCSP server.

Yes that is what I meant, sorry for the confusion.
I think this might be relevant for some people who would prefer not to
trigger unnecessary queries for privacy reasons.

Anyways ssllabs shows a warning that the website will be degraded from A
to C in a month. Not sure that matters all that much, but if there is an
oppertunity to change the available ciphers at some point...


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

Smartcard working completely with GPG2 and incompletely with GPG1.4

[chris . p . 16]

Hello all,

after using GnuPG since 2014 I now purchased a Nitrokey USB smartcard. I set it 
up mainly* following the steps at 
https://wiki.fsfe.org/TechDocs/CardHowtos/CardWithSubkeysUsingBackups with 
GnuPG 2 and tried to configure GnuPG 1.4 to work likewise (on Linux Mint, it's 
installed as well). I'm now running into a strange problem which is a bit like 
https://lists.gnupg.org/pipermail/gnupg-users/2015-September/054345.html , but 
the other way around.

With GnuPG 2, signing, encrypting and decrypting a file works without any 
problems. With 1.4, I can encrypt and sign a file, but I can't decrypt it. It's 
failing with the message:

gpg: public key decryption failed: general error
gpg: decryption failed: secret key not available

The commands gpg --card-status and gpg2 --card-status seem to display mainly 
the same things, the only strange line is "Key Attributes" at GPG 1.4:

$ gpg --card-status
Application ID ...: 
Version ..: 2.1
Manufacturer .: ZeitControl
Serial number : 
Name of cardholder: Christoph Pxxx
Language prefs ...: de
Sex ..: male
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : forced
Key attributes ...: 0R 0R 0R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 10
Signature key : D2F4 E619 8D05 9E98 AD58  7E6E 9965 610B 43F2 7C98
  created : 2017-01-24 17:52:18
Encryption key: 4AD3 7EE7 6418 CABE 4026  923E D82A 7A84 3A07 266F
  created : 2014-04-12 10:52:41
Authentication key: [none]
General key info..: pub  4096R/43F27C98 2017-01-24 Christoph Pxxx 

sec#  4096R/E728903D  created: 2014-04-12  expires: never 
ssb>  4096R/3A07266F  created: 2014-04-12  expires: never 
  card-no: 0005 5031
ssb>  4096R/43F27C98  created: 2017-01-24  expires: never 
  card-no: 0005 5031


$ gpg2 --card-status
Reader ...: 
Application ID ...: 
Version ..: 2.1
Manufacturer .: ZeitControl
Serial number : 
Name of cardholder: Christoph Pxxx
Language prefs ...: de
Sex ..: male
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : forced
Key attributes ...: rsa4096 rsa4096 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 10
Signature key : D2F4 E619 8D05 9E98 AD58  7E6E 9965 610B 43F2 7C98
  created : 2017-01-24 17:52:18
Encryption key: 4AD3 7EE7 6418 CABE 4026  923E D82A 7A84 3A07 266F
  created : 2014-04-12 10:52:41
Authentication key: [none]
General key info..: sub  rsa4096/43F27C98 2017-01-24 Christoph Pxxx 

sec#  rsa4096/E728903D  created: 2014-04-12  expires: never 
ssb>  rsa4096/3A07266F  created: 2014-04-12  expires: never 
card-no: 0005 5031
ssb>  rsa4096/43F27C98  created: 2017-01-24  expires: never 
card-no: 0005 5031

I also set up a logfile for scdaemon as in the mentioned thread ("verbose", 
"debug ipc, cardio" in ~/.gnupg/scdaemon.conf). At encryption, there doesn't 
seem to be much difference. At decryption however, when using GnuPG 1.4 the new 
lines in scdaemon are

2017-01-25 19:54:15 scdaemon[8806] DBG: chan_5 <- SERIALNO openpgp
2017-01-25 19:54:15 scdaemon[8806] DBG: chan_5 -> S SERIALNO 
 0
2017-01-25 19:54:15 scdaemon[8806] DBG: chan_5 -> OK
2017-01-25 19:54:15 scdaemon[8806] DBG: chan_5 <- RESTART
2017-01-25 19:54:15 scdaemon[8806] DBG: chan_5 -> OK

while using GnuPG 2.1 leads to 26 lines consisting of the decryption 
information. Instead of "SERIALNO openpgp" it's just "SERIALNO" there.

The output of 'gpg-connect-agent "KEYINFO --list" /bye' is

S KEYINFO 4C4D4CBB69450D70DAECB0929B4E57E00D96A270 T 
 OPENPGP.2 - - - - -
S KEYINFO 259BD34A8AFCFDE34C08C637086496C890AF3640 D - - - P - - -
S KEYINFO 6BB6690E54C14D959135BBFEA6665F2E8A04231C T 
 OPENPGP.1 - - - - -
OK

– I don't have an authentication subkey.

I know this is much information, but as all of this was asked for in the thread 
mentioned above, I thought it'd be better providing you with all of these 
outputs now than sending them one at a time later. I hope you have an idea why 
this strange problem occurs.

Regards,

Chris

P. S.: I'm sure you've noticed that, but anyway: Every "" sequence is not 
taken from the original output, but changed for anonymity reasons.

*: I used my existing RSA keypair, generated a signing subkey and put this 
subkey and the already existing encryption subkey on the card. So, no DSA & 
Elgamal. I also didn't follow the steps after "Ready to go" as I don't have 
more than one encryption subkey.

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

Re: Mail address to account conversion (keybase.io)

[Andrew Gallagher]

On 25/01/17 14:51, Felix Van der Jeugt wrote:
> Dear all,
> 
> Recently, keybase.io stopped their email forwarding service. Now, my
> noc...@keybase.io uid can no longer receive email. I'd normally revoke
> the uid, but my account, keybase.io/noctua, can still receive messages
> through the website.
> 
> I'm in a dilemma now: should I revoke the uid because the email address
> is invalid? It's nice to have a reference to the account in my key,
> though.

If the ID still "belongs" to you (in some meaningful sense) then
there's no need to revoke it just because it is unusable for the
purposes of email. It is merely a convention that IDs correspond to
email addresses. If your keybase account still exists, has a 1-to-1
mapping with that ID, and is still under your control, then IMO it's
legitimate to keep the ID - particularly if it is used as a reference
point for other things. The presence of an ID on a public key makes no
claim as to whether the ID is usable for a particular purpose. True,
people might try to email you on that ID, but the worst that will
happen is they get a bounce (and you have other, usable IDs on the same
pubkey I assume).

Andrew.



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

Mail address to account conversion (keybase.io)

[Felix Van der Jeugt]

Dear all,

Recently, keybase.io stopped their email forwarding service. Now, my
noc...@keybase.io uid can no longer receive email. I'd normally revoke
the uid, but my account, keybase.io/noctua, can still receive messages
through the website.

I'm in a dilemma now: should I revoke the uid because the email address
is invalid? It's nice to have a reference to the account in my key,
though.

Any advice on this would be welcome.

Sincerely,
Felix


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

Re: gnupg website

[Robert J. Hansen]

> This whole banning of SHA-1 and 3DES for public https servers and in
> particular ssllabs' new grades is mostly security theater.

For that matter, I'm still in the dark as to what the big problem with
three-key 3DES is.  The best attack against it requires more RAM than
exists in the entire world and only reduces it to 112 bits.

3DES is slow, ungainly, and has been largely replaced by better
ciphers... but *unsafe*?

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

Re: gnupg website

[Peter Lebbing]

On 25/01/17 09:52, Werner Koch wrote:
> OCSP is used as an alternative to CRLs and not directly related to
> privacy.

The OP might have meant "OCSP Stapling" which includes the OCSP data in
the data sent by the webserver during TLS session setup. That way, the
OCSP data doesn't need to be fetched from an OCSP server, which would
leak the fact a certain website certificate is being verified to the
OCSP server.

OCSP (without stapling) is already possible for the gnupg.org website
certificate:

> Authority Information Access (not critical):
> Access Method: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers)
> Access Location URI: 
> http://crt.usertrust.com/GandiStandardSSLCA2.crt
> Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp)
> Access Location URI: http://ocsp.usertrust.com

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: gnupg website

[Andrew Gallagher]

> On 25 Jan 2017, at 08:52, Werner Koch  wrote:
> 
> On Wed, 25 Jan 2017 01:05, si...@web.de said:
> 
>> not sure this is the perfect place, but I wanted to point out that the
>> gnupg.org website still uses sha1 as a mac.
> 
> Despite that SHA-1 is not yet broken they now even claims that HMAC-SHA1
> is broken?  I do not even known a theoretical attack on HMAC-MD5

Browsers are not deprecating HMAC-SHA-1, but the use of SHA-1 in certificate 
signature generation. These are not the same thing. 

gnupg.org's own cert uses SHA-256 and it's intermediate uses SHA-364. Nothing 
to see here, move along. :-)

Andrew. 

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

Re: gnupg website

[Werner Koch]

On Wed, 25 Jan 2017 01:05, si...@web.de said:

> not sure this is the perfect place, but I wanted to point out that the
> gnupg.org website still uses sha1 as a mac.

Despite that SHA-1 is not yet broken they now even claims that HMAC-SHA1
is broken?  I do not even known a theoretical attack on HMAC-MD5.

This whole banning of SHA-1 and 3DES for public https servers and in
particular ssllabs' new grades is mostly security theater.  Sure, this
helps to raise awareness that we always need to be prepared to replace
algorithms and for that it is a Good Thing.

However, for the Web threat model these algorithms are still fine: To
attack Web sites there are _much_ easier ways than to break SHA-1 or to
inject JS to generate incredible large amounts of traffic to reach the
limit of 64 bit block ciphers.  Let alone the contradiction of sending
Javascript to the client and claiming security of the user/client.

This reminds me of the proverbial barbed wire equipped gate protected by
a bunch of gunmen and 5 miles of a 2 feet high latticework fence.  Guess
where the thieves will enter the property.

> Also, activating OCSP to increase privacy might be a good idea too.

OCSP is used as an alternative to CRLs and not directly related to
privacy.  On a CA break the next update of your browser will put the A
onto its internal blacklist anyway.  When the server key is compromised
OCSP does not help at all

> Thanks for your work on open source encryption.

:-)


Shalom-Salam,

   Werner

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


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

Re: Changing passphrase parameters (s2k options)

[Werner Koch]

On Mon, 23 Jan 2017 13:34, pe...@digitalbrains.com said:

> (FWIW, I don't think you can currently do either. Possibly you can
> change the s2k-count via the agent protocol, but that might not pertain

No, that is not possible.  Right now the agent always uses AES and S2K
paremeters which require on the running machine about 100ms for
decryption.


Salam-Shalom,

   Werner

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


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