Re: How U2F works

[Glenn Rempe]

Just chiming in here with some comments below. I am an active U2F user
and have played around with the server API's and read some of the
specs. Just to be clear, not an expert on U2F.

On 2/27/17 3:28 PM, NIIBE Yutaka wrote:
> Hello,
> 
> Let me ask a question about U2F.  Or, more generally, possibility
> to enhance GnuPG for web authentication.
> 

> Anyhow, it would be possible for Gnuk to add U2F support (somehow 
> limited, because of available resource on board).  Also, it would
> be possible for scdaemon (or other application) to emulate U2F
> protocol (just like Scute does emulate PKCS#11).
> 
> Well, I have two concerns for U2F.
> 
> (1) Atterstation key
> 
> In the document of U2F:
> 
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html#verifying-that-a-u2f-device-is-genuine
>
>  It explains about Atterstation key.
> 
> If it were common for services to do this Atterstation key check,
> U2F emulation or free U2F implementation will be no real use with
> no private key of the vendor.   (It reminds me the old days when
> Apache couldn't serve https because no certificate authority issued
> certificate for servers with Apache.)  I wondor if Atterstation key
> check is common or not.

Well, the attestation key would be checked by the server side process
right? And that is optional to check (but perhaps not optional to
send). So you probably would need to ask those that are integrating
U2F as a server auth method. Sending this seems to be a requirement
based on the spec link you sent. Couldn't you get a vendor specific
attestation key in any case for GnuK and use the same key across all
devices?

Yubico describes something about the attestation metadata they use here:

https://developers.yubico.com/U2F/Attestation_and_Metadata/

> 
> 
> (2) JavaScript
> 
> It seems for me that there are special JavaScript(s) to offer
> access API to U2F.  I don't quite understand how it works to the
> physical device.
> 
> I don't like nonfree JavaScript which may interfere user' control.
> 
> Is it easy for free script (as in freedom) to integrate a script
> for U2F access?  Any such example scripts or any such services
> which do so?

I believe that at this point almost all use of U2F is through web
browsers that support talking to the U2F hardware API's directly. Only
Chrome has full support now, and Firefox and Opera are working on it
but are not yet generally available. The web Javascript API's are just
for requesting registration of a token or authentication. So you can't
use U2F in a browser that does not have support for it no matter what
JS you load in your page.

Browser support:

https://www.yubico.com/support/knowledge-base/categories/articles/browsers-support-u2f/

Yubico Demo Code and JS API

https://developers.yubico.com/U2F/Libraries/Using_a_library.html

JS Polyfill

https://github.com/mastahyeti/u2f-api

> 
> Here, my concern is that if it is all for proprietary world, I am 
> reluctant to consider seriously about U2F.

FIDO U2F is based on an openly published standard but only for you to
'read and analyze'. Seems like you have to become a member of the FIDO
alliance to be protected. Its not an Internet RFC.

"FIDO's specifications are public and available for anyone to read and
analyze. But only FIDO Alliance Members benefit from “the promise” to
not assert patent rights against other members’ implementations (see
the FIDO Alliance Membership Agreement for details). Anyone may join
the FIDO Alliance; we encourage even very small companies with a very
low cost to join at the entry level. Members at all levels not only
benefit from the mutual non-assert protection, but also participate
with FIDO Alliance members, activities and developments; Associates
have more limited participation benefits. All are invited to join the
FIDO Alliance and participate."

https://fidoalliance.org/faqs/

> 
> 
> And finally, if web authentication is important, I would like to
> use the infrastructure of GnuPG to manage my own crypto computation
> and my own private keys.  Currently, we can use GnuPG for SSH
> authentication by its ssh-agent emulation.  I would like to extend
> this.

Wouldn't making this work require the browser vendors to support some
kind of 'pluggable local auth' that gnupg would emulate, and not only
support for hardware tokens like Yubikey? I don't know if they support
this broader concept or not.

https://fidoalliance.org/specifications/overview/

What though is the benefit of using gnupg key as the crypto behind the
client auth? Seems like you are more exposed by having a portable gpg
key as opposed to a hardware embedded key. U2F makes it so easy to add
a backup key, and most implementations let you drop and add keys
pretty easily. Just trying to figure out if backing U2F with gpg, if
that is what you are proposing, is worth it?

> 
> Any thoughts?  Thanks in advance.
> 

Cheers.



signature.asc
Description: OpenPGP digital signature

Re: SHA1 collision found

[Glenn Rempe]

If you read the announcement Google never uses the words "completely broken" 
that you attribute to them. I believe that was someone else's characterization.

Mis-attribution and name calling can also be unhelpful.

Google's security team has been the driving force behind two major security 
issues this week alone (SHA1 and Cloudflare) and with SHA1 they made concrete 
something that was only theoretical before. Let's give credit where credit is 
due.

On Feb 24, 2017, 09:27 -0800, Melvin Carvalho , wrote:
>
>
> On 23 February 2017 at 19:24,  wrote:
> > Today was announced that SHA1 is now completely broken
> > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>
> This is nonsense.
>
> Google security team calling sha1 "completely broken" simply means google's 
> security team is completely broken.
>
> Fearmongering like this unhelpful to the open source community.___
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

Awesome! Works perfectly now. Tested on macOS (Sierra) Safari and
current iOS Safari.

Congrats on your A+ at SSLlabs

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

I would suggest you also look at doing HSTS browser preload now that
you have long duration HSTS and a good modern TLS suite. It would
require being applied to sub-domains as well I think which you may or
may not be able to do. You can test (and register for it) here:

https://hstspreload.org/?domain=gnupg.org

Thanks for fixing this issue. Its been bugging me for months. :-)

Glenn

On 1/30/17 9:22 AM, Werner Koch wrote:
> On Mon, 30 Jan 2017 11:56, w...@gnupg.org said:
> 
>> I am working on that.  But please given me a few days.  I want to
>> align
> 
> Time warp: All servers updated.  Sslabs rating is now A+
> (respective A for those without HSTS).  The used pound version is
> can be found at git.gnupg.org.
> 
> Hope that helps the Sierras
> 
> 
> Salam-Shalom,
> 
> Werner
> 
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEHYo11lajUTmaOI4vCiVDbdRDnGwFAliPkEQACgkQCiVDbdRD
nGwLyA/+Nr4ZTY7t3JFsRjoJjmjEz03KuKDiXOY+8KhrzMiUkK+S+uQxZd0/XyU0
Cx+DQnV03UP2egNQiZaF9v4kR07VTigXR+gF0x56xASJVd4lxFOZ24+ngv8xLru1
YK2L9MKjs2qLc5UCYXUrpg6gY0Ey2kr+lOiDotKt7nT6Gmt1K601QyetzkAld19P
ZLM+zkEn2x5MhApA7k5j39tM9lHCPFPgxMeeM7R0UWZCx1AQQ8R+ejNpDQqN9LYD
fzLbo+Vb0K15gZ3MJuc/sUhaYfWtMKI9UpgwGX1iihkKlq52rQ2oLfxgn4NOT3TG
AMwglvNrIEPnADd86CLevRiWsbuiSGAmqJusjNF8R9gloOpoII5t+p6TMFpVonWW
KmBtqizSuPF2d5d8fC0W/j7fYVXfbs6apJ+UM/CyGSY/vZlqTB2V6YwGrjDs1Qex
3A/MRDxfuSfNBG80v9u8QIFwk3OZPNEUhy5bnU8aSb18qP0CTKOkc7R9lrUGTe66
FKJNeeClI8VxHlmybrV6qWtx8u1AqDI3gTSrjVoFmWlZu4/rk5h9jxfBH8tpXTHb
iSXhNUunsZfnv72DVaaLChSWUVuBd7TO/Kw+7jmCpN6J7vsAQlN+PptPQ/d3etVB
ncp6KuoaTcmEoetfjlJRV8viutyZNMGcuychc+B6lAG8K9FzswQ=
=JkIi
-END PGP SIGNATURE-

___
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

Werner,

Is there a plan to take action on this TLS issue the Julien and I have
written about? I believe all Safari and iOS users are excluded from
gnupg.org without action on the TLS setup.

Cheers

On 1/26/17 11:15 AM, Julien Vehent wrote:
> Hello,
> 
> I'm the maintainer of the Server Side TLS guidelines at Mozilla.
> I'm happy to help with the HTTPS setup of gnupg.org in any way I
> can.
> 
> Here's the configuration currently measures by the TLS
> Observatory, along with some recommendations to reach Modern
> level.
> 
> --- Ciphers Evaluation --- prio cipher protocols
> pfs curves 1DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2
> DH,2048bits 2DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2
> DH,2048bits 3DES-CBC3-SHA   TLSv1,TLSv1.1,TLSv1.2 None
>  OCSP Staplingfalse Server Side Ordering true Curves
> Fallback  false
> 
> --- Analyzers --- * Mozilla evaluation: intermediate - for modern
> level: remove ciphersuites DHE-RSA-AES128-SHA, DHE-RSA-AES256-SHA,
> DES-CBC3-SHA - for modern level: consider adding ciphers
> ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384,
> ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305,
> ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256,
> ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA384,
> ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES128-SHA256 - for modern
> level: remove protocols TLSv1, TLSv1.1 - for modern level: consider
> enabling OCSP stapling - for modern level: enable Perfect Forward
> Secrecy with a curve of at least 256bits, don't use DHE - for
> modern level: use a certificate of type ecdsa, not RSA
> 
> Hope this helps, Julien
> 
> On Thu 26.Jan'17 at 10:48:28 -0800, Glenn Rempe wrote:
>> Werner, you (or anyone setting up a web server themselves
>> really) might also find this config generator from Mozilla
>> helpful as a shortcut in creating what is considered a modern web
>> server config for TLS.
>> 
>> https://mozilla.github.io/server-side-tls/ssl-config-generator/
>> 
>> https://wiki.mozilla.org/Security/Server_Side_TLS
>> 
>> This config may not apply to gnupg.org directly since its not
>> clear what web server you are running. In any case it will tell
>> you which suites you are recommended to support for modern(ish)
>> browsers.
>> 
>> I would also note that there is room for improvement regarding
>> the security headers the gnupg.org sends with its content.
>> 
>> https://securityheaders.io/?q=gnupg.org=on
>> 
>> You are using HSTS, which is generally very good, but in this
>> case it forcibly breaks users experience since it requires me to
>> connect with TLS but that is not possible since you are not
>> advertising a TLS suite that shares common ground with my browser
>> (or millions of other potential visitors).
>> 
>> Cheers.
>> 
>> On 1/26/17 3:49 AM, Andrew Gallagher wrote:
>>> On 26/01/17 00:16, Andrew Gallagher wrote:
>>>> 
>>>> 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.
>>> 
>>> I've spoken to ssllabs and it appears that this was an
>>> ambiguity in the wording of their blog post. That means the
>>> downgrade to C next month is legit - not because 3DES is
>>> present, but because 3DES is present *and* GCM is absent.
>>> 
>>> What both this and Glenn's Apple issue have in common is the
>>> lack of ECDHE+GCM suites in the cipher list. I generally use
>>> the following config in Apache:
>>> 
>>> SSLCipherSuite \ "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
>>> EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
>>> EECDH+aRSA+SHA256 \ EECDH EDH+AESGCM EDH+aRSA +3DES 3DES \
>>> !aNULL !eNULL !LOW !EXP !MD5 !KRB5 !PSK !SRP !DSS !SEED !RC4"
>>> 
>>> This uses all HIGH suites in a sensible order but still falls
>>> back to 3DES for XP compatibility. When retiring 3DES this
>>> simplifies to:
>>> 
>>> SSLCipherSuite \ "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
>>> EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
>>> EECDH+aRSA+SHA256 \ EECDH EDH+AESGCM EDH+aRSA !MEDIUM !LOW
>>> !aNULL !eNULL !PSK"
>>> 
>>> Andrew.
>>> 
>>> 
>>> 
>>> ___ 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

Werner, you (or anyone setting up a web server themselves really)
might also find this config generator from Mozilla helpful as a
shortcut in creating what is considered a modern web server config for
TLS.

https://mozilla.github.io/server-side-tls/ssl-config-generator/

https://wiki.mozilla.org/Security/Server_Side_TLS

This config may not apply to gnupg.org directly since its not clear
what web server you are running. In any case it will tell you which
suites you are recommended to support for modern(ish) browsers.

I would also note that there is room for improvement regarding the
security headers the gnupg.org sends with its content.

https://securityheaders.io/?q=gnupg.org=on

You are using HSTS, which is generally very good, but in this case it
forcibly breaks users experience since it requires me to connect with
TLS but that is not possible since you are not advertising a TLS suite
that shares common ground with my browser (or millions of other
potential visitors).

Cheers.

On 1/26/17 3:49 AM, Andrew Gallagher wrote:
> On 26/01/17 00:16, Andrew Gallagher wrote:
>> 
>> 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.
> 
> I've spoken to ssllabs and it appears that this was an ambiguity
> in the wording of their blog post. That means the downgrade to C
> next month is legit - not because 3DES is present, but because 3DES
> is present *and* GCM is absent.
> 
> What both this and Glenn's Apple issue have in common is the lack 
> of ECDHE+GCM suites in the cipher list. I generally use the 
> following config in Apache:
> 
> SSLCipherSuite \ "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
> EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
> EECDH+aRSA+SHA256 \ EECDH EDH+AESGCM EDH+aRSA +3DES 3DES \ !aNULL 
> !eNULL !LOW !EXP !MD5 !KRB5 !PSK !SRP !DSS !SEED !RC4"
> 
> This uses all HIGH suites in a sensible order but still falls back 
> to 3DES for XP compatibility. When retiring 3DES this simplifies 
> to:
> 
> SSLCipherSuite \ "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
> EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
> EECDH+aRSA+SHA256 \ EECDH EDH+AESGCM EDH+aRSA !MEDIUM !LOW !aNULL 
> !eNULL !PSK"
> 
> Andrew.
> 
> 
> 
> ___ Gnupg-users
> mailing list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEHYo11lajUTmaOI4vCiVDbdRDnGwFAliKRHYACgkQCiVDbdRD
nGz5xg/7BITjIZlPTQ3dmTmbFx5/griGFF0gRD7oDelH7Diytqc2moQLJU0DfynZ
JBDlOkLIidzhSYQMR6ce/wzq/McV/fEuHhKsDTxDtSgU0tGe02xwg4MXCopP3OB9
6iO0zw8VwysDz+H4TDvx+/8CqwUeOBk+oRDZybZgH3xgBDVc8YsuWSCQVZJZdDEG
JEnolJeWz+fS28FFkqN+hEcmqOT0Cxo1fRXClM1hOBRCl4BxPrE5WeFYag3YT6/a
Y33GXA6+v+5lcC2il5vQY4Y1Obdn3kYK9E/aRs2gRSmEVX7rQ8lbuPRpz3WVLqFp
sUZ3BEvdXSjWPAG65xKopsaD+PnKpkzIKTcjQLy+3dx08A8l5V4wDSpjd9M86I7c
h32vByUjYq/l5rVztP8ZOkW3tq6ParyVw22VyjJGcj0LlyBnAbgcrCbw2ZsVFFnr
72Q8lfMrK8B+2YHyVz68CM54K29OAsm459OdzCcN8MXUSp33ck2TYoJxhsT+qWR6
1N2y1kb+Noq6ewYktUCwUHwwLLIoOCa3UiF1lMTpziq/rNjz0sIcvpg1ml7GymO7
8/lqxX5OyEMVACXbVQkNtwhVMagih1CWPgwZHCZWiVk/2BS85sYou0kvsxZByW44
0vRWRAbgcMWPw7viD7gVY8SksmqGblJfogKTqD382Wjp/gk1FvM=
=P0Vg
-END PGP SIGNATURE-

___
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=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

Re: Proof for a creation date

[Glenn Rempe]

On 12/5/16 4:11 AM, Bertram Scharpf wrote:
> I might resume it to two possibilities to accomplish the task:
> 
>   - Post a digest to a site where you cannot withdraw it
> ever and where it can be retrieved by everybody. This
> could be a Github issue, on Reddit or Twitter or maybe
> even on the GnuPG mailing list.

Posting on a forum or github issue does not provide immutable and
cryptographically verifiable proof that a digest existed at a specific
point in time. It is very weak from that standpoint.

> 
> The disadvantage is that you are dependent on the
> provider of the site to continue the service and that
> your information can be found there. This could most
> notably become a problem because the post is, in the
> end, an abuse of the forum.

If you use one of the services that implants your digest on the
blockchain it is guaranteed to be immutable once transactions are
layered on top of it (within minutes to hours).

This approach does NOT require the service that originally posted this
digest to continue to exist past that point in time as you can
independently verify either the digest or the merkle tree root digest
that you posted using open source software.

As an example, I wrote a Ruby wrapper for the Tierion API and this Ruby
code does not require Tierion to continue to exist past the point when
you retrieve a receipt (which are the merkle tree root verification
instructions that the code can follow). You can verify that a hash
exists in the merkle tree independently and for as long as the
blockchain exists (or as long as you keep your own independent copy of
it). This also provides consensus from thousands of miner machines as to
the rough time when a transaction containing your digest was submitted
since all transactions contain the hash of the prior transactions.
Changing and earlier hash would also require rebuilding all hashes on
top of it which is considered computationally infeasible. This is
similar to how a chain of git commits work, but distributed with real
monetary value on the line. It usually takes about 10-30 minutes from
when you submit the hash to when it is permanently and immutably
embedded in the blockchain.

Tierion is free to use, but requires you to calculate the merkle tree
proof to verify it later (not hard with open source software that is
available). www.proofofexistence.com directly submits your digest on the
blockchain (no merkle tree, your transaction is not shared with other
digests), so it is a bit easier to prove later, but you need to pay them
in BTC to cover the transaction costs and their costs at the time you
make the API call. I think its a couple of dollars worth of BTC.

See
https://github.com/grempe/tierion
https://tierion.com/docs#blockchain-receipts
http://www.chainpoint.org
https://en.wikipedia.org/wiki/Merkle_tree
https://tierion.com/docs/hashapi
https://www.proofofexistence.com

>   - Let one or more people sign your document and provide
> the signatures yourself.
> 
> The weak point is how to find these people and to make
> them do what you want. The service
>  makes
> signatures in a format that is no longer supported.

Not only does itconult.co.uk provide signatures from a key that is no
longer importable in modern GnuPG, you are also relying on the fact that
their system clock is accurate and can never be changed maliciously or
through error. This is not an assumption you can make. There is also no
immutable storage of the hash only a signature that was claimed to be
made at a certain time. A claim that cannot be verified later since it
is lacking context.



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

Re: Proof for a creation date [GishPuppy]

[Glenn Rempe]

Unfortunately, I think the public key from that service is no longer importable 
in modern GnuPG.

https://gnupg.org/faq/whats-new-in-2.1.html#nopgp2

Trying to import the public key on this page results in no public key being 
imported. Without this the service cannot be used to verify the signature on a 
timestamp report (I reported this to them several years ago. No changes were 
made).  Also, this service is not a very secure source of time. They use their 
own clock. They claim some security by using an incrementing counter and 
publishing signed snapshots to a usenet group.  Bottom line though is this 
service is pretty ancient and requires a lot of trust on your part of the 
administrator.

http://www.itconsult.co.uk/stamper/stampinf.htm

$ gpg2 --verbose --import stamper.asc
gpg: armor header: Version: 2.6.3i
gpg: Total number processed: 3
gpg:     skipped PGP-2 keys: 3

$ gpg2 --version
gpg (GnuPG) 2.1.16

> Bertram Scharpf wrote:
>
> > I want to make evidence that I created a document
> > _before_ a certain point of time.
> >
>
>
> http://www.itconsult.co.uk/stamper.htm
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Proof for a creation date

[Glenn Rempe]

Tierion creates a Merkle tree of incoming hashes and puts the root of the 
Merkle tree on the Bitcoin blockchain which proves that the hash was placed 
there prior to the time embedded in the BTC transaction. You want to use their 
HashAPI.

https://tierion.com/features

Other similar services are:

http://truetimestamp.org
https://proofofexistence.com

These services don't need GnuPG, but nothing to stop you from hashing a signed 
document.

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

Re: PCI DSS compliance

[Glenn Rempe]

I think this is where you want to look into a Hardware Security Module
(HSM) or a solution like Hashicorp's Vault server. The split secret would
be used to initialize either of those solutions (Vault uses split keys to
unseal the server out of the box, and can even encrypt those shares to
several different GPG keys when the root key is created, this way the
shares are never exposed in plaintext form to anyone, not even the original
admin that creates the key)

https://en.wikipedia.org/wiki/Hardware_security_module
https://www.yubico.com/products/yubihsm/
https://www.vaultproject.io

I don't know if any HSM's support hardware based protected GnuPG encryption
or not.

If you want to experiment with a Shamir Secret Sharing key split you can
look at an implementation in Ruby that I have created which also has a
simple command line interface for splitting and recombining secrets.

https://github.com/grempe/tss-rb

In any case I think you would have those trusted admins, with shares of a
private key passphrase, unlock the key in memory at boot time of your
application and this server would be the only one that is capable of
automated decryption using that unlocked private key. They would need to
repeat this process at each reboot or if the process that contains the key
crashes.

I am not aware of GnuPG ever supporting Shamir Secret Sharing style
encryption key splitting. They may exist, I just don't know.

Cheers,

Glenn


On Thu, Nov 10, 2016 at 11:10 AM NdK  wrote:

> Il 10/11/2016 16:24, helices ha scritto:
>
> > Our company must decrypt ~100 files 7x24 in near real time. How can 
> > work - or any reasonable alternative - in such a production environment?
> Wouldn't a smartcard solve (at least partially) the issue?
> Insert it in a pinpad reader and have the PIN shared between two
> administrators. Both are required at system boot to unlock the card. If
> the card gets removed, no single admin can unlock it.
> Sure, an admin could just use it while connected to the server to
> decrypt files (or simply read stored files) but as others said there's
> no way to prevent that if the attacker have physical access to the system.
>
> BYtE,
>  Diego
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Keybase integration with GnuPG?

[Glenn Rempe]

>
>
> > Are there any current plans to integrate Keybase.io into GnuPG at some
> > point in the future?
>
> (ObWarning: I am not a GnuPG developer.)
>
> I think this is unlikely to occur.  Werner's spoken out pretty strongly
> against the keybase.io model, which relies heavily on social media outlets
> like Facebook to provide confidence in an identity.  However, few people in
> the privacy community like or trust Facebook, which makes relying on
> something like keybase.io problematic -- it looks too much like GnuPG is
> encouraging the use of a platform (FB) that it's philosophically opposed
> to.
>

I think you are operating under some assumptions about Keybase that are not
entirely accurate. Contrary to what you state, Keybase.io does not support
Facebook as a proof destination.

https://github.com/keybase/keybase-issues/issues/518

I have a pretty complete Keybase profile if you are interested to see the
services they *do* currently support.  Please note that many of these are
not social networking platforms but also domains, DNS records, and Bitcoin
accounts that I control.

https://keybase.io/grempe


> The counterargument is that keybase.io works just fine with several other
> back-ends which are more respecting of privacy -- and if a user wishes to
> trust FB, why should GnuPG refuse to honor that user's choice?


True. Keybase supports a number of ways to hosts proofs currently. I
imagine they will add more as they mature for those sites that can meet the
requirements for hosting a proof that is public and can only be controlled
by a single user. This not only allows you to find public keys for a
person, but to authenticate that a person who claims to control the account
on site A is provably the same person who claims to control an account on
site B or a certain GPG key.

You can also host proofs on your own domain as a static signed file or as a
DNS record. Here is an example where I demonstrate that I control my
personal website:

https://www.rempe.us/keybase.txt

You can learn a bit more about this here:

https://keybase.io/docs/server_security/following

Please also note that for most of the last year Keybase is in the midst of
a transition away from using GPG keys as the primary identifier and the
primary way of signing proofs. They have already moved to a model where
NaCl keypairs are used to identify various devices the user controls, and
then the user can sign proofs on various services with those NaCl keys. You
can still add one, or more, GPG keys into this mix.

https://keybase.io/blog/keybase-new-key-model

Keybase is creating a form of the Web of Trust, but it does not rely on, or
even require at all, GPG keys or the use of social networking services.
Facebook is not supported at all.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

[Glenn Rempe]

On Fri, Jan 15, 2016 at 10:29:13AM +0100, Simon Josefsson wrote:
> Glenn Rempe <gl...@rempe.us> writes:
> 
> > I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey to
> > manage my gpg private keys and I am using that key for SSH auth.  I have it
> > all up and running but I ran into some issues as well so I wrote up a blog
> > post.  I'd appreciate any suggestions for improvement and especially for
> > any ideas for a better fix for the workaround I had to do that I documented
> > at the end of the post.  Maybe this will be of some use to those wanting to
> > use the latest gpg for SSH auth on a Mac with a Yubikey.
> >
> > https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/
> 
> Have you tried killing/restarting scdaemon only, not gpg-agent?
> 
> Try:
> 
> gpgconf --reload scdaemon
> 
> or
> 
> gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye

I am on OS X, and just so you know I have turned off the OS X system
scdaemon per this blog post (I did this before upgrading to GnuPG 2.1):

https://gpgtools.tenderapp.com/discussions/problems/28634-gpg-agent-stops-working-after-osx-upgrade-to-yosemite#comment_35808149

So I am using just the scdaemon embedded with GPG I believe.

I just tried your suggestion to reload the internal scdaemon with
'gpgconf --reload scdaemon' and that also worked just as well as killing
gpg-agent, and probably without some side effects, none of which I've
noticed yet. So that is a step in the right direction, but I still have to
run it every time I remove/reinsert the card and SSH to a remote host
or it fails with a 'Permission denied (publickey)' error. So this seems
like a step in the right direction, but I still have to use ControlPlane
to restart scdaemon on insert/remove events.

> 
> Why do you add the keygrip to the sshcontrol file?  I have never needed
> that step.  For me it uses the right key directly.  Is it because you
> have another (revoked) A subkey?  It sounds somewhat of sub-optimal
> behaviour for gpg-agent's SSH support to use a revoked key instead of
> the non-revoked key.

I do have a revoked Authentication sub-key on my primary key, but I
no longer use it and that is also not why I added the keygrip entry to
sshcontrol file.  I added it at the suggestion of Werner in this post:

https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html

And these blog posts:
http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html
http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key

Is this suggestion outdated?

> 
> /Simon



-- 
Glenn Rempe

email : gl...@rempe.us
voice : (415) 613-1653
twitter   : @grempe
gpg key id: 0xA4A288A3BECCAE17
gpg fingerprint   : 497A 6138 963D 6C47 202B  238B A4A2 88A3 BECC AE17


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

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

[Glenn Rempe]

I'm not sure when the use of sshcontrol emerged. My impression was that it
is only used as part of GnuPG 'Modern' 2.1.x versions. That being said, If
I remove the keygrip entry from the sshcontrol file it appears to work
fine.  The only difference I've just noticed is in the output of 'ssh-add
-l':

with keygrip in sshcontrol:
~/.gnupg$ ssh-add -l
error fetching identities for protocol 1: agent refused operation
2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg cardio:000MYCARDNUM
(RSA)
2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg (none) (RSA)

without key grip in sshcontrol:
~/.gnupg$ ssh-add -l
error fetching identities for protocol 1: agent refused operation
2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg cardno:000MYCARDNUM
(RSA)

Any ideas for also eliminating that error message, or understanding why its
there are appreciated.

As for the suggestion by the2nd at otpme.org regarding the scdaemon bug.
This sounded promising, but when I investigated a bit it seems that the
commit in that thread that indicated this issue might be fixed on master
(f42c50dbf00c2e6298ca6830cbe6d36805fa54a3) was committed on Dec 2, 2015,
and gnupg version 2.1.10 was tagged on Dec 4, 2015.  So that fix should
already be in the version of GnuPG I am using (2.1.10) and yet I am still
seeing a problem.

/tmp/gnupg (master ✔)$ git log f42c50dbf00c2e6298ca6830cbe6d36805fa54a3
commit f42c50dbf00c2e6298ca6830cbe6d36805fa54a3
Author: NIIBE Yutaka 
Date:   Thu Dec 3 11:26:24 2015 +0900

scd: Fix "Conflicting usage" bug.

* scd/apdu.c (apdu_close_reader): Call CLOSE_READER method even if we
  got an error from apdu_disconnect.
* scd/app-common.h (no_reuse): Remove.
* scd/app.c (application_notify_card_reset): Deallocate APP here.
(select_application, release_application): Don't use NO_REUSE.

--

Reproducible scenario: Invoke gpg --card-edit session from a terminal.
Invoke another gpg --card-edit session from another.  Remove a token.
Insert a token again.  Type RET on both terminals.  One of terminal
answers "Conflicting usage".

Perhaps, having NO_REUSE field was to avoid race conditions.  Now,
APP can be safely deallocated by application_notify_card_reset.

Thanks to the2nd.

I installed 2.1.10 from this homebrew recipe:

https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb

My SSH client is the one that comes with OS X 'El Capitan':

/tmp/gnupg (master ✔)$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8




On Fri, Jan 15, 2016 at 12:31 PM Simon Josefsson 
wrote:

> > > Why do you add the keygrip to the sshcontrol file?  I have never
> > > needed that step.  For me it uses the right key directly.  Is it
> > > because you have another (revoked) A subkey?  It sounds somewhat of
> > > sub-optimal behaviour for gpg-agent's SSH support to use a revoked
> > > key instead of the non-revoked key.
> >
> > I do have a revoked Authentication sub-key on my primary key, but I
> > no longer use it and that is also not why I added the keygrip entry to
> > sshcontrol file.  I added it at the suggestion of Werner in this post:
> >
> > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html
> >
> > And these blog posts:
> > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html
> > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key
> >
> > Is this suggestion outdated?
>
> I don't recall ever using it, and I've been using SSH with smartcards
> through gpg-agent for over 10 years.  What happens if you drop that
> part?  For me it has always selected the right subkey automatically.
>
> /Simon
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

[Glenn Rempe]

Thanks Peter, I was not aware of that (and it certainly explains the double
entry in ssh-add -l.

btw, Werner was not writing that response to me. It was just pointed out to
me, so yes it was
probably not smart card specific I would guess. I'll update the blog post
to reflect that we
probably do not need to modify sshcontrol for use with Yubikey.

Back to the main issue I am having. I followed the instructions to output a
verbose scdaemon log
which I was exercising this issue.  Here is a gist with the commands I was
running and the resulting
logfile.

https://gist.github.com/grempe/e143796b8f399f5fa391

Perhaps NIIBE Yutaka or someone else more knowledgable than I can take a
look and
get us closer to resolution. :-)

Thanks for everyone who is helping.


On Fri, Jan 15, 2016 at 3:08 PM Peter Lebbing <pe...@digitalbrains.com>
wrote:

> On 15/01/16 21:17, Glenn Rempe wrote:
> > I added it at the suggestion of Werner in this post:
> >
> > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html
> >
> > And these blog posts:
> > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html
> > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key
> >
> > Is this suggestion outdated?
>
> No, but I'm fairly sure Werner did not realise you were using a smartcard
> when
> he wrote that. Obviously, I can't look into the man's mind, but that's my
> guess.
>
> For regular, on-disk keys, it is necessary to add the keygrip to
> sshcontrol. For
> smartcards, it's automatically added when the smartcard is inserted. I
> guess it
> fits with automatically added secret key stubs when the smartcard is
> inserted
> (to use a smartcard on a fresh PC, import your own public key, insert your
> smartcard, and you're done).
>
> 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 <http://digitalbrains.com/2012/openpgp-key-peter>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Yubikey, GnuPG 2.1 Modern, and SSH on OS X

[Glenn Rempe]

I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey to
manage my gpg private keys and I am using that key for SSH auth.  I have it
all up and running but I ran into some issues as well so I wrote up a blog
post.  I'd appreciate any suggestions for improvement and especially for
any ideas for a better fix for the workaround I had to do that I documented
at the end of the post.  Maybe this will be of some use to those wanting to
use the latest gpg for SSH auth on a Mac with a Yubikey.

https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/

Here is a discussion thread that describes *exactly* the issue I am still
having (if I don't use my workaround to kill and restart gpg-agent on every
yubikey insertion and deletion):

https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053796.html

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