Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Duane Whitty]

On 17-06-05 11:11 PM, Daniel Kahn Gillmor wrote:
> On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
>> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>>> what does "bullet-proof" mean, specifically? 
>>
>> For me it means that the idendicons should be visually easy to read
>> and cryptographically secure. Sorry that i have no better explanation.
> 
> here's one way to try to frame the question: Imagine the situation as a
> game, where you have two players on one team, "defense" named Alice and
> Bob; Alice wants to send a message to Bob.  Another player on the
> opposing team, "offense", is named Mallory, is trying to send a message
> to Bob as well, but trying to trick Bob into thinking that the incoming
> message comes from Alice.
> 
> The way the game is played, either Alice or Mallory gets to send a
> message.  Bob has to decide whether the message actually came from
> Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
> the "offense" wins.  The game is played multiple times.
> 
> Is that the scenario you're thinking of?  If so, does the defense need
> to win 100% of the time over thousands of games?  or is it acceptable
> for offense to win occasionally?
> 
> In any case question is: how much work does Mallory need to do to get
> Bob to make a mistake?  How frequently can Mallory trick Bob into
> accepting mail from her as though it were from Alice?  Conversely, how
> many messages that were actually from Alice can Bob accidentally reject
> without making Alice upset enough to give up on the entire
> communications scheme?
> 
> When you frame the problem this way, you can start thinking more
> concretely about what "bulletproof" means, and you can actually design
> user trials to test proposals.
> 
> There are probably other ways to concretize the problem, this is just
> one that i've come up with.  But without a concrete way to understand
> what we're looking for, words like "bullet proof" or "easy to read" or
> "cryptographically secure" are tough to get people to agree on.
> 
> I suspect (as discussed upthread) that TOFU will have better metrics for
> "defense" at the game described above than any attempt that involves
> asking people to visually distinguish deterministically-generated
> identicons.  But i don't know, because i haven't tested it.
> 
>--dkg
> 

Excellent scenario and explanation Daniel, thank you!  I firmly believe
your suspicions regarding identicons will be fully shown accurate.

However, I am having difficulty following how TOFU would/could provide
better metrics for the "defense" side of the game.  As I understand the
concept of TOFU (Trust On First Use), when you receive a signed email
gpg tests that signature against the key retrieved from the public key
servers associated with the email.

To me this says nothing about whether you are actually communicating
with who you think you are communicating with.  It justs says "Yes, the
signature on the email you received was generated by the same key
associated with that email address on the public key servers."

This is not enough to convince me I am communicating with someone I
know.  For instance, I have not imported even one of the many keys I
receive from emails to this mailing list into my keyring because there
is no trust there.  And when I move to gpg 2.1 I will make certain that
TOFU is not enabled.

I think TOFU could potentially be a win for Mallory.  TOFU may make
people more likely to take for granted that they are communicating with
a trusted party because the email they received says it's someone they
trust and GPG says it's a good signature from al...@example.com.

The problem with this is that they never communicated with Alice to
learn her email address is actually al...@trustme.com.

My personal opinion, for whatever that is worth, is that TOFU is going
to have people sending signed/encrypted email back and forth to each
other without them having done the work to ensure they are actually
communicating with their intended parties.  Trust takes work.

Once the work on establishing identities has been done and trust has
been established there is no need to remember keys because the key will
be locally associated with the email address belonging to the trusted
party you wish to communicate with.

Best Regards,
Duane

-- 
Duane Whitty
du...@nofroth.com



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

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Daniel Kahn Gillmor]

On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>> what does "bullet-proof" mean, specifically? 
>
> For me it means that the idendicons should be visually easy to read
> and cryptographically secure. Sorry that i have no better explanation.

here's one way to try to frame the question: Imagine the situation as a
game, where you have two players on one team, "defense" named Alice and
Bob; Alice wants to send a message to Bob.  Another player on the
opposing team, "offense", is named Mallory, is trying to send a message
to Bob as well, but trying to trick Bob into thinking that the incoming
message comes from Alice.

The way the game is played, either Alice or Mallory gets to send a
message.  Bob has to decide whether the message actually came from
Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
the "offense" wins.  The game is played multiple times.

Is that the scenario you're thinking of?  If so, does the defense need
to win 100% of the time over thousands of games?  or is it acceptable
for offense to win occasionally?

In any case question is: how much work does Mallory need to do to get
Bob to make a mistake?  How frequently can Mallory trick Bob into
accepting mail from her as though it were from Alice?  Conversely, how
many messages that were actually from Alice can Bob accidentally reject
without making Alice upset enough to give up on the entire
communications scheme?

When you frame the problem this way, you can start thinking more
concretely about what "bulletproof" means, and you can actually design
user trials to test proposals.

There are probably other ways to concretize the problem, this is just
one that i've come up with.  But without a concrete way to understand
what we're looking for, words like "bullet proof" or "easy to read" or
"cryptographically secure" are tough to get people to agree on.

I suspect (as discussed upthread) that TOFU will have better metrics for
"defense" at the game described above than any attempt that involves
asking people to visually distinguish deterministically-generated
identicons.  But i don't know, because i haven't tested it.

   --dkg


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

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Stefan Claas]

On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
> On Mon 2017-06-05 16:22:26 +0200, Stefan Claas wrote:
>>>  * in the "distinguishing" model, it's not clear that any of the schemes
>>>i've seen are actually better for most humans against a dedicated
>>>attacker who crafts fingerprints to make visual identities that look
>>>similar.  do you have any studies showing this capability against a
>>>motivated and technically capable attacker?
>> No, of course i have not. My thoughts as a not so-skilled GnuPG user
>> would be that it helps users detecting (assuming it's bullet-proof)
> what does "bullet-proof" mean, specifically?  I ask this not for
> pedantry's sake, but because clearly stating the problem makes it
> possible to know whether a specific solution is applicable.
For me it means that the idendicons should be visually easy to read
and cryptographically secure. Sorry that i have no better explanation.
>
>> a proper key from a fake key more easily if they have not yet signed
>> (locally) a public key while they already exchanged a couple of
>> emails.  I can speak only of Thunderbird/Enigmail wich i use now. It
>> gives a user the usual "Untrusted Good Signatur" and i have to click
>> also on the Details button to carefully verify the fingerprint from an
>> addional list to see if the key belongs to the person the signature
>> claims. An additional visual fingerprint would make that proccess for
>> me easier, if it's bullet-proof.
> It sounds to me like you're saying that you find the key verification
> and certification steps as implemented by enigmail to be
> difficult-to-use.  You wouldn't be the only person who has that
> impression.
>
> But i don't see how a graphical icon solves that problem.  Isn't it a
> workflow problem, and not a visual-comparison problem?  If there's a
> standard thing (comparison, lookup, verification) you expect to be able
> to do with the tool, the tool should make that thing easy and simple to
> do.
>
> What specifically is the thing that you're trying to do when you click
> "Details" and verify the fingerprint (from what list?)?  Enigmail itself
> can compare fingerprints far better than you or i can, even if there is
> a graphical representation involved :) Maybe there's a different
> question or different interface Enigmail ought to offer in the "Details"
> view entirely?
Well, in the past, before i started using this email combination i
used web based email accounts copy and pasted the message into
a text editor and had no auto key retrival and looked up WWW
key servers to download the required key to verify the sig. I had
not often communications back then. So this was an acceptable
workflow for me.

With the current set-up it's all automatic and my understanding is
that in case i would receive a fake message my set-up would download
the fake key, display it as "Untrusted Good Signature" too, because i
have not yet locally signed the key. Therefore i click details to see the
fingerprint (which i can't memorizy) and look it up again. Maybe, as
casual user who never used this set-up before, i make a fundamentally
mistake in understanding of how the auto retrieve and verify function
works. I mean why is a Details button there to see a fingerprint which
i believe nobody can memorize in the first place? It must serve a purpose,
or not?

>>> I'd generally think that if you're looking for a tool to help people
>>> remember and recognize keys that they've seen before, then a mail user
>>> agent is in a great position to do exactly that: just tell the user
>>> explicitly what they've seen before, how often, etc.  why depend on the
>>> human visual cortex or on human ability for numeric recall?
>> I could imagine that Joe user average may not always look at mail headers
>> very carefully for a little typo in the from: or reply-to: header in his
>> mail client or web-mailer.
> i agree with you that users won't look at mail headers closely, which is
> why the e-mail client (the "mail user agent", or MUA) should be the
> thing to do the comparison, and to make it very clear to the user when
> something is amiss.  But that still doesn't answer the question of what
> the MUA should actually be trying to compare and what results it should
> be highlighting.
>
For me a MUA is passive and happily accepts what he receives, whether it's
correct content or not, so i can't answer that question, sorry.

Regards
Stefan
 




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

[Announce] GnuPG Funding Campaign Launched

[Werner Koch]

Independent Encryption Software, GnuPG, Needs Financial Support

  Düsseldorf, Germany --- Tuesday, June 6, 2017.  The GnuPG Project
  today announced the launch of a funding campaign to further support
  and improve its leading mail and data encryption software, GnuPG.  The
  campaign aims to secure 15000 Euro per month in recurring donations
  from individual donors to finance the development of their free
  software.  Donations can be made at the newly reworked website:



  Activists, journalists, lawyers, and many others rely on GnuPG to
  protect their communication.  The software guards emails, files, and
  programs from government and criminal snooping and spying on Windows,
  Mac, and Linux.  And, more than two-thirds of the servers running the
  Internet rely on GnuPG to verify the integrity of system updates.

  Ongoing government spying revelations have shown how little of our
  information is really safe.  GnuPG is one of the few tools that can
  offer real protection, free of commercial interests.  Edward Snowden
  used it to encrypt his communications with journalists.  Many
  institutions use GnuPG because by using an open standard they can be
  sure that they will always be able to access their data.

  The 6 person development team is currently financed from a successful
  campaign in early 2015, regular donations from the Linux Foundation,
  Stripe, Facebook, and a few paid development projects.  To ensure
  long-term stability the new campaign focuses on recurring donations
  and not one-time donations.  Says lead developer Werner Koch: “We want
  to continue our work in the long term.  But, we want to do so in such
  a way that our first loyalty is unambiguously to the general public.
  This means making sure that a majority of our funding comes from
  individual donors, and not corporations.”

  To highlight GnuPG's role in protecting data, user stories from 26
  organizations including activist groups, news organizations, lawyers,
  and companies from all over the world have been collected.  Their
  testimonials are presented in daily changing videos on the campaign
  site.


About GNU Privacy Guard (GnuPG)

  Since 1997, GnuPG has allowed individuals and companies to encrypt and
  sign data and communication using the well-established and highly
  interoperable OpenPGP standard.  It comes with state of the art
  cryptography and features a versatile key management system.  GnuPG,
  also known as GPG or sometimes incorrectly as PGP, can be used
  standalone, but has all features needed for easy integration with
  other software.  It is used as the core cryptography engine of a
  wealth of other applications: For example Thunderbird with Enigmail,
  Gpg4win, and GPGTools.  Most operating systems use GnuPG's signing
  ability to protect system updates against malicious attempts to
  introduce backdoors.  GnuPG is available free of charge, and comes
  with all source code to allow anyone to audit the software.
  


About g10 Code GmbH

  g10 Code GmbH is the privately owned legal entity behind the GnuPG
  Project.  They employ all developers and keep all profits for the
  development of GnuPG and related free software.
  


### Media contacts:

  Neal H. Walfield, Werner Koch
  Email: me...@gnupg.org
  Phone: +49-2104-4938797 (during European business hours)
  Twitter: @gnupg
  OpenPGP: 370C 0FC3 1293 B339 61C1 FC20 B367 1B93 6BA8 BCB2
___
Gnupg-announce mailing list
gnupg-annou...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: scute / firefox: cannot connect to GPG agent

[Fabian Peter Hammerle]

> Can you check that after starting Firefox, you still have
> only one GPG-Agent and one Scdaemon running?

Before launching Firefox:

$ ps aux | grep -P '(scdaemon|gpg-agent)'
> fabianp+  3242 [...] gpg-agent --homedir /home/fabianpeter/.gnupg 
> --use-standard-socket --daemon
> fabianp+  3518 [...] grep -P (scdaemon|gpg-agent)
> fabianp+ 26815 [...] scdaemon --multi-server
$ gpg-connect-agent "SCD GETINFO pid" /bye
> D 26815
> OK

Strangely enough Firefox does no longer write anything to stdout or stderr.
Unfortunately, I don't know what changed since I received the error
message last time.

$ export GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 
$ echo $GPG_AGENT_INFO
> /run/user/1000/gnupg/S.gpg-agent:0:1
$ firefox &
> [1] 3616

While Firefox was running no other instances of gpg-agent or scdaemon
were launched:

$ ps aux | grep -P '(scdaemon|gpg-agent)' 
> fabianp+  3242 [...] gpg-agent --homedir /home/fabianpeter/.gnupg 
> --use-standard-socket --daemon
> fabianp+  3746 [...] grep -P (scdaemon|gpg-agent)
> fabianp+ 26815 [...] scdaemon --multi-server

With the Yubikey unplugged Firefox' Device Manager now shows a menu item
'GnuPG Smart Card Daemon':
Status: Not Present
Description: GnuPG Smart Card Daemon
Manufacturer: g10 Code GmbH
HW Version: 2.1
FW Version: 1.5

When I plug in my Yubikey and re-open the Device Manager most values are empty:
change to:
Status: Not Present
Description: [empty]
Manufacturer:  [empty]
HW Version: [empty]
FW Version: [empty]

(Screenshots attached)

While Firefox is running I am not able to access my smartcard with gpg:

$ date | gpg -e | gpg # gpg test 
> gpg: encrypted with 4096-bit RSA key, ID CD90DBE8B7C5FE43, created 2016-10-16
>   "Fabian Peter Hammerle "
> gpg: public key decryption failed: No SmartCard daemon
> gpg: decryption failed: No secret key
$ gpg-connect-agent "SCD GETINFO pid" /bye
> ERR 67108983 No SmartCard daemon 

Before I loaded Scute in Firefox the very first time,
I used gpgsm the create a x509 cert for the auth subkey (pos. 3) on the Yubikey.
I signed the certificate with another key in gpgsm (also on smartcard).

$ gpgsm --list-secret-keys --with-validation 0x33C90BD1
> [...]
>Issuer: /CN=Fabian Peter Hammerle/C=AT
>   Subject: /CN=Fabian Peter Hammerle/C=AT
>  validity: 2017-06-02 21:59:08 through 2017-07-02 21:59:08
>  key type: 4096 bit RSA
> key usage: digitalSignature nonRepudiation
> ext key usage: clientAuth (suggested)
>   fingerprint: 94:F5:1F:46:07:5D:28:68:8A:F3:A6:39:DB:BD:E4:4E:33:C9:0B:D1
>  card s/n: D276000[...]
>   [certificate is good]

Thank you very much for your support!

Fabian


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

Re: scute / firefox: cannot connect to GPG agent

[Fabian Peter Hammerle]

> The maximal size for the certificate to be stored on the token is indicated
> by the "mcl3" value (so, 2048 bytes in this example). Your DER-encoded
> certificate should not be bigger than that.

$ gpg-connect-agent 'SCD GETATTR EXTCAP' /bye | grep -Po 'mcl3=\d+'  
mcl3=1216

My certificate is slightly larger:

$ gpgsm --export '&22BD35[...]6F89B' | wc --bytes
1432

> As far as I know there is no command in the gpg card editor to erase the
> certificate, but I *think* using the writecert command with /dev/null as
> input should do the trick (I have not tested).

Unfortunately I was not successful using /dev/null:

gpg/card> writecert 3 < /dev/null
gpg: error writing certificate to card: Invalid argument

> Scute can fetch the certificate both from the 
> token itself, or from the gpgsm store. But it will try first to fetch it 
> from the token.

To test my configuration I temporarily disabled the call to
scute_agent_get_cert():

diff --git a/src/gpgsm.c b/src/gpgsm.c
index 2a2906f..5c2674a 100644
--- a/src/gpgsm.c
+++ b/src/gpgsm.c
@@ -124,7 +124,7 @@ scute_gpgsm_get_cert (char *grip, int no, cert_get_cb_t 
cert_get_cb, void *hook)
 
   /* If the key is from the card, we might get the certificate from
  the card as well.  */
-  if (no >= 0)
+  if (false && no >= 0)
 {
   struct cert cert;

The Certificate Manager now shows an entry under 'Your Certificates'.

I was able to login via Client Auth using my Yubikey.
Amazing :-)

Thank you very much for your continuous help!

I'll try to find a way to erase the certificate from the Yubikey.

Fabian


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

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Daniel Kahn Gillmor]

On Mon 2017-06-05 16:22:26 +0200, Stefan Claas wrote:
>>  * in the "distinguishing" model, it's not clear that any of the schemes
>>i've seen are actually better for most humans against a dedicated
>>attacker who crafts fingerprints to make visual identities that look
>>similar.  do you have any studies showing this capability against a
>>motivated and technically capable attacker?
>
> No, of course i have not. My thoughts as a not so-skilled GnuPG user
> would be that it helps users detecting (assuming it's bullet-proof)

what does "bullet-proof" mean, specifically?  I ask this not for
pedantry's sake, but because clearly stating the problem makes it
possible to know whether a specific solution is applicable.

> a proper key from a fake key more easily if they have not yet signed
> (locally) a public key while they already exchanged a couple of
> emails.  I can speak only of Thunderbird/Enigmail wich i use now. It
> gives a user the usual "Untrusted Good Signatur" and i have to click
> also on the Details button to carefully verify the fingerprint from an
> addional list to see if the key belongs to the person the signature
> claims. An additional visual fingerprint would make that proccess for
> me easier, if it's bullet-proof.

It sounds to me like you're saying that you find the key verification
and certification steps as implemented by enigmail to be
difficult-to-use.  You wouldn't be the only person who has that
impression.

But i don't see how a graphical icon solves that problem.  Isn't it a
workflow problem, and not a visual-comparison problem?  If there's a
standard thing (comparison, lookup, verification) you expect to be able
to do with the tool, the tool should make that thing easy and simple to
do.

What specifically is the thing that you're trying to do when you click
"Details" and verify the fingerprint (from what list?)?  Enigmail itself
can compare fingerprints far better than you or i can, even if there is
a graphical representation involved :) Maybe there's a different
question or different interface Enigmail ought to offer in the "Details"
view entirely?

>> I'd generally think that if you're looking for a tool to help people
>> remember and recognize keys that they've seen before, then a mail user
>> agent is in a great position to do exactly that: just tell the user
>> explicitly what they've seen before, how often, etc.  why depend on the
>> human visual cortex or on human ability for numeric recall?
>
> I could imagine that Joe user average may not always look at mail headers
> very carefully for a little typo in the from: or reply-to: header in his
> mail client or web-mailer.

i agree with you that users won't look at mail headers closely, which is
why the e-mail client (the "mail user agent", or MUA) should be the
thing to do the comparison, and to make it very clear to the user when
something is amiss.  But that still doesn't answer the question of what
the MUA should actually be trying to compare and what results it should
be highlighting.

   --dkg


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

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Stefan Claas]

On 05.06.17 17:40, Stefan Claas wrote:
> And another thought, since this thread says "app developers". How would
> services like StartMail, ProtonMail or gmx.de for example handle this...?
>
> If i remember correctly users have not the possibillity to sign someone
> elses pub-key when they both use the same service. If someone gains
> unauthorized access to one account and use his own fake pub key...?!
>
Appologies to all, i had a brain fart with this unauthorized access
sentence and
a fake pub key.

Regards
Stefan


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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

On 06/05/2017 07:54 PM, Fabian Peter Hammerle wrote:

Ah, I didn't know I had to write the certificate onto the Yubikey.


You do not *have* to; Scute can fetch the certificate both from the 
token itself, or from the gpgsm store. But it will try first to fetch it 
from the token.


Storing the certificate on the token itself instead on relying on the 
gpgsm store allows you to use your token on a machine that is not your 
usual machine.




Could you extract the certificate from the smartcard and have a look at it?
   $ gpg --card-edit
   gpg/card> readcert 3 > file.der
   gpg/card> quit


$ od -x file.der

000 217f 0082      
020        
*
400  00ff
403


I don't pretend to be a X.509 or ASN1 expert (far from it!), but this 
does not look like a X.509 certificate at all.




gpg: error writing certificate to card: Provided object is too large

Do I have to choose a smaller key size?


Check the maximal size supported by the Yubikey:

  $ gpg-connect-agent 'SCD GETATTR EXTCAP' /bye

The output should be a line like the following:

  S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=0

The maximal size for the certificate to be stored on the token is 
indicated by the "mcl3" value (so, 2048 bytes in this example). Your 
DER-encoded certificate should not be bigger than that.


But if it happens that your Yubikey does not support 4096-bit 
certificates, and you still want such a certificate, then you could 
simply erase the (corrupted) certificate on the Yubikey. As I said 
above, Scute will fetch the certificate from the gpgsm store if it 
cannot find it on the token.


As far as I know there is no command in the gpg card editor to erase the 
certificate, but I *think* using the writecert command with /dev/null as 
input should do the trick (I have not tested).




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

Re: scute / firefox: cannot connect to GPG agent

[Fabian Peter Hammerle]

> Did you import your new certificate onto the Yubikey? Because independently
> of what your gpgsm store may contain, Scute will always try to fetch the
> certificate from the token itself.

Ah, I didn't know I had to write the certificate onto the Yubikey.
I only imported it into gpgsm following this guide: 
http://scute.org/scute.html/Certificate-Preparation.html

> Could you extract the certificate from the smartcard and have a look at it?
>   $ gpg --card-edit
>   gpg/card> readcert 3 > file.der
>   gpg/card> quit

$ od -x file.der
> 000 217f 0082      
> 020        
> *
> 400  00ff
> 403

I just tried to write the certificate onto the Yubiykey:

$ gpg --edit-card
Reader ...: Yubico Yubikey 4 OTP U2F CCID 00 00
[...]
ssb>  rsa4096/3AA08B6113EC625C  created: 2016-12-25  expires: never
[...]
gpg/card> admin
Admin commands are allowed
gpg/card> writecert 3 

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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

On 06/05/2017 07:04 PM, Fabian Peter Hammerle wrote:

scute: scute_agent_get_cert: got certificate from card with length 259
OK, this is weird. 259 bytes seems too short for a X.509 certificate, 
especially one based on 4096-bit public key (for comparison, my own 
2048-bit certificate is 1587 bytes).


Maybe an error occured when the certificate was stored on the Yubikey, 
and the certificate there is actually truncated?


Could you extract the certificate from the smartcard and have a look at 
it? Run gpg in card-edit mode, and at the prompt, use the (undocumented) 
readcert command to save the certificate to a file


  $ gpg --card-edit

  gpg/card> readcert 3 > file.der
  gpg/card> quit

Then inspect the contents of file.der, using e.g. openssl:

  $ openssl x509 -inform DER -in file.der -text



Due to scute 'rejecting certificate' I just removed my current
certificate for the auth subkey from gpgsm and created / imported a new
self-signed certificate:

> [...]

Anyway, Scute still logs the same error message:


Did you import your new certificate onto the Yubikey? Because 
independently of what your gpgsm store may contain, Scute will always 
try to fetch the certificate from the token itself.




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

Re: scute / firefox: cannot connect to GPG agent

[Fabian Peter Hammerle]

> Could you perform your tests again with Scute debugging turned on?

Scute log when launching Firefox with Yubikey unplugged:

> scute debug init: flags=0xff
> scute: scute_agent_initialize: Establishing connection to gpg-agent

After plugging in the Yubikey:

> scute: scute_agent_get_cert: got certificate from card with length 259
> scute: asn1_get_element: wrong element in lookup path
> scute: scute_attr_prv: rejecting certificate: could not get subject: General 
> error
> scute: scute_agent_get_cert: got certificate from card with length 259
> scute: asn1_get_element: wrong element in lookup path
> scute: scute_attr_prv: rejecting certificate: could not get subject: General 
> error
[repeating rapidly]

Due to scute 'rejecting certificate' I just removed my current
certificate for the auth subkey from gpgsm and created / imported a new
self-signed certificate:

$ gpgsm --gen-key
> [...]
> Please select what kind of key you want:
>(1) RSA
>(2) Existing key
>(3) Existing key from card
> Your selection? 3
> Serial number of the card: D27600[...]
> Available keys:
>(1) C2E04B00B3F087DB143B4BB6411813BA220ED4BA OPENPGP.1
>(2) FDB0E6A955AA1194D369A942B8EF10E6C66E0BB4 OPENPGP.2
>(3) 22BD35D43F4D748110C935CC6B8D13575306F89B OPENPGP.3
> Your selection? 3
> [...]
> Create self-signed certificate? (y/N) y
> These parameters are used:
> Key-Type: card:OPENPGP.3
> Key-Length: 1024
> Key-Usage: sign
> Serial: random
> Name-DN: CN=scute test,C=AT
> 
> Proceed with creation? (y/N) y
> Now creating self-signed certificate.  This may take a while ...
> gpgsm: about to sign the certificate for key: 
> &22BD35D43F4D748110C935CC6B8D13575306F89B
> gpgsm: certificate created
> Ready.
> -BEGIN CERTIFICATE-
> [...]

I am not sure why gpgsm wrote
> Key-Length: 1024
although the actual key length is 4096:

$ gpg --list-secret-keys --with-keygrip | grep -B 1 
22BD35D43F4D748110C935CC6B8D13575306F89B
> ssb>  rsa4096 2016-12-25 [A]
>   Keygrip = 22BD35D43F4D748110C935CC6B8D13575306F89B

However, the newly created certificate seams to be valid:

$ gpgsm --list-secret-keys --with-keygrip --with-validation 'scute test' 
> [...]
>Issuer: /CN=scute test/C=AT
>   Subject: /CN=scute test/C=AT
>  validity: 2017-06-05 16:40:48 through 2063-04-05 17:00:00
>  key type: 4096 bit RSA
> key usage: digitalSignature nonRepudiation
>  chain length: unlimited
>   fingerprint: 0E:1F:DC:B0:43:FD:1B:93:70:76:C0:2A:B1:22:8E:3A:B0:8B:D4:52
>   keygrip: 22BD35D43F4D748110C935CC6B8D13575306F89B
>  card s/n: D276000[...]
>   [certificate is good]

Anyway, Scute still logs the same error message:

> scute: scute_agent_get_cert: got certificate from card with length 259
> scute: asn1_get_element: wrong element in lookup path
> scute: scute_attr_prv: rejecting certificate: could not get subject: General 
> error


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

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Stefan Claas]

On 05.06.17 16:22, Stefan Claas wrote:
> On 04.06.17 22:20, Daniel Kahn Gillmor wrote:
>
>> I'd generally think that if you're looking for a tool to help people
>> remember and recognize keys that they've seen before, then a mail user
>> agent is in a great position to do exactly that: just tell the user
>> explicitly what they've seen before, how often, etc.  why depend on the
>> human visual cortex or on human ability for numeric recall?
> I could imagine that Joe user average may not always look at mail headers
> very carefully for a little typo in the from: or reply-to: header in his
> mail client or web-mailer.
And another thought, since this thread says "app developers". How would
services like StartMail, ProtonMail or gmx.de for example handle this...?

If i remember correctly users have not the possibillity to sign someone
elses pub-key when they both use the same service. If someone gains
unauthorized access to one account and use his own fake pub key...?!

Regards
Stefan



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

Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Stefan Claas]

On 04.06.17 22:20, Daniel Kahn Gillmor wrote:

> Hi Stefan--
>
> I think you're asking about two sort of different things.
>
> on the one hand, you're asserting that the 32-bit keyid isn't sufficient
> for any sort of cryptographic verification.  that's absolutely correct,
> and enigmail really shouldn't be exposing the 32-bit keyID to humans
> where it can avoid doing so.  I've written more about this here:
>
>   https://debian-administration.org/users/dkg/weblog/105

Very good article Daniel i will re-read and save it as reference
and let other people know about it.


> You're also asking about graphical representations of the cryptographic
> identity -- a graphical representation of a fingerprint, basically.
> The community has seen several different proposals of graphical
> fingerprint representations in the past, and every one i've seen
> gets stuck when faced with the hard questions.  In particular:
>
>  * is the goal *recognition* of the fingerprint (i.e. "does this
>fingerprint look sufficiently similar to the one i've seen in the
>past for me to remember it?"), or is the goal *distinguishing* from a
>maliciously-crafted fingerprint (i.e. "am i certain that this
>fingerprint is an exact match of one that i expect to see from the
>peer who i think should have been signing this e-mail?")
>
>  * In the "recognition" model, it's not clear that any
>cryptographically-strong guarantees are made to the user.  So why tie
>the visual identity to the cryptographic identity if we think it's
>spoofable?
>
>  * in the "distinguishing" model, it's not clear that any of the schemes
>i've seen are actually better for most humans against a dedicated
>attacker who crafts fingerprints to make visual identities that look
>similar.  do you have any studies showing this capability against a
>motivated and technically capable attacker?

No, of course i have not. My thoughts as a not so-skilled GnuPG user
would be that it helps users detecting (assuming it's bullet-proof) a
proper key from a fake key more easily if they have not yet signed
(locally) a public key while they already exchanged a couple of emails.
I can speak only of Thunderbird/Enigmail wich i use now. It gives a
user the usual "Untrusted Good Signatur" and i have to click also on
the Details button to carefully verify the fingerprint from an addional
list to see if the key belongs to the person the signature claims. An
additional visual fingerprint would make that proccess for me easier,
if it's bullet-proof.

> I'd generally think that if you're looking for a tool to help people
> remember and recognize keys that they've seen before, then a mail user
> agent is in a great position to do exactly that: just tell the user
> explicitly what they've seen before, how often, etc.  why depend on the
> human visual cortex or on human ability for numeric recall?

I could imagine that Joe user average may not always look at mail headers
very carefully for a little typo in the from: or reply-to: header in his
mail client or web-mailer.

Regards
Stefan



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

Re: Question for app developers, like Enigmail etc. - Identicons

[Daniel Kahn Gillmor]

Hi Stefan--

I think you're asking about two sort of different things.

on the one hand, you're asserting that the 32-bit keyid isn't sufficient
for any sort of cryptographic verification.  that's absolutely correct,
and enigmail really shouldn't be exposing the 32-bit keyID to humans
where it can avoid doing so.  I've written more about this here:

  https://debian-administration.org/users/dkg/weblog/105

You're also asking about graphical representations of the cryptographic
identity -- a graphical representation of a fingerprint, basically.
The community has seen several different proposals of graphical
fingerprint representations in the past, and every one i've seen
gets stuck when faced with the hard questions.  In particular:

 * is the goal *recognition* of the fingerprint (i.e. "does this
   fingerprint look sufficiently similar to the one i've seen in the
   past for me to remember it?"), or is the goal *distinguishing* from a
   maliciously-crafted fingerprint (i.e. "am i certain that this
   fingerprint is an exact match of one that i expect to see from the
   peer who i think should have been signing this e-mail?")

 * In the "recognition" model, it's not clear that any
   cryptographically-strong guarantees are made to the user.  So why tie
   the visual identity to the cryptographic identity if we think it's
   spoofable?

 * in the "distinguishing" model, it's not clear that any of the schemes
   i've seen are actually better for most humans against a dedicated
   attacker who crafts fingerprints to make visual identities that look
   similar.  do you have any studies showing this capability against a
   motivated and technically capable attacker?

I'd generally think that if you're looking for a tool to help people
remember and recognize keys that they've seen before, then a mail user
agent is in a great position to do exactly that: just tell the user
explicitly what they've seen before, how often, etc.  why depend on the
human visual cortex or on human ability for numeric recall?

  --dkg


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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

On 06/05/2017 10:20 AM, Fabian Peter Hammerle wrote:

Does anyone know what might cause the 'sharing violation' error?


I am not sure. Can you check that after starting Firefox, you still have 
only one GPG-Agent and one Scdaemon running?


If you run the following command:

  $ gpg-connect-agent "SCD GETINFO pid" /bye

(which returns the PID of the running Scdaemon), do you get the same PID 
than the one displayed in your error messages?



Damien



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

Re: scute / firefox: cannot connect to GPG agent

[Fabian Peter Hammerle]

I just cloned Scute from git://git.gnupg.org/scute.git
(commit 10a19467bc2a95b4aa91176924a91be427d3157a)

The error messages changed (compared to my initial mail):

$ GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 firefox
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> gpg-agent[2998]: card has S/N: D276000[...]
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> scdaemon[2999]: pcsc_connect failed: sharing violation (0x801b)
> gpg-agent[2998]: card has S/N: D276000[...]
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> scdaemon[2999]: detected reader ''
> scdaemon[2999]: pcsc_connect failed: sharing violation (0x801b)
> gpg-agent[2998]: card has S/N: D276000[...]
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> scdaemon[2999]: detected reader ''
> scdaemon[2999]: pcsc_connect failed: sharing violation (0x801b)
[repeating rapidly]

pcscd reports:
> pcscd[3001]: 01000753 winscard.c:284:SCardConnect() Error Reader Exclusive

As far as I know, only gnupg accesses my smartcard.

Decryption, signing, and ssh authentication work as usual.

Restarting gpg-agent, scdaemon, pcscd and rebooting did not change anything.

Does anyone know what might cause the 'sharing violation' error?

Fabian


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