From calestyo at scientia.net Wed Apr 1 00:40:35 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Wed, 01 Apr 2015 00:40:35 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <878uedhrbu.fsf@alice.fifthhorseman.net>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
Message-ID: <1427841635.17032.147.camel@scientia.net>
... at least when it comes to crypto.
Let me use this word snippet from DKG to more generally think about the
TOFU concept :-)
On Tue, 2015-03-31 at 15:58 -0400, Daniel Kahn Gillmor wrote:
> The devil is
TOFU!
What have we had in the recent years when it came about
cryptographically secured message exchange (and message doesn't mean
"mail", it means "any data") that was actually used on a broader basis?
a) OpenPGP and similar schemes, where peers are typically more or less
directly authenticated (e.g. by personal meeting and fingerprint
exchange)[0].
This btw. also includes things like SSH, at least when one
directly/securely exchanges SSH keys.
This PKIs put the whole control under the user. He can decide who he
signs/trusts, or how many indirections (in the case of WoT) he'll
trust and so on.
b) X.509, and similar schemes, where trust in another one's identity is
not directly authenticated, but rather one trusts one (or hundreds)
of central points (the CAs) to do the right thing.
This includes basically all SSL/TLS, because this is typically only
used with X.509, and yes I know there is a RFC for OpenPGP + TLS, but
is there even a client who implements that?
Here, the control is effectively fully out the user's hand. The CA
alone decides, can forge (accidentally or on purpose) identities and
so on.
Theoretically the user can decide which CAs he trust, but in practise
this won't work either, since you have no control which CAs your peer
use.
Each CA can typically also assert the whole namespace (i.e. *all*
domainnames,... or *all* personal names - and not just the ones from
e.g. Lithuania)
(a) Is typically only used by people who want stronger security (i.e.
those who don't trust that fragile strict hierarchical and CA based
model of X.509). Or in cases where it needs to be sure that a 3rd party
cannot forge anything (e.g. when distributing packages of a Linux
distro).
(b) Is - whether intended as such or not - typically used for the
masses. Everything in the web (i.e. https) that is secured.
(btw: (b) is in concepts quite similar to TOFU,... no-one ever actually
verifies the CA's root certs... it's also trust on first use, what your
(e.g. browser) vendor ships)
That the X.509/strict hierarchical system is inherently broken, was
clear to everyone for many years (not only since Snowden or the growing
frequency of cases where CAs did something evil).
The masses didn't really complain, neither did any of the bigger players
(banks, Google, Mozilla, MS). The system worked at least to that extent
that people felt save and not enough damage was made by cybercriminals
to make a change worth.
Thanks to incompetent and/or corrupt CAs (does really anyone believe the
story that Turktrust or CNNIC's sub CA just made that forged CAs by
accident?), thanks to greedy companies like Google/Mozilla/MS/Apple who
only care about money and or market share, the system was kept alive and
thanks to them it was weakened more and more by the introduction of more
and more CAs (IIRC Modzilla ships around 150 these days, not counting
intermediate CAs).
You have the money? You'll be a CA and can do what ever you like!
And even if abuse gets public, Mozilla and friends likely won't ban you
(again see e.g. Turktrust, CNNIC).
Now since the whole NSA/GHCQ scandal and since the CA system showed more
and more to be what it is - broken - people started to actually
recognise that problem.
So the same people/player who knowingly kept the broken system alive,
are now looking for ways to fix it (which however isn't really possible
by nature).
The most prominent "solution" is probably TOFU, or key pinning or
however you call it.
It seems like a bad joke that those player, who are all too often
against open standard and who are well known to happily cooperate with
or even advise government agencies are now the ones trying to push TOFU
as "soluion".
Honi soit qui mal y pense!
So... TOFU.
Trust on first use.
That's basically like what we've had in the good old days with anonymous
SSL/TLS modes, where it was clear to everyone, that this doesn't really
provide security. Or similar to just blindly accepting a SSH server host
key without checking whether it's actually the right one.
Well it's that anonymous authentication + pinning of the respective
credentials (key, cert, or however you call it).
One can use TOFU "alone", e.g. just trusting any credential (like a
self-signed cert) on the first use. Or hybrid with e.g. the strict
hierarchical model from X.509.
The idea how TOFU should "solve" or at least improve things is, that
you'd recognise if subsequent connections go to the same destination
(because you have it's credentials/keys pinned/trusted - on their first
use).
The first bad assumption here is that one would have gained "trust" at
any stage. This is simply not true.
One cannot know, whether the peer on the first connection/communication
was actually the desired one (and has thus deserved "trust") or whether
it was my neighbours son, some cyber criminal or the BND (yes even the
German intelligence service isn't that bad as people often may think).
TOFU doesn't prevent MitM at the first connection at all, and once that
would have happened, an attacker could simply MitM every further
connection.
So TOFU makes some further assumptions:
1a) In practise one would have simply good enough chances that the first
connection (where trust is given) is not attacked.
1b) (see below)
2) And even if it was attacked (and all further communication relayed
via Mallory), one would sooner or later notice it.
I really wonder how one can just dare to make any of these two
assumptions and sell it to people... o.O
As for (1):
We already know that NSA/etc. sit literally at all the central network
places, the internet exchanges, the transatlantic cables, quite surely
in satellites and so on.
They either cooperate with the big content providers (Facebook, Google,
etc.) and the big Tier-1s (Level, Akamai and that like), they force them
to cooperate by law (national security letters, gag orders) or they
simply hack them.
Quite likely most of the commercial companies (i.e. those who file
lawsuits against the NSA and protest loudly) just happily cooperate in
reality.
They (NSA/etc.) also even hack the network hardware before it's
delivered to customers.
We know that they have extremely large powers, even already when
operating under law (cause in the US and others, when it comes to
surveillance or economical espionage law doesn't really matter),... and
if law should be in their way, well then they simply ignore it.
So again, how on earth could one believe that one would be safe from
MitM attacks in the "OFU" stage of TOFU?
Quite contrary, one must very well assume that they actually are listen
and sneak in as soon as a target would be interesting.
And even if you don't look at NSA/Co. - the same principle just applies
to the big players AND to cyber criminals.
They likely don't have access to that large part of the cake as e.g. the
NSA, but how can one just assume that the simple cyber criminal who
attacks you for ransom money isn't capable of getting in the line for a
MitM?
We see that basically daily with highly sophisticated attacks on two
factor authentication systems like smsTAN in mobile banking and lots
more.
So the argument (which is 1b) that typically comes next:
"Well they may be able to MitM most connections, but it would be too
expensive for them to do this on a broad scale ... and _therefore_ it
prevents or at least helps against mass surveillance.
Again, how can one just make such a blind and naive assumption.
We already know the extreme things they're capable of, like storing vast
amounts of data for lata use. We know the extremely big computing
centres they have (and these are just the ones publicly known - I don't
need to wear my alu hat, to believe that there real capacities are many
times higher; history has proven that.).
IMHO the arguments (1a) "in practice on will be lucky and the 'first
use', i.e. when the key is pinned/trusted, will be the right one" as
well as (1b) "well even if not, it at least prevents mass
surveillance"... are at best completely unproven, but likely simply
plain wrong, naive and - in all doing respect - stupid[1].
Then there's argument (2). The idea behind is:
If one makes an anonymous key exchange, then even when it's anonymous
(but trusted) in the first place, one would/could sooner or later
notice, if one was attacked (in the single case), respectively whether
mass surveillance continues.
Let's look at the single case:
When I notice "sooner or later" that I was MitM attacked, then it's
likely already too late. My precious data is likely already stolen or
e.g. evil code may have been already introduced in my system or e.g. my
bank account is already empty.
A cybercriminal who's on to me, or a intelligence agent who has really
targeted me simply wouldn't care.
The former only wants money and if his attack is noticed, well he didn't
send me his address in advance so he'll just move on to the next victim.
And the later... either they have already what they wanted, or it's at
least better for them to have a bit than nothing.
In both cases, the argument "that one may sooner or later notice it" is
simply moot.
And let's look at the mass surveillance case, the idea is basically:
*If* the masses would use opportunistic encryption with TOFU, then
they'd be secure unless the agencies already MitM most or all of them at
the "OFU" stage of TOFU.
But, since one can find out later (e.g. by really comparing the
credentials when meeting the actual peer) people would notice that mass
surveillance is still in place... and then...
then..
then...
then what?
A big outcry? Governments changing the system and stopping mass
surveillance? People start switching to really secure (i.e. mutually
authenticated communication)?
Forgot it already? We've had these things already! A big scandal. A big
outcry.
What happend? Nothing (at least on "their" side).
Actually quite the contrary - what paranoid people just assumed to be
the case (i.e. the mass surveillance before) is now publicly confirmed
and justified by NSA/Co.
So, to all the proponents of TOFU/key pinning and that like:
How can you dare to make assumption (2)?
How can you dare to believe that this would prevent NSA/Co. from
attacking (in the form of surveillance) people?
We already know that they do much worse things (like actively breaking
into computer systems, computer sabotage, and so on), they're basically
the same as cyber criminals just that they do it for the "good"[2] and
that they don't need to fear any consequences (in contrast to cyber
criminals; remember that people who illegally copy a video get worse
punishment than rapists or murderers).
IMHO, TOFU won't help you at all against mass surveillance:
- As said above, it won't keep the high level attackers (NSA level,
which are the typical bodies for mass surveillance) from doing their
business.
If everyone would do opportunistic encryption in conjunction with TOFU,
they would simply adapt and MitM every connection they can. It would be
publicly known, just as their mass surveillance is known now.
- The next lower level of attackers who do mass surveillance are
actually the big companies which now try to sell security to people
(Google, Facebook and that like).
For them it would actually get harder to do surveillance (because they
cannot easily operate outside the law). But their form of surveillance
is anyway completely different.
People voluntarily (actually just happily) give them all their data
(look at Facebook).
So they don't care about encryption as an enemy at all
- Last but not least, cyber criminals.
They typically don't care so much about mass surveillance, and even if
they would: They already operate outside the law, so as soon as they can
MitM people - they would.
Last but not least, some motivational analysis and my personal opinion
about how TOFU-like ideas affects security of single people as well as
the masses.
TOFU is IMHO clearly indented for the masses, i.e. those who don't know
to much about crypto, and simply want to use the web. Why? Well simply
because it doesn't give any real strong additional security. So all the
paranoid people, or experts and that like, they likely simply would want
to continue with their safe mutually performed authentication (be it for
OpenPGP, or accessing an SSH server).
So the argument by proponents is often:
3) "that we (i.e. software developers, standard makers, other experts)
need to secure the masses".
Remember the beginning of my lengthy mail (sorry for that btw.)? Were I
basically wrote that noone (not even the banks who loose money) care
about the flaws of the X.509 model?
That's just it. No one cares. At least not until people would suffer
more severe consequences.
Mass surveillance? Well all people complain, but apart from a few none
of them *really* cares (because if, then they would look for ways to
protect themselves).
A hacked email account or the knowledge that all unencrypted
emails/Whatsupp/etc. can be read either by anyone or at least some
others? Do you really think the masses(!) would care?
A few cases of hacked bank accounts? Well that's perhaps when people
start to get annoyed, but as long as the banks pay for the damage...
this ain't a big deal either.
So when it comes to (3) I really wonder:
Why would "we" need to secure the masses, when they typically don't care
anyway? At least not above the level of says "yeah it's a shame that XYZ
happens.." + secretly thinking .oO(but I don' really care either).
Don't get me wrong, I don't say that we should remove security/crypto
from the masses.
But I don't see why we should be obliged to introduce TOFU (for which
it's IMHO questionable whether it increases security at all) when we
already have a system which works for the masses:
X.509
Apart from allowing forgeries and surveillance, and apart from single
cases where this was even done by Cybercriminals (remember when the
reserved the TLD www.p?ypal.com[3] or something like that and got a
certificate for it).
So much for the question, why would the masses want TOFU.
And I'm not going to analyse now which motivation some bigger (e.g. US)
players may actually have to advertise key pinning and that like now as
a big step forward so that people feel secure again.
Honi soit qui mal y pense!
Long story short, my analysis of the TOFU principle and key pinning
methods is the following:
a) at best, it would give people a short longing improvement in they
security, *if* (and only *if* and as long) attackers don't decide to
already start attacking[4] them at the "OFU" stage.
b) at worst - people could assume - it wouldn't harm either
but I think that's wrong:
more realistically:
c) the massive campaign in favour of TOFU that we see at all different
levels: standards making (yeah, HTML2 has now nearly-mandatory
encryption - so it's secure, isn't it?), development and the communities
has IMHO actually quite a number of dangers:
- The masses will actually believe that they'd be now at least more
secure than before.
Thus they will care less about their effective security and even less
about the political dimension of the whole topic.
In the light of new crypto wars being probably just started - quite
bad.[5]
- Developers, standard makers and experts actually start believing the
illusion of TOFU and care less about implementing stronger rock solid
mutually authenticated crypto systems.
- Which in turn will (in the long term) also affect those people (like
most/many OpenPGP users) who really wanted strong security, and who
put their efforts into it.
Simply because less software/standards may provide that strong
security.
In the end, the minority who really wants (and or needs) security, would
likely start to suffer for a majority who even doesn't care about it.
Best wishes,
Chris.
[0] And just to prevent Werner from the usual comment: yes I know,
OpenPGP doesn't mandate this or the WoT,... but I guess one can easily
say that it's mostly used in that way.
[1] And yes I use such harsh words, because people already believed in
the past the intelligence services, cybercriminals weren't capable of
this and that (or at least not doing it)... and they did as if it was a
complete surprise when Snowden revealed his stuff. And now, where they
should know much better, they do it again.
[2] And no I'm not questioning here whether this is the case or not,
actually I don't believe that NSA/BND/Co. are evil per se.
[3] I assume everyone noticed the first a being actually not an a but a
U+0430 CYRILLIC SMALL LETTER A.
[4] And we must generally assume that an attacker has no reason not to,
since he'll always attack the weakest chain in the target. So if he
finds something weaker, e.g. flash installed ;-) he'll take that, but if
there's no better alternative, why should he not do MitM respectively
mass MitMs?
[5] And probably quite bad for Snowden, cause the first day Putin sees
no PR use in him anymore and the US would have to offer anything, we'll
probably disappear forever in some US supermax.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
From dkg at fifthhorseman.net Wed Apr 1 00:43:35 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 31 Mar 2015 18:43:35 -0400
Subject: gpg --list-keys performance [was: Re: GnuPG 2.1.2 making tons of
syscalls]
In-Reply-To: <20150330120738.GA10435@localhost>
References: <20150225091420.GA2052@localhost>
<20150330120738.GA10435@localhost>
Message-ID: <87bnj8hjoo.fsf@alice.fifthhorseman.net>
On Mon 2015-03-30 08:07:38 -0400, Guilhem Moulin wrote:
> On Wed, 25 Feb 2015 at 10:14:20 +0100, Guilhem Moulin wrote:
>> $ time gpg --homedir /tmp/gnupg1 --list-sigs >/dev/null
>> 1:57.54 (83.55 user, 33.57 sys) 9264k maxres
>> $ time gpg2 --homedir /tmp/gnupg2 --list-sigs >/dev/null
>> 2:24:34 (564.61 user, 8083.49 sys) 14936k maxres
>> [?]
>> The second timming is really odd: over 2h of system time? Surely it
>> must be a bug.
>> [?]
>> $ time gpg --homedir /tmp/gnupg1 --list-sigs 0x39278DA8109E6244 >/dev/null
>> 0:17.24 (11.72 user, 5.46 sys) 8852k maxres
>> $ time gpg2 --homedir /tmp/gnupg2 --list-sigs 0x39278DA8109E6244 >/dev/null
>> 0:30.85 (3.26 user, 27.50 sys) 14564k maxres
>
> Doesn't anyone acknowledge this behavior and the fact that it's a bug?
> I can't believe all these syscalls are intended, somehow. Incidentally,
> Jesus Cea made a similar observation (with 2.0.27) when updating the
> trustdb:
>
> http://lists.gnupg.org/pipermail/gnupg-users/2015-March/053343.html
I'm seeing the same behavior you're seeing, and yes, it seems like a
problem.
I also see that you've opened a related bug report here:
https://bugs.g10code.com/gnupg/issue1710
maybe it would be good to file separate bug reports for each specific
issue so we can track them down? the TL;DR of your initial post had a
number of good independent details.
Have you tried profiling the extremely slow invocations with "valgrind
--tool=callgrind" ? that might yield some hints about where to start
fixing the problem.
--dkg
From calestyo at scientia.net Wed Apr 1 00:48:50 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Wed, 01 Apr 2015 00:48:50 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <1427841635.17032.147.camel@scientia.net>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net>
Message-ID: <1427842130.17032.151.camel@scientia.net>
Perhaps two small additions which just popped up in my mind:
a) regarding the "we must secure a majority who actually doesn't
*really* care about security" a funny analogy came into my mind:
Does anyone know any insurance companies that give their insurances
for free to customers who don't want them? ;)
b) For those who want a "simpler to use" (i.e. one that doesn't required
proper mutual authentication) crypto system for email, systems like
CAcert would IMHO do the job at a better level than TOFU.
Cheers :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
From calestyo at scientia.net Wed Apr 1 03:36:06 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Wed, 01 Apr 2015 03:36:06 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <1427841635.17032.147.camel@scientia.net>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net>
Message-ID: <1427852166.17032.171.camel@scientia.net>
And perhaps one further reason why massive MitM attacks would likely not
noticed:
There's an (hopefully) April Fool's Day joke today on German Magazine
heise[0], which tells the story how the NSA cooperates with Facebook in
order to control government critical demonstrations/protests/etc..
The story tells how they "made" a program were messages between
protesters were manipulated so that they came all to the wrong places or
at wrong times.
The "internal study" of the NSA concluded that masses can be much better
controlled by subtly manipulating them and it's much better than simply
blocking their messages. They also concluded that this would have great
psychological impact on the organisers of such protests (e.g. against
TTIP, ACTA and that like), cause when no people showed up, they would
think the public isn't on their side after a few failures and give up.
So far this is just a nice, unfortunately far too realistically possible
story and if something like that would really be true, the point of
totalitarian dictatorship would have been definitely crossed - one that
no one even recognises unless he's part of the system.
The aspect which makes it interesting concerning the argumentation my
rant against TOFU is the following:
In that story the NSA is aware that the "core people" of such
demonstrations would notice if they are manipulated, so they're simply
left out and get the real data.
This is basically one more reason why the pro-TOFU argument (2) in my
previous mail (i.e. that people would notice as mass-MitM) is moot
(apart from the major reason/fact that, even if they'd notice it
wouldn't change anything):
Mass surveillance power like the NSA can probably determine which people
are likely to ever really mutually authenticate properly (and thus
notice a massive MitM attack) and just exclude these (and attack them
via other means).
We already know that the "mark" people just using Tor and those who are
really involved in crypto development are "marked" for sure as well.
I wouldn't be surprised if their have a internal "Werner-Koch-Sucks"
nursery school and a "DJB-is-Evil" Kindergarden. ;-)
In fact, we cannot even know for 100% sure whether we're all reading the
same mailing list.
Maybe my rant against TOFU shows up completely different approving it on
your side.
Maybe hypothetical concerns from some experts against Goldilocks never
appeared as such when they posted it to the CFRG mailing list.
But whenever one looks at the mailing list archives, one sees his
personal (non-manipulated) version.
Cheers,
Chris.
[0] http://www.heise.de/newsticker/meldung/NSA-Skandal-Facebook-unterwandert-Flashmob-Verabredungen-2592853.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
From gniibe at fsij.org Wed Apr 1 09:57:48 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 01 Apr 2015 16:57:48 +0900
Subject: [PATCH] scd: fix keytocard
Message-ID: <551BA4FC.3090801@fsij.org>
Hello,
This patch is fix for the issue:
https://bugs.g10code.com/gnupg/issue1846
The Patch consists of three parts.
(1) agent: Don't update key storage at the time of KEYTOCARD
(2) agent: Enhance LEARN command to have --force option to update key storage
(3) g10: Fix keyedit to call LEARN --force
This fix is not a perfect solution as there is a possibility (in
theory) that user would remove the smartcard after "keytocard" before
"quit", but I think that it's good enough in practice.
diff --git a/agent/agent.h b/agent/agent.h
index f60061e..d61e634 100644
--- a/agent/agent.h
+++ b/agent/agent.h
@@ -495,7 +495,7 @@ int agent_card_scd (ctrl_t ctrl, const char *cmdline,
/*-- learncard.c --*/
-int agent_handle_learn (ctrl_t ctrl, int send, void *assuan_context);
+int agent_handle_learn (ctrl_t ctrl, int send, void *assuan_context, int force);
/*-- cvt-openpgp.c --*/
diff --git a/agent/command.c b/agent/command.c
index 96fbf19..3188bbd 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -1655,25 +1655,27 @@ cmd_get_confirmation (assuan_context_t ctx, char *line)
static const char hlp_learn[] =
- "LEARN [--send][--sendinfo]\n"
+ "LEARN [--send] [--sendinfo] [--force]\n"
"\n"
"Learn something about the currently inserted smartcard. With\n"
"--sendinfo information about the card is returned; with --send\n"
- "the available certificates are returned as D lines.";
+ "the available certificates are returned as D lines; with --force\n"
+ "private key storage will be updated by the result.";
static gpg_error_t
cmd_learn (assuan_context_t ctx, char *line)
{
ctrl_t ctrl = assuan_get_pointer (ctx);
gpg_error_t err;
- int send, sendinfo;
+ int send, sendinfo, force;
send = has_option (line, "--send");
sendinfo = send? 1 : has_option (line, "--sendinfo");
+ force = has_option (line, "--force");
if (ctrl->restricted)
return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));
- err = agent_handle_learn (ctrl, send, sendinfo? ctx : NULL);
+ err = agent_handle_learn (ctrl, send, sendinfo? ctx : NULL, force);
return leave_cmd (ctx, err);
}
@@ -2409,12 +2411,10 @@ cmd_keytocard (assuan_context_t ctx, char *line)
gpg_error_t err = 0;
unsigned char grip[20];
gcry_sexp_t s_skey = NULL;
- gcry_sexp_t s_pkey = NULL;
unsigned char *keydata;
size_t keydatalen, timestamplen;
const char *serialno, *timestamp_str, *id;
unsigned char *shadow_info = NULL;
- unsigned char *shdkey;
time_t timestamp;
if (ctrl->restricted)
@@ -2492,48 +2492,8 @@ cmd_keytocard (assuan_context_t ctx, char *line)
snprintf (keydata+keydatalen-1, 30, "(10:created-at10:%010lu))", timestamp);
keydatalen += 10 + 19 - 1;
err = divert_writekey (ctrl, force, serialno, id, keydata, keydatalen);
- if (err)
- {
- xfree (keydata);
- goto leave;
- }
- xfree (keydata);
-
- err = agent_public_key_from_file (ctrl, grip, &s_pkey);
- if (err)
- goto leave;
-
- shadow_info = make_shadow_info (serialno, id);
- if (!shadow_info)
- {
- err = gpg_error (GPG_ERR_ENOMEM);
- gcry_sexp_release (s_pkey);
- goto leave;
- }
- keydatalen = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0);
- keydata = xtrymalloc (keydatalen);
- if (keydata == NULL)
- {
- err = gpg_error_from_syserror ();
- gcry_sexp_release (s_pkey);
- goto leave;
- }
- gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keydata, keydatalen);
- gcry_sexp_release (s_pkey);
- err = agent_shadow_key (keydata, shadow_info, &shdkey);
xfree (keydata);
- xfree (shadow_info);
- if (err)
- {
- log_error ("shadowing the key failed: %s\n", gpg_strerror (err));
- goto leave;
- }
-
- keydatalen = gcry_sexp_canon_len (shdkey, 0, NULL, NULL);
- err = agent_write_private_key (grip, shdkey, keydatalen, 1);
- xfree (shdkey);
- leave:
return leave_cmd (ctx, err);
}
diff --git a/agent/learncard.c b/agent/learncard.c
index 62569ce..b7ce633 100644
--- a/agent/learncard.c
+++ b/agent/learncard.c
@@ -299,7 +299,7 @@ send_cert_back (ctrl_t ctrl, const char *id, void *assuan_context)
/* Perform the learn operation. If ASSUAN_CONTEXT is not NULL and
SEND is true all new certificates are send back via Assuan. */
int
-agent_handle_learn (ctrl_t ctrl, int send, void *assuan_context)
+agent_handle_learn (ctrl_t ctrl, int send, void *assuan_context, int force)
{
int rc;
diff --git a/g10/call-agent.c b/g10/call-agent.c
index 4bac8a0..fa643a1 100644
--- a/g10/call-agent.c
+++ b/g10/call-agent.c
@@ -673,7 +673,7 @@ learn_status_cb (void *opaque, const char *line)
/* Call the scdaemon to learn about a smartcard */
int
-agent_scd_learn (struct agent_card_info_s *info)
+agent_scd_learn (struct agent_card_info_s *info, int force)
{
int rc;
struct default_inq_parm_s parm;
diff --git a/g10/call-agent.h b/g10/call-agent.h
index 9c104e8..df570a4 100644
--- a/g10/call-agent.h
+++ b/g10/call-agent.h
@@ -77,7 +77,7 @@ struct agent_card_genkey_s {
void agent_release_card_info (struct agent_card_info_s *info);
/* Return card info. */
-int agent_scd_learn (struct agent_card_info_s *info);
+int agent_scd_learn (struct agent_card_info_s *info, int force);
/* Send an APDU to the card. */
gpg_error_t agent_scd_apdu (const char *hexapdu, unsigned int *r_sw);
diff --git a/g10/card-util.c b/g10/card-util.c
index 4b584bf..a291a07 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -81,7 +81,7 @@ change_pin (int unblock_v2, int allow_admin)
struct agent_card_info_s info;
int rc;
- rc = agent_scd_learn (&info);
+ rc = agent_scd_learn (&info, 0);
if (rc)
{
log_error (_("OpenPGP card not available: %s\n"),
@@ -374,7 +374,7 @@ card_status (estream_t fp, char *serialno, size_t serialnobuflen)
if (serialno && serialnobuflen)
*serialno = 0;
- rc = agent_scd_learn (&info);
+ rc = agent_scd_learn (&info, 0);
if (rc)
{
if (opt.with_colons)
@@ -1702,7 +1702,7 @@ factory_reset (void)
but tries to find out something about the card first.
*/
- err = agent_scd_learn (&info);
+ err = agent_scd_learn (&info, 0);
if (gpg_err_code (err) == GPG_ERR_OBJ_TERM_STATE
&& gpg_err_source (err) == GPG_ERR_SOURCE_SCD)
termstate = 1;
diff --git a/g10/keyedit.c b/g10/keyedit.c
index 91f5dae..2f9469f 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -1450,6 +1450,7 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
char *answer = NULL;
int redisplay = 1;
int modified = 0;
+ int sec_shadowing = 0;
int run_subkey_warnings = 0;
int toggle;
int have_commands = !!commands;
@@ -1836,8 +1837,7 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
if (card_store_subkey (node, xxpk ? xxpk->pubkey_usage : 0))
{
redisplay = 1;
- /* Only the secret key has been modified; thus
- there is no need to set the modified flag. */
+ sec_shadowing = 1;
}
}
}
@@ -1923,7 +1923,7 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
if (card_store_subkey (node, 0))
{
redisplay = 1;
- /* FIXME:sec_modified = 1;*/
+ sec_shadowing = 1;
}
}
release_kbnode (node);
@@ -2182,7 +2182,7 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
case cmdQUIT:
if (have_commands)
goto leave;
- if (!modified)
+ if (!modified && !sec_shadowing)
goto leave;
if (!cpr_get_answer_is_yes ("keyedit.save.okay",
_("Save changes? (y/N) ")))
@@ -2204,7 +2204,18 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr,
break;
}
}
- else
+
+ if (sec_shadowing)
+ {
+ err = agent_scd_learn (NULL, 1);
+ if (err)
+ {
+ log_error (_("update failed: %s\n"), gpg_strerror (err));
+ break;
+ }
+ }
+
+ if (!modified && !sec_shadowing)
tty_printf (_("Key not changed so no update needed.\n"));
if (update_trust)
diff --git a/g10/keygen.c b/g10/keygen.c
index 769e193..4b0398a 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -4487,7 +4487,7 @@ gen_card_key (int algo, int keyno, int is_primary, kbnode_t pub_root,
/* Send the learn command so that the agent creates a shadow key for
card key. We need to do that now so that we are able to create
the self-signatures. */
- err = agent_scd_learn (NULL);
+ err = agent_scd_learn (NULL, 0);
if (err)
{
/* Oops: Card removed during generation. */
--
From guilhem at fripost.org Wed Apr 1 16:50:23 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Wed, 1 Apr 2015 16:50:23 +0200
Subject: gpg --list-keys performance [was: Re: GnuPG 2.1.2 making tons of
syscalls]
In-Reply-To: <87bnj8hjoo.fsf@alice.fifthhorseman.net>
References: <20150225091420.GA2052@localhost>
<20150330120738.GA10435@localhost>
<87bnj8hjoo.fsf@alice.fifthhorseman.net>
Message-ID: <20150401145023.GA1515@localhost>
On Tue, 31 Mar 2015 at 18:43:35 -0400, Daniel Kahn Gillmor wrote:
> I also see that you've opened a related bug report here:
>
> https://bugs.g10code.com/gnupg/issue1710
>
> maybe it would be good to file separate bug reports for each specific
> issue so we can track them down? the TL;DR of your initial post had a
> number of good independent details.
Thanks for the suggestion. I filed https://bugs.g10code.com/gnupg/issue1938
and https://bugs.g10code.com/gnupg/issue1939 for the other two points of
my initial mail.
> Have you tried profiling the extremely slow invocations with "valgrind
> --tool=callgrind" ? that might yield some hints about where to start
> fixing the problem.
After a quick look (have to improve my debugging skills I'm afraid :-P)
gpg2 --homedir /tmp/gnupg1 --with-colons --list-sigs 0x39278DA8109E6244
8,581,286,919 ???:0x00030690 [/usr/bin/gpg2]
3,747,695,772 ???:0x0002d4a0 [/usr/bin/gpg2]
3,714,625,963 ???:_transform [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
2,251,439,456 ???:_gcry_mpi_scan [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
1,812,455,446 ???:0x00092930 [/usr/bin/gpg2]
979,689,330 ???:0x00033530 [/usr/bin/gpg2]
845,059,243 ???:do_get_buffer [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
742,384,639 /build/glibc-jhsZw7/glibc-2.19/malloc/malloc.c:_int_malloc [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
497,838,818 /build/glibc-jhsZw7/glibc-2.19/malloc/malloc.c:_int_free [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
405,209,527 ???:_gcry_md_block_write [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
gpg2 --homedir /tmp/gnupg2 --with-colons --list-sigs 0x39278DA8109E6244
542,468,568 ???:0x0002d4a0 [/usr/bin/gpg2]
383,560,000 ???:0x0006c920 [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
325,177,890 ???:_gcry_mpi_scan [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
293,168,038 /build/glibc-jhsZw7/glibc-2.19/string/../sysdeps/i386/i686/multiarch/../memcpy.S:__GI_memcpy [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
276,299,702 /build/glibc-jhsZw7/glibc-2.19/malloc/malloc.c:_int_malloc [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
262,348,939 /build/glibc-jhsZw7/glibc-2.19/string/../sysdeps/i386/i686/multiarch/../mempcpy.S:__GI_mempcpy [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
182,778,924 ???:0x0008fda0 [/usr/bin/gpg2]
181,082,759 /build/glibc-jhsZw7/glibc-2.19/malloc/malloc.c:_int_free [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
145,235,430 ???:0x0006c8d8 [/lib/i386-linux-gnu/libgcrypt.so.20.0.3]
102,452,710 /build/glibc-jhsZw7/glibc-2.19/libio/getc.c:getc [/lib/i386-linux-gnu/i686/cmov/libc-2.19.so]
I guess I must compile gpg with debugging symbols to get proper
functions names, but these billions calls are somewhat scary :-P
--
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From dkg at fifthhorseman.net Wed Apr 1 19:26:56 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 01 Apr 2015 13:26:56 -0400
Subject: [openpgp] Encrypting / Signing the mail subject?
In-Reply-To:
References:
Message-ID: <87bnj7g3of.fsf@alice.fifthhorseman.net>
On Sat 2015-03-28 10:19:54 -0400, Albrecht Dre? wrote:
> And I think it's not necessary if RFC 5751 would simply define that
> the "inner" protected message container *must* have the same
> Message-ID as the "outer" one. If anyone is concerned that this
> violates the requirement of uniqueness (RFC 5322, sect. 3.6.4), the
> inner container could have instead of the "Message-ID" (which is *not*
> required!) something like a "Protected-Message-ID" with the same
> value. If someone tampered with the "outer" message-id, the receiving
> MUA could still detect this case by the presence of the
> "Protected-Message-ID". This approach would *not* break compatibility
> with existing implementations.
requiring the inner-message-id to be identical to the outer message-id
would mean that you would not be able to hide the message-id in an
encrypted message.
hiding the message-id would be useful, for example, when sending the
same message to multiple mailboxes, encrypted separately, but not
wanting the server operators to be able to link those messages together
as the same message.
--dkg
From gniibe at fsij.org Thu Apr 2 05:31:23 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 02 Apr 2015 12:31:23 +0900
Subject: Should I mark/announce GNOME as incompatible with gpg2 for now?
In-Reply-To: <53FF49B0.3010603@thewalter.net>
References: <53FF0869.8090201@thewalter.net> <53FF3D4A.9050005@fsij.org>
<53FF49B0.3010603@thewalter.net>
Message-ID: <551CB80B.6060600@fsij.org>
Hello,
This message is reply to the one in August 2014, since I keep
seeing reports from GnuPG users.
On 08/29/2014 12:24 AM, Stef Walter wrote:
> On 28.08.2014 16:31, NIIBE Yutaka wrote:
>> Hello,
>>
>> It's not new. It has been incompatible for years, already.
>>
>> On 08/28/14 19:46, Stef Walter wrote:
>>> Should I go ahead and announce that gpg2 (version 2.0.23+) is
>>> incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x
>>> for now?
>>
>> Please note that gpg-agent is not the "GPG password caching daemon".
>>
>> It's not new issue for smartcard/token users and SSH users for gpg2
>> (both of 2.0 and 2.1) with GNOME.
>>
>> (1) When users have smartcard/token, it doesn't work well.
>>
>> (2) When users configure the SSH-agent feature of gpg-agent, it
>> doesn't work well.
>>
>> We need to disable the features of gnome-keyring, for years.
>>
>> However, how to disable the features of gpg-agent/ssh-agent for
>> gnome-keyring has been changed in version to version. I had figured
>> out how to do that in GNOME2 and in younger GNOME 3, but now, I don't
>> know how we can disable the features in GNOME 3.12 or later (using
>> proper gpg-agent).
>
> I'm not against contributions which remove the gpg-agent and ssh-agent
> from gnome-keyring. The equivalent features and use cases should be
> provided elsewhere, and it's a done deal.
I wonder if you could consider applying the following patch (against
master of gnome-keyring git repo) as a first step.
This can be a message that the features are minor and possibly should
not be used as a default.
diff --git a/configure.ac b/configure.ac
index 6e6a92c..17120a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -337,34 +337,34 @@ fi
#
AC_ARG_ENABLE([ssh-agent],
- AC_HELP_STRING([--disable-ssh-agent],
- [Don't include SSH agent in gnome-keyring]))
+ AC_HELP_STRING([--enable-ssh-agent],
+ [Include SSH agent in gnome-keyring]))
-if test "$enable_ssh_agent" != "no"; then
+if test "$enable_ssh_agent" = "yes"; then
AC_DEFINE(WITH_SSH, 1, [Whether to build SSH agent or not])
ssh_status="yes"
else
ssh_status="no"
fi
-AM_CONDITIONAL(WITH_SSH, test "$enable_ssh_agent" != "no")
+AM_CONDITIONAL(WITH_SSH, test "$enable_ssh_agent" = "yes")
# --------------------------------------------------------------------
# GPG Agent support
#
AC_ARG_ENABLE([gpg-agent],
- AC_HELP_STRING([--disable-gpg-agent],
- [Don't include GPG agent in gnome-keyring]))
+ AC_HELP_STRING([--enable-gpg-agent],
+ [Include GPG agent in gnome-keyring]))
-if test "$enable_gpg_agent" != "no"; then
+if test "$enable_gpg_agent" = "yes"; then
AC_DEFINE(WITH_GPG, 1, [Whether to build GPG agent or not])
gpg_status="yes"
else
gpg_status="no"
fi
-AM_CONDITIONAL(WITH_GPG, test "$enable_gpg_agent" != "no")
+AM_CONDITIONAL(WITH_GPG, test "$enable_gpg_agent" = "yes")
# --------------------------------------------------------------------
# libgcrypt
--
From patrick-mailinglists at whonix.org Thu Apr 2 15:29:39 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Thu, 02 Apr 2015 13:29:39 +0000
Subject: gpg-bash-lib - gpg file verification bash library - first public
release announcement - 0.5-1
Message-ID: <551D4443.9020808@whonix.org>
gpg-bash-lib is a gpg file verification bash library, addresses
comprehensive threat model, that covers file name tampering, indefinite
freeze, rollback, endless data attacks, etc.
https://github.com/Whonix/gpg-bash-lib
Why?
Writing bash scripts that do file verification using gpg that really is
secure and passes a comprehensive threat model, that covers indefinite
freeze, rollback, endless data attacks, etc. is hard.
gpg-bash-lib's goal is to provide a bash library that we can
collaboratively develop, audit and abstract the hard work into reuseable
functions.
Checking gpg exit codes only is insufficient. Quote Werner Koch [1]
(gnupg lead developer):
"there is no clear distinction between the codes and for proper
error reporting you are advised to use the --status-fd messages."
(For a definition of these attacks, see TUF [2] (The Update Framework)'s
[3] threat model [4] [5].)
Mini Demo:
After installation, if you would run the following command.
/usr/share/gpg-bash-lib/examples/one
You would see the following output.
your_script_begin: ...
verification: BEGIN
verification: END
your_script_output: BEGIN
gpg_bash_lib_output_failure_status: false
gpg_bash_lib_output_gpg_verify_exit_code: 0
gpg_bash_lib_output_goodsig_status: true
gpg_bash_lib_output_validsig_status: true
gpg_bash_lib_output_fingerprint_in_hex:
5E08605EBEA0FE88695DCB88FD0A8B4171DFE4E4
gpg_bash_lib_output_signed_on_unixtime: 1422049448
gpg_bash_lib_output_signed_on_date: March 01 13:56:27 UTC 2015
gpg_bash_lib_output_notation[$file at name]: test-file
gpg_bash_lib_output_file_name_tampering: false
gpg_bash_lib_output_freshness_status: true
gpg_bash_lib_output_freshness_detail: current
gpg_bash_lib_output_freshness_msg:
- Freshness: Signature is current.
- valid-max: Signatures are valid up to 30 days.
- Signature Creation Date: March 01 13:56:27 UTC 2015
- Current System Date : March 02 16:0:55 UTC 2015
- Local System Clock: Your clock seems okay.
- Relative Signature Creation Time: According to your system clock,
signature was created 2 days 26 minutes 3 seconds ago.
gpg_bash_lib_output_alright_status: true
your_script_output: END
All information (Signature Creation Date, etc.) are easily accessible
through separate variables, which are all documented.
Documentation:
https://github.com/Whonix/gpg-bash-lib/blob/master/README.mediawiki
Usage examples:
https://github.com/Whonix/gpg-bash-lib/tree/master/usr/share/gpg-bash-lib/examples
Main code file:
https://github.com/Whonix/gpg-bash-lib/blob/master/usr/lib/gpg-bash-lib/modules.d/50_common
Specifically, does the status-fd parsing code look sane?
https://github.com/Whonix/gpg-bash-lib/blob/d6cff902f40135c3e100a5bb13a6fe8275a41828/usr/lib/gpg-bash-lib/modules.d/50_common#L350
Could you leave some feedback please?
Anyone else interested to contribute?
Cheers,
Patrick
[1] http://lists.gnupg.org/pipermail/gnupg-devel/2005-December/022559.html
[2] https://www.updateframework.com/
[3] https://github.com/theupdateframework/tuf
[4] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md
[5] http://www.webcitation.org/6F7Io2ncN
From gniibe at fsij.org Fri Apr 3 11:06:25 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 03 Apr 2015 18:06:25 +0900
Subject: [PATCH] scd: fix keytocard
In-Reply-To: <551BA4FC.3090801@fsij.org>
References: <551BA4FC.3090801@fsij.org>
Message-ID: <551E5811.8050905@fsij.org>
On 04/01/2015 04:57 PM, NIIBE Yutaka wrote:
> This patch is fix for the issue:
> https://bugs.g10code.com/gnupg/issue1846
>
> The Patch consists of three parts.
>
> (1) agent: Don't update key storage at the time of KEYTOCARD
> (2) agent: Enhance LEARN command to have --force option to update key storage
> (3) g10: Fix keyedit to call LEARN --force
>
> This fix is not a perfect solution as there is a possibility (in
> theory) that user would remove the smartcard after "keytocard" before
> "quit", but I think that it's good enough in practice.
I updated the patch to really does (2), and commit/push-ed to master
after some tests with Gnuk Token.
For 2.1, this --force option of learn command can be used for the issie
1798: https://bugs.g10code.com/gnupg/issue1798
--
From jose.castillo at gmail.com Fri Apr 3 23:30:42 2015
From: jose.castillo at gmail.com (Jose Castillo)
Date: Fri, 3 Apr 2015 17:30:42 -0400
Subject: Proposal for multiple keys on an OpenPGP smart card
Message-ID:
Ever since reading a wishlist for a next-gen OpenPGP card in February [1], the idea of multiple decryption keys on a card has seemed like a great idea to me. Others in the conversation suggested that it might be advantageous to have generic slots for keys, such that a card could contain more than one signing or authentication key. After delving into the relevant ISO smart card specs, I have a thought as to how this could be added to the OpenPGP smart card specification. I?ve written up a proposal, which I?m including below.
The proposal uses the ISO 7816 ?Manage Security Environment? command to swap between different sets of keys on a single card. I added this to an existing JavaCard implementation as a quick experiment [2], and was able to fit 21 2048-bit RSA keys on a stock 40K card before running out of space. Swapping between these keys is simple; the command just manipulates a pointer to the current security environment, and it?s backwards-compatible; gpg --card-status only sees the default security environment since it resets whenever the application is selected.
This isn?t a fully-formed idea yet, and I?m not a smart card expert; there may be something completely off base in here. Still I wanted to throw it out there in the hope that it might move the conversation forward. I?d love to see some way to support multiple keys on an OpenPGP smart card in the future.
- Joey
[1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052683.html
[2]: https://github.com/josecastillo/OpenPGP-Card/tree/securityenvironment/
-----
Proposal: Multiple keys on OpenPGP Smart Card
=============================================
The OpenPGP smart card supports the use of three keys: a key each for signature, decipherment and authentication. The goal of this proposal is to include a standards-compliant method for supporting multiple keys of each type on the same smart card. There are two main use cases for this functionality:
1. Allow for the storage of expired or revoked decipherment keys, such that users can continue to decipher old messages with their card even if they generate a new key.
2. Allow for the storage of multiple identities on a single smart card.
The mechanism proposed for this functionality is the ISO 7816 command MANAGE SECURITY ENVIRONMENT, which according to the spec, "prepares secure messaging and security commands (e.g., EXTERNAL, INTERNAL and GENERAL AUTHENTICATE, see also PERFORM SECURITY OPERATION)".
Under this proposal, cards may support up to 20 security environments. The security environment encapsulates all data related to cryptographic tasks that are performed on the card; specifically, each security environment encapsulates:
* Slots for signing, decipherment and authentication keys.
* A set of key fingerprint DO's (C7, C8, C9)
* A set of key generation timestamp DO's (CE, CF, D0)
* If supported, a writable set of algorithm attributes (C1, C2, C3)
* An independent signature counter
When the OpenPGP application is selected, it is operating in the default security environment, which has a SEID of 1. Using the commands outlined below, the terminal can switch the card into another security environment.
When the terminal queries the data objects listed above, or any constructed DO that includes them, the card returns the relevant data for the current SE. PUT DATA commands for these DO's store the data in the current SE. Commands that put or generate keys store them in the current SE. PSO and INTERNAL AUTHENTICATE operations operate with the keys in the current SE. Signatures made while in a SE increment the signature counter for that SE.
Indicating support for Security Environments
--------------------------------------------
Support for the functionality in this proposal could be indicated by setting a flag in the first byte of the Extended Capabilities DO, which currently has three bits reserved for future use.
Modifications to existing commands
----------------------------------
This proposal requires one modification to an existing command. Space on smart cards is limited, and it may be possible for a card to run out of space before filling all of the available slots for keys. Therefore, when the terminal issues a PUT DATA or GENERATE ASYMMETRIC KEY command, and the card does not have sufficient memory to store the data or key, the card will respond with a SW1-SW2 of 6A84 (Not enough memory space in file), and return the card to the state it was in before the command was issued.
New commands and access conditions
----------------------------------
* RESTORE SECURITY ENVIRONMENT
- Access Condition: Always
* ERASE SECURITY ENVIRONMENT
- Access Condition: VERIFY of PW3
* STORE SECURITY ENVIRONMENT
- Access Condition: VERIFY of PW3
RESTORE SECURITY ENVIRONMENT
----------------------------
* Command:
- INS: 22
- P1: F3
- P2: The SEID to switch to (0x01-0x14)
* Response SW1-SW2:
- 9000: Success
- 6A88: Referenced data not found (SEID out of range)
This command switches the card into the requested security environment. After issuing this command, the terminal should query the Application Related Data DO (6E), which will contain the key metadata and algorithm attributes for the security environment that was requested.
ERASE SECURITY ENVIRONMENT
--------------------------
* Command:
- INS: 22
- P1: F4
- P2: The SEID to erase
* Response SW1-SW2:
- 9000: Success
- 6985: Condition of use not satisfied
- 6A88: Referenced data not found (SEID out of range)
This command erases the keys and DO's in the security environment specified in P2. Implementations that allocate space for keys and DO's on demand may reclaim the space at this time.
STORE SECURITY ENVIRONMENT
--------------------------
* Command:
- INS: 22
- P1: F2
- P2: The SEID to overwrite
* Response SW1-SW2:
- 9000: Success
- 6985: Condition of use not satisfied
- 6A88: Referenced data not found (SEID out of range)
This command moves the keys and DO's in the current SE to the SE specified in P2, overwriting any keys and DO's in that environment, and then switches the card to that SE. The previous SE is replaced with an empty SE.
For example: If the current environment is the default (SE 1), and the terminal issues a STORE SECURITY ENVIRONMENT command for SE 2, all keys and data will be moved to SE 2, and SE 1 will be empty. At the conclusion of the command, the current SE will be SE 2.
Backwards Compatibility
-----------------------
Since the card will always be in the default SE when powered up, this proposal is generally backwards compatible; terminals that do not understand the new commands will always interact with the default security environment, and there are no changes to the format of the data returned from the card.
There is a scenario in which a card with an available key slot in the default SE may not have room for a new key; in this case, the card would return an unexpected response of 6A88 to a PUT DATA or GENERATE ASYMMETRIC KEY command. This scenario bears investigation.
Implications for compatible clients
-----------------------------------
This proposal adds a bit of additional complexity to the use of smart cards; in particular, it might no longer be sufficient for the client to note the serial number of the card where a key is stored. Compatible clients might also have to note which security environment the key resides in. Furthermore, the ability to move keys between security environments might make this even more difficult.
In its desire to be backwards compatible, this proposal does not modify any of the responses from the card application; as such, getting information about all the keys on a card requires switching into each of the available security environments and querying the application related data. It might make sense to add an additional constructed DO for GET DATA that returns information about the available security environments and keys, or expand the Application Related Data DO to add information about the available security environments.
From wk at gnupg.org Sat Apr 4 12:06:13 2015
From: wk at gnupg.org (Werner Koch)
Date: Sat, 04 Apr 2015 12:06:13 +0200
Subject: TOFU - motivation
In-Reply-To: <87bnj9f2fr.wl-neal@walfield.org> (Neal H. Walfield's message of
"Tue, 31 Mar 2015 20:26:48 +0200")
References: <87bnj9f2fr.wl-neal@walfield.org>
Message-ID: <87384g9pii.fsf@vigenere.g10code.de>
On Tue, 31 Mar 2015 20:26, neal at walfield.org said:
> GnuPG. In this note, I want to lay the ground work. This is probably
> uncontroversial, but I think it is important to state it explicitly.
It seems some folks don't like that concepts but after all it is what
Marcus and me suggested in our STEED proposal.
I am not sure who mentioned that years ago on the cryptography list: We
hackers want all the users to understand and use complicated things like
the WoT or Bridge-CAs but for our own day to day work we rely on a
single simple and easy to explain method: ssh's known_hosts. Which is
what we now call TOFU.
> case, an email address) and a key. The idea is the following. The
> first time that we observe a message from a particular email address,
> we record the email and the key. After that, each time we receive a
I think it is important to also offer other ways of seeding this
relationship. For example: Taken from a visiting card, received by
mail, retrieved via DNS(SEC) and so on. Such an origin data field can
can then be used to bump up or down the initial trust one can have in
this key/mail relationship.
> Implementing the logic in GnuPG has a small trade-off: it's not quite
> the right level of abstraction. That is, it is probably easier to
> implement TOFU in an MUA. For instance, if there is a mismatch, the
Right. This has already been discussed more than 10 years ago when we
rewrote Kmail and Mutt where I proposed to also extend the address books
to keep track of fingerprints and communication history. However, the
budget for these projects and their milestone plan did not have enough
room to implement this. To my disappointment no volunteer stepped into
it and added this to the addressbook. Thus I think it is the right
approach to help implementers by offering a GnuPG feature to store and
use this information.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Sat Apr 4 12:19:00 2015
From: wk at gnupg.org (Werner Koch)
Date: Sat, 04 Apr 2015 12:19:00 +0200
Subject: TOFU - motivation
In-Reply-To: <551AFAC7.3020805@sixdemonbag.org> (Robert J. Hansen's message of
"Tue, 31 Mar 2015 15:51:35 -0400")
References: <87bnj9f2fr.wl-neal@walfield.org>
<551AFAC7.3020805@sixdemonbag.org>
Message-ID: <87vbhc8acr.fsf@vigenere.g10code.de>
On Tue, 31 Mar 2015 21:51, rjh at sixdemonbag.org said:
> GnuPG is a toolbox. TOFU is a policy. Keep 'em separated and everyone
> will be happier. That isn't to say you can't do TOFU, just don't expect
> people to be cheerful about the prospect of putting policy into GnuPG.
Sorry, but we already have a policy in GnuPG: --trust-model=foo. The
default is the WoT but many users resort to --trust-model=always which
does only protect against passive attacks and not against any kind of
active attacks (e.g. MitM).
GnuPG allows to override this policy and many frontends have their own
override features or simply implement their own thing. Nobody will be
forced to use a --trust-model=tofu but it is very likely that it will
eventually be the default.
> No, we don't. One email system might be TOFU, and another email system
> might require strong identity checks. Or what about the case of two
> TOFU systems: should system A be required to trust the certificates
> entered by system B? They're both writing to the same GnuPG trust DB,
> after all.
The idea is not to throw away the WoT which is stored in trustdb.gpg but
to implement an additional systems. Whether this will also the same
file or a different one is a technical question and not a policy issue.
> As it currently stands, TOFU would (should) be done at the MUA level.
> When the MUA receives a message, it can call GnuPG to discover the
> certificate used for signing. If the certificate used is not what the
> MUA expects, it can ask the dialog what to do: no upcall required.
Right, this is the idea. What we will implement in GnuPG is just a
database and functions to update and query a database. Now, if a MUA
decides to use a different set of keys and mail addresses (which are our
identities) it is free to use a different --homedir.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Sat Apr 4 12:22:26 2015
From: wk at gnupg.org (Werner Koch)
Date: Sat, 04 Apr 2015 12:22:26 +0200
Subject: TOFU - motivation
In-Reply-To: <551B0045.40403@sixdemonbag.org> (Robert J. Hansen's message of
"Tue, 31 Mar 2015 16:15:01 -0400")
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<87619hhr1p.fsf@alice.fifthhorseman.net>
<551B0045.40403@sixdemonbag.org>
Message-ID: <87r3s08a71.fsf@vigenere.g10code.de>
On Tue, 31 Mar 2015 22:15, rjh at sixdemonbag.org said:
> The Web of Trust handles this by allowing people to decide their own
> trusted introducers. But for system-wide TOFU, *every* application with
> write access to the DB is a trusted introducer.
I think there is a misunderstanding. There won't be a system-wide TOFU.
The database storing the TOFU data will be local to the gnupg home
directory in the very same way as the ownertrust (trustdb.gpg) is.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From achim at pietig.com Sat Apr 4 12:50:16 2015
From: achim at pietig.com (Achim Pietig)
Date: Sat, 04 Apr 2015 12:50:16 +0200
Subject: Proposal for multiple keys on an OpenPGP smart card
In-Reply-To:
References:
Message-ID: <551FC1E8.8040702@pietig.com>
Hi Joey,
the discussion to support multiple key sets is old and relaunches from time to time.
I have a ready design while using Security Environments, as you proposed.
Up to now the idea was rejected by several people because of the complexity in GnuPG and other software that handles the card.
Multiple users also require multiple password sets - this will extend the handling of the card a lot.
Because actual smart cards always belong to a single identity, this topic will get no high priority.
In a few days the next version 3 of the card specification will be launched - it adds elliptic curve cryptography and storage for more certificatees to use the card in other envirionment.
These topics are much more requested than multiple users/key-sets.
After finalising the spec and programming the new card I will check how much space ist available for other key sets - so the topic can be added in a version 3.x later.
An important goal of the actual card is a good price for small volumes! The actual chip has abaut 20K for program and data and I think it will be used completely for the new functions.
Adding multiple keys will lead into a bigger chip with higher costs - it must be checked kow many people need this enhancement and will pay much more for a card...
Regards
Achim
Am 03.04.2015 um 23:30 schrieb Jose Castillo:
> Ever since reading a wishlist for a next-gen OpenPGP card in February [1], the idea of multiple decryption keys on a card has seemed like a great idea to me. Others in the conversation suggested that it might be advantageous to have generic slots for keys, such that a card could contain more than one signing or authentication key. After delving into the relevant ISO smart card specs, I have a thought as to how this could be added to the OpenPGP smart card specification. I?ve written up a proposal, which I?m including below.
>
> The proposal uses the ISO 7816 ?Manage Security Environment? command to swap between different sets of keys on a single card. I added this to an existing JavaCard implementation as a quick experiment [2], and was able to fit 21 2048-bit RSA keys on a stock 40K card before running out of space. Swapping between these keys is simple; the command just manipulates a pointer to the current security environment, and it?s backwards-compatible; gpg --card-status only sees the default security environment since it resets whenever the application is selected.
>
> This isn?t a fully-formed idea yet, and I?m not a smart card expert; there may be something completely off base in here. Still I wanted to throw it out there in the hope that it might move the conversation forward. I?d love to see some way to support multiple keys on an OpenPGP smart card in the future.
>
> - Joey
>
> [1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052683.html
> [2]: https://github.com/josecastillo/OpenPGP-Card/tree/securityenvironment/
>
> -----
>
> Proposal: Multiple keys on OpenPGP Smart Card
> =============================================
>
> The OpenPGP smart card supports the use of three keys: a key each for signature, decipherment and authentication. The goal of this proposal is to include a standards-compliant method for supporting multiple keys of each type on the same smart card. There are two main use cases for this functionality:
>
> 1. Allow for the storage of expired or revoked decipherment keys, such that users can continue to decipher old messages with their card even if they generate a new key.
> 2. Allow for the storage of multiple identities on a single smart card.
>
> The mechanism proposed for this functionality is the ISO 7816 command MANAGE SECURITY ENVIRONMENT, which according to the spec, "prepares secure messaging and security commands (e.g., EXTERNAL, INTERNAL and GENERAL AUTHENTICATE, see also PERFORM SECURITY OPERATION)".
>
> Under this proposal, cards may support up to 20 security environments. The security environment encapsulates all data related to cryptographic tasks that are performed on the card; specifically, each security environment encapsulates:
>
> * Slots for signing, decipherment and authentication keys.
> * A set of key fingerprint DO's (C7, C8, C9)
> * A set of key generation timestamp DO's (CE, CF, D0)
> * If supported, a writable set of algorithm attributes (C1, C2, C3)
> * An independent signature counter
>
> When the OpenPGP application is selected, it is operating in the default security environment, which has a SEID of 1. Using the commands outlined below, the terminal can switch the card into another security environment.
>
> When the terminal queries the data objects listed above, or any constructed DO that includes them, the card returns the relevant data for the current SE. PUT DATA commands for these DO's store the data in the current SE. Commands that put or generate keys store them in the current SE. PSO and INTERNAL AUTHENTICATE operations operate with the keys in the current SE. Signatures made while in a SE increment the signature counter for that SE.
>
> Indicating support for Security Environments
> --------------------------------------------
>
> Support for the functionality in this proposal could be indicated by setting a flag in the first byte of the Extended Capabilities DO, which currently has three bits reserved for future use.
>
> Modifications to existing commands
> ----------------------------------
>
> This proposal requires one modification to an existing command. Space on smart cards is limited, and it may be possible for a card to run out of space before filling all of the available slots for keys. Therefore, when the terminal issues a PUT DATA or GENERATE ASYMMETRIC KEY command, and the card does not have sufficient memory to store the data or key, the card will respond with a SW1-SW2 of 6A84 (Not enough memory space in file), and return the card to the state it was in before the command was issued.
>
> New commands and access conditions
> ----------------------------------
>
> * RESTORE SECURITY ENVIRONMENT
> - Access Condition: Always
> * ERASE SECURITY ENVIRONMENT
> - Access Condition: VERIFY of PW3
> * STORE SECURITY ENVIRONMENT
> - Access Condition: VERIFY of PW3
>
> RESTORE SECURITY ENVIRONMENT
> ----------------------------
>
> * Command:
> - INS: 22
> - P1: F3
> - P2: The SEID to switch to (0x01-0x14)
> * Response SW1-SW2:
> - 9000: Success
> - 6A88: Referenced data not found (SEID out of range)
>
> This command switches the card into the requested security environment. After issuing this command, the terminal should query the Application Related Data DO (6E), which will contain the key metadata and algorithm attributes for the security environment that was requested.
>
> ERASE SECURITY ENVIRONMENT
> --------------------------
>
> * Command:
> - INS: 22
> - P1: F4
> - P2: The SEID to erase
> * Response SW1-SW2:
> - 9000: Success
> - 6985: Condition of use not satisfied
> - 6A88: Referenced data not found (SEID out of range)
>
> This command erases the keys and DO's in the security environment specified in P2. Implementations that allocate space for keys and DO's on demand may reclaim the space at this time.
>
> STORE SECURITY ENVIRONMENT
> --------------------------
>
> * Command:
> - INS: 22
> - P1: F2
> - P2: The SEID to overwrite
> * Response SW1-SW2:
> - 9000: Success
> - 6985: Condition of use not satisfied
> - 6A88: Referenced data not found (SEID out of range)
>
> This command moves the keys and DO's in the current SE to the SE specified in P2, overwriting any keys and DO's in that environment, and then switches the card to that SE. The previous SE is replaced with an empty SE.
>
> For example: If the current environment is the default (SE 1), and the terminal issues a STORE SECURITY ENVIRONMENT command for SE 2, all keys and data will be moved to SE 2, and SE 1 will be empty. At the conclusion of the command, the current SE will be SE 2.
>
> Backwards Compatibility
> -----------------------
>
> Since the card will always be in the default SE when powered up, this proposal is generally backwards compatible; terminals that do not understand the new commands will always interact with the default security environment, and there are no changes to the format of the data returned from the card.
>
> There is a scenario in which a card with an available key slot in the default SE may not have room for a new key; in this case, the card would return an unexpected response of 6A88 to a PUT DATA or GENERATE ASYMMETRIC KEY command. This scenario bears investigation.
>
> Implications for compatible clients
> -----------------------------------
>
> This proposal adds a bit of additional complexity to the use of smart cards; in particular, it might no longer be sufficient for the client to note the serial number of the card where a key is stored. Compatible clients might also have to note which security environment the key resides in. Furthermore, the ability to move keys between security environments might make this even more difficult.
>
> In its desire to be backwards compatible, this proposal does not modify any of the responses from the card application; as such, getting information about all the keys on a card requires switching into each of the available security environments and querying the application related data. It might make sense to add an additional constructed DO for GET DATA that returns information about the available security environments and keys, or expand the Application Related Data DO to add information about the available security environments.
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
From klaus at flittner.org Sat Apr 4 16:50:52 2015
From: klaus at flittner.org (Klaus Flittner)
Date: Sat, 4 Apr 2015 16:50:52 +0200
Subject: Implementation of the openpgp smartcard specification 2.0 for
zeitcontrol basiccard
Message-ID: <20150404165052.2274b7e6@jupiter>
Hello,
some years ago i played with the zeitcontrol basiccards [1] especially the variant ZC7.5 and implemented the OpenPGP Smartcard application on them.
Recently i found the code again and thought it might be of interest to some of you.
In comparison to the official OpenPGP card, this implementation allows command chaining and should thus allow larger keys with more readers, since in my experience extended APDU are not well supported in most smartcard readers.
Be aware that this was only a small project to learn a bit about smartcard communication protocols. So this implementation might be vulnerable to all kind of attacks as i am no specialist in cryptography.
Disclaimer aside the code can be found at:
http://git.27o.de/openpgpcard
Regards,
Klaus Flittner
[1] http://www.zeitcontrol.de/en/products/chip-cards/processor-chip-cards/basiccard
From nicholas.cole at gmail.com Sat Apr 4 18:26:09 2015
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Sat, 4 Apr 2015 17:26:09 +0100
Subject: TOFU - motivation
In-Reply-To: <87r3s08a71.fsf@vigenere.g10code.de>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<87619hhr1p.fsf@alice.fifthhorseman.net>
<551B0045.40403@sixdemonbag.org>
<87r3s08a71.fsf@vigenere.g10code.de>
Message-ID:
On Saturday, 4 April 2015, Werner Koch wrote:
> On Tue, 31 Mar 2015 22:15, rjh at sixdemonbag.org said:
>
> > The Web of Trust handles this by allowing people to decide their own
> > trusted introducers. But for system-wide TOFU, *every* application with
> > write access to the DB is a trusted introducer.
>
> I think there is a misunderstanding. There won't be a system-wide TOFU.
> The database storing the TOFU data will be local to the gnupg home
> directory in the very same way as the ownertrust (trustdb.gpg) is.
>
Why add the complexity of a second database? Why not use a local signature
(perhaps with a special flag). Seems much simpler to me and would work
with existing tools.
N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From patrick at enigmail.net Sun Apr 5 17:33:51 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 5 Apr 2015 17:33:51 +0200
Subject: gpg 2.1: no error message if gpg-agent or pinentry fail
In-Reply-To: <87bnjzmtan.fsf@vigenere.g10code.de>
References: <54DA437F.2020509@enigmail.net>
<87bnjzmtan.fsf@vigenere.g10code.de>
Message-ID: <552155DF.8030805@enigmail.net>
On 11.03.15 16:45, Werner Koch wrote:
> Trying to decrypt something gives these messages:
>
> [...] gpg: public key decryption failed: Tribute to D. A. [GNUPG:]
> ERROR pkdecrypt_failed 67108906 [GNUPG:] BEGIN_DECRYPTION [GNUPG:]
> DECRYPTION_FAILED gpg: decryption failed: No secret key [GNUPG:]
> END_DECRYPTION
>
> Right you can't see the source of the error. Thus we need to look
> at the ERROR status line:
>
> $ gpg-error 67108906 67108906 = (4, 42) = (GPG_ERR_SOURCE_GPGAGENT,
> GPG_ERR_TRIBUTE_TO_D_A) = (GPG Agent, Tribute to D. A.)
As it looks like, gpg-error is not always installed. I think I can
live with it, if I know the source of the error.
Is the following interpretation of the error number correct: ?
- bits 1-24: used for the error code
- bits 25-31: used for the source of the error as defined in
gpg_err_source_t. The error sources are guaranteed to be the same
across all versions of GnuPG.
Thanks
-Patrick
From wk at gnupg.org Sun Apr 5 19:30:11 2015
From: wk at gnupg.org (Werner Koch)
Date: Sun, 05 Apr 2015 19:30:11 +0200
Subject: TOFU - motivation
In-Reply-To:
(Nicholas Cole's message of "Sat, 4 Apr 2015 17:26:09 +0100")
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<87619hhr1p.fsf@alice.fifthhorseman.net>
<551B0045.40403@sixdemonbag.org> <87r3s08a71.fsf@vigenere.g10code.de>
Message-ID: <87zj6m7aak.fsf@vigenere.g10code.de>
On Sat, 4 Apr 2015 18:26, nicholas.cole at gmail.com said:
> Why add the complexity of a second database? Why not use a local signature
> (perhaps with a special flag). Seems much simpler to me and would work
> with existing tools.
Because you would need to sign your key each time you verify a mail from
someone. Sure, it could be put into an unhashed signature subpacket but
maintaining this is pretty complex. For example you need to copy the
data over to the latest valid self-signature and be prepared for
conflicts after importing updates of the key. A separate and random
access DB is much easier to work with when it comes to local data.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From nicholas.cole at gmail.com Mon Apr 6 00:15:21 2015
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Sun, 5 Apr 2015 23:15:21 +0100
Subject: TOFU - motivation
In-Reply-To: <87zj6m7aak.fsf@vigenere.g10code.de>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<87619hhr1p.fsf@alice.fifthhorseman.net>
<551B0045.40403@sixdemonbag.org>
<87r3s08a71.fsf@vigenere.g10code.de>
<87zj6m7aak.fsf@vigenere.g10code.de>
Message-ID:
On Sun, Apr 5, 2015 at 6:30 PM, Werner Koch wrote:
> On Sat, 4 Apr 2015 18:26, nicholas.cole at gmail.com said:
>
>> Why add the complexity of a second database? Why not use a local signature
>> (perhaps with a special flag). Seems much simpler to me and would work
>> with existing tools.
>
> Because you would need to sign your key each time you verify a mail from
> someone. Sure, it could be put into an unhashed signature subpacket but
> maintaining this is pretty complex. For example you need to copy the
> data over to the latest valid self-signature and be prepared for
> conflicts after importing updates of the key. A separate and random
> access DB is much easier to work with when it comes to local data.
Oh, no point at all putting it in to an unhashed packet.
I just thought that if gpg-agent were storing the passphrase, then
making a local signature would not actually be a hassle. Give it a
notation or similar to make it clear what is going on, but otherwise
it would be completely transparent to other tools. You could upgrade
the signature if needed, or revoke it, etc.
From gniibe at fsij.org Mon Apr 6 04:13:15 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 06 Apr 2015 11:13:15 +0900
Subject: Implementation of the openpgp smartcard specification 2.0 for
zeitcontrol basiccard
In-Reply-To: <20150404165052.2274b7e6@jupiter>
References: <20150404165052.2274b7e6@jupiter>
Message-ID: <5521EBBB.5060109@fsij.org>
On 04/04/2015 11:50 PM, Klaus Flittner wrote:
> Recently i found the code again and thought it might be of interest
> to some of you.
Great. Thank you for sharing your experience.
> In comparison to the official OpenPGP card, this implementation
> allows command chaining and should thus allow larger keys with more
> readers, since in my experience extended APDU are not well supported
> in most smartcard readers.
I agree.
In Gnuk, I use short APDU + command chaining + get response. In the
beginning of the project, I used extended APDU format, as it looked
simple and easy. But I found contrary, in fact.
Short APDU is good for host environment, too. One of major reasons
why I dropped extended APDU in Gnuk was I found a bug in a version of
libusbx which caused a problem by larger packet (it was around 2012).
I believe that it is better for card and token implementations to
support short APDU and command chaining.
--
From gniibe at fsij.org Mon Apr 6 04:48:17 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 06 Apr 2015 11:48:17 +0900
Subject: Proposal for multiple keys on an OpenPGP smart card
In-Reply-To:
References:
Message-ID: <5521F3F1.8040005@fsij.org>
On 04/04/2015 06:30 AM, Jose Castillo wrote:
> Others in the conversation suggested that it might be advantageous
> to have generic slots for keys, such that a card could contain more
> than one signing or authentication key. After delving into the
> relevant ISO smart card specs, I have a thought as to how this could
> be added to the OpenPGP smart card specification. I?ve written up a
> proposal, which I?m including below.
Thank you for your proposal. Use of MANAGE SECURITY ENVIRONMENT is
natural to me.
BTW, the idea of supporting more keys was also discussed around Gnuk
Token. And for Gnuk, there is another way for backward compatibility;
supporting multiple cards within a single token. This doesn't require
any changes (to the specification and to the host software).
In December 2013, I added an experimental configuration option
--enable-hid-card-change for Gnuk, so that a user can control it's
card status of insertion by CTRL or NumLock key of host PC (I know
it's hackish, but it doesn't require any additional hardware). I
explained that this feature could be used to support multiple
(virtual) cards within a single token, but it seemed that it didn't
appeal its users.
The new usage of --enable-hid-card-change would be interesting from
the viewpoint of user interaction. Suppose we will introduce some new
authentication scheme for the device-to-user or the card-to-user, and
traditional PIN will be entered by pinpad/button on the token. Given
this new user authentication and new button, it would be OK to setup
empty PIN for key-to-user authentication; like, heavy authentication
on insertion, but just a confirmation button on
singing/decryption/authentication.
--
From mansourmoufid at gmail.com Mon Apr 6 05:18:51 2015
From: mansourmoufid at gmail.com (Mansour Moufid)
Date: Sun, 5 Apr 2015 23:18:51 -0400
Subject: [patch] do not print version string by default
Message-ID: <20150405231851.d41e0ebdb269d0b9a859ef8d@gmail.com>
Hello everyone,
You may have heard about the law enforcement agents who are accused of
stealing some Silk Road bitcoins. They used GPG at some point and the
version string is used as "evidence" to identify them -- which is of
course ridiculous but it is what it is.
See: https://twitter.com/wiretapped/status/582663354533195777
Let's not print the version string by default.
Yours,
Mansour
diff --git a/doc/gpg.texi b/doc/gpg.texi
index 741271e..c70b9e0 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -2514,10 +2514,10 @@ protected by the signature.
@opindex emit-version
Force inclusion of the version string in ASCII armored output. If
given once only the name of the program and the major number is
-emitted (default), given twice the minor is also emitted, given triple
+emitted, given twice the minor is also emitted, given triple
the micro is added, and given quad an operating system identification
is also emitted. @option{--no-emit-version} disables the version
-line.
+line (default).
@item --sig-notation @code{name=value}
@itemx --cert-notation @code{name=value}
diff --git a/g10/gpg.c b/g10/gpg.c
index da4224f..e994439 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -2146,7 +2146,7 @@ main (int argc, char **argv)
opt.def_cert_expire = "0";
set_homedir (default_homedir ());
opt.passphrase_repeat = 1;
- opt.emit_version = 1; /* Limit to the major number. */
+ opt.emit_version = 0;
/* Check whether we have a config file on the command line. */
orig_argc = argc;
From wk at gnupg.org Mon Apr 6 12:38:24 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 Apr 2015 12:38:24 +0200
Subject: [patch] do not print version string by default
In-Reply-To: <20150405231851.d41e0ebdb269d0b9a859ef8d@gmail.com> (Mansour
Moufid's message of "Sun, 5 Apr 2015 23:18:51 -0400")
References: <20150405231851.d41e0ebdb269d0b9a859ef8d@gmail.com>
Message-ID: <87h9st7d9b.fsf@vigenere.g10code.de>
On Mon, 6 Apr 2015 05:18, mansourmoufid at gmail.com said:
> Let's not print the version string by default.
It does not help you. There subtle difference between all OpenPGP
implementations and versions which can be used for forensic analysis.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Mon Apr 6 12:39:30 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 Apr 2015 12:39:30 +0200
Subject: TOFU - motivation
In-Reply-To:
(Nicholas Cole's message of "Sun, 5 Apr 2015 23:15:21 +0100")
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<87619hhr1p.fsf@alice.fifthhorseman.net>
<551B0045.40403@sixdemonbag.org> <87r3s08a71.fsf@vigenere.g10code.de>
<87zj6m7aak.fsf@vigenere.g10code.de>
Message-ID: <87d23h7d7h.fsf@vigenere.g10code.de>
On Mon, 6 Apr 2015 00:15, nicholas.cole at gmail.com said:
> I just thought that if gpg-agent were storing the passphrase, then
> making a local signature would not actually be a hassle. Give it a
For me and some other this won't work because we keep our primary key
offline.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From nicholas.cole at gmail.com Mon Apr 6 12:48:24 2015
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Mon, 6 Apr 2015 11:48:24 +0100
Subject: TOFU - motivation
In-Reply-To: <87d23h7d7h.fsf@vigenere.g10code.de>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<87619hhr1p.fsf@alice.fifthhorseman.net>
<551B0045.40403@sixdemonbag.org>
<87r3s08a71.fsf@vigenere.g10code.de>
<87zj6m7aak.fsf@vigenere.g10code.de>
<87d23h7d7h.fsf@vigenere.g10code.de>
Message-ID:
On Monday, 6 April 2015, Werner Koch wrote:
> On Mon, 6 Apr 2015 00:15, nicholas.cole at gmail.com said:
>
> > I just thought that if gpg-agent were storing the passphrase, then
> > making a local signature would not actually be a hassle. Give it a
>
> For me and some other this won't work because we keep our primary key
> offline.
>
People who know enough to do that and are cautious enough to do that
probably shouldn't be using TOFU. ;-)
But you could always have a less secure online key for TOFU.
Seriously though, the reason I think my idea might be worth implementing is
that it provides a pathway to teach users to be more secure, rather than
being a completely separate system.
"this signature was made automatically when you first used the key. For
better security you should check the fingerprint and upgrade the
signature." Or similar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From infinity0 at pwned.gg Mon Apr 6 23:57:38 2015
From: infinity0 at pwned.gg (Ximin Luo)
Date: Mon, 06 Apr 2015 23:57:38 +0200
Subject: [patch] do not print version string by default
In-Reply-To: <87h9st7d9b.fsf@vigenere.g10code.de>
References: <20150405231851.d41e0ebdb269d0b9a859ef8d@gmail.com>
<87h9st7d9b.fsf@vigenere.g10code.de>
Message-ID: <55230152.9000105@pwned.gg>
On 06/04/15 12:38, Werner Koch wrote:
> On Mon, 6 Apr 2015 05:18, mansourmoufid at gmail.com said:
>
>> Let's not print the version string by default.
>
> It does not help you. There subtle difference between all OpenPGP
> implementations and versions which can be used for forensic analysis.
>
>
This isn't an argument to not print the version string. There might be subtle differences, but adding yet another subtle difference makes the problem strictly worse.
What technical reason is there to *not* accept this patch?
X
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
From infinity0 at pwned.gg Tue Apr 7 00:01:11 2015
From: infinity0 at pwned.gg (Ximin Luo)
Date: Tue, 07 Apr 2015 00:01:11 +0200
Subject: [patch] do not print version string by default
In-Reply-To: <55230152.9000105@pwned.gg>
References: <20150405231851.d41e0ebdb269d0b9a859ef8d@gmail.com>
<87h9st7d9b.fsf@vigenere.g10code.de> <55230152.9000105@pwned.gg>
Message-ID: <55230227.9030704@pwned.gg>
On 06/04/15 23:57, Ximin Luo wrote:
> On 06/04/15 12:38, Werner Koch wrote:
>> On Mon, 6 Apr 2015 05:18, mansourmoufid at gmail.com said:
>>
>>> Let's not print the version string by default.
>>
>> It does not help you. There subtle difference between all OpenPGP
>> implementations and versions which can be used for forensic analysis.
>>
>>
>
> This isn't an argument to not print the version string. There might be subtle differences, but adding yet another subtle difference makes the problem strictly worse.
>
Whoops, this was a typo. I meant to say, "it does not help you" isn't an argument to keep printing the version string.
> What technical reason is there to *not* accept this patch?
>
X
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
From wk at gnupg.org Tue Apr 7 19:38:46 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Apr 2015 19:38:46 +0200
Subject: gpg 2.1: no error message if gpg-agent or pinentry fail
In-Reply-To: <552155DF.8030805@enigmail.net> (Patrick Brunschwig's message of
"Sun, 5 Apr 2015 17:33:51 +0200")
References: <54DA437F.2020509@enigmail.net>
<87bnjzmtan.fsf@vigenere.g10code.de> <552155DF.8030805@enigmail.net>
Message-ID: <87d23f3kk9.fsf@vigenere.g10code.de>
On Sun, 5 Apr 2015 17:33, patrick at enigmail.net said:
> As it looks like, gpg-error is not always installed. I think I can
> live with it, if I know the source of the error.
It is a development tool.
> Is the following interpretation of the error number correct: ?
> - bits 1-24: used for the error code
> - bits 25-31: used for the source of the error as defined in
> gpg_err_source_t. The error sources are guaranteed to be the same
> across all versions of GnuPG.
Yes. The error source constants are all defined by libgpg-error and
they are thus system wide identical.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Tue Apr 7 19:36:32 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Apr 2015 19:36:32 +0200
Subject: [patch] do not print version string by default
In-Reply-To: <55230152.9000105@pwned.gg> (Ximin Luo's message of "Mon, 06 Apr
2015 23:57:38 +0200")
References: <20150405231851.d41e0ebdb269d0b9a859ef8d@gmail.com>
<87h9st7d9b.fsf@vigenere.g10code.de> <55230152.9000105@pwned.gg>
Message-ID: <87h9sr3knz.fsf@vigenere.g10code.de>
On Mon, 6 Apr 2015 23:57, infinity0 at pwned.gg said:
> What technical reason is there to *not* accept this patch?
This has been discussed a wile back when we changed from printing the
full version number to only the major version. We want to be able to
research whether 1.x is still in active use.
If you don't agree to it please use --no-emit-version. If you have
security concerns you should use a 2.x version. Although we backport
important things to 1.4, the 2.1 code base is much more matured and thus
less prone to bugs.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From gniibe at fsij.org Wed Apr 8 10:40:42 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 08 Apr 2015 17:40:42 +0900
Subject: Private key transfer format
Message-ID: <5524E98A.9020603@fsij.org>
Hello,
I'm trying to fix the issue: https://bugs.g10code.com/gnupg/issue1937
Here, we need to enhance the OpenPGP Private Key Transfer Format.
Currently, as it is described in agent/keyformat.txt, it's like:
(openpgp-private-key
(version V)
(algo PUBKEYALGO)
(curve CURVENAME)
(skey _ P1 _ P2 _ P3 ... e PN)
(csum n)
(protection PROTTYPE PROTALGO IV S2KMODE S2KHASH S2KSALT S2KCOUNT))
For private keys in smartcard, it can be something like following:
(openpgp-private-key
(version V)
(algo PUBKEYALGO)
(curve CURVENAME)
(skey _ P1 _ P2 _ P3 ... _ PN_minus_1) # ??? pkey???
(csum n)
(shadowed PROTOCOL (INFO)))
How about this?
If it's ok, it seems not good to say "skey" as it's public key
parameters only. "pkey" would be better.
Besides, I found that the description of "ti-v1" (token info version 1).
In the current implementation, it is "t1-v1" (Tee-One Vee-One). Shall we
support "ti-v1" too? Or just fix the description in keyformat.txt?
--
From jose.castillo at gmail.com Wed Apr 8 18:22:26 2015
From: jose.castillo at gmail.com (Jose Castillo)
Date: Wed, 8 Apr 2015 12:22:26 -0400
Subject: Proposal for multiple keys on an OpenPGP smart card
In-Reply-To: <551FC1E8.8040702@pietig.com>
References:
<551FC1E8.8040702@pietig.com>
Message-ID: <2CAB1F64-323F-4DEF-8CE3-B23BE2BCE5A7@gmail.com>
> On Apr 4, 2015, at 6:50 AM, Achim Pietig wrote:
>
> Multiple users also require multiple password
> sets - this will extend the handling of the card
> a lot. Because actual smart cards always belong
> to a single identity, this topic will get no
> high priority.
Interesting. I had assumed that the same PW1 and PW3 could be used for all the key sets on the card, since a card generally does belong to one person. Even if they have two identities on a card (e.g. work and home, or current and expired), they?re the same person accessing those keys. I can see where multiple PINs could lead to more complexity ? and more utility for some.
> An important goal of the actual card is a
> good price for small volumes! The actual chip
> has abaut 20K for program and data and I think
> it will be used completely for the new functions.
> Adding multiple keys will lead into a bigger chip
> with higher costs
Very understandable, although it?s worth noting that since it?s an open spec, others can implement the application and add functionality as long as it?s in line with the spec. While one card might have limited space, a token like Gnuk or Yubikey could implement this functionality on a roomier chip, provided it?s in the spec and supported by the terminal application.
--
Joey Castillo
www.joeycastillo.com
From neal at walfield.org Wed Apr 8 22:25:51 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 08 Apr 2015 22:25:51 +0200
Subject: Improved fingerprint representation
Message-ID: <87oamyl640.wl-neal@walfield.org>
Hi,
Most of you are probably familiar with the diceware password generator
[1]. Very briefly: instead of thinking of a password, one:
- rolls a die 5 times,
- converts this into a base 6 number, and,
- indexes a list of "7776 short words, abbreviations and
easy-to-remember character strings."
This is repeated until the desired password strength is reached. The
resulting passphrase has a quantifiable amount of entropy and is
allegedly easy to remember.
I used this technique recently and found many of the words to be
difficult to remember. Here are the first few entries:
11111 a
11112 a&p
11113 a's
11114 aa
11115 aaa
11116 aaaa
11121 aaron
11122 ab
11123 aba
11124 ababa
11125 aback
11126 abase
11131 abash
11132 abate
11133 abbas
11134 abbe
11135 abbey
11136 abbot
11141 abbott
I personally don't think the words are that memorable. Further, many
are very similar to others ('abbot' and 'abbott', for instance). I
think this has to do with two factors: the list has too many entries
and it strives for short words.
I created a new, shorter list. It is based on Voice of America's
Special English Word Book [2]. These are 1500 simple English words
that form the foundation of any English speaker's / learner's
vocabulary [3]. Thus, they are easier to remember.
Because we only need 6^4 words, I first removed words that are easily
misspelled. For this, I consulted OED's list of commonly misspelled
words. Then, I took the shortest 6^4 words.
While doing this, it occured to me that such a list could be used to
display fingerprints. Personally, I often have trouble comparing the
40 hexadecimal characters on the piece of paper with the 40
hexadecimal characters on the screen.
I whipped together a little awk script that converts fingerprints
using this list (I just use the first 1024 entries, i.e., 10-bit
chunks). In terms of the number of characters, the phrases are about
twice as long as a fingerprint, but they seem to me to be much easier
to read aloud and compare. Here are a few examples:
8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367
grow heat hijack corn music effect adult partner
high custom capture evil marry funeral car prison
A4D9 4E92 B098 6AB5 EE9D CD75 5DE2 4996 5B03 58A2
listen explain request marry job many enter loud
part poison pull industry invite female coffee call
5200 54A5 3C19 CBB2 E7F5 6396 8723 4295 786B 0BAD
distance accident delegate dig behind charge chance shoot
exile edge floor period interest rain mental return
11C2 94DF 1D6C 9698 FEFE 231D 3BF6 09C6 8BAF CDBD
attach among develop only fertile effect ignore nice
bread force next happy old change shock fire
(It now occurs to me that this is probably also a good way to display
ssh fingerprints.)
To encourage this readable adoption, I propose adding it to the output
of gpg --list-keys. Thus, instead of:
pub 3744R/0xAACB3243630052D9 2015-04-07 [expires: 2025-04-04]
Key fingerprint = 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9
uid [ultimate] Neal H. Walfield
uid [ultimate] Neal H. Walfield
uid [ultimate] Neal H. Walfield
sub 2048R/0x7223B56678E02528 2015-04-07 [expires: 2017-04-06]
sub 2048R/0xC2B819056C652598 2015-04-07 [expires: 2017-04-06]
sub 2048R/0xA3506AFB820ABD08 2015-04-07 [expires: 2017-04-06]
gpg --list-keys would print:
pub 3744R/0xAACB3243630052D9 2015-04-07 [expires: 2025-04-04]
Key fingerprint = 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9
* Key phrase = idea engine fresh daughter light self major request
* hurt hospital mate parade curfew house agency moderate
uid [ultimate] Neal H. Walfield
uid [ultimate] Neal H. Walfield
uid [ultimate] Neal H. Walfield
sub 2048R/0x7223B56678E02528 2015-04-07 [expires: 2017-04-06]
sub 2048R/0xC2B819056C652598 2015-04-07 [expires: 2017-04-06]
sub 2048R/0xA3506AFB820ABD08 2015-04-07 [expires: 2017-04-06]
What do others think?
Thanks,
Neal
[1] http://world.std.com/~reinhold/diceware.html
[2] https://en.wikipedia.org/wiki/Special_English
[3] https://en.wikipedia.org/wiki/Passive_vocabulary
[4] https://www.oxforddictionaries.com/us/words/common-misspellings-american
From neal at walfield.org Wed Apr 8 22:37:02 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 08 Apr 2015 22:37:02 +0200
Subject: Gnome Keyring and gpg
Message-ID: <87mw2il5ld.wl-neal@walfield.org>
Hi,
I'd like to resume the discussion about GnuPG and Gnome Keyring. I
read the thread from last Auguest [1], but I couldn't find much more
information. Stef, could you please tell me exactly what Gnome
Keyring needs to do?
As I understand the issue, Gnome Keyring wants to cache the password
for the secret key. It seems to me that the easiest solution is to
direct GnuPG to use a special pinentry program that is Gnome Keyring
aware. Basically, gnupg invokes this program when it needs a
password. But, instead of immediately showing a dialog, it first
checks whether Gnome Keyring has cached the password. If not, it uses
a Gnome-themed dialog to prompt the user for the password. If the
password is accepted, it can then save it in the Gnome Keyring. I
suspect that this is much simpler than implementing a gpg-agent proxy.
Perhaps I'm missing something. If so, please help me better
understand the issue.
Thanks,
Neal
[1] https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028689.html
From lion at lion.leolix.org Wed Apr 8 23:16:27 2015
From: lion at lion.leolix.org (Philipp Schafft)
Date: Wed, 08 Apr 2015 21:16:27 +0000
Subject: Improved fingerprint representation
In-Reply-To: <87oamyl640.wl-neal@walfield.org>
References: <87oamyl640.wl-neal@walfield.org>
Message-ID: <20150408211649.2001812CF0@grassland.keep-cool.org>
reflum,
On Wed, 2015-04-08 at 22:25 +0200, Neal H. Walfield wrote:
> Hi,
>
> Most of you are probably familiar with the diceware password generator
> [1]. [...]
> While doing this, it occured to me that such a list could be used to
> display fingerprints. Personally, I often have trouble comparing the
> 40 hexadecimal characters on the piece of paper with the 40
> hexadecimal characters on the screen.
>
> I whipped together a little awk script that converts fingerprints
> using this list (I just use the first 1024 entries, i.e., 10-bit
> chunks). In terms of the number of characters, the phrases are about
> twice as long as a fingerprint, but they seem to me to be much easier
> to read aloud and compare. Here are a few examples:
>
> 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367
>
> grow heat hijack corn music effect adult partner
> high custom capture evil marry funeral car prison
> [...]
>
>
> (It now occurs to me that this is probably also a good way to display
> ssh fingerprints.)
> [...]
> What do others think?
Just a little pointer to 'Bubble Babble':
'In computing, Bubble Babble is a binary data encoding designed by Antti
Huima. This encoding uses alternation of consonants and vowels to encode
binary data to pseudowords that can be pronounced more easily than
arbitrary lists of hexadecimal digits.'[0]
If someone wants to play with it, there is also a Perl Module[1].
[0] http://bohwaz.net/archives/web/Bubble_Babble.html
[1] http://search.cpan.org/~btrott/Digest-BubbleBabble-0.02/lib/Digest/BubbleBabble.pm
> [1] http://world.std.com/~reinhold/diceware.html
> [2] https://en.wikipedia.org/wiki/Special_English
> [3] https://en.wikipedia.org/wiki/Passive_vocabulary
> [4] https://www.oxforddictionaries.com/us/words/common-misspellings-american
--
Philipp.
(Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
From rjh at sixdemonbag.org Thu Apr 9 00:18:23 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 08 Apr 2015 18:18:23 -0400
Subject: Improved fingerprint representation
In-Reply-To: <87oamyl640.wl-neal@walfield.org>
References: <87oamyl640.wl-neal@walfield.org>
Message-ID: <5525A92F.4080203@sixdemonbag.org>
> What do others think?
I think you've reinvented the PGP Biometric Word List. I'd much rather
see GnuPG use the BWL than this, if for no other reason than
interoperability with PGP.
https://en.wikipedia.org/wiki/PGP_word_list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL:
From wk at gnupg.org Thu Apr 9 10:14:28 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Apr 2015 10:14:28 +0200
Subject: Improved fingerprint representation
In-Reply-To: <5525A92F.4080203@sixdemonbag.org> (Robert J. Hansen's message of
"Wed, 08 Apr 2015 18:18:23 -0400")
References: <87oamyl640.wl-neal@walfield.org>
<5525A92F.4080203@sixdemonbag.org>
Message-ID: <876195yazf.fsf@vigenere.g10code.de>
On Thu, 9 Apr 2015 00:18, rjh at sixdemonbag.org said:
> I think you've reinvented the PGP Biometric Word List. I'd much rather
> see GnuPG use the BWL than this, if for no other reason than
This discussion pops up every few years. We recently had it again at
cryptography:
http://lists.randombit.net/pipermail/cryptography/2015-February/007072.html
the usual outcome of these discussions is that the word lists are fine
for English speaking people but problematic for the rest of the world.
This problem is very old and the reason why more than 50 years ago the
ICAO came up with a spelling alphabet to be used on noisy channels and
between people of different mother tongue.
$ gpg --fingerprint --with-icao-spelling wheatstone
pub ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
Key fingerprint = C1D3 4B69 219E 4AEE C0BA 1C21 E3FD FF21 8E45 B72B
"Charlie One Delta Three Four Bravo Six Niner
Two One Niner Echo Four Alfa Echo Echo
Charlie Zero Bravo Alfa One Charlie Two One
Echo Three Foxtrot Delta Foxtrot Foxtrot Two One
Eight Echo Four Five Bravo Seven Two Bravo"
uid [ultimate] Werner Koch (wheatstone commit signing)
agreed, that is longer than a word list but easier to pronounce and
understand by most people. And the alphabet is easy to learn so that
the new gpg option is not always needed.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From neal at walfield.org Thu Apr 9 10:36:22 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 09 Apr 2015 10:36:22 +0200
Subject: Improved fingerprint representation
In-Reply-To: <5525A92F.4080203@sixdemonbag.org>
References: <87oamyl640.wl-neal@walfield.org>
<5525A92F.4080203@sixdemonbag.org>
Message-ID: <871tjtbsvt.wl-neal@walfield.org>
Hi Robert,
At Wed, 08 Apr 2015 18:18:23 -0400,
Robert J. Hansen wrote:
> > What do others think?
>
> I think you've reinvented the PGP Biometric Word List. I'd much rather
> see GnuPG use the BWL than this, if for no other reason than
> interoperability with PGP.
>
> https://en.wikipedia.org/wiki/PGP_word_list
Thanks for the pointer. The BWL is a good list. Looking at the
Wikipedia article, at lot more thought went into its creation than my
list. Happily, I just spent very little time on it.
Neal
From neal at walfield.org Thu Apr 9 10:58:34 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 09 Apr 2015 10:58:34 +0200
Subject: Improved fingerprint representation
In-Reply-To: <876195yazf.fsf@vigenere.g10code.de>
References: <87oamyl640.wl-neal@walfield.org>
<5525A92F.4080203@sixdemonbag.org>
<876195yazf.fsf@vigenere.g10code.de>
Message-ID: <87zj6hadad.wl-neal@walfield.org>
At Thu, 09 Apr 2015 10:14:28 +0200,
Werner Koch wrote:
> On Thu, 9 Apr 2015 00:18, rjh at sixdemonbag.org said:
>
> > I think you've reinvented the PGP Biometric Word List. I'd much rather
> > see GnuPG use the BWL than this, if for no other reason than
>
> This discussion pops up every few years. We recently had it again at
> cryptography:
>
> http://lists.randombit.net/pipermail/cryptography/2015-February/007072.html
Thanks for the pointer.
> the usual outcome of these discussions is that the word lists are fine
> for English speaking people but problematic for the rest of the world.
> This problem is very old and the reason why more than 50 years ago the
> ICAO came up with a spelling alphabet to be used on noisy channels and
> between people of different mother tongue.
>
> $ gpg --fingerprint --with-icao-spelling wheatstone
> pub ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
> Key fingerprint = C1D3 4B69 219E 4AEE C0BA 1C21 E3FD FF21 8E45 B72B
> "Charlie One Delta Three Four Bravo Six Niner
> Two One Niner Echo Four Alfa Echo Echo
> Charlie Zero Bravo Alfa One Charlie Two One
> Echo Three Foxtrot Delta Foxtrot Foxtrot Two One
> Eight Echo Four Five Bravo Seven Two Bravo"
> uid [ultimate] Werner Koch (wheatstone commit signing)
>
> agreed, that is longer than a word list but easier to pronounce and
> understand by most people. And the alphabet is easy to learn so that
> the new gpg option is not always needed.
The encodings clearly have different trade offs. ICAO is easier for
more people. But, it is also grounded in English and only really
generalizes to Western European languages. Thus, it also excludes a
huge (but slightly smaller) portion of the world's population.
Further, using ICAO encoding of a fingerprint requires about 2.5 times
as much space. And, due to the limited vocabulary, it includes more
repetition, which is a cause of errors both in transmission (e.g., via
phone) and for quick visual comparisons (e.g., comparing
fingerprints).
Since gpg already has a --with-icao-spelling option, how about also
supporting a --with-word-spelling or --with-bwl-spelling?
Neal
From neal at walfield.org Thu Apr 9 11:24:42 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 09 Apr 2015 11:24:42 +0200
Subject: gnome-keyring Gnome Keyring and gpg
In-Reply-To: <55262289.2010208@gnome.org>
References: <87mw2il5ld.wl-neal@walfield.org>
<55262289.2010208@gnome.org>
Message-ID: <87y4m1ac2t.wl-neal@walfield.org>
Hi Stef,
Thanks for the quick reply.
At Thu, 09 Apr 2015 08:56:09 +0200,
Stef Walter wrote:
>
> On 08.04.2015 22:37, Neal H. Walfield wrote:
> > Hi,
> >
> > I'd like to resume the discussion about GnuPG and Gnome Keyring. I
> > read the thread from last Auguest [1], but I couldn't find much more
> > information. Stef, could you please tell me exactly what Gnome
> > Keyring needs to do?
> >
> > As I understand the issue, Gnome Keyring wants to cache the password
> > for the secret key. It seems to me that the easiest solution is to
> > direct GnuPG to use a special pinentry program that is Gnome Keyring
> > aware. Basically, gnupg invokes this program when it needs a
> > password. But, instead of immediately showing a dialog, it first
> > checks whether Gnome Keyring has cached the password. If not, it uses
> > a Gnome-themed dialog to prompt the user for the password. If the
> > password is accepted, it can then save it in the Gnome Keyring. I
> > suspect that this is much simpler than implementing a gpg-agent proxy.
>
> Indeed. That seems like the best approach.
Just to confirm explicitly: if we use a PIN entry program that
supports saving passwords in GKR, then GKR has no reason to proxy gpg
agent.
> There's a GSoC proposal to do work on this over the Summer.
>
> https://wiki.gnome.org/Outreach/SummerOfCode/2015/Ideas#Confirmed_Ideas
> https://bugzilla.gnome.org/show_bug.cgi?id=742094
That's good news.
> One thing that seems to be missing is getting a full keyid in the
> pinentry for use when optionally storing the passphrase in
> gnome-keyring. In theory one can "screen scrape" a short keyid this out
> of the prompt message ... but that's pretty fragile.
>
> So a bit of additional work to have gpg2 pass an Assuan OPTION with the
> keyid or a unique identifier, if that's preferrable. The absence of
> which would indicate that the passphrase does not belong to a stable
> entity (like a key).
I think this should not be a problem. I've filed a bug requesting
this feature:
https://bugs.g10code.com/gnupg/issue1945
Neal
From wk at gnupg.org Thu Apr 9 13:37:03 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Apr 2015 13:37:03 +0200
Subject: Improved fingerprint representation
In-Reply-To: <87zj6hadad.wl-neal@walfield.org> (Neal H. Walfield's message of
"Thu, 09 Apr 2015 10:58:34 +0200")
References: <87oamyl640.wl-neal@walfield.org>
<5525A92F.4080203@sixdemonbag.org>
<876195yazf.fsf@vigenere.g10code.de> <87zj6hadad.wl-neal@walfield.org>
Message-ID: <878ue1wn1c.fsf@vigenere.g10code.de>
On Thu, 9 Apr 2015 10:58, neal at walfield.org said:
> The encodings clearly have different trade offs. ICAO is easier for
> more people. But, it is also grounded in English and only really
> generalizes to Western European languages. Thus, it also excludes a
> huge (but slightly smaller) portion of the world's population.
Hwoever it is the world standard in aviation and between HAMs (radio
amateurs). Thus possible to learn for everyone who is able to type gpg
--some-weird-option-name ;-).
> Since gpg already has a --with-icao-spelling option, how about also
> supporting a --with-word-spelling or --with-bwl-spelling?
The reason why I added --with-icao-spelling is that I often noticed
during key signing parties that some folks don't know the ICAO and had
problems to recite their fingerprint.
For another word list I would like to wait for the outcome of the just
started OpenPGP update discussions. We will for sure come up with a new
fingerprint format and that may then also define an alternate
representation to be be used over phone or on flag poles. The new
fingerprints will likely be larger than 20 bytes and it may be useful to
replace the hex notation by a base-32 notation.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From gniibe at fsij.org Thu Apr 9 13:52:45 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 09 Apr 2015 20:52:45 +0900
Subject: [PATCH] export smartcard stub (was: Private key transfer format)
In-Reply-To: <5524E98A.9020603@fsij.org>
References: <5524E98A.9020603@fsij.org>
Message-ID: <5526680D.5040005@fsij.org>
On 04/08/2015 05:40 PM, NIIBE Yutaka wrote:
> Hello,
>
> I'm trying to fix the issue: https://bugs.g10code.com/gnupg/issue1937
>
> Here, we need to enhance the OpenPGP Private Key Transfer Format.
>
> Currently, as it is described in agent/keyformat.txt, it's like:
>
> (openpgp-private-key
> (version V)
> (algo PUBKEYALGO)
> (curve CURVENAME)
> (skey _ P1 _ P2 _ P3 ... e PN)
> (csum n)
> (protection PROTTYPE PROTALGO IV S2KMODE S2KHASH S2KSALT S2KCOUNT))
>
> For private keys in smartcard, it can be something like following:
>
> (openpgp-private-key
> (version V)
> (algo PUBKEYALGO)
> (curve CURVENAME)
> (skey _ P1 _ P2 _ P3 ... _ PN_minus_1) # ??? pkey???
> (csum n)
> (shadowed PROTOCOL (INFO)))
>
> How about this?
I implemented, but reading the implementation of GnuPG 2.0.x and
OpenPGP format for smartcard stub, I think that it is more natural
to represent it like:
(openpgp-private-key
(version V)
(algo PUBKEYALGO)
(curve CURVENAME)
(skey _ P1 _ P2 _ P3 ... _ PN)
(csum n)
(protection none plain SERIAL 101 none GNU 2))
Then, it will have 1-to-1 mapping to the representation in OpenPGP
format.
Here is the patch. I tested and confirmed that GnuPG can export
secret key (with smartcard serial number).
diff --git a/agent/command.c b/agent/command.c
index 3188bbd..9fa2e90 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -2221,6 +2221,7 @@ cmd_export_key (assuan_context_t ctx, char *line)
char *cache_nonce;
char *passphrase = NULL;
unsigned char *shadow_info = NULL;
+ char *serialno = NULL;
char *pend;
int c;
@@ -2271,9 +2272,10 @@ cmd_export_key (assuan_context_t ctx, char *line)
goto leave;
if (shadow_info)
{
- /* Key is on a smartcard. */
- err = gpg_error (GPG_ERR_UNUSABLE_SECKEY);
- goto leave;
+ err = parse_shadow_info (shadow_info, &serialno, NULL, NULL);
+ xfree (shadow_info);
+ if (err)
+ goto leave;
}
if (openpgp)
@@ -2281,7 +2283,7 @@ cmd_export_key (assuan_context_t ctx, char *line)
/* The openpgp option changes the key format into the OpenPGP
key transfer format. The result is already a padded
canonical S-expression. */
- if (!passphrase)
+ if (!passphrase && !shadow_info)
{
err = agent_ask_new_passphrase
(ctrl, _("This key (or subkey) is not protected with a passphrase."
@@ -2290,7 +2292,9 @@ cmd_export_key (assuan_context_t ctx, char *line)
if (err)
goto leave;
}
- err = convert_to_openpgp (ctrl, s_skey, passphrase, &key, &keylen);
+
+ err = convert_to_openpgp (ctrl, s_skey, serialno, passphrase,
+ &key, &keylen);
if (!err && passphrase)
{
if (!cache_nonce)
@@ -2312,6 +2316,12 @@ cmd_export_key (assuan_context_t ctx, char *line)
}
else
{
+ if (serialno)
+ { /* Key is on a smartcard. */
+ err = gpg_error (GPG_ERR_UNUSABLE_SECKEY);
+ goto leave;
+ }
+
/* Convert into a canonical S-expression and wrap that. */
err = make_canon_sexp_pad (s_skey, 1, &key, &keylen);
}
@@ -2351,6 +2361,7 @@ cmd_export_key (assuan_context_t ctx, char *line)
leave:
+ xfree (serialno);
xfree (cache_nonce);
xfree (passphrase);
xfree (wrappedkey);
@@ -2359,7 +2370,6 @@ cmd_export_key (assuan_context_t ctx, char *line)
gcry_sexp_release (s_skey);
xfree (ctrl->server_local->keydesc);
ctrl->server_local->keydesc = NULL;
- xfree (shadow_info);
return leave_cmd (ctx, err);
}
diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c
index b00f032..bd75bd5 100644
--- a/agent/cvt-openpgp.c
+++ b/agent/cvt-openpgp.c
@@ -1391,9 +1391,13 @@ extract_private_key (gcry_sexp_t s_key, int req_private_key_data,
/* Convert our key S_KEY into an OpenPGP key transfer format. On
success a canonical encoded S-expression is stored at R_TRANSFERKEY
and its length at R_TRANSFERKEYLEN; this S-expression is also
- padded to a multiple of 64 bits. */
+ padded to a multiple of 64 bits.
+ When SERIALNO is non-NULL, it's for smartcard serialno hex-string.
+ PASSPHRASE points to the memory for encrypting the private key.
+ */
gpg_error_t
-convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
+convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key,
+ const unsigned char *serialno, const char *passphrase,
unsigned char **r_transferkey, size_t *r_transferkeylen)
{
gpg_error_t err;
@@ -1402,8 +1406,10 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
gcry_mpi_t array[10];
gcry_sexp_t curve = NULL;
gcry_sexp_t flags = NULL;
+ const char *proto_type, *proto_algo, *s2k_hash;
char protect_iv[16];
char salt[8];
+ unsigned int s2k_mode;
unsigned long s2k_count;
int i, j;
@@ -1414,32 +1420,49 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
for (i=0; i < DIM (array); i++)
array[i] = NULL;
- err = extract_private_key (s_key, 1, &algoname, &npkey, &nskey, NULL,
- array, DIM (array), &curve, &flags);
+ err = extract_private_key (s_key, !serialno, &algoname, &npkey, &nskey,
+ NULL, array, DIM (array), &curve, &flags);
if (err)
return err;
- gcry_create_nonce (protect_iv, sizeof protect_iv);
- gcry_create_nonce (salt, sizeof salt);
- /* We need to use the encoded S2k count. It is not possible to
- encode it after it has been used because the encoding procedure
- may round the value up. */
- s2k_count = get_standard_s2k_count_rfc4880 ();
- err = apply_protection (array, npkey, nskey, passphrase,
- GCRY_CIPHER_AES, protect_iv, sizeof protect_iv,
- 3, GCRY_MD_SHA1, salt, s2k_count);
+ if (serialno)
+ {
+ s2k_mode = 101; /* GnuPG extension. */
+ proto_type = "none";
+ proto_algo = "plain";
+ if (hex2bin (serialno, protect_iv, sizeof protect_iv) < 0)
+ err = gpg_error (GPG_ERR_BAD_SECKEY);
+ s2k_hash = "none";
+ strcpy (salt, "GNU");
+ s2k_count = 2; /* Divert to OpenPGP smartcard. */
+ array[npkey] = GCRYMPI_CONST_ONE;
+ }
+ else
+ {
+ s2k_mode = 3;
+ proto_type = "sha1";
+ proto_algo = "aes";
+ gcry_create_nonce (protect_iv, sizeof protect_iv);
+ s2k_hash = "sha1";
+ gcry_create_nonce (salt, sizeof salt);
+ /* We need to use the encoded S2k count. It is not possible to
+ encode it after it has been used because the encoding procedure
+ may round the value up. */
+ s2k_count = get_standard_s2k_count_rfc4880 ();
+ err = apply_protection (array, npkey, nskey, passphrase,
+ GCRY_CIPHER_AES, protect_iv, sizeof protect_iv,
+ 3, GCRY_MD_SHA1, salt, s2k_count);
+ }
+
/* Turn it into the transfer key S-expression. Note that we always
return a protected key. */
if (!err)
{
- char countbuf[35];
membuf_t mbuf;
void *format_args[10+2];
gcry_sexp_t tmpkey;
gcry_sexp_t tmpsexp = NULL;
- snprintf (countbuf, sizeof countbuf, "%lu", s2k_count);
-
init_membuf (&mbuf, 50);
put_membuf_str (&mbuf, "(skey");
for (i=j=0; i < npkey; i++)
@@ -1447,7 +1470,7 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
put_membuf_str (&mbuf, " _ %m");
format_args[j++] = array + i;
}
- put_membuf_str (&mbuf, " e %m");
+ put_membuf_str (&mbuf, serialno ? " _ %m" : " e %m");
format_args[j++] = array + npkey;
put_membuf_str (&mbuf, ")\n");
put_membuf (&mbuf, "", 1);
@@ -1461,19 +1484,27 @@ convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key, const char *passphrase,
err = gcry_sexp_build_array (&tmpkey, NULL, format, format_args);
xfree (format);
}
+
if (!err)
- err = gcry_sexp_build (&tmpsexp, NULL,
- "(openpgp-private-key\n"
- " (version 1:4)\n"
- " (algo %s)\n"
- " %S%S\n"
- " (protection sha1 aes %b 1:3 sha1 %b %s))\n",
- algoname,
- curve,
- tmpkey,
- (int)sizeof protect_iv, protect_iv,
- (int)sizeof salt, salt,
- countbuf);
+ {
+ char countbuf[35];
+
+ snprintf (countbuf, sizeof countbuf, "%lu", s2k_count);
+ err = gcry_sexp_build (&tmpsexp, NULL,
+ "(openpgp-private-key\n"
+ " (version 1:4)\n"
+ " (algo %s)\n"
+ " %S%S\n"
+ " (protection %s %s %b %u %s %b %s))\n",
+ algoname,
+ curve,
+ tmpkey,
+ proto_type, proto_algo,
+ (int)sizeof protect_iv, protect_iv, s2k_mode,
+ s2k_hash, serialno ? 3: (int)sizeof salt, salt,
+ countbuf);
+ }
+
gcry_sexp_release (tmpkey);
if (!err)
err = make_canon_sexp_pad (tmpsexp, 0, r_transferkey, r_transferkeylen);
diff --git a/agent/cvt-openpgp.h b/agent/cvt-openpgp.h
index d27a776..9bacb06 100644
--- a/agent/cvt-openpgp.h
+++ b/agent/cvt-openpgp.h
@@ -29,6 +29,7 @@ gpg_error_t convert_from_openpgp_native (ctrl_t ctrl,
unsigned char **r_key);
gpg_error_t convert_to_openpgp (ctrl_t ctrl, gcry_sexp_t s_key,
+ const unsigned char *serialno,
const char *passphrase,
unsigned char **r_transferkey,
size_t *r_transferkeylen);
diff --git a/agent/keyformat.txt b/agent/keyformat.txt
index 42c4b1f..56a7688 100644
--- a/agent/keyformat.txt
+++ b/agent/keyformat.txt
@@ -236,6 +236,11 @@ This format is used to transfer keys between gpg and gpg-agent.
* S2KSALT is the 8 byte salt
* S2KCOUNT is the count value from RFC-4880.
+For smartcard stub, it's:
+
+* PN is dummy data: 1 (and not encrypted)
+* PROTECTION is: (protection none plain SERIAL 101 none GNU 2)
+
Persistent Passphrase Format
============================
diff --git a/doc/DETAILS b/doc/DETAILS
index fd72b88..6fd01e0 100644
--- a/doc/DETAILS
+++ b/doc/DETAILS
@@ -1137,6 +1137,7 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB:
1 octet - S2K Usage: either 254 or 255.
1 octet - S2K Cipher Algo: 0
1 octet - S2K Specifier: 101
+ 1 octet - S2K Hash Algorithm: 0
3 octets - "GNU"
1 octet - GNU S2K Extension Number.
diff --git a/g10/export.c b/g10/export.c
index b65fb8d..5711021 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -449,6 +449,32 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk)
s2k_count = strtoul (string, NULL, 10);
xfree (string);
}
+ else
+ { /* It's smartcard stub. */
+ protect_algo = 0;
+ s2k_algo = 0;
+
+ value = gcry_sexp_nth_data (list, 3, &valuelen);
+ if (!value || !valuelen || valuelen > sizeof iv)
+ goto bad_seckey;
+ memcpy (iv, value, valuelen);
+ ivlen = valuelen;
+log_printhex ("XXX iv", iv, ivlen);
+ string = gcry_sexp_nth_string (list, 4);
+ if (!string)
+ goto bad_seckey;
+ s2k_mode = strtol (string, NULL, 10);
+ xfree (string);
+ value = gcry_sexp_nth_data (list, 6, &valuelen);
+ if (!value || !valuelen || valuelen > 3 || memcmp (value, "GNU", 3))
+ goto bad_seckey;
+ memset (s2k_salt, 0, sizeof s2k_salt);
+ string = gcry_sexp_nth_string (list, 7);
+ if (!string)
+ goto bad_seckey;
+ s2k_count = strtoul (string, NULL, 10);
+ xfree (string);
+ }
/* Parse the gcrypt PK algo and check that it is okay. */
gcry_sexp_release (list);
@@ -606,7 +632,7 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk)
/* log_printf ("\n"); */
/* } */
- if (!is_v4 || is_protected != 2 )
+ if (!is_v4 || (is_protected != 0 && is_protected != 2) )
{
/* We only support the v4 format and a SHA-1 checksum. */
err = gpg_error (GPG_ERR_NOT_IMPLEMENTED);
@@ -675,18 +701,21 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk)
}
/* Do some sanity checks. */
- if (s2k_count > 255)
+ if (is_protected)
{
- /* We expect an already encoded S2K count. */
- err = gpg_error (GPG_ERR_INV_DATA);
- goto leave;
+ if (s2k_count > 255)
+ {
+ /* We expect an already encoded S2K count. */
+ err = gpg_error (GPG_ERR_INV_DATA);
+ goto leave;
+ }
+ err = openpgp_cipher_test_algo (protect_algo);
+ if (err)
+ goto leave;
+ err = openpgp_md_test_algo (s2k_algo);
+ if (err)
+ goto leave;
}
- err = openpgp_cipher_test_algo (protect_algo);
- if (err)
- goto leave;
- err = openpgp_md_test_algo (s2k_algo);
- if (err)
- goto leave;
/* Check that the public key parameters match. Note that since
Libgcrypt 1.5 gcry_mpi_cmp handles opaque MPI correctly. */
@@ -700,7 +729,7 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk)
/* Check that the first secret key parameter in SKEY is encrypted
and that there are no more secret key parameters. The latter is
guaranteed by the v4 packet format. */
- if (!gcry_mpi_get_flag (skey[npkey], GCRYMPI_FLAG_OPAQUE))
+ if (is_protected && !gcry_mpi_get_flag (skey[npkey], GCRYMPI_FLAG_OPAQUE))
goto bad_seckey;
if (npkey+1 < DIM (skey) && skey[npkey+1])
goto bad_seckey;
@@ -721,18 +750,33 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk)
ski->is_protected = 1;
ski->sha1chk = 1;
ski->algo = protect_algo;
- ski->s2k.mode = s2k_mode;
+ if (is_protected == 0)
+ ski->s2k.mode = 1000 + s2k_count;
+ else
+ {
+ ski->s2k.mode = s2k_mode;
+ ski->s2k.count = s2k_count;
+ }
ski->s2k.hash_algo = s2k_algo;
assert (sizeof ski->s2k.salt == sizeof s2k_salt);
memcpy (ski->s2k.salt, s2k_salt, sizeof s2k_salt);
- ski->s2k.count = s2k_count;
assert (ivlen <= sizeof ski->iv);
memcpy (ski->iv, iv, ivlen);
ski->ivlen = ivlen;
/* Store the protected secret key parameter. */
- pk->pkey[npkey] = skey[npkey];
- skey[npkey] = NULL;
+ if (is_protected)
+ {
+ pk->pkey[npkey] = skey[npkey];
+ skey[npkey] = NULL;
+ }
+ else
+ {
+ pk->pkey[npkey] = gcry_mpi_set_opaque (NULL,
+ xstrdup ("dummydata"),
+ 10 * 8);
+ }
+
/* That's it. */
--
From wk at gnupg.org Thu Apr 9 14:06:41 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Apr 2015 14:06:41 +0200
Subject: Private key transfer format
In-Reply-To: <5524E98A.9020603@fsij.org> (NIIBE Yutaka's message of "Wed, 08
Apr 2015 17:40:42 +0900")
References: <5524E98A.9020603@fsij.org>
Message-ID: <871tjtwlny.fsf@vigenere.g10code.de>
On Wed, 8 Apr 2015 10:40, gniibe at fsij.org said:
> For private keys in smartcard, it can be something like following:
>
> (openpgp-private-key
> (version V)
> (algo PUBKEYALGO)
> (curve CURVENAME)
> (skey _ P1 _ P2 _ P3 ... _ PN_minus_1) # ??? pkey???
> (csum n)
> (shadowed PROTOCOL (INFO)))
>
> How about this?
Why do we need it at all. The smartcard has all the required
information. Do you want to create a stub key (shadowed-private-key) in
private-keys-v1.d/ from some information provided by gpg? I do not
think this will work: gpg does not know whether there is a
smartcard. Importing a secring.gpg with a smart card stub key might have
this information but it is not sure whether this smartcard is really
available.
Would't it be better to require insertion of the smartcard to attest
that a smartcard is really available? As of now this required the use
of the LEARN Assuan command. However, at least for OpenPGP cards we
could try to create a shadowed-private-key automatically after a card
has been inserted. scdaemon emits an event and gpg-agent could at its
spare time (ticker thread) create this shadow key.
> Besides, I found that the description of "ti-v1" (token info version 1).
>
> In the current implementation, it is "t1-v1" (Tee-One Vee-One). Shall we
> support "ti-v1" too? Or just fix the description in keyformat.txt?
Ooops. Better fix the documentation.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Thu Apr 9 14:19:31 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Apr 2015 14:19:31 +0200
Subject: FYI: Scheduling releases
Message-ID: <87wq1lv6i4.fsf@vigenere.g10code.de>
Hi,
it is now close to two month since 2.1.2 was released and there have
been about 80 commits since then. Thus 2.1.3 is long overdue.
The reason for the current delay are: I wanted to have LDAP support,
there have been lots of bug reports, I have been on vacation for a few
days, and administrative work kept me away from coding work. Thus the
current state is that there are still some open bugs I wanted to get
fixed but won't be able to do that the next few days.
I plan to release 2.1.3 next week despite of the open bugs and from then
on continue to do monthly releases regardless of open problems (except
for security problems of course).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL:
From gniibe at fsij.org Thu Apr 9 16:00:13 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 09 Apr 2015 23:00:13 +0900
Subject: Private key transfer format
In-Reply-To: <871tjtwlny.fsf@vigenere.g10code.de>
References: <5524E98A.9020603@fsij.org> <871tjtwlny.fsf@vigenere.g10code.de>
Message-ID: <552685ED.7060503@fsij.org>
On 04/09/2015 09:06 PM, Werner Koch wrote:
> On Wed, 8 Apr 2015 10:40, gniibe at fsij.org said:
>
>> For private keys in smartcard, it can be something like following:
>>
>> (openpgp-private-key
>> (version V)
>> (algo PUBKEYALGO)
>> (curve CURVENAME)
>> (skey _ P1 _ P2 _ P3 ... _ PN_minus_1) # ??? pkey???
>> (csum n)
>> (shadowed PROTOCOL (INFO)))
>>
>> How about this?
>
> Why do we need it at all. The smartcard has all the required
> information. Do you want to create a stub key (shadowed-private-key) in
> private-keys-v1.d/ from some information provided by gpg? I do not
> think this will work: gpg does not know whether there is a
> smartcard. Importing a secring.gpg with a smart card stub key might have
> this information but it is not sure whether this smartcard is really
> available.
>
> Would't it be better to require insertion of the smartcard to attest
> that a smartcard is really available? As of now this required the use
> of the LEARN Assuan command. However, at least for OpenPGP cards we
> could try to create a shadowed-private-key automatically after a card
> has been inserted. scdaemon emits an event and gpg-agent could at its
> spare time (ticker thread) create this shadow key.
I thought it was a regression. In GnuPG 1.4 and 2.0, some people did
--export-secret-keys for smartcard. Well, I naively tried to "fix"
as a response to the bug report.
Yes, I think that we can just drop the support of --export-secret-keys
for smartcard, and fix documentations.
Well, in my opinion, it is unlikely there are some smartcard users who
expect serial number exact check by GnuPG with --export-secret-keys in
a machine and --import on another machine.
--
From neal at walfield.org Thu Apr 9 17:16:24 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 09 Apr 2015 17:16:24 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <1427841635.17032.147.camel@scientia.net>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net>
Message-ID: <87twwp9vsn.wl-neal@walfield.org>
Hi Christoph,
I apologize for the late reply. Your arguments are well stated and I
needed some time to digest them and to do some reading and thinking of
my own.
I think it is fair to summarize your post as follows: TOFU is
significantly weaker than the Web of Trust and adoption of TOFU will
weaken the WoT. Although you provide a number of arguments that
support your claim that TOFU is weak, you didn't provide any arguments
that the WoT is significantly stronger. I think that this is where
your argument breaks down. The following are some weaknesses in the
WoT:
- When you rely on the WoT, you rely on the people who made the
signatures to have done due diligence (which is itself not very
well defined).
There are, however, many examples of people signing keys that they
haven't checked or checked poorly. In 2006, for instance, Martin
Krafft used a "fake" id at the DebConf KSP. Only 1 in 10 people
called him out. Here's his explanation and some reactions:
http://madduck.net/blog/2006.05.24:tr-id-at-keysigning/
https://lists.debian.org/debian-devel/2006/05/msg01393.html
https://lists.debian.org/debian-devel/2006/05/msg01416.html
https://lists.debian.org/debian-devel/2006/05/msg01440.html
https://lists.debian.org/debian-devel/2006/05/msg01615.html
More recently (2014), Martin tweeted:
Received signatures for my #GPG key again at #DebConf14 although
I did not attend the keysigning event.
https://twitter.com/martinkrafft/status/504350313915367424
- You bring up nation states as potential threats multiple times.
This is ironic, because key signatures are typically based on
verifying government issued id. If the government wants to
infiltrate the WoT, it apparently just has to create a few fake ids
and send some agents to a Debian KSP after which they'll quickly be
in the stongly connected set and can certify any key they like.
See this note from Mike Perry (Tor Project) covering this as well
as other weaknesses in the WoT:
https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html
(He also argues for TOFU and multipath authentication.)
- In practice, the WoT is hard to use. If you endow marginal trust
in others' signatures, then it can be hard to find a good path.
The other day, I tried to verify a friend's key. Even though I
have about 100 signatures on my main key and he has 37, gpg said
his key was not trusted.
- The practical result is that exploiting the WoT is hard. You
either need to directly verify someone's identity (which isn't
really WoT), get a lot of signatures or just ignore the frequent
not trusted warnings (which I and many others often do).
- Ignoring these warning *is* a serious problem as Erinn Clark, the
release manager for Tor, has recently observed. Someone uploaded a
key with her identity to the public key servers. If people have
gotten into the bad habit of using trust=always (or ignoring the
warning), then they'll happily accept signatures from this bad key.
TOFU and its emphasis on consistency could potentially help here.
- Indeed, some well-known cryptographers, such as Peter Gutmann,
argue that continuity (i.e., TOFU) is strictly better than third
party attestations (i.e., signatures):
http://www.cypherpunks.to/~peter/T2_Key_Management.pdf (Page 8).
- The WoT suffers from the revocation problem. For instance, it
takes hours for key updates to propagate between the servers
participating in pool.sks-keyservers.net. Further, GnuPG doesn't
check for key updates automatically so the problems are actually
worse than when using PKI.
- The WoT leaks lots of information.
Thanks,
Neal
From wk at gnupg.org Thu Apr 9 17:17:04 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Apr 2015 17:17:04 +0200
Subject: Private key transfer format
In-Reply-To: <552685ED.7060503@fsij.org> (NIIBE Yutaka's message of "Thu, 09
Apr 2015 23:00:13 +0900")
References: <5524E98A.9020603@fsij.org> <871tjtwlny.fsf@vigenere.g10code.de>
<552685ED.7060503@fsij.org>
Message-ID: <87oamxtjpr.fsf@vigenere.g10code.de>
On Thu, 9 Apr 2015 16:00, gniibe at fsij.org said:
> Yes, I think that we can just drop the support of --export-secret-keys
> for smartcard, and fix documentations.
Okay
> Well, in my opinion, it is unlikely there are some smartcard users who
> expect serial number exact check by GnuPG with --export-secret-keys in
> a machine and --import on another machine.
FWIW, there is a bug report that moving a key from one smart card to
another does not update the stub file. We may want to check for
conflicting serial number is a stub file and either a) update the stub
file with the new serial number or b) allow to store several serial
numbers in one stub file. The latter would be useful if several persons
have a smartcard with the same key and use the same box or if you create
several smartcards for backup purposes.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From gniibe at fsij.org Thu Apr 9 18:38:23 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 10 Apr 2015 01:38:23 +0900
Subject: Identifier of OpenPGPcard (was: Private key transfer format)
In-Reply-To: <87oamxtjpr.fsf@vigenere.g10code.de>
References: <5524E98A.9020603@fsij.org>
<871tjtwlny.fsf@vigenere.g10code.de> <552685ED.7060503@fsij.org>
<87oamxtjpr.fsf@vigenere.g10code.de>
Message-ID: <5526AAFF.2070705@fsij.org>
On 04/10/2015 12:17 AM, Werner Koch wrote:
> FWIW, there is a bug report that moving a key from one smart card to
> another does not update the stub file. We may want to check for
> conflicting serial number is a stub file and either a) update the stub
> file with the new serial number or b) allow to store several serial
> numbers in one stub file. The latter would be useful if several persons
> have a smartcard with the same key and use the same box or if you create
> several smartcards for backup purposes.
I'm considering an option of not having serial number in a stub file
at all... and... this let me consider how we (should) identify a
smartcard.
Suppose that a user doesn't (need to) recognize the serial number,
then, I think that a serial number in a stub file is only useful a bit
when GnuPG asked users to insert another smartcard when a different
smartcard is inserted already.
Suppose that new hypothetical OpenPGPcard will be identified by a
fingerprint of primary key or User ID, then it would be much better to
show the fingerprint (or User ID) to users.
In OpenPGP, a single primary RSA/DSA/ECC/whatever key can be used by
multiple User IDs. Considering this situation, it seems for me that a
fingerprint of primary key should be an identifier of a smartcard
(even when all are subkeys and no primary key on a smartcard).
In fact, Gnuk has a feature to register its serial number by a user.
But it seems that it's only me who use this feature. Perhaps, it
suggests that people don't have a practice to recognize the serial
number as an identifier.
Any thought?
--
From kristian.fiskerstrand at sumptuouscapital.com Thu Apr 9 18:45:14 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 09 Apr 2015 17:45:14 +0100
Subject: Identifier of OpenPGPcard
In-Reply-To: <5526AAFF.2070705@fsij.org>
References: <5524E98A.9020603@fsij.org>
<871tjtwlny.fsf@vigenere.g10code.de> <552685ED.7060503@fsij.org>
<87oamxtjpr.fsf@vigenere.g10code.de> <5526AAFF.2070705@fsij.org>
Message-ID: <5526AC9A.7030201@sumptuouscapital.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04/09/2015 05:38 PM, NIIBE Yutaka wrote:
> On 04/10/2015 12:17 AM, Werner Koch wrote:
>> FWIW, there is a bug report that moving a key from one smart card
>> to another does not update the stub file. We may want to check
>> for conflicting serial number is a stub file and either a) update
>> the stub file with the new serial number or b) allow to store
>> several serial numbers in one stub file. The latter would be
>> useful if several persons have a smartcard with the same key and
>> use the same box or if you create several smartcards for backup
>> purposes.
>
..
>
> In OpenPGP, a single primary RSA/DSA/ECC/whatever key can be used
> by multiple User IDs. Considering this situation, it seems for me
> that a fingerprint of primary key should be an identifier of a
> smartcard (even when all are subkeys and no primary key on a
> smartcard).
And how would you differentiate in the case you have one smartcard
with the primary key only kept securely and one smartcard for daily
use with subkeys only?
>
> In fact, Gnuk has a feature to register its serial number by a
> user. But it seems that it's only me who use this feature.
> Perhaps, it suggests that people don't have a practice to recognize
> the serial number as an identifier.
>
> Any thought?
>
- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"A ship is safe in harbour, but that's not what ships are for"
(Will Shedd)
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVJqyWAAoJEP7VAChXwav6snQH/RmMuZBVl0uWXVCKxPvJj+e/
YN/tcNdbW6tY7BZYGEmOmBoYA34PRgs/eq1X7W0ju3kAMiE7V5KEUrNQAPAwBDJ6
dtsU9Nc0p2PbLRa6xiWBxz2cWVq4B5FHNe2hAhTuPAY4a0Pmo49GKojo+MVH5qfZ
5u2WXuOVBnwOPmpTUHcoxQ5ZbOA9ck4kAKZiWw2pXIbHEMc+PCNdtagL7vcr/Y7H
kmsD8ItWw9Lgs+8eYMqi2cp10PkwPseFZP8hmrSNXoFaiunSCatLmGV2DNaiFs6k
REX/Pl06VSBokzy+r7peGp/C3kUJFHIuNaD0nq1Ohz74f3ZRUipLouYDttjNv9Y=
=bnfH
-----END PGP SIGNATURE-----
From lists-gnupgdev at lina.inka.de Thu Apr 9 22:04:46 2015
From: lists-gnupgdev at lina.inka.de (lists-gnupgdev at lina.inka.de)
Date: Thu, 9 Apr 2015 22:04:46 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <87twwp9vsn.wl-neal@walfield.org>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net>
<87twwp9vsn.wl-neal@walfield.org>
Message-ID: <20150409220446.00007fe0.ecki@lina.inka.de>
Hello,
fully support your analysis, Neal:
Am Thu, 09 Apr 2015 17:16:24 +0200
schrieb "Neal H. Walfield" :
> I think it is fair to summarize your post as follows: TOFU is
> significantly weaker than the Web of Trust and adoption of TOFU will
> weaken the WoT. Although you provide a number of arguments that
> support your claim that TOFU is weak,
I think "significantly weaker" does not apply as the two concepts are
not either-or: you can check the keys in critical situations (and in
those I would only rely on first hand verified keys anyway). Having TOFU
in that scenario by default only increases automated checks for mostof
the time where you do not care about a trust path anyway, and therefore
strengthen the overall PGP communication "quality".
And of course a WoT is not weakend if you do TOFU in addition - as long
as you do not use TOFU informations for signing
And even then, there
are enough WoT participants today which already do weak checking:
> - When you rely on the WoT, you rely on the people who made the
> signatures to have done due diligence (which is itself not very
> well defined).
Exactly, and beeing more aware of people with sloppy signing policies
might actually improve the WoT even more.
And another thing, having learned a "wrong" certificate with TOFU means
would actually improve the chance to notice a conflict once another key
is seen. And then you can still research which one was the right one.
Something you do not get when you have two conflicting marginally
trusted keys otherwise (with default tools).
Gruss
bernd
From calestyo at scientia.net Thu Apr 9 23:51:06 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Thu, 09 Apr 2015 23:51:06 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <87twwp9vsn.wl-neal@walfield.org>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net> <87twwp9vsn.wl-neal@walfield.org>
Message-ID: <1428616266.6212.74.camel@scientia.net>
Hey.
On Thu, 2015-04-09 at 17:16 +0200, Neal H. Walfield wrote:
> I apologize for the late reply. Your arguments are well stated and I
> needed some time to digest them and to do some reading and thinking of
> my own.
No worries :)
> I think it is fair to summarize your post as follows: TOFU is
> significantly weaker than the Web of Trust and adoption of TOFU will
> weaken the WoT.
Not quite. Actually I think I didn't write so much about why the WoT
might be good, but more why TOFU is evil (the later doesn't make the
former necessary better).
> Although you provide a number of arguments that
> support your claim that TOFU is weak, you didn't provide any arguments
> that the WoT is significantly stronger. I think that this is where
> your argument breaks down.
I don't think so, actually I think when you compare TOFU with the WoT
then you compare apples and oranges.
The WoT is a trust model, like the strict hierarchical model employed
with X.509.
TOFU is not really a trust model, IMHO, since it's simply a wrong
assumption that it would give any real trust about the identity.
It's basically like a decision that you believe that the first time
someone tells you an answer about some question, then you believe that
very answer and consider any other possible future answer to be wrong.
So when you ask me the first time in your like: "Are apples a fruit?"
and I tell you "no they're a species of monkeys" you'd believe and trust
that.
(No one who's sane would IMHO do that in real life, but anyway...)
So if you really want to call TOFU a trust model, than I'd call it
"believe anything", again nothing which I would want to do, when it goes
about security.
Apart from that, I didn't say that the WoT is perfect... actually it's
not.
The only thin that's really perfect is if you do direct mutual
authentication with your peers (which is actually one of the big usage
scenarios for OpenPGP).
But even then it's much better than the strict hierarchical model from
X.509 or the "trust model" from TOFU (i.e. trust anything on first use),
cause the user has still full control:
He decides which direct peers he trusts and "how much" and he decides
how many level an indirect trust path can go + how many different paths
to a indirect peer are required.
And usually people know whom of their direct peers they can trust (not
to be evil + to do the identification process correctly). Of course this
isn't a 100% guarantee (my friends could be NSA spies).
But it's still way better than what the other two give you:
- X.509
The CA is in full control, whatever it says you'll trust
- TOFU
no control at all,... or maybe controlled by good luck or your network
provider, or the one who is the first in the line to be reachable by
the target you try to contact
i.e. it's IMHO even worse than the CA model, cause you have even more
potential places where you can be attacked (MitM).
> - When you rely on the WoT, you rely on the people who made the
> signatures to have done due diligence (which is itself not very
> well defined).
Sure, absolutely,... never disputed this.
But when I really use the WoT (in contrast to what I do most, i.e.
direct mutual authentication), than I know my friends and I know whom of
them signs just because he knows the guy XYZ promises him that he really
is XYZ (but has accidentally forgotten his ID document or whatever) and
whom of them demands passport + DNA sample ;-)
It's still me who decides where I want to give a lesser level of trust
than with direct mutual authentication.
> There are, however, many examples of people signing keys that they
> haven't checked or checked poorly. In 2006, for instance, Martin
> Krafft used a "fake" id at the DebConf KSP. Only 1 in 10 people
> called him out. Here's his explanation and some reactions:
>
> http://madduck.net/blog/2006.05.24:tr-id-at-keysigning/
> https://lists.debian.org/debian-devel/2006/05/msg01393.html
> https://lists.debian.org/debian-devel/2006/05/msg01416.html
> https://lists.debian.org/debian-devel/2006/05/msg01440.html
> https://lists.debian.org/debian-devel/2006/05/msg01615.html
>
> More recently (2014), Martin tweeted:
>
> Received signatures for my #GPG key again at #DebConf14 although
> I did not attend the keysigning event.
>
> https://twitter.com/martinkrafft/status/504350313915367424
Sure... happens especially with more "famous" persons...
> - You bring up nation states as potential threats multiple times.
> This is ironic, because key signatures are typically based on
> verifying government issued id. If the government wants to
> infiltrate the WoT, it apparently just has to create a few fake ids
> and send some agents to a Debian KSP after which they'll quickly be
> in the stongly connected set and can certify any key they like.
Again, this is basically true. But I don't think it's such a big problem
either.
a) As mentioned before, I can still decide whom I want to believe. And
if some information is really precious, I simply only rely on direct
mutual authentication.
b) The problem you describe boils basically down to "what's an
identity". Is "Linus Torvalds" the guy born somewhere in Finland whose
certificate of birth says Linus Torvalds, or is he the guy of any name
who makes major contributions under that name to Linux and so on for
years.
So yes, a government can of course fake his passport, but since he's
famous, they'd also need a double. And if he'd have signed all his
contributions then people would probably go for "the guy who made that
contributions signed by key ABCDE" and not "the guy whose officially
named Linus Torvalds" (at least from a security PoV and in an "ideal"
world).
c) For a stranger, when you want to sign his key to improve the WoT, is
there any better way to prove his identity (one that doesn't require to
check through all his life and history) than ID docs?
In other words, when you sign strangers to enrich the WoT, then you
cannot do much that would be better, can you? And you personally
probably won't communicate with that stranger anyway.. and others that
use your signature as part of an indirect trust path have again (a).
And for those people I really know personally, I don't care much what
their passport says - it's just the name by whom I recognise them,
whether it's now the right or a fake name. The trust for their
identification comes from how they look, sound, behave etc.
d) Last but not least:
Again your argument is nothing which X.509 or TOFU would solve better.
In X.509, CAs also use ID documents... at best... and more realistically
they do a challenge response to some email address (at least when it
comes about server certificates)... which is IMHO a bad joke, when you
afterwards use fancy XXXXbit keys to "secure" things.
And TOFU again, makes no identity check at all.
>
> See this note from Mike Perry (Tor Project) covering this as well
> as other weaknesses in the WoT:
>
> https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html
I just had a short glance over this, but he seems to misunderstand many
basic principles.
Like "It leaks information", which is I guess unavoidable when you want
to have a system where you can authenticated against peers which you've
never met.
Trust and especially "visible trust paths" are IMHO the only chance to
get at least some kind of identification.
His point that everyone would be a CA... well sure but where's the
problem? A CA is not much more as something the assures an identity,
whether I trust it or not, is a completely different topic.
There are a number of problems with communication to the keyserver
network, but actually not so much the ones he describes, but rather
blocking and/or downgrade attacks.
But these problems exist in similar (worse) forms for X.509 either, and
with TOFU again you have nothing at all.
The scenario he devises is IMHO, while realistic, simply stupid and made
up just to counter-argue the WoT:
A single "assuring" key (Roger) whose key is either compromised or to
whom Edward has no trust path at all (and thus a fake Roger key could be
presented by the sysadmins).
Of course it's realistic that one wants to communicate with someone else
one has never met, but then relying on a single other key?! Well you
can't protect people from shooting into their own feet, can you?
Better look at whom you give full trust.
And in the other direction (i.e. the journalist verifying Edward, there
seems to be now trust path at all?)... well realistic,... but
nevertheless a stupid evaluation... it's like I'd give my laptop a bad
evaluation because it cannot fly.
Actually this example shows the following:
You have a situation (secure communication between people that never
directly met is required) that needs to be solved.
A situation wich is inherently unsolvable... and he measures the WoT on
failing in this situation.
But both, X.509 and TOFU would perform much worse. We've all seen how
easy it apparently is to trick commercial CAs into giving you what you
want (or you are China and simply run your own).
And TOFU... well if the sysadmins are in between, why should they be
able to attack the WoT (where they need at least that compromised key)
but not the fully unsecured trust on first use?
This example just shows why TOFU is an illusion, especially when someone
decides to do something (MitM) against it and especially since there is
no single reason, which would prevent e.g. the NSA from doing mass MitM.
> - In practice, the WoT is hard to use. If you endow marginal trust
> in others' signatures, then it can be hard to find a good path.
> The other day, I tried to verify a friend's key. Even though I
> have about 100 signatures on my main key and he has 37, gpg said
> his key was not trusted.
Sure, but a) you can control yourself how much you want and b) you want
it to solve a problem that is inherently unsolvable.
What kind of magic should it do to create the trust it doesn't have? At
least it does a bit more than the other models.
> - The practical result is that exploiting the WoT is hard. You
> either need to directly verify someone's identity (which isn't
> really WoT)
As I've said, the WoT shouldn't be expected to magically give everyone
trust between everyone.
If you have a better solution how this could be done,... just tell us =)
But again, nothing where TOFU would give you anything more.
> get a lot of signatures or just ignore the frequent
> not trusted warnings (which I and many others often do).
You can't blame the system for using it explicitly and intentionally
wrong.
> - Ignoring these warning *is* a serious problem as Erinn Clark, the
> release manager for Tor, has recently observed.
And TOFU is basically like *always* and *automatically* ignoring that
warning (of course just on the first use, but that's no difference from
what you'd do with your WoT or first time SSH), while still promising
people that they'd be now more secure against "something".
> Someone uploaded a
> key with her identity to the public key servers. If people have
> gotten into the bad habit of using trust=always (or ignoring the
> warning), then they'll happily accept signatures from this bad key.
> TOFU and its emphasis on consistency could potentially help here.
The either you or I misunderstand something about it ^^
How does TOFU help here? Trust on first use (without any further
checks)... what's the different from blindly saying trust=always?
> - Indeed, some well-known cryptographers, such as Peter Gutmann,
> argue that continuity (i.e., TOFU) is strictly better than third
> party attestations (i.e., signatures):
>
> http://www.cypherpunks.to/~peter/T2_Key_Management.pdf (Page 8).
I haven't read through all of this, but I don't see him advertising
TOFU, does he?
What he says is "Key Continuity",... which is basically what OpenPGP
(and others give) you by using the same key, and not creating e.g. a new
OpenPGP key for each communication.
That's basically why we use public-key cryptography, that we don't need
to securely exchange a new symmetric key for each message (respectively
the PKC does that for us).
He also says "Verify that the current key is the same as the one that
you got previously" which *is not just* TOFU.
TOFU does this (after the first use), but so do the others.
And when looking at his example for SSH he says:
"On first connect, client software asks the user to verify the key" and
"Done via the key fingerprint"... and this is actually not-TOFU.
He want's people to *verify* the key... (e.g. via the fingerprint) and
not simply trust it on first use.
> - The WoT suffers from the revocation problem. For instance, it
> takes hours for key updates to propagate between the servers
> participating in pool.sks-keyservers.net.
First, this isn't really a part of the WoT.
It's simply the question of how to make key and key revocation
directories.
Admittedly, the OpenPGP keyserver network has it's problems (IIRC I
reported them here or at a gnupg mailing list already years ago),... but
they still perform *way* better than how the same problem is solved at
the X.509 side (in practice and always just voluntary OOCP query, or
CRLs which are even less often updated or mostly not even reachable)...
and infinitely better than what TOFU does (no revocation directory at
all,.. or at best some periodic auto-revocation like you have with
HPKP).
The keyserver network is actually the only thing right now which could
at least in principle be used to somewhat protect against evil keyserver
operators, in that each query and each submission is always made to
multiple of them (and something like hkps be used).
> Further, GnuPG doesn't
> check for key updates automatically so the problems are actually
> worse than when using PKI.
I assume with PKI you mean the X.509 PKI?
Not really,... first, this is nothing what the standard would mandate.
So if at all it would only be a gnupg issue.
And for X.509 it doesn't check for new keys, if at all then only for
revocations. And there we all know that basically all systems do this
just opportunistically, because the OSCP/CRL system is so fragile.
Browsers typically don't even warn you when a OSCP query failed (if they
even do it at all).
> - The WoT leaks lots of information.
You had that before I think, but again... nothing that you could really
solve by any other system (and especially not TOFU, which definitely
would need some way to fetch the keys of arbitrary peers).
It's basically like you'd want a phone book (to communicate with
strangers) but that phone book wouldn't be allowed to contain any names
(and perhaps not even numbers).
Long story short,... I don't think the the opponents (X.509, TOFU)
perform in any of your points better than the WoT does.
But more general, my post about TOFU was less an advertisement for the
WoT - it was just a collection of arguments against TOFU, both at the
technical level itself and at the higher "meta" level of the long term
political and social problems it introduces.
If you compare it with other trust models than you miss my actual
points.
For me the central point of TOFU is the anonymous authentication which
is entrusted on the first use.
And this is also what makes it worse than any of the other trust models,
simply because it gives you nothing (unless you have good luck).
And the really evil part about it is, that it's now sold to people as a
good way against mass surveillance, which is in turn based on completely
unrealistic assumptions (i.e. that NSA&Co. would stand still and do
nothing).
Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
From gniibe at fsij.org Fri Apr 10 02:23:11 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 10 Apr 2015 09:23:11 +0900
Subject: Label of OpenPGPcard (was: Identifier of OpenPGPcard)
In-Reply-To: <5526AC9A.7030201@sumptuouscapital.com>
References: <5524E98A.9020603@fsij.org>
<871tjtwlny.fsf@vigenere.g10code.de> <552685ED.7060503@fsij.org>
<87oamxtjpr.fsf@vigenere.g10code.de> <5526AAFF.2070705@fsij.org>
<5526AC9A.7030201@sumptuouscapital.com>
Message-ID: <552717EF.3080002@fsij.org>
On 04/10/2015 01:45 AM, Kristian Fiskerstrand wrote:
> And how would you differentiate in the case you have one smartcard
> with the primary key only kept securely and one smartcard for daily
> use with subkeys only?
Thank you for this use case. I didn't consider this specific case.
No, it is not possible to differentiate by an identifier in this case.
Well, I shouldn't call it identifier, perhaps. Let me call it label.
In the case of primary key only smartcard and subkeys only smartcard
under same primary key, it will be obvious that each smartcard will
have the information needed (primary key, or subkey) or not. A user
can examine by gpg --card-status.
Let me rephrase the questions:
(1) What kind of information should be there in a stub when
private key is on a smartcard?
(2) How we should prompt a user for different smartcard?
For (1), I think that a label (of primary key fingerprint) make sense.
I consider a serial number would be questionable (if user doesn't pay
much attention).
For (2), I think that it is user-friendly to be asked:
Please insert a smartcard for primary key YYY...YYY.
or:
Please insert a smartcard for subkey XXX...XXX
of primary key YYY...YYY.
I mean, it would be just confusing to be asked with serial number
SS...SS:
Please insert a smartcard with SS...SS
for key XXX...XXX
--
From brian at minton.name Fri Apr 10 01:41:26 2015
From: brian at minton.name (Brian Minton)
Date: Thu, 09 Apr 2015 23:41:26 +0000
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <1428616266.6212.74.camel@scientia.net>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net> <87twwp9vsn.wl-neal@walfield.org>
<1428616266.6212.74.camel@scientia.net>
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
IMHO here is one advantage of TOFU: Imagine that at any given time, a
third party is intercepting (and potentially modifying) your
communications. In many cases they may not control all paths between you
and the keyserver network. Therefore you may receive the legitimate key as
well as a fake one, causing an alarm (or at least extra caution). This
doesn't help if the adversary controls all traffic between your computer
and the outside world, but in some cases you could go to a cyber cafe, etc.
to get a second path to the keyservers.
For example, when using ssh, which uses TOFU, I often connect to a host
from multiple ISPs to make sure the host key fingerprint matches.
I agree with the idea of using WoT in conjunction with TOFU, not as a
replacement.
-----BEGIN PGP SIGNATURE-----
Version: OpenKeychain v3.1.2
iIAEAREIACghHEJyaWFuIE1pbnRvbiA8YnJpYW5AbWludG9uLm5hbWU+BQJVJw4X
AAoJEGuOs6Blz7qpJcgBAICjqmJVuN+H/5/pyD98dyqsxCcAEnd/DZ6xjb8uBEKt
AP4jLisM5UpinmQihqjQ6AgtfQnPRAteyWbZKhmVhhjtQQ==
=awQR
-----END PGP SIGNATURE-----
On Thu, Apr 9, 2015, 5:53 PM Christoph Anton Mitterer
wrote:
> Hey.
>
>
> On Thu, 2015-04-09 at 17:16 +0200, Neal H. Walfield wrote:
> > I apologize for the late reply. Your arguments are well stated and I
> > needed some time to digest them and to do some reading and thinking of
> > my own.
> No worries :)
>
>
> > I think it is fair to summarize your post as follows: TOFU is
> > significantly weaker than the Web of Trust and adoption of TOFU will
> > weaken the WoT.
> Not quite. Actually I think I didn't write so much about why the WoT
> might be good, but more why TOFU is evil (the later doesn't make the
> former necessary better).
>
>
>
> > Although you provide a number of arguments that
> > support your claim that TOFU is weak, you didn't provide any arguments
> > that the WoT is significantly stronger. I think that this is where
> > your argument breaks down.
> I don't think so, actually I think when you compare TOFU with the WoT
> then you compare apples and oranges.
>
> The WoT is a trust model, like the strict hierarchical model employed
> with X.509.
> TOFU is not really a trust model, IMHO, since it's simply a wrong
> assumption that it would give any real trust about the identity.
> It's basically like a decision that you believe that the first time
> someone tells you an answer about some question, then you believe that
> very answer and consider any other possible future answer to be wrong.
> So when you ask me the first time in your like: "Are apples a fruit?"
> and I tell you "no they're a species of monkeys" you'd believe and trust
> that.
> (No one who's sane would IMHO do that in real life, but anyway...)
>
> So if you really want to call TOFU a trust model, than I'd call it
> "believe anything", again nothing which I would want to do, when it goes
> about security.
>
>
> Apart from that, I didn't say that the WoT is perfect... actually it's
> not.
> The only thin that's really perfect is if you do direct mutual
> authentication with your peers (which is actually one of the big usage
> scenarios for OpenPGP).
>
> But even then it's much better than the strict hierarchical model from
> X.509 or the "trust model" from TOFU (i.e. trust anything on first use),
> cause the user has still full control:
> He decides which direct peers he trusts and "how much" and he decides
> how many level an indirect trust path can go + how many different paths
> to a indirect peer are required.
> And usually people know whom of their direct peers they can trust (not
> to be evil + to do the identification process correctly). Of course this
> isn't a 100% guarantee (my friends could be NSA spies).
> But it's still way better than what the other two give you:
> - X.509
> The CA is in full control, whatever it says you'll trust
> - TOFU
> no control at all,... or maybe controlled by good luck or your network
> provider, or the one who is the first in the line to be reachable by
> the target you try to contact
> i.e. it's IMHO even worse than the CA model, cause you have even more
> potential places where you can be attacked (MitM).
>
>
>
> > - When you rely on the WoT, you rely on the people who made the
> > signatures to have done due diligence (which is itself not very
> > well defined).
> Sure, absolutely,... never disputed this.
> But when I really use the WoT (in contrast to what I do most, i.e.
> direct mutual authentication), than I know my friends and I know whom of
> them signs just because he knows the guy XYZ promises him that he really
> is XYZ (but has accidentally forgotten his ID document or whatever) and
> whom of them demands passport + DNA sample ;-)
> It's still me who decides where I want to give a lesser level of trust
> than with direct mutual authentication.
>
>
> > There are, however, many examples of people signing keys that they
> > haven't checked or checked poorly. In 2006, for instance, Martin
> > Krafft used a "fake" id at the DebConf KSP. Only 1 in 10 people
> > called him out. Here's his explanation and some reactions:
> >
> > http://madduck.net/blog/2006.05.24:tr-id-at-keysigning/
> > https://lists.debian.org/debian-devel/2006/05/msg01393.html
> > https://lists.debian.org/debian-devel/2006/05/msg01416.html
> > https://lists.debian.org/debian-devel/2006/05/msg01440.html
> > https://lists.debian.org/debian-devel/2006/05/msg01615.html
> >
> > More recently (2014), Martin tweeted:
> >
> > Received signatures for my #GPG key again at #DebConf14 although
> > I did not attend the keysigning event.
> >
> > https://twitter.com/martinkrafft/status/504350313915367424
> Sure... happens especially with more "famous" persons...
>
>
> > - You bring up nation states as potential threats multiple times.
> > This is ironic, because key signatures are typically based on
> > verifying government issued id. If the government wants to
> > infiltrate the WoT, it apparently just has to create a few fake ids
> > and send some agents to a Debian KSP after which they'll quickly be
> > in the stongly connected set and can certify any key they like.
> Again, this is basically true. But I don't think it's such a big problem
> either.
>
> a) As mentioned before, I can still decide whom I want to believe. And
> if some information is really precious, I simply only rely on direct
> mutual authentication.
>
> b) The problem you describe boils basically down to "what's an
> identity". Is "Linus Torvalds" the guy born somewhere in Finland whose
> certificate of birth says Linus Torvalds, or is he the guy of any name
> who makes major contributions under that name to Linux and so on for
> years.
> So yes, a government can of course fake his passport, but since he's
> famous, they'd also need a double. And if he'd have signed all his
> contributions then people would probably go for "the guy who made that
> contributions signed by key ABCDE" and not "the guy whose officially
> named Linus Torvalds" (at least from a security PoV and in an "ideal"
> world).
>
> c) For a stranger, when you want to sign his key to improve the WoT, is
> there any better way to prove his identity (one that doesn't require to
> check through all his life and history) than ID docs?
> In other words, when you sign strangers to enrich the WoT, then you
> cannot do much that would be better, can you? And you personally
> probably won't communicate with that stranger anyway.. and others that
> use your signature as part of an indirect trust path have again (a).
> And for those people I really know personally, I don't care much what
> their passport says - it's just the name by whom I recognise them,
> whether it's now the right or a fake name. The trust for their
> identification comes from how they look, sound, behave etc.
>
> d) Last but not least:
> Again your argument is nothing which X.509 or TOFU would solve better.
> In X.509, CAs also use ID documents... at best... and more realistically
> they do a challenge response to some email address (at least when it
> comes about server certificates)... which is IMHO a bad joke, when you
> afterwards use fancy XXXXbit keys to "secure" things.
> And TOFU again, makes no identity check at all.
>
>
> >
> > See this note from Mike Perry (Tor Project) covering this as well
> > as other weaknesses in the WoT:
> >
> > https://lists.torproject.org/pipermail/tor-talk/2013-
> September/030235.html
> I just had a short glance over this, but he seems to misunderstand many
> basic principles.
> Like "It leaks information", which is I guess unavoidable when you want
> to have a system where you can authenticated against peers which you've
> never met.
> Trust and especially "visible trust paths" are IMHO the only chance to
> get at least some kind of identification.
>
> His point that everyone would be a CA... well sure but where's the
> problem? A CA is not much more as something the assures an identity,
> whether I trust it or not, is a completely different topic.
>
> There are a number of problems with communication to the keyserver
> network, but actually not so much the ones he describes, but rather
> blocking and/or downgrade attacks.
> But these problems exist in similar (worse) forms for X.509 either, and
> with TOFU again you have nothing at all.
>
> The scenario he devises is IMHO, while realistic, simply stupid and made
> up just to counter-argue the WoT:
> A single "assuring" key (Roger) whose key is either compromised or to
> whom Edward has no trust path at all (and thus a fake Roger key could be
> presented by the sysadmins).
> Of course it's realistic that one wants to communicate with someone else
> one has never met, but then relying on a single other key?! Well you
> can't protect people from shooting into their own feet, can you?
> Better look at whom you give full trust.
> And in the other direction (i.e. the journalist verifying Edward, there
> seems to be now trust path at all?)... well realistic,... but
> nevertheless a stupid evaluation... it's like I'd give my laptop a bad
> evaluation because it cannot fly.
>
> Actually this example shows the following:
> You have a situation (secure communication between people that never
> directly met is required) that needs to be solved.
> A situation wich is inherently unsolvable... and he measures the WoT on
> failing in this situation.
> But both, X.509 and TOFU would perform much worse. We've all seen how
> easy it apparently is to trick commercial CAs into giving you what you
> want (or you are China and simply run your own).
> And TOFU... well if the sysadmins are in between, why should they be
> able to attack the WoT (where they need at least that compromised key)
> but not the fully unsecured trust on first use?
> This example just shows why TOFU is an illusion, especially when someone
> decides to do something (MitM) against it and especially since there is
> no single reason, which would prevent e.g. the NSA from doing mass MitM.
>
>
> > - In practice, the WoT is hard to use. If you endow marginal trust
> > in others' signatures, then it can be hard to find a good path.
> > The other day, I tried to verify a friend's key. Even though I
> > have about 100 signatures on my main key and he has 37, gpg said
> > his key was not trusted.
> Sure, but a) you can control yourself how much you want and b) you want
> it to solve a problem that is inherently unsolvable.
> What kind of magic should it do to create the trust it doesn't have? At
> least it does a bit more than the other models.
>
>
> > - The practical result is that exploiting the WoT is hard. You
> > either need to directly verify someone's identity (which isn't
> > really WoT)
> As I've said, the WoT shouldn't be expected to magically give everyone
> trust between everyone.
> If you have a better solution how this could be done,... just tell us =)
>
> But again, nothing where TOFU would give you anything more.
>
>
> > get a lot of signatures or just ignore the frequent
> > not trusted warnings (which I and many others often do).
> You can't blame the system for using it explicitly and intentionally
> wrong.
>
>
> > - Ignoring these warning *is* a serious problem as Erinn Clark, the
> > release manager for Tor, has recently observed.
> And TOFU is basically like *always* and *automatically* ignoring that
> warning (of course just on the first use, but that's no difference from
> what you'd do with your WoT or first time SSH), while still promising
> people that they'd be now more secure against "something".
>
>
> > Someone uploaded a
> > key with her identity to the public key servers. If people have
> > gotten into the bad habit of using trust=always (or ignoring the
> > warning), then they'll happily accept signatures from this bad key.
> > TOFU and its emphasis on consistency could potentially help here.
> The either you or I misunderstand something about it ^^
> How does TOFU help here? Trust on first use (without any further
> checks)... what's the different from blindly saying trust=always?
>
>
> > - Indeed, some well-known cryptographers, such as Peter Gutmann,
> > argue that continuity (i.e., TOFU) is strictly better than third
> > party attestations (i.e., signatures):
> >
> > http://www.cypherpunks.to/~peter/T2_Key_Management.pdf (Page 8).
> I haven't read through all of this, but I don't see him advertising
> TOFU, does he?
>
> What he says is "Key Continuity",... which is basically what OpenPGP
> (and others give) you by using the same key, and not creating e.g. a new
> OpenPGP key for each communication.
> That's basically why we use public-key cryptography, that we don't need
> to securely exchange a new symmetric key for each message (respectively
> the PKC does that for us).
> He also says "Verify that the current key is the same as the one that
> you got previously" which *is not just* TOFU.
> TOFU does this (after the first use), but so do the others.
> And when looking at his example for SSH he says:
> "On first connect, client software asks the user to verify the key" and
> "Done via the key fingerprint"... and this is actually not-TOFU.
> He want's people to *verify* the key... (e.g. via the fingerprint) and
> not simply trust it on first use.
>
>
> > - The WoT suffers from the revocation problem. For instance, it
> > takes hours for key updates to propagate between the servers
> > participating in pool.sks-keyservers.net.
> First, this isn't really a part of the WoT.
> It's simply the question of how to make key and key revocation
> directories.
> Admittedly, the OpenPGP keyserver network has it's problems (IIRC I
> reported them here or at a gnupg mailing list already years ago),... but
> they still perform *way* better than how the same problem is solved at
> the X.509 side (in practice and always just voluntary OOCP query, or
> CRLs which are even less often updated or mostly not even reachable)...
> and infinitely better than what TOFU does (no revocation directory at
> all,.. or at best some periodic auto-revocation like you have with
> HPKP).
> The keyserver network is actually the only thing right now which could
> at least in principle be used to somewhat protect against evil keyserver
> operators, in that each query and each submission is always made to
> multiple of them (and something like hkps be used).
>
>
> > Further, GnuPG doesn't
> > check for key updates automatically so the problems are actually
> > worse than when using PKI.
> I assume with PKI you mean the X.509 PKI?
> Not really,... first, this is nothing what the standard would mandate.
> So if at all it would only be a gnupg issue.
> And for X.509 it doesn't check for new keys, if at all then only for
> revocations. And there we all know that basically all systems do this
> just opportunistically, because the OSCP/CRL system is so fragile.
> Browsers typically don't even warn you when a OSCP query failed (if they
> even do it at all).
>
>
> > - The WoT leaks lots of information.
> You had that before I think, but again... nothing that you could really
> solve by any other system (and especially not TOFU, which definitely
> would need some way to fetch the keys of arbitrary peers).
> It's basically like you'd want a phone book (to communicate with
> strangers) but that phone book wouldn't be allowed to contain any names
> (and perhaps not even numbers).
>
>
>
> Long story short,... I don't think the the opponents (X.509, TOFU)
> perform in any of your points better than the WoT does.
> But more general, my post about TOFU was less an advertisement for the
> WoT - it was just a collection of arguments against TOFU, both at the
> technical level itself and at the higher "meta" level of the long term
> political and social problems it introduces.
> If you compare it with other trust models than you miss my actual
> points.
>
> For me the central point of TOFU is the anonymous authentication which
> is entrusted on the first use.
> And this is also what makes it worse than any of the other trust models,
> simply because it gives you nothing (unless you have good luck).
> And the really evil part about it is, that it's now sold to people as a
> good way against mass surveillance, which is in turn based on completely
> unrealistic assumptions (i.e. that NSA&Co. would stand still and do
> nothing).
>
>
> Cheers,
> Chris.
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From gniibe at fsij.org Fri Apr 10 07:01:58 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 10 Apr 2015 14:01:58 +0900
Subject: Private key transfer format
In-Reply-To: <552685ED.7060503@fsij.org>
References: <5524E98A.9020603@fsij.org> <871tjtwlny.fsf@vigenere.g10code.de>
<552685ED.7060503@fsij.org>
Message-ID: <55275946.4020309@fsij.org>
On 04/09/2015 11:00 PM, NIIBE Yutaka wrote:
> I thought it was a regression. In GnuPG 1.4 and 2.0, some people did
> --export-secret-keys for smartcard. Well, I naively tried to "fix"
> as a response to the bug report.
>
> Yes, I think that we can just drop the support of --export-secret-keys
> for smartcard, and fix documentations.
>
> Well, in my opinion, it is unlikely there are some smartcard users who
> expect serial number exact check by GnuPG with --export-secret-keys in
> a machine and --import on another machine.
Sorry, this attitude of mine is wrong somehow. It's my near sight, I
only considered about GnuPG. It's complicated.
Perhaps, this requires changing some existing practice(?, so to say).
I found a document with --export-secret-subkey for stub:
https://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups
And, it is described in FAQ of OpenKeychain:
http://www.openkeychain.org/faq/
Although exporting the stub was not intended feature in GnuPG 1.4 and
2.0, people used that (beyond GnuPG).
We could/should convince OpenKeychain (or other OpenPGP application,
if any) about handling of secret key stub; there is no need to export
and import secret key stub, but stub can be generated by smartcard
itself.
Let me confirm the current position of GnuPG 2.1: For new machine, it
is a public key of OpenPGP we need to import (or fetch) and stub
could/should be generated with a smartcard (gpg --card-status does
that).
Note that the background of the issue1937 [0] is exporting the stub
from GnuPG and importing it to OpenKeychain (that is, into different
application of OpenPGP).
[0] https://bugs.g10code.com/gnupg/issue1937
--
From neal at walfield.org Fri Apr 10 10:06:44 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 10 Apr 2015 10:06:44 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <20150409220446.00007fe0.ecki@lina.inka.de>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net>
<87twwp9vsn.wl-neal@walfield.org>
<20150409220446.00007fe0.ecki@lina.inka.de>
Message-ID: <87r3rs9zl7.wl-neal@walfield.org>
Hi Bernd,
At Thu, 9 Apr 2015 22:04:46 +0200,
lists-gnupgdev at lina.inka.de wrote:
> Am Thu, 09 Apr 2015 17:16:24 +0200
> schrieb "Neal H. Walfield" :
>
> > I think it is fair to summarize your post as follows: TOFU is
> > significantly weaker than the Web of Trust and adoption of TOFU will
> > weaken the WoT. Although you provide a number of arguments that
> > support your claim that TOFU is weak,
>
> I think "significantly weaker" does not apply as the two concepts are
> not either-or: you can check the keys in critical situations (and in
> those I would only rely on first hand verified keys anyway). Having TOFU
> in that scenario by default only increases automated checks for mostof
> the time where you do not care about a trust path anyway, and therefore
> strengthen the overall PGP communication "quality".
>
> And of course a WoT is not weakend if you do TOFU in addition - as long
> as you do not use TOFU informations for signing
>
> And even then, there
> are enough WoT participants today which already do weak checking:
I agree that it is reasonable to use both the WoT and TOFU to better
identify inconsistencies (i.e., keys changing). I think Christoph
argued that using TOFU will undermine the WoT, because people will
think TOFU is enough and as such not support the WoT as much. This is
a worse-is-better argument: the existence of an easy half-solution
means fewer people will embrace the more difficult full solution. I
often agree with this argument, but in this case, I don't think it
applies: the WoT is not better (i.e., more secure) than TOFU.
Neal
From neal at walfield.org Fri Apr 10 11:37:18 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 10 Apr 2015 11:37:18 +0200
Subject: the TOFU lie - or why I want my meat...
In-Reply-To: <1428616266.6212.74.camel@scientia.net>
References: <87bnj9f2fr.wl-neal@walfield.org>
<878uedhrbu.fsf@alice.fifthhorseman.net>
<1427841635.17032.147.camel@scientia.net>
<87twwp9vsn.wl-neal@walfield.org>
<1428616266.6212.74.camel@scientia.net>
Message-ID: <87pp7c9ve9.wl-neal@walfield.org>
At Thu, 09 Apr 2015 23:51:06 +0200,
Christoph Anton Mitterer wrote:
> > I think it is fair to summarize your post as follows: TOFU is
> > significantly weaker than the Web of Trust and adoption of TOFU will
> > weaken the WoT.
> Not quite. Actually I think I didn't write so much about why the WoT
> might be good, but more why TOFU is evil (the later doesn't make the
> former necessary better).
I understood from your mails that you thought the WoT is better than
TOFU based on the following comment (among others):
At Wed, 01 Apr 2015 00:40:35 +0200,
Christoph Anton Mitterer wrote:
> OpenPGP and similar schemes ... [are] typically only used by
> people who want stronger security (i.e. those who don't trust
> that fragile strict hierarchical and CA based model of X.509). Or
> in cases where it needs to be sure that a 3rd party cannot forge
> anything (e.g. when distributing packages of a Linux distro).
> TOFU is not really a trust model, IMHO, since it's simply a wrong
> assumption that it would give any real trust about the identity.
> It's basically like a decision that you believe that the first time
> someone tells you an answer about some question, then you believe that
> very answer and consider any other possible future answer to be wrong.
> So when you ask me the first time in your like: "Are apples a fruit?"
> and I tell you "no they're a species of monkeys" you'd believe and trust
> that.
> (No one who's sane would IMHO do that in real life, but anyway...)
>
> So if you really want to call TOFU a trust model, than I'd call it
> "believe anything", again nothing which I would want to do, when it goes
> about security.
I think we have fundamentally different perspectives.
Using an analogy from statistics, you seem to have a frequentist
perspective and I have a Bayesian perspective. Neither one is better
than the other. They simply interpret probabilities in different ways
and thus provide different information. When a frequentist says that
the probability of an event is 10%, then we expect that the event will
occur 1 out of 10 times. For a Bayesian, probabilities corresond to
degrees of *belief*. Thus, when a Bayesian says that the probability
of an event is 10%, it is very much grounded in a set of beliefs. As
the Bayesian observes more evidence, the beliefs are updated and they
(hopefully) begin to converge to the truth. Because the Bayesian has
so little data at the beginning (i.e., prior to any evidence) a
so-called prior is used. This represents the belief in the absence of
evidence.
For more information about Frequentists vs. Bayesian methodologies,
see Larry Wasserman's blog post:
https://normaldeviate.wordpress.com/2012/11/17/what-is-bayesianfrequentist-inference/
So, how does this apply to TOFU? You seem to be arguing that once we
see a key, TOFU asserts that it is 100% correct and can be relied upon
until we see evidence to the contrary. I'd argue that this it the
wrong approach: this is just a little bit of evidence and we need to
be skeptical. Instead, we should use a strong prior that says we
don't know if we can trust this key. Then, after seeing one example,
we might assert P(K is correct) = (say) 10%. As we observe evidence
that the key is really controlled by the same person, we increase our
belief that the observed key is correct. We get more evidence by
observing more signed mails from the same person (which are preferably
received via different network paths, which decreases our belief that
there is an active MITM attack). Note: that our prior also means that
we will never assert with 100% confidence that the key is correct.
> b) The problem you describe boils basically down to "what's an
> identity". Is "Linus Torvalds" the guy born somewhere in Finland whose
> certificate of birth says Linus Torvalds, or is he the guy of any name
> who makes major contributions under that name to Linux and so on for
> years.
> So yes, a government can of course fake his passport, but since he's
> famous, they'd also need a double. And if he'd have signed all his
> contributions then people would probably go for "the guy who made that
> contributions signed by key ABCDE" and not "the guy whose officially
> named Linus Torvalds" (at least from a security PoV and in an "ideal"
> world).
This is an example of consistency and exactly what TOFU can identify.
> c) For a stranger, when you want to sign his key to improve the WoT, is
> there any better way to prove his identity (one that doesn't require to
> check through all his life and history) than ID docs?
> In other words, when you sign strangers to enrich the WoT, then you
> cannot do much that would be better, can you? And you personally
> probably won't communicate with that stranger anyway.. and others that
> use your signature as part of an indirect trust path have again (a).
> And for those people I really know personally, I don't care much what
> their passport says - it's just the name by whom I recognise them,
> whether it's now the right or a fake name. The trust for their
> identification comes from how they look, sound, behave etc.
Again, you argue for consistency!
> d) Last but not least:
> Again your argument is nothing which X.509 or TOFU would solve better.
> In X.509, CAs also use ID documents... at best... and more realistically
> they do a challenge response to some email address (at least when it
> comes about server certificates)... which is IMHO a bad joke, when you
> afterwards use fancy XXXXbit keys to "secure" things.
> And TOFU again, makes no identity check at all.
TOFU doesn't check identify. It checks consistency. This is what I
said in my original note:
TOFU is good for checking an association between an identity (in our
case, an email address) and a key.
> > - The practical result is that exploiting the WoT is hard. You
> > either need to directly verify someone's identity (which isn't
> > really WoT)
> As I've said, the WoT shouldn't be expected to magically give everyone
> trust between everyone.
> If you have a better solution how this could be done,... just tell us =)
If the WoT is rarely usable, then its utility is low.
> > get a lot of signatures or just ignore the frequent
> > not trusted warnings (which I and many others often do).
> You can't blame the system for using it explicitly and intentionally
> wrong.
Sure you can. If such a system is in use and it is inadequate (in
this case, it is too sophisticated and too burdensome for most users),
then we should look for something else.
> > Someone uploaded a
> > key with her identity to the public key servers. If people have
> > gotten into the bad habit of using trust=always (or ignoring the
> > warning), then they'll happily accept signatures from this bad key.
> > TOFU and its emphasis on consistency could potentially help here.
> The either you or I misunderstand something about it ^^
> How does TOFU help here? Trust on first use (without any further
> checks)... what's the different from blindly saying trust=always?
The ability to identify inconsistencies. If you just use
trust=always, then you won't notice changes.
> Long story short,... I don't think the the opponents (X.509, TOFU)
> perform in any of your points better than the WoT does.
> But more general, my post about TOFU was less an advertisement for the
> WoT - it was just a collection of arguments against TOFU, both at the
> technical level itself and at the higher "meta" level of the long term
> political and social problems it introduces.
> If you compare it with other trust models than you miss my actual
> points.
I guess I misunderstood parts of your posts.
I acknowledge that TOFU has limitations, but I see it's ability to
check consistency as being very valuable.
Neal
From wk at gnupg.org Fri Apr 10 12:49:18 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Apr 2015 12:49:18 +0200
Subject: Private key transfer format
In-Reply-To: <55275946.4020309@fsij.org> (NIIBE Yutaka's message of "Fri, 10
Apr 2015 14:01:58 +0900")
References: <5524E98A.9020603@fsij.org> <871tjtwlny.fsf@vigenere.g10code.de>
<552685ED.7060503@fsij.org> <55275946.4020309@fsij.org>
Message-ID: <87lhi0qmvl.fsf@vigenere.g10code.de>
On Fri, 10 Apr 2015 07:01, gniibe at fsij.org said:
> Let me confirm the current position of GnuPG 2.1: For new machine, it
Just a quick note:
GnuPG 2.0 will hopefully soon be replaced by 2.1. We won't keep on
maintaining 2.0 except for security updates and maybe useful features we
can easily backport.
Smart card support for 1.4 will fade out - it is not justified.
Smartcards require user interaction and thus there use on servers is
quite limited.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Sat Apr 11 20:34:43 2015
From: wk at gnupg.org (Werner Koch)
Date: Sat, 11 Apr 2015 20:34:43 +0200
Subject: [Announce] GnuPG 2.1.3 released
Message-ID: <87mw2ems3g.fsf@vigenere.g10code.de>
Hello!
The GnuPG Project is pleased to announce the availability of the
another release of GnuPG modern: Version 2.1.3.
The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.
GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories. GnuPG itself is a command line tool with features for easy
integration with other applications. A wealth of frontend applications
and libraries making use of GnuPG are available. Since version 2 GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.
GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.
Three different versions of GnuPG are actively maintained:
- GnuPG "modern" (2.1) is the latest development with a lot of new
features. This announcement is about the first release of this
version.
- GnuPG "stable" (2.0) is the current stable version for general use.
This is what most users are currently using.
- GnuPG "classic" (1.4) is the old standalone version which is most
suitable for older or embedded platforms.
You may not install "modern" (2.1) and "stable" (2.0) at the same
time. However, it is possible to install "classic" (1.4) along with
any of the other versions.
Noteworthy changes in version 2.1.3
===================================
* gpg: LDAP keyservers are now supported by 2.1.
* gpg: New option --with-icao-spelling.
* gpg: New option --print-pka-records. Changed the PKA method to use
CERT records and hashed names.
* gpg: New command --list-gcrypt-config. New parameter "curve"
for --list-config.
* gpg: Print a NEWSIG status line like gpgsm always did.
* gpg: Print MPI values with --list-packets and --verbose.
* gpg: Write correct MPI lengths with ECC keys.
* gpg: Skip legacy PGP-2 keys while searching.
* gpg: Improved searching for mail addresses when using a keybox.
* gpgsm: Changed default algos to AES-128 and SHA-256.
* gpgtar: Fixed extracting files with sizes of a multiple of 512.
* dirmngr: Fixed SNI handling for hkps pools.
* dirmngr: extra-certs and trusted-certs are now always loaded from
the sysconfig dir instead of the homedir.
* Fixed possible problems due to compiler optimization, two minor
regressions, and other bugs.
A detailed description of the changes found in the 2.1 versions can be
found at https://gnupg.org/faq/whats-new-in-2.1.html .
Getting the Software
====================
Please follow the instructions found at https://gnupg.org/download/ or
read on:
GnuPG 2.1.3 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server. The list of mirrors can be found
at . Note that GnuPG is not available
at ftp.gnu.org.
On ftp.gnupg.org you find these files:
ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.3.tar.bz2 (4762k)
ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.3.tar.bz2.sig
This is the GnuPG source code compressed using BZIP2 and its OpenPGP
signature.
An experimental Windows installer for this version will be released next
week.
This version fixes a lot of bugs found after the release of 2.1.2 but
there are still known bugs which we are working on. Please check the
the bug tracker, https://wiki.gnupg.org, or mailing list archives for
known problems and workaround.
Checking the Integrity
======================
In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:
* If you already have a version of GnuPG installed, you can simply
verify the supplied signature. For example to verify the signature
of the file gnupg-2.1.3.tar.bz2 you would use this command:
gpg --verify gnupg-2.1.3.tar.bz2.sig gnupg-2.1.3.tar.bz2
This checks whether the signature file matches the source file.
You should see a message indicating that the signature is good and
made by one or more of the release signing keys. Make sure that
this is a valid key, either by matching the shown fingerprint
against a trustworthy list of valid release signing keys or by
checking that the key has been signed by trustworthy other keys.
See below for information on the signing keys.
* If you are not able to use an existing version of GnuPG, you have
to verify the SHA-1 checksum. On Unix systems the command to do
this is either "sha1sum" or "shasum". Assuming you downloaded the
file gnupg-2.1.3.tar.bz2, you would run the command like this:
sha1sum gnupg-2.1.3.tar.bz2
and check that the output matches the next line:
091e69ec1ce3f0032e6b135e4da561e8d46d20a7 gnupg-2.1.3.tar.bz2
Release Signing Keys
====================
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions. The keys are also signed by the long term keys of
their respective owners. Current releases are signed by one or more
of these four keys:
2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959
David Shaw (GnuPG Release Signing Key)
rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
NIIBE Yutaka (GnuPG Release Key)
rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9
Werner Koch (Release Signing Key)
You may retrieve these files from a keyserver using this command
gpg --keyserver hkp://keys.gnupg.net --recv-keys \
249B39D24F25E3B6 04376F3EE0856959 \
2071B08A33BD3F06 8A861B1C7EFD60D9
The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed using by a different key.
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese,
Czech, French, German, Japanese, Russian, and Ukrainian being almost
completely translated (2062 different strings).
Documentation
=============
If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at
https://gnupg.org/faq/whats-new-in-2.1.html
The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well but they have not all the
details available as are the manual. It is also possible to read the
complete manual online in HTML format at
https://gnupg.org/documentation/manuals/gnupg/
or in Portable Document Format at
https://gnupg.org/documentation/manuals/gnupg.pdf .
The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing. You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems. Many of the new features are around for
several years and thus enough public knowledge is already available.
You may also want to follow postings at https://gnupg.org/blob/.
Support
========
Please consult the archive of the gnupg-users mailing list before
reporting a bug .
We suggest to send bug reports for a new release to this list in favor
of filing a bug at . For commercial support
requests we keep a list of known service companies at:
https://gnupg.org/service.html
If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gnupg-devel mailing
list for discussion.
Thanks
======
We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.
Since the start of the funding campaign in December several thousand
people have been kind enough to donate a total of 250000 Euro to support
this project. In addition the Linux Foundation gave a grant of $ 60000
for 2015, Stripe.com and Facebook.com each pledged $ 50000 per year.
I am amazed by this superb and unexpected support for the GnuPG project.
This allowed us to continue the project, employ a second full time
developer, and gives us the resources to improve things which have been
delayed for too long.
Thank you all!
Salam-Shalom,
Werner
p.s.
This is a announcement only mailing list. Please send replies only to
the gnupg-users at gnupg.org mailing lists.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
From kristian.fiskerstrand at sumptuouscapital.com Sun Apr 12 01:29:35 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 12 Apr 2015 01:29:35 +0200
Subject: [PATCH] dirmngr: Fix segfault in ldap engine
Message-ID: <5529AE5F.7010109@sumptuouscapital.com>
dirmngr: keyserver --help results in segfault, backtrace on [0]. Patch
attached:
(ks-engine-ldap.c) Fix segfault caused by missing check whether uri is
initialized
Additionally two issues with LDAP support:
(i) --refresh-keys is not implemented , so can't do gpg --keyserver
ldap://keys.domain --refresh-keys @domain
gpg: keyserver refresh failed: Not supported
(ii) No warning is printed if returned list is truncated. 2.0 gives a
gpgkeys: search results exceeded server limit. First 2 results shown.
2.1 just prints the two records returned with no warning.
References:
[0] http://download.sumptuouscapital.com/gnupg/gnupg-2.1.3-segfault.txt
--
----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Veni vidi visa
I came, I saw, I bought
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-2.1.3-dirmngr-Fix-segfault-in-ldap-engine.patch
Type: text/x-patch
Size: 962 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL:
From kristian.fiskerstrand at sumptuouscapital.com Sun Apr 12 01:40:30 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 12 Apr 2015 01:40:30 +0200
Subject: [PATCH] dirmngr: Fix segfault in ldap engine
In-Reply-To: <5529AE5F.7010109@sumptuouscapital.com>
References: <5529AE5F.7010109@sumptuouscapital.com>
Message-ID: <5529B0EE.1000801@sumptuouscapital.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04/12/2015 01:29 AM, Kristian Fiskerstrand wrote:
> (ii) No warning is printed if returned list is truncated. 2.0 gives
> a gpgkeys: search results exceeded server limit. First 2 results
> shown. 2.1 just prints the two records returned with no warning.
For clarification , this relates to --search operation
- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Qui audet vincit
Who dares wins
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVKbDpAAoJEP7VAChXwav6ookIAIwOe4XbxWRlI1iPwlTSL0Tm
u2GVRegGL3MAeNkdgX7cUpyZRMzgteNMrL5QkBDrjBgioeWsRMReG8TbG4vUjiFm
hBjTGqDOMfWPbaK0ZP7DSyjTx2Fec0LgOT4zNWhhyUm+P4riS4mYqcX9rm+mXXMJ
k9DsoqFNBqnWxZjoG5Qq6ntS1BaCtx4Lq+8lff4imVCCD8guPJeqC1S3ER5OQ55i
EF7gwGFTbEroD6Tk+mZzfTxWb6tY9gnplBCiLiGyjB9wRxm6wqN2mVC4EH3m/EBt
hV5w5OdbaEtjB+cQ881d9YSphRdPrH4AafLDHPsQTCEUjaPPucX0c5ka14dWOXU=
=ubWm
-----END PGP SIGNATURE-----
From kristian.fiskerstrand at sumptuouscapital.com Sun Apr 12 01:51:40 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 12 Apr 2015 01:51:40 +0200
Subject: [Announce] GnuPG 2.1.3 released
In-Reply-To: <87mw2ems3g.fsf@vigenere.g10code.de>
References: <87mw2ems3g.fsf@vigenere.g10code.de>
Message-ID: <5529B38C.5030504@sumptuouscapital.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04/11/2015 08:34 PM, Werner Koch wrote:
> Hello!
>
> The GnuPG Project is pleased to announce the availability of the
> another release of GnuPG modern: Version 2.1.3.
> Noteworthy changes in version 2.1.3
> ===================================
>
> * gpg: LDAP keyservers are now supported by 2.1.
...
> * dirmngr: Fixed SNI handling for hkps pools.
Thanks! Rudimentary testing shows I have no issues with hkps any
longer and ldap working for --search and --recv-key (with some
limitations as provided in my other email, but not blockers).
With these two fixes in place I'll start the process of moving GnuPG
2.1 branch into unstable in Gentoo (I just updated to 2.1.3 in
experimental) :)
- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nunc aut numquam
Now or never
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVKbOIAAoJEP7VAChXwav6KdUIALvqJ/EDFdVHaZ9/RqPFBlSf
Q3HaAuXpqOf8OlG6kRI5Fm+pvvoelI//rZLtNHCTZaMaiB4aKkf85Y0RfpBm1tCE
GYA+/PvQ3M189fUNVQn7DbbnUz3cdjZ7qIiOPdwVRZdB5dt3iV9fvMQ3pmOEDDmk
apFn6l3xA7OWZMFGOsRtugO+1mdgKRXtd2xxj1D0sPOl48X4D91YAJ7G7dGzzLlv
41D7Bt1v0tmZSTENL07fzLtvX1qLT+lvR5ANZ5UIpbq1mbMV5zY07Q8NE69HTONZ
trEU8ME44N73s8LwzHvA47c5PWFlG7X4Wa1S5Mo8M4+3FJ0WtGwD55Bebpp2NRU=
=pCo6
-----END PGP SIGNATURE-----
From patrick at enigmail.net Sun Apr 12 13:01:03 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 12 Apr 2015 13:01:03 +0200
Subject: [Announce] GnuPG 2.1.3 released
In-Reply-To: <87mw2ems3g.fsf__42151.7276358374$1428778401$gmane$org@vigenere.g10code.de>
References: <87mw2ems3g.fsf__42151.7276358374$1428778401$gmane$org@vigenere.g10code.de>
Message-ID: <552A506F.8080803@enigmail.net>
On 11.04.15 20:34, Werner Koch wrote:
> Hello!
>
> The GnuPG Project is pleased to announce the availability of the
> another release of GnuPG modern: Version 2.1.3.
Hi Werner
I get the following build error on Mac OS X (using LLVM 6.1.0 / clang
602.0.49):
gcc [...] -Wall -Wno-pointer-sign -Wpointer-arith -MT t-stringhelp.o -MD
-MP -MF .deps/t-stringhelp.Tpo -c -o t-stringhelp.o t-stringhelp.c
t-stringhelp.c:488:3: error: function definition is not allowed here
-Patrick
From kristian.fiskerstrand at sumptuouscapital.com Sun Apr 12 14:11:56 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 12 Apr 2015 14:11:56 +0200
Subject: GnuPG 2.1.3 fails to build without LDAP support
Message-ID: <552A610C.4050701@sumptuouscapital.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
GnuPG 2.1.3 has introduced a hard dependency on LDAP, resulting in
failure if openldap is not present despite being configured with
- --without-ldap. Full build log at [0], but the relevant snippet is
/lib\"" -O2 -pipe -Wall -Wno-pointer-sign
- -Wpointer-arith -c -o ldap-parse-uri.o ldap-parse-uri.c
ks-engine-ldap.c:43:19: fatal error: ldap.h: No such file or directory
# include
^
compilation terminated.
Makefile:755: recipe for target 'ks-engine-ldap.o' failed
make[3]: *** [ks-engine-ldap.o] Error 1
make[3]: *** Waiting for unfinished jobs....
ldap-parse-uri.c:27:19: fatal error: ldap.h: No such file or directory
# include
missing some USE_LDAP enclosures?
References:
[0] https://bugs.gentoo.org/show_bug.cgi?id=546348
- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"If the facts don't fit the theory, change the facts"
(Albert Einstein)
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVKmEJAAoJEP7VAChXwav6Br0H/3LdLBmsZY4xcYOoFQjduy5G
nbVUjwaDnF099MIdOitAvq9vRInYIZ7jIMoKtcCf2VdG/3i/P3wj2XBGbdXfRPYt
Gj0zAZrOVLVHpQXoL3Tbg38cfuI8ald/rVtR8Vu3QV0Akixhhc4kXf/ZRQB0lz4p
xvRuewaraJt5r4g0mJk71T2v67NM67YCynoSKgBllTgnhrV1qXIIuy0y0Xuk4jcF
WbByi2T+RiFTvDx1C/g5Ny71xQf+mOUrSSgtKw7JT6Imbrz4hPD1O1a4aaFRH75+
ZL8F0izrU+Ogy2fpgMVaKdUBMrgf02B8ELYM8+jziKO4X6C454eNEgo0oupz0QU=
=uSCe
-----END PGP SIGNATURE-----
From hanno at hboeck.de Sun Apr 12 14:22:09 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Sun, 12 Apr 2015 14:22:09 +0200
Subject: GnuPG 2.1.3 fails to build without LDAP support
In-Reply-To: <552A610C.4050701@sumptuouscapital.com>
References: <552A610C.4050701@sumptuouscapital.com>
Message-ID: <20150412142209.42feeebd@pc1.fritz.box>
On Sun, 12 Apr 2015 14:11:56 +0200
Kristian Fiskerstrand
wrote:
> GnuPG 2.1.3 has introduced a hard dependency on LDAP, resulting in
> failure if openldap is not present despite being configured with
> - --without-ldap. Full build log at [0], but the relevant snippet is
I had already found that and reported it to the bugtracker:
https://bugs.g10code.com/gnupg/issue1949
Unfortunately it came too late for 2.1.3. Will add the URL to the
gentoo bug.
--
Hanno B?ck
http://hboeck.de/
mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
From dkg at fifthhorseman.net Sun Apr 12 20:53:23 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 12 Apr 2015 14:53:23 -0400
Subject: [Announce] GnuPG 2.1.3 released
In-Reply-To: <87mw2ems3g.fsf@vigenere.g10code.de>
References: <87mw2ems3g.fsf@vigenere.g10code.de>
Message-ID: <874molxjoc.fsf@alice.fifthhorseman.net>
On Sat 2015-04-11 14:34:43 -0400, Werner Koch wrote:
> The GnuPG Project is pleased to announce the availability of the
> another release of GnuPG modern: Version 2.1.3.
Thanks for this, Werner!
It looks like the git repository is missing the gnupg-2.1.3 tag (it
appears to belong on commit b1e1959d59a12b53c016ca9c95aee3a62c0bfc00)
If you coud push the tag to the git repo, that would be helpful too.
Regards,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL:
From dkg at fifthhorseman.net Mon Apr 13 02:20:15 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 12 Apr 2015 20:20:15 -0400
Subject: [PATCH] curl-shim: clean up varargs
In-Reply-To: <87zj8872vo.fsf@alice.fifthhorseman.net>
References: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net>
<87lhjvlas4.fsf@vigenere.g10code.de> <87zj8872vo.fsf@alice.fifthhorseman.net>
Message-ID: <87egnox4jk.fsf@alice.fifthhorseman.net>
On Fri 2015-02-20 15:18:51 -0500, Daniel Kahn Gillmor wrote:
> On Wed 2015-02-18 06:27:39 -0500, Werner Koch wrote:
>> On Wed, 18 Feb 2015 10:11, dkg at fifthhorseman.net said:
>>> * keyserver/curl-shim.c (curl_easy_setopt) : ensure that va_end is
>>> called.
>>
>> That was right in time for the next 2.0 release. Thanks to Joshua
>> Rogers and you.
>
> thanks, that was quick :) I think it should be applied to master as well
> as STABLE-BRANCH-2-0.
it looks like this still needs to be applied to master, post 2.1.3.
--dkg
From dkg at fifthhorseman.net Mon Apr 13 02:57:32 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 12 Apr 2015 20:57:32 -0400
Subject: why does pinentry embed libassuan?
Message-ID: <878udwx2tf.fsf@alice.fifthhorseman.net>
i'm in reviewing the build process for pinentry (curses, gtk-2, qt4),
and i notice that they're all embedding libassuan.
for platforms like debian that have a system version of the assuan
dynamic library available, is there a reason for using this embedded
version?
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL:
From dkg at fifthhorseman.net Mon Apr 13 06:15:40 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 Apr 2015 00:15:40 -0400
Subject: more missing tags: libgpg-error-1.19
Message-ID: <87vbh0vf2r.fsf@alice.fifthhorseman.net>
Hi Werner--
it looks like the libgpg-error git repository is also missing a tag for
libgpg-error-1.19. (i think it belongs on
d77c33ae608d67086ea057cca5ddee99a7202f8b). If you could push that tag,
it would be useful for folks who are looking for verifications via git.
thanks,
--dkg
From wk at gnupg.org Mon Apr 13 09:26:03 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Apr 2015 09:26:03 +0200
Subject: [PATCH] curl-shim: clean up varargs
In-Reply-To: <87egnox4jk.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
message of "Sun, 12 Apr 2015 20:20:15 -0400")
References: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net>
<87lhjvlas4.fsf@vigenere.g10code.de>
<87zj8872vo.fsf@alice.fifthhorseman.net>
<87egnox4jk.fsf@alice.fifthhorseman.net>
Message-ID: <871tjolcac.fsf@vigenere.g10code.de>
On Mon, 13 Apr 2015 02:20, dkg at fifthhorseman.net said:
> it looks like this still needs to be applied to master, post 2.1.3.
We do not use curl in 2.1 .
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Mon Apr 13 09:25:19 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Apr 2015 09:25:19 +0200
Subject: [Announce] GnuPG 2.1.3 released
In-Reply-To: <874molxjoc.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
message of "Sun, 12 Apr 2015 14:53:23 -0400")
References: <87mw2ems3g.fsf@vigenere.g10code.de>
<874molxjoc.fsf@alice.fifthhorseman.net>
Message-ID: <876190lcbk.fsf@vigenere.g10code.de>
On Sun, 12 Apr 2015 20:53, dkg at fifthhorseman.net said:
> It looks like the git repository is missing the gnupg-2.1.3 tag (it
> appears to belong on commit b1e1959d59a12b53c016ca9c95aee3a62c0bfc00)
Sorry. Just pushed.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Mon Apr 13 09:33:26 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Apr 2015 09:33:26 +0200
Subject: why does pinentry embed libassuan?
In-Reply-To: <878udwx2tf.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
message of "Sun, 12 Apr 2015 20:57:32 -0400")
References: <878udwx2tf.fsf@alice.fifthhorseman.net>
Message-ID: <87wq1gjxdl.fsf@vigenere.g10code.de>
On Mon, 13 Apr 2015 02:57, dkg at fifthhorseman.net said:
> i'm in reviewing the build process for pinentry (curses, gtk-2, qt4),
> and i notice that they're all embedding libassuan.
That is an old stripped down version with only the server part. It is
plain stdin/stdout based and does not know anything about sockets.
With the exception of changing error code constants in 2010 it has not
been touched for more than 10 years. Am not sure whether this is good
or bad but at least it does not introduced error due to socket based
code.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From neal at walfield.org Mon Apr 13 10:41:22 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 13 Apr 2015 10:41:22 +0200
Subject: [PATCH] dirmngr: Fix segfault in ldap engine
In-Reply-To: <5529AE5F.7010109@sumptuouscapital.com>
References: <5529AE5F.7010109@sumptuouscapital.com>
Message-ID: <87k2xga099.wl-neal@walfield.org>
Hi Kristian,
Thanks for reporting these issues. I'll take a look at them soon.
Neal
At Sun, 12 Apr 2015 01:29:35 +0200,
Kristian Fiskerstrand wrote:
>
> dirmngr: keyserver --help results in segfault, backtrace on [0]. Patch
> attached:
>
> (ks-engine-ldap.c) Fix segfault caused by missing check whether uri is
> initialized
>
> Additionally two issues with LDAP support:
> (i) --refresh-keys is not implemented , so can't do gpg --keyserver
> ldap://keys.domain --refresh-keys @domain
> gpg: keyserver refresh failed: Not supported
>
> (ii) No warning is printed if returned list is truncated. 2.0 gives a
> gpgkeys: search results exceeded server limit. First 2 results shown.
> 2.1 just prints the two records returned with no warning.
>
> References:
> [0] http://download.sumptuouscapital.com/gnupg/gnupg-2.1.3-segfault.txt
> --
> ----------------------------
> Kristian Fiskerstrand
> Blog: http://blog.sumptuouscapital.com
> Twitter: @krifisk
> ----------------------------
> Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> ----------------------------
> Veni vidi visa
> I came, I saw, I bought
From neal at walfield.org Mon Apr 13 12:06:12 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 13 Apr 2015 12:06:12 +0200
Subject: GnuPG 2.1.3 fails to build without LDAP support
In-Reply-To: <20150412142209.42feeebd@pc1.fritz.box>
References: <552A610C.4050701@sumptuouscapital.com>
<20150412142209.42feeebd@pc1.fritz.box>
Message-ID: <87r3rouyuj.wl-neal@walfield.org>
At Sun, 12 Apr 2015 14:22:09 +0200,
Hanno B?ck wrote:
>
> On Sun, 12 Apr 2015 14:11:56 +0200
> Kristian Fiskerstrand
> wrote:
>
> > GnuPG 2.1.3 has introduced a hard dependency on LDAP, resulting in
> > failure if openldap is not present despite being configured with
> > - --without-ldap. Full build log at [0], but the relevant snippet is
>
> I had already found that and reported it to the bugtracker:
> https://bugs.g10code.com/gnupg/issue1949
I've checked in a fix and updated the bug report. Please let me know
if there are anymore problems.
Thanks,
Neal
From dkg at fifthhorseman.net Mon Apr 13 15:44:51 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 Apr 2015 09:44:51 -0400
Subject: [PATCH] curl-shim: clean up varargs
In-Reply-To: <871tjolcac.fsf@vigenere.g10code.de>
References: <1424250691-31497-1-git-send-email-dkg@fifthhorseman.net>
<87lhjvlas4.fsf@vigenere.g10code.de> <87zj8872vo.fsf@alice.fifthhorseman.net>
<87egnox4jk.fsf@alice.fifthhorseman.net> <871tjolcac.fsf@vigenere.g10code.de>
Message-ID: <87h9skuoq4.fsf@alice.fifthhorseman.net>
Thanks for the quick response, Werner.
On Mon 2015-04-13 03:26:03 -0400, Werner Koch wrote:
> On Mon, 13 Apr 2015 02:20, dkg at fifthhorseman.net said:
>
>> it looks like this still needs to be applied to master, post 2.1.3.
>
> We do not use curl in 2.1 .
maybe keyserver/curl-shim.c should be removed from the master branch
then? We have revision control to get it back should we ever need it,
so keeping unused/dead code in the master branch seems unnecessary.
--dkg
From kristian.fiskerstrand at sumptuouscapital.com Mon Apr 13 18:56:26 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Mon, 13 Apr 2015 18:56:26 +0200
Subject: GnuPG 2.1.3 fails to build without LDAP support
In-Reply-To: <87r3rouyuj.wl-neal@walfield.org>
References: <552A610C.4050701@sumptuouscapital.com>
<20150412142209.42feeebd@pc1.fritz.box> <87r3rouyuj.wl-neal@walfield.org>
Message-ID: <552BF53A.6010303@sumptuouscapital.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04/13/2015 12:06 PM, Neal H. Walfield wrote:
> At Sun, 12 Apr 2015 14:22:09 +0200, Hanno B?ck wrote:
>>
>> On Sun, 12 Apr 2015 14:11:56 +0200 Kristian Fiskerstrand
>> wrote:
>>
>>> GnuPG 2.1.3 has introduced a hard dependency on LDAP, resulting
>>> in failure if openldap is not present despite being configured
>>> with - --without-ldap. Full build log at [0], but the relevant
>>> snippet is
>>
>> I had already found that and reported it to the bugtracker:
>> https://bugs.g10code.com/gnupg/issue1949
>
> I've checked in a fix and updated the bug report. Please let me
> know if there are anymore problems.
>
Thanks, this commit seems to have solved the issue.
- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nomina stultorum scribuntur ubique locorum
Fools have the habit of writing their names everywhere
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVK/U2AAoJEP7VAChXwav6opQIAI0UGBIlYXQjeefrytjRhkon
ZUdEY7N4dkOQ3dNaF3sHHf+GmRnm1Ipj/CuJQBWxyprN3Y6LOKkzbQX64PqK9Am9
O17zqfD8UDzQ8gfuw+kNxJ85mESYL1wTEC0vsW5D/zujLuKl5aqOZlUH+JSYF8ch
gINUDbhjG4PfWpl5tdPEcC6I3v3X8noC/ClJsHawmJvRRMTD5Qa8opj7exOxAZr6
1iWKlL3l0pAQ3kTzL//ohFvgZTOeo0rYxsPOj1FsigJRUNlARybFpSZ6qez8Vtsk
tGFPRjNDmzEc/W8CCOT+wy7hjl1GAePHkPfCimLMBGP+UAEQtr3zGm143xV57ks=
=eEPx
-----END PGP SIGNATURE-----
From gniibe at fsij.org Tue Apr 14 04:31:37 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 14 Apr 2015 11:31:37 +0900
Subject: [PATCH] scd: better handling of extended APDU
Message-ID: <552C7C09.9030000@fsij.org>
Hello,
This is a patch for GnuPG's internal ccid-driver support for better
handling of extended APDU. This is basically the response to
https://bugs.g10code.com/gnupg/issue1947
This patch is tested by the reporter, and confirmed it works well.
I'm going to commit/push this to master.
Please test it if you have readers which supports extended APDU.
Well, extended APDU is a kind of difficult specification in smartcard
and its readers (to be implemented). If possible, I wouldn't like to
implement this feature, but there is an OpenPGPcard implementation
which doesn't provide command-chaining, this is inevitable.
Just reading the specification lightly, it looks like extended APDU is
modern way and good for smartcard. But, observing some reader
implementations with problems, I couldn't say it's good thing.
Following implementation is not general purpose, but intended only
for OpenPGPcard implementations because CCID_MAX_BUF is about 2KB.
To be general purpose, it would be like 64KB, and/or we need to offer
specific API, so that application can specify buffer size for readers.
Currently, in scd/app-openpgp.c, it just has
app->app_local->cardcap.ext_lc_le (if we can use extended APDU), but
the capability of reader matter.
Basically, it means that the application for smartcard and its reader
cannot be layered like:
application
reader
smartcard
I understand that the extended APDU was intended to make things
easier, but it just introduced more problems, in practice.
In this development, I tested VASCO DIGIPASS 920 with OpenPGPcard 2.0
with RSA-2048 keys. VASCO DIGIPASS 920 has extended APDU support, but
dwMaxCCIDMsgLen=271. It supports sending (from host PC to reader)
large APDU chained by smaller CCID message, so, decryption works well.
But I realized that it doesn't work well to receive large APDU from
smartcard (and to send it to host PC by chained smaller CCID message).
So, there is no way with this card reader to get correct output of gpg
--card-status (specifically, reading public key from smartcard fails).
diff --git a/scd/apdu.c b/scd/apdu.c
index 53cc4b9..f6cca8c 100644
--- a/scd/apdu.c
+++ b/scd/apdu.c
@@ -3806,9 +3806,9 @@ send_le (int slot, int class, int ins, int p0, int p1,
apdu[apdulen++] = ins;
apdu[apdulen++] = p0;
apdu[apdulen++] = p1;
- apdu[apdulen++] = 0; /* Z byte: Extended length marker. */
- if (lc >= 0)
+ if (lc > 0)
{
+ apdu[apdulen++] = 0; /* Z byte: Extended length marker. */
apdu[apdulen++] = ((lc >> 8) & 0xff);
apdu[apdulen++] = (lc & 0xff);
memcpy (apdu+apdulen, data, lc);
@@ -3817,6 +3817,8 @@ send_le (int slot, int class, int ins, int p0, int p1,
}
if (le != -1)
{
+ if (lc <= 0)
+ apdu[apdulen++] = 0; /* Z byte: Extended length marker. */
apdu[apdulen++] = ((le >> 8) & 0xff);
apdu[apdulen++] = (le & 0xff);
}
diff --git a/scd/app-common.h b/scd/app-common.h
index 50046a4..379bcd1 100644
--- a/scd/app-common.h
+++ b/scd/app-common.h
@@ -67,10 +67,10 @@ struct app_ctx_s {
size_t serialnolen; /* Length in octets of serialnumber. */
const char *apptype;
unsigned int card_version;
- int did_chv1;
- int force_chv1; /* True if the card does not cache CHV1. */
- int did_chv2;
- int did_chv3;
+ unsigned int did_chv1:1;
+ unsigned int force_chv1:1; /* True if the card does not cache CHV1. */
+ unsigned int did_chv2:1;
+ unsigned int did_chv3:1;
struct app_local_s *app_local; /* Local to the application. */
struct {
void (*deinit) (app_t app);
diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c
index 1926f71..151b371 100644
--- a/scd/ccid-driver.c
+++ b/scd/ccid-driver.c
@@ -96,6 +96,16 @@
#define DRVNAME "ccid-driver: "
+/* Max length of buffer with out CCID message header of 10-byte
+ Sending: 547 for RSA-4096 key import
+ APDU size = 540 (24+4+256+256)
+ commnd + lc + le = 4 + 3 + 0
+ Sending: write data object of cardholder certificate
+ APDU size = 2048
+ commnd + lc + le = 4 + 3 + 0
+ Receiving: 2048 for cardholder certificate
+*/
+#define CCID_MAX_BUF (2048+7+10)
/* Depending on how this source is used we either define our error
output to go to stderr or to the jnlib based logging functions. We
@@ -242,7 +252,7 @@ struct ccid_driver_s
unsigned char t1_nr;
unsigned char nonnull_nad;
int max_ifsd;
- int ifsd;
+ int max_ccid_msglen;
int ifsc;
unsigned char apdu_level:2; /* Reader supports short APDU level
exchange. With a value of 2 short
@@ -711,7 +721,7 @@ prepare_special_transport (ccid_driver_t handle)
handle->nonnull_nad = 0;
handle->auto_ifsd = 0;
handle->max_ifsd = 32;
- handle->ifsd = 0;
+ handle->max_ccid_msglen = CCID_MAX_BUF;
handle->has_pinpad = 0;
handle->apdu_level = 0;
switch (handle->id_product)
@@ -743,7 +753,6 @@ parse_ccid_descriptor (ccid_driver_t handle,
handle->nonnull_nad = 0;
handle->auto_ifsd = 0;
handle->max_ifsd = 32;
- handle->ifsd = 0;
handle->has_pinpad = 0;
handle->apdu_level = 0;
handle->auto_voltage = 0;
@@ -884,6 +893,7 @@ parse_ccid_descriptor (ccid_driver_t handle,
us = convert_le_u32(buf+44);
DEBUGOUT_1 (" dwMaxCCIDMsgLen %5u\n", us);
+ handle->max_ccid_msglen = us;
DEBUGOUT ( " bClassGetResponse ");
if (buf[48] == 0xff)
@@ -2794,109 +2804,101 @@ is_exlen_apdu (const unsigned char *apdu, size_t apdulen)
/* Helper for ccid_transceive used for APDU level exchanges. */
static int
ccid_transceive_apdu_level (ccid_driver_t handle,
- const unsigned char *apdu_buf, size_t apdu_buflen,
+ const unsigned char *apdu_buf, size_t apdu_len,
unsigned char *resp, size_t maxresplen,
size_t *nresp)
{
int rc;
- unsigned char send_buffer[10+261+300], recv_buffer[10+261+300];
- const unsigned char *apdu;
- size_t apdulen;
- unsigned char *msg;
+ unsigned char msg[CCID_MAX_BUF];
+ const unsigned char *apdu_p;
+ size_t apdu_part_len;
size_t msglen;
unsigned char seqno;
int bwi = 4;
+ unsigned char chain = 0;
- msg = send_buffer;
+ if (apdu_len == 0 || apdu_len > sizeof (msg) - 10)
+ return CCID_DRIVER_ERR_INV_VALUE; /* Invalid length. */
- apdu = apdu_buf;
- apdulen = apdu_buflen;
- assert (apdulen);
+ apdu_p = apdu_buf;
+ while (1)
+ {
+ apdu_part_len = apdu_len;
+ if (apdu_part_len > handle->max_ccid_msglen - 10)
+ {
+ apdu_part_len = handle->max_ccid_msglen - 10;
+ chain |= 0x01;
+ }
- /* The maximum length for a short APDU T=1 block is 261. For an
- extended APDU T=1 block the maximum length 65544; however
- extended APDU exchange level is not fully supported yet. */
- if (apdulen > sizeof (send_buffer) - 10)
- return CCID_DRIVER_ERR_INV_VALUE; /* Invalid length. */
+ msg[0] = PC_to_RDR_XfrBlock;
+ msg[5] = 0; /* slot */
+ msg[6] = seqno = handle->seqno++;
+ msg[7] = bwi;
+ msg[8] = chain;
+ msg[9] = 0;
+ memcpy (msg+10, apdu_p, apdu_part_len);
+ set_msg_len (msg, apdu_part_len);
+ msglen = 10 + apdu_part_len;
- msg[0] = PC_to_RDR_XfrBlock;
- msg[5] = 0; /* slot */
- msg[6] = seqno = handle->seqno++;
- msg[7] = bwi; /* bBWI */
- msg[8] = 0; /* RFU */
- msg[9] = 0; /* RFU */
- memcpy (msg+10, apdu, apdulen);
- set_msg_len (msg, apdulen);
- msglen = 10 + apdulen;
+ rc = bulk_out (handle, msg, msglen, 0);
+ if (rc)
+ return rc;
- rc = bulk_out (handle, msg, msglen, 0);
- if (rc)
- return rc;
+ apdu_p += apdu_part_len;
+ apdu_len -= apdu_part_len;
- msg = recv_buffer;
- rc = bulk_in (handle, msg, sizeof recv_buffer, &msglen,
- RDR_to_PC_DataBlock, seqno, 5000, 0);
- if (rc)
- return rc;
+ rc = bulk_in (handle, msg, sizeof msg, &msglen,
+ RDR_to_PC_DataBlock, seqno, 5000, 0);
+ if (rc)
+ return rc;
+
+ if (!(chain & 0x01))
+ break;
- if (msg[9] == 1)
+ chain = 0x02;
+ }
+
+ apdu_len = 0;
+ while (1)
{
- size_t total_msglen = msglen;
+ apdu_part_len = msglen - 10;
+ if (resp && apdu_len + apdu_part_len <= maxresplen)
+ memcpy (resp + apdu_len, msg+10, apdu_part_len);
+ apdu_len += apdu_part_len;
- while (1)
- {
- unsigned char status;
+ if (!(msg[9] & 0x01))
+ break;
- msg = recv_buffer + total_msglen;
+ msg[0] = PC_to_RDR_XfrBlock;
+ msg[5] = 0; /* slot */
+ msg[6] = seqno = handle->seqno++;
+ msg[7] = bwi;
+ msg[8] = 0x10; /* Request next data block */
+ msg[9] = 0;
+ set_msg_len (msg, 0);
+ msglen = 10;
- msg[0] = PC_to_RDR_XfrBlock;
- msg[5] = 0; /* slot */
- msg[6] = seqno = handle->seqno++;
- msg[7] = bwi; /* bBWI */
- msg[8] = 0x10; /* Request next data block */
- msg[9] = 0;
- set_msg_len (msg, 0);
- msglen = 10;
-
- rc = bulk_out (handle, msg, msglen, 0);
- if (rc)
- return rc;
-
- rc = bulk_in (handle, msg, sizeof recv_buffer - total_msglen, &msglen,
- RDR_to_PC_DataBlock, seqno, 5000, 0);
- if (rc)
- return rc;
- status = msg[9];
- memmove (msg, msg+10, msglen - 10);
- total_msglen += msglen - 10;
- if (total_msglen >= sizeof recv_buffer)
- return CCID_DRIVER_ERR_OUT_OF_CORE;
-
- if (status == 0x02)
- break;
- }
+ rc = bulk_out (handle, msg, msglen, 0);
+ if (rc)
+ return rc;
- apdu = recv_buffer + 10;
- apdulen = total_msglen - 10;
- }
- else
- {
- apdu = msg + 10;
- apdulen = msglen - 10;
+ rc = bulk_in (handle, msg, sizeof msg, &msglen,
+ RDR_to_PC_DataBlock, seqno, 5000, 0);
+ if (rc)
+ return rc;
}
if (resp)
{
- if (apdulen > maxresplen)
+ if (apdu_len > maxresplen)
{
DEBUGOUT_2 ("provided buffer too short for received data "
"(%u/%u)\n",
- (unsigned int)apdulen, (unsigned int)maxresplen);
+ (unsigned int)apdu_len, (unsigned int)maxresplen);
return CCID_DRIVER_ERR_INV_VALUE;
}
- memcpy (resp, apdu, apdulen);
- *nresp = apdulen;
+ *nresp = apdu_len;
}
return 0;
--
From dkg at fifthhorseman.net Tue Apr 14 04:50:17 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 Apr 2015 22:50:17 -0400
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
Message-ID: <87twwjs9sm.fsf@alice.fifthhorseman.net>
On Tue 2014-12-16 19:13:19 -0500, Daniel Kahn Gillmor wrote:
> i'm trying to test "gpg --refresh" with large keyrings in gnupg 2.1.1.
> It's better than it was before, but i'm still getting some errors with a
> larger keyring.
>
> In particular, i'm seeing an abort when i try to refresh the a large
> keyring against an hkps keyserver; only the first 83 keys get refreshed,
> and then gpg aborts with:
>
> gpg: keyserver refresh failed: Input/output error
I'm still seeing this problem with gpg --refresh for large keyrings in
2.1.3 (though the cutoff is different -- it's about 88 now instead of
83). I've opened https://bugs.g10code.com/gnupg/issue1950 to track the
issue.
--dkg
From gniibe at fsij.org Tue Apr 14 09:42:31 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 14 Apr 2015 16:42:31 +0900
Subject: Updated Japanese Translation for libgpg-error
Message-ID: <552CC4E7.8070907@fsij.org>
Hello,
I committed and pushed the update of Japanese Translation of
libgpg-error.
--
From wk at gnupg.org Tue Apr 14 10:09:36 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 14 Apr 2015 10:09:36 +0200
Subject: [PATCH] scd: better handling of extended APDU
In-Reply-To: <552C7C09.9030000@fsij.org> (NIIBE Yutaka's message of "Tue, 14
Apr 2015 11:31:37 +0900")
References: <552C7C09.9030000@fsij.org>
Message-ID: <871tjngmgv.fsf@vigenere.g10code.de>
On Tue, 14 Apr 2015 04:31, gniibe at fsij.org said:
> Just reading the specification lightly, it looks like extended APDU is
> modern way and good for smartcard. But, observing some reader
> implementations with problems, I couldn't say it's good thing.
That is also my experience. Thus I consider TPDU mode much more
flexible because it is easier to fix bugs in our software than in the
firmware. (Some readers seem to have an non-documented way to switch to
TPDU mode which their vendors use to implement extended APDU mode in
their Windows drivers.)
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Tue Apr 14 10:11:14 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 14 Apr 2015 10:11:14 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <87twwjs9sm.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
message of "Mon, 13 Apr 2015 22:50:17 -0400")
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
Message-ID: <87wq1ff7tp.fsf@vigenere.g10code.de>
On Tue, 14 Apr 2015 04:50, dkg at fifthhorseman.net said:
> I'm still seeing this problem with gpg --refresh for large keyrings in
> 2.1.3 (though the cutoff is different -- it's about 88 now instead of
Seems to be a different problem. Without TLS I was able to refresh
hundreds of keys.
> 83). I've opened https://bugs.g10code.com/gnupg/issue1950 to track the
Need to look at it. Do you have the same problem when using the hkps
pool?
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From bjk at luxsci.net Wed Apr 15 01:03:05 2015
From: bjk at luxsci.net (Ben Kibbey)
Date: Tue, 14 Apr 2015 19:03:05 -0400
Subject: libgpgme and gpg genkey passphrase inquire
Message-ID: <1429052641-2728836.99318832.ft3EN36Bb008082@rs146.luxsci.com>
Hello,
I'd like the ability to use a key-file as a passphrase when generating a
new keypair. Attached are patches for both gpg and libgpgme. I'm not
sure if the gpg patch will break anything since it implies --batch when
--command-fd is set along with --gen-key. The gpgme patch just sets the
passphrase command handler like the other gpgme crypto functions do.
--
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-gen-key-to-inquire-a-passphrase.patch
Type: text/x-diff
Size: 1238 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-use-of-user-passphrase-handler-during-genkey.patch
Type: text/x-diff
Size: 1047 bytes
Desc: not available
URL:
From gniibe at fsij.org Wed Apr 15 07:03:30 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 15 Apr 2015 14:03:30 +0900
Subject: Backport candidates to 2.0 branch
Message-ID: <552DF122.2050102@fsij.org>
Hello,
I updated po/ja.po in STABLE-BRANCH-2-0. Then, I examined the changes
in master after 2.1.2 to today.
Following five commits can be just cherry-picked to STABLE-BRANCH-2-0.
scd: Fix possible NULL deref in apdu.c
author Werner Koch
Sun, 15 Mar 2015 11:15:55 +0000 (12:15 +0100)
commit ef0a3abf7305133d071bf1a94a7f461082f9a9aa
agent: Fix length test in sshcontrol parser.
author Werner Koch
Sun, 15 Mar 2015 12:04:48 +0000 (13:04 +0100)
commit 3529dd8bb5bafc4e02915648d5f409bd27a9cc37
gpgparsemail: Fix case of zero length continuation lines.
author Werner Koch
Thu, 9 Apr 2015 17:06:33 +0000 (19:06 +0200)
commit 3fbeba64a8bfb2b673230c124a3d616b6568fd2f
gpgparsemail: Fix last commit (3f2bdac)
author Werner Koch
Fri, 10 Apr 2015 06:34:35 +0000 (08:34 +0200)
commit 9433661419043431a6cfc7d84c8450e0b2f6c353
scd: better handling of extended APDU. master
author NIIBE Yutaka
Tue, 14 Apr 2015 05:17:03 +0000 (14:17 +0900)
commit 971d558e862db878a7310e06ed7116dbe36886ab
--
From ben at adversary.org Wed Apr 15 20:44:55 2015
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 16 Apr 2015 04:44:55 +1000
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <87twwjs9sm.fsf@alice.fifthhorseman.net>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
Message-ID: <552EB1A7.3010105@adversary.org>
On 14/04/2015 12:50 pm, Daniel Kahn Gillmor wrote:
> On Tue 2014-12-16 19:13:19 -0500, Daniel Kahn Gillmor wrote:
>> i'm trying to test "gpg --refresh" with large keyrings in gnupg 2.1.1.
>> It's better than it was before, but i'm still getting some errors with a
>> larger keyring.
>>
>> In particular, i'm seeing an abort when i try to refresh the a large
>> keyring against an hkps keyserver; only the first 83 keys get refreshed,
>> and then gpg aborts with:
>>
>> gpg: keyserver refresh failed: Input/output error
>
> I'm still seeing this problem with gpg --refresh for large keyrings in
> 2.1.3 (though the cutoff is different -- it's about 88 now instead of
> 83). I've opened https://bugs.g10code.com/gnupg/issue1950 to track the
> issue.
I have a work-around for something else relating to dirmngr which may
also serve as work-around for this. Now since I've got around 9,400
keys in my public keyring, if I can do a full refresh (regardless of
keyserver or server connection protocol), then that ought to do the
job. Now granted, I'm not trying to force TLS connections to the
keyservers, but the reason for that is that my workaround is to pipe
all keyserver traffic through proxychains and Tor.
I figure that since the keys are what they are, they can protect
themselves. So the real benefit is in foiling traffic analysis and
since all Tor connections use TLS within the Tor network anyway, no
one's going to really be able to see which keys I'm requesting or
updating.
Now here's the thing, via the proxychains tunnel there is no trouble
with a TLS connection (proxychains feeds into a default privoxy
instance and then into the Tor SOCKS5 service, all of which is strung
together with a handful of bash scripts to load the relevant homedir
and optionally restart dimngr through proxychains). It happily
munches its way through approx. 9,300 of those keys. The remaining
hundred or so have hard-coded keyserver preferences pointing to https,
hkps or ldap services and those keel over with the same errors that
have been reported already or a report that the keyserver cannot be
reached.
Note also that using proxychains is only necessary because while
dirmngr recognises a specified keyserver, it doesn't recognise proxy
settings. Whether this is related or not, I haven't yet one hundred
percent confirmed (because I haven't gotten around to setting up a
MitM on my own traffic).
Now, without taking each packet apart, there is one major difference
between the Tor TLS connections and GPG's TLS connections. That, of
course, is that most notorious of SSL/TLS libraries: GnuTLS. My
suspicion is that this is the source of the failure to reach hkps and
https keyservers, regardless of variations in the error messages GPG
responds with.
Now I get that there's that annoying license conflict which pretty
much locks GPG into GnuTLS, in spite of it's ... ah, track record.
However, there's a nice and easy solution to that whole situation: add
support for SOCKS5 proxies and restore support for HTTP/S proxies
natively to allow a local proxy configuration to utilise the user's
choice of GnuTLS, OpenSSL, LibreSSL or whatever else (e.g. my Tor
service is compiled with OpenSSL 1.0.2 and ec_nistp_64_gcc_128
enabled). Then worry about isolating what GnuTLS broke this time.
Yes, this is a guestimate ... but given past performance, the chances
that GnuTLS broke something (again), it's a reasonably well founded
one. Hence my suggestion to remove GnuTLS from the equation.
Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL:
From dkg at fifthhorseman.net Wed Apr 15 23:17:41 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Apr 2015 17:17:41 -0400
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <552EB1A7.3010105@adversary.org>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net> <552EB1A7.3010105@adversary.org>
Message-ID: <87mw29ozuy.fsf@alice.fifthhorseman.net>
On Wed 2015-04-15 14:44:55 -0400, Ben McGinnes wrote:
> I have a work-around for something else relating to dirmngr which may
> also serve as work-around for this. Now since I've got around 9,400
> keys in my public keyring, if I can do a full refresh (regardless of
> keyserver or server connection protocol), then that ought to do the
> job. Now granted, I'm not trying to force TLS connections to the
> keyservers, but the reason for that is that my workaround is to pipe
> all keyserver traffic through proxychains and Tor.
>
> I figure that since the keys are what they are, they can protect
> themselves. So the real benefit is in foiling traffic analysis and
> since all Tor connections use TLS within the Tor network anyway, no
> one's going to really be able to see which keys I'm requesting or
> updating.
Does this protect the privacy of your keyring effectively against people
snooping between tor and the keyserver, though?
Your keyring is likely to be unique to you.
Tor circuits to a particular endpoint are likely to be stable over the
period of time it would take to fetch the whole keyring.
As a result, someone monitoring traffic as it flows between the tor exit
nodes and the keyservers can see your keyring today, and can probably
notice when you add new keys to your keyring.
> Now here's the thing, via the proxychains tunnel there is no trouble
> with a TLS connection (proxychains feeds into a default privoxy
> instance and then into the Tor SOCKS5 service, all of which is strung
> together with a handful of bash scripts to load the relevant homedir
> and optionally restart dimngr through proxychains). It happily
> munches its way through approx. 9,300 of those keys. The remaining
> hundred or so have hard-coded keyserver preferences pointing to https,
> hkps or ldap services and those keel over with the same errors that
> have been reported already or a report that the keyserver cannot be
> reached.
You can specify keyserver-options no-honor-keyserver-url if you want to
avoid this last bit. Are you saying that this doesn't work with dirmngr
for you?
> Note also that using proxychains is only necessary because while
> dirmngr recognises a specified keyserver, it doesn't recognise proxy
> settings.
This is distressing. the dirmngr info pages clearly documents these
options:
'--honor-http-proxy'
If the environment variable 'http_proxy' has been set, use its
value to access HTTP servers.
'--http-proxy HOST[:PORT]'
Use HOST and PORT to access HTTP servers. The use of this options
overrides the environment variable 'http_proxy' regardless whether
'--honor-http-proxy' has been set.
I just tested it and i think they're still broken for 2.1.3.
I see that https://bugs.g10code.com/gnupg/issue1786 has been opened
about this, i've just commented there. Let's take this part of the
discussion there.
> Now, without taking each packet apart, there is one major difference
> between the Tor TLS connections and GPG's TLS connections. That, of
> course, is that most notorious of SSL/TLS libraries: GnuTLS. My
> suspicion is that this is the source of the failure to reach hkps and
> https keyservers, regardless of variations in the error messages GPG
> responds with.
Hm, there was no "failure to reach hkps and https keyservers" -- just
that the refresh process terminates after some number of keys are
fetched, instead of continuing through the entire list. I don't think
the rest of your proposal addresses the concerns i've raised in this
thread -- if the proxy situation is working, that doesn't remove the
need for hkps.
--dkg
PS I think calling GnuTLS "most notorious" is bizarre.
From dkg at fifthhorseman.net Wed Apr 15 23:38:52 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Apr 2015 17:38:52 -0400
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <87wq1ff7tp.fsf@vigenere.g10code.de>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net> <87wq1ff7tp.fsf@vigenere.g10code.de>
Message-ID: <87iocxoyvn.fsf@alice.fifthhorseman.net>
On Tue 2015-04-14 04:11:14 -0400, Werner Koch wrote:
> On Tue, 14 Apr 2015 04:50, dkg at fifthhorseman.net said:
>
>> I'm still seeing this problem with gpg --refresh for large keyrings in
>> 2.1.3 (though the cutoff is different -- it's about 88 now instead of
>
> Seems to be a different problem. Without TLS I was able to refresh
> hundreds of keys.
agreed, i can do so as well.
>> 83). I've opened https://bugs.g10code.com/gnupg/issue1950 to track the
>
> Need to look at it. Do you have the same problem when using the hkps
> pool?
Hm, when i use hkps://hkps.pool.sks-keyservers.net i can fetch 165 keys
without an error.
I'm not sure how to tell from the dirmngr log which server it was
actually connecting to at that point though.
--dkg
From ben at adversary.org Thu Apr 16 00:49:50 2015
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 16 Apr 2015 08:49:50 +1000
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <87mw29ozuy.fsf@alice.fifthhorseman.net>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net> <552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
Message-ID: <552EEB0E.4050709@adversary.org>
On 16/04/2015 7:17 am, Daniel Kahn Gillmor wrote:
> On Wed 2015-04-15 14:44:55 -0400, Ben McGinnes wrote:
>> I have a work-around for something else relating to dirmngr which may
>> also serve as work-around for this. Now since I've got around 9,400
>> keys in my public keyring, if I can do a full refresh (regardless of
>> keyserver or server connection protocol), then that ought to do the
>> job. Now granted, I'm not trying to force TLS connections to the
>> keyservers, but the reason for that is that my workaround is to pipe
>> all keyserver traffic through proxychains and Tor.
>>
>> I figure that since the keys are what they are, they can protect
>> themselves. So the real benefit is in foiling traffic analysis and
>> since all Tor connections use TLS within the Tor network anyway, no
>> one's going to really be able to see which keys I'm requesting or
>> updating.
>
> Does this protect the privacy of your keyring effectively against people
> snooping between tor and the keyserver, though?
In a sense, there's no clear link to me even if it is open to view.
> Your keyring is likely to be unique to you.
To an extent yeah, but the majority of those keys are the Bitcoin-OTC
user list, the entirety of ncsc.mil and a bunch of really strange
types posting to lists like gnupg-users, gnupg-devel and
enigmail-users. They really are the strange ones. ;)
> Tor circuits to a particular endpoint are likely to be stable over the
> period of time it would take to fetch the whole keyring.
In a country with a decent Internet connection, sure. Over here in
Australia, however, you can be pretty sure that you'll hit the ten
minute window more than once.
> As a result, someone monitoring traffic as it flows between the tor exit
> nodes and the keyservers can see your keyring today, and can probably
> notice when you add new keys to your keyring.
Which is one more reason to add pretty much every key I encounter and
never delete them. Working out which ones are seriously used is quite
another thing.
Anyway, the next step to mitigate all of that is a rather more obvious
course: install my own SKS keyserver or two (one here on the LAN and
one out in some nebulous hosting space).
>> Now here's the thing, via the proxychains tunnel there is no
>> trouble with a TLS connection (proxychains feeds into a default
>> privoxy instance and then into the Tor SOCKS5 service, all of which
>> is strung together with a handful of bash scripts to load the
>> relevant homedir and optionally restart dimngr through
>> proxychains). It happily munches its way through approx. 9,300 of
>> those keys. The remaining hundred or so have hard-coded keyserver
>> preferences pointing to https, hkps or ldap services and those keel
>> over with the same errors that have been reported already or a
>> report that the keyserver cannot be reached.
>
> You can specify keyserver-options no-honor-keyserver-url if you want
> to avoid this last bit.
Ah, I'd forgotten that one. I'll run it with that shortly and also
put a timer on it (see if I'm right on the sad, sad state of ADSL
here).
> Are you saying that this doesn't work with dirmngr for you?
It will make direct connections, but it won't recognise the
--keyserver-options http-proxy settings. Nor will it honour shell or
curl http_proxy values (my testing of that monitored the Tor proxy
interfaces with tcpdump). Which led to digging proxychains out of the
archives.
>> Note also that using proxychains is only necessary because while
>> dirmngr recognises a specified keyserver, it doesn't recognise
>> proxy settings.
>
> This is distressing. the dirmngr
Yeah, but there are a bunch of not yet implemented dirmngr functions
(like dirmngr --shutdown).
> I see that https://bugs.g10code.com/gnupg/issue1786
> has been opened about this, i've just commented there.
> Let's take this part of the discussion there.
Lay on MacDuff ... I guess creating that login for wiki access will be
used properly after all.
> Now, without taking
>> each packet apart, there is one major difference between the Tor
>> TLS connections and GPG's TLS connections. That, of course, is
>> that most notorious of SSL/TLS libraries: GnuTLS. My suspicion is
>> that this is the source of the failure to reach hkps and https
>> keyservers, regardless of variations in the error messages GPG
>> responds with. >
> Hm, there was no "failure to reach hkps and
> https keyservers" -- just that the refresh process terminates
>> after some number of keys are > fetched, instead of continuing
>> through the entire list.
Ah, different errors then. Mine attempts to work it's way through the
entire list but complains about not finding (not reaching) the small
percentage of keys that set keyserver settings.
It does, however, also produce these errors when when explicitly
pursuing https or hkps servers and no proxy set:
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error
With the proxy reactivated, the gpg.conf setting pointing to the
ipv4.pool (in order to bypass the ipv6 conflict previously reported)
overrides command line options to access the hkps.pool. Changing that
to https or hkps produces the general errors above.
> I don't think > the rest of your proposal
>> addresses the concerns i've raised in this > thread -- if the proxy
>> situation is working, that doesn't remove the need for hkps.
No arguments there, though I still am inclined to lean towards the
fault being with the means by which GPG attempts to communicate across
TLS, especially when it clearly has no trouble when going through the
proxychains/Tor/openssl tunnel, nor is there any trouble with the
1.4.19 code (I made a copy of my homedir, so one is live with 1.4 and
the other with 2.1), which relies on libcurl instead.
Anyway, it should be easy enough to prove, just break down every
single step that dirmngr performs and run it manually. Either that or
try replacing GnuTLS with OpenSSL (obviously releasing that is out of
the question) and seeing if it works. Obviously if it does, GnuTLS is
back in the naughty corner. Anyway, that's why I'm more in favour of
abstracting that transport component out of GPG so a the best
transport method for that network can be specified by a user (well, an
advanced user or sysadmin). Since HKP/S is just a cut down HTTP/S
then as long as dirmngr can speak HTTP 1.1 it should be able to cope
just fine.
>> PS I think calling GnuTLS "most notorious" is bizarre.
Really? OpenSSL is by no stretch of the imagination perfect either,
but at least it's not trying to pass itself off as part of the GNU
Project when it's developer turned his back on said project several
years ago. It's only the default lib for GNU & FSF because said
developer didn't drop the GPL. I'll skip the itemised vulnerabilities
its presented because I don't want to have to encrypt this in order to
compress it down to a size SMTP will deal with ... and that's only a
slight exaggeration.
Yeah, OpenSSL went for a bigger impact with Heartbleed and what not,
but that's because of the market share it has and why? Because the
only "alternative" was GnuTLS ... which has been on a semi-permanent
blacklist as a result of the stupid vulnerabilities. Round and round
we go ... ;)
That said, I'd love to be proven wrong and to see that GnuTLS is a
genuinely viable alternative to OpenSSL. I just doubt it's reached
that point yet. To put it another way, I certainly wouldn't bet any
of my own money on the prospect of GnuTLS not being the culprit or
adversely affecting the results here.
Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL:
From wk at gnupg.org Thu Apr 16 11:38:47 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 16 Apr 2015 11:38:47 +0200
Subject: [PATCH] pinentry-gtk-2
In-Reply-To: (Yuri D'Elia's message of "Tue, 23
Dec 2014 13:13:24 +0100")
References:
Message-ID: <87lhhs76qg.fsf@vigenere.g10code.de>
On Tue, 23 Dec 2014 13:13, wavexx at thregr.org said:
> It handles ESC (defaulting to cancel) while entering a passphrase.
> Any chance this gets looked at?
Pushed. Thanks.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Thu Apr 16 11:48:56 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 16 Apr 2015 11:48:56 +0200
Subject: gpg-agent: Show PID/command line of the requesting process
In-Reply-To: (Yuri D'Elia's message of "Tue, 23
Dec 2014 18:56:58 +0100")
References:
Message-ID: <87h9sg769j.fsf@vigenere.g10code.de>
On Tue, 23 Dec 2014 18:56, wavexx at thregr.org said:
> When using gpg-agent in daemon mode it's not always obvious which
> process is requesting authorization for unlocking a key. The agent
> should always show the PID/command of the requester.
That is probably nice for developers but most users don't known about
processes working in the background. In most cases they will see "gpg"
with some cryptic options and don't understand what this is about.
> The command line is extracted from /proc/[pid]/cmdline. Does somebody
It is all system specific. A process may also change the shown command
line; which is also system specific.
> Having a fixed text would be easy (such as: Program [PID] [command] is
> requesting to unlock the secret key ...). While doing some tests, it
I would put it into the title bar which is what I use for testing
pinentry. Telling the pinentry about the requesting socket and pid is
possible so that a pinentry may display the information at its own
discretion.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From bjk at luxsci.net Thu Apr 16 12:42:55 2015
From: bjk at luxsci.net (Ben Kibbey)
Date: Thu, 16 Apr 2015 06:42:55 -0400
Subject: gpg-agent: Show PID/command line of the requesting process
In-Reply-To: <87h9sg769j.fsf@vigenere.g10code.de>
References: <87h9sg769j.fsf@vigenere.g10code.de>
Message-ID: <1429180981-514111.244835979.ft3GAguqh011478@rs146.luxsci.com>
On Thu, Apr 16, 2015 at 11:48:56AM +0200, Werner Koch wrote:
> > The command line is extracted from /proc/[pid]/cmdline. Does somebody
>
> It is all system specific. A process may also change the shown command
> line; which is also system specific.
I have been thinking about creating a portable library to do this. There
have been cases where it would be useful other places too. As additional
security there could be a list of programs allowed to invoke the
pinentry. D-Bus has something similar if I remember right, as far as
command line lookup, but thats another thing altogether.
--
Ben Kibbey
From wavexx at thregr.org Thu Apr 16 12:54:10 2015
From: wavexx at thregr.org (Yuri D'Elia)
Date: Thu, 16 Apr 2015 12:54:10 +0200
Subject: gpg-agent: Show PID/command line of the requesting process
In-Reply-To: <87h9sg769j.fsf@vigenere.g10code.de>
References: <87h9sg769j.fsf@vigenere.g10code.de>
Message-ID: <552F94D2.2050104@thregr.org>
On 04/16/2015 11:48 AM, Werner Koch wrote:
> On Tue, 23 Dec 2014 18:56, wavexx at thregr.org said:
>> When using gpg-agent in daemon mode it's not always obvious which
>> process is requesting authorization for unlocking a key. The agent
>> should always show the PID/command of the requester.
>
> That is probably nice for developers but most users don't known about
> processes working in the background. In most cases they will see "gpg"
> with some cryptic options and don't understand what this is about.
Yes, true. However users that don't know about this will also ignore the
key being unlocked as well. Pinentry could easily have a 'details'
section showing more details, such as those.
Not to say that it's not cryptic. The problem that even PID/command is
sometimes not enough to understand for a developer as to why a key is
being unlocked.
But it's a start, and it's arguably something that doesn't come from the
program itself.
From wk at gnupg.org Fri Apr 17 14:39:03 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 17 Apr 2015 14:39:03 +0200
Subject: gpg-agent: Show PID/command line of the requesting process
In-Reply-To: <552F94D2.2050104@thregr.org> (Yuri D'Elia's message of "Thu, 16
Apr 2015 12:54:10 +0200")
References: <87h9sg769j.fsf@vigenere.g10code.de>
<552F94D2.2050104@thregr.org>
Message-ID: <874mof3p5k.fsf@vigenere.g10code.de>
On Thu, 16 Apr 2015 12:54, wavexx at thregr.org said:
> key being unlocked as well. Pinentry could easily have a 'details'
> section showing more details, such as those.
Good idea. We need to add an un-hide passpharse button anyway.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From heirecka at exherbo.org Sat Apr 18 10:58:49 2015
From: heirecka at exherbo.org (Heiko Becker)
Date: Sat, 18 Apr 2015 10:58:49 +0200
Subject: [PATCH] configure.ac: Use PKG_PROG_PKG_CONFIG
Message-ID: <1429347529-4551-1-git-send-email-heirecka@exherbo.org>
..instead of hard-coding pkg-config with AC_PATH_PROG.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 646bc32..cf5c592 100644
--- a/configure.ac
+++ b/configure.ac
@@ -276,7 +276,7 @@ AC_ARG_ENABLE(pinentry-gtk2,
dnl check for pkg-config
if test "$pinentry_gtk_2" != "no"; then
- AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
+ PKG_PROG_PKG_CONFIG
if test x"${PKG_CONFIG}" = xno ; then
pinentry_gtk_2=no
fi
--
2.3.3
From guilhem at fripost.org Mon Apr 20 11:17:31 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Mon, 20 Apr 2015 11:17:31 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <552EEB0E.4050709@adversary.org>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
<552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
<552EEB0E.4050709@adversary.org>
Message-ID: <20150420091731.GA6078@localhost>
On Thu, 16 Apr 2015 at 08:49:50 +1000, Ben McGinnes wrote:
> On 16/04/2015 7:17 am, Daniel Kahn Gillmor wrote:
>> Tor circuits to a particular endpoint are likely to be stable over the
>> period of time it would take to fetch the whole keyring.
>
> In a country with a decent Internet connection, sure. Over here in
> Australia, however, you can be pretty sure that you'll hit the ten
> minute window more than once.
Doesn't gpg use a single connection for the whole --refresh-keys? AFIK
the 10min windows (?MaxCircuitDirtiness? in the torrc) is only relevant
for new connections; I doubt tor client kills existing TCP connections
when updating circuits.
To force a circuit update each 10min, you could refresh your keyring one
key at a time. Or use a tool like parcimonie [0], or simply use the
gnupg-curl module with a different SOCKS5 username/password for each key
(assuming the ?IsolateSOCKSAuth? flag is set in your torrc, which is the
default):
gpg --http-proxy=socks5h://$FPR:$RANDOM at 127.0.0.1:9050 --recv-key $FPR
Unfortunately this is broken with 2.1, because dirmngr currently doesn't
honor --http-proxy (Issue1786).
--
Guilhem.
[0] https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From wk at gnupg.org Mon Apr 20 11:34:10 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 20 Apr 2015 11:34:10 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <20150420091731.GA6078@localhost> (Guilhem Moulin's message of
"Mon, 20 Apr 2015 11:17:31 +0200")
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
<552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
<552EEB0E.4050709@adversary.org> <20150420091731.GA6078@localhost>
Message-ID: <87zj63ywh9.fsf@vigenere.g10code.de>
On Mon, 20 Apr 2015 11:17, guilhem at fripost.org said:
> Doesn't gpg use a single connection for the whole --refresh-keys? AFIK
> the 10min windows (?MaxCircuitDirtiness? in the torrc) is only relevant
> for new connections; I doubt tor client kills existing TCP connections
At the gpg (or better openpgp) summit last weekend we talked about this
and came up with the idea to add a --use-tor option to make it easier to
use TOR.
> Unfortunately this is broken with 2.1, because dirmngr currently doesn't
> honor --http-proxy (Issue1786).
Right. The reason I put a fixme in the code was to first decide whether
to break some existing options and put all network related code into
dirmngr.
I will work on these things with a higher priority.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From guilhem at fripost.org Mon Apr 20 14:03:44 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Mon, 20 Apr 2015 14:03:44 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <87zj63ywh9.fsf@vigenere.g10code.de>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
<552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
<552EEB0E.4050709@adversary.org> <20150420091731.GA6078@localhost>
<87zj63ywh9.fsf@vigenere.g10code.de>
Message-ID: <20150420120344.GA7010@localhost>
On Mon, 20 Apr 2015 at 11:34:10 +0200, Werner Koch wrote:
> On Mon, 20 Apr 2015 11:17, guilhem at fripost.org said:
>> Doesn't gpg use a single connection for the whole --refresh-keys? AFIK
>> the 10min windows (?MaxCircuitDirtiness? in the torrc) is only relevant
>> for new connections; I doubt tor client kills existing TCP connections
>
> At the gpg (or better openpgp) summit last weekend we talked about this
> and came up with the idea to add a --use-tor option to make it easier to
> use TOR.
That would be awesome! Please beware DNS leaks, though. Also, do you
plan to restore SOCKSv5 proxying (via --http-proxy and libcurl)? With
1.4 and 2.0 it's very convenient for fine-grained Tor circuit uses
(E.g., with libcurl's ?socks5h://? and a custom username:password.)
> I will work on these things with a higher priority.
Many thanks :-)
--
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From gniibe at fsij.org Tue Apr 21 02:25:03 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 21 Apr 2015 09:25:03 +0900
Subject: 2.1.x regression (Re: gpg2 keytocard removes secret key)
In-Reply-To: <54E3DC36.6050406@fsij.org>
References: <87oaossape.fsf@muck.riseup.net> <54E3DC36.6050406@fsij.org>
Message-ID: <553598DF.9050308@fsij.org>
On 02/18/2015 02:35 AM, micah anderson wrote:
> To move the secret key material to the card, removing it from the
> computer, you would simply do a 'keytocard' operation, and then quit and
> save. In order to keep the secret key material on the computer, you
> would do the same operation, but this time you would *not* save when you
> quit. There are a number of tutorials out there that describe this step
> as the way to do it.
>
> I discovered yesterday that this third method does not work with gpg2,
> when you do the 'keytocard' operation, the secret key material is
> removed, you do not have the ability to opt-out of the saving process.
On 02/18/2015 09:26 AM, NIIBE Yutaka wrote:
> I opened the issue here to track:
>
> https://bugs.g10code.com/gnupg/issue1846
This bug was fixed in 2.1.3. Please note that the solution is not
perfect. It generates a private key stub from the card information.
I'm going to close this issue on the tracker.
It usually works well, but there are at lease two cases it doesn't
work.
(1) When a user remove the card before quit after keytocard.
(2) When a card reader has some problem reading out RSA public key
from the card.
For (1), it can be recovered by manually remove private key file on host
and invoke 'gpg --card-status'.
I encountered the problem of (2), when I tested VASCO DIGIKEY 920
reader with OpenPGPcard for RSA-2048. It supports extended APDU level
exchange, but it's dwMaxCCIDsize is only 271. With this reader,
chaining blocks works well for host-to-reader, but it seems that
chaining is not implemented for the reader-to-host and the response
from card (to reader, then, to host) for read-public-key always fails
because the CCID message size were more than 271 in extended APDU
level.
I know this is a corner case. But, it is a good lesson for me.
I think that it would be better for OpenPGPcard specification (and
implementations) to work with such (broken) readers. To do that, it
should support working with short APDU level exchange with
command-chaining (for host-to-reader, reader-to-card) and get-response
(for card-to-reader, reader-to-host).
I guess that this kinds of problems (of extended APDU level exchange)
are already noticed by smartcard industry. In the document of PC/SC
standard, "Interoperability Specification for ICCs and Personal
Computer Systems", Part 10 IFDs with Secure PIN Entry Capabilities
(revision 2.02.09, November, 2012), we can find the addition of
dwMaxAPDUDataSize for reader attribute.
Unfortunately, it's not the addition to the USB CCID specification
(yet).
Yes, this can improve an application program to cope with readers with
extended APDU level exchange, a bit. Simultaneously, it is an
evidence that abstraction/encapsulation by extended APDU level
exchange doesn't work well (as intended), and an application program
has to care reader's capability, in detail, when it communicates to
card.
With dwMaxAPDUDataSize, we can avoid a mysterious error which might be
caused by reader's buffer size limitation, that's true. But, still,
some large command or large response would have no way to work with
extended APDU level. It only suggests short APDU level exchange or
TPDU level exchange.
--
From ben at adversary.org Tue Apr 21 03:19:24 2015
From: ben at adversary.org (Ben McGinnes)
Date: Tue, 21 Apr 2015 11:19:24 +1000
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <20150420091731.GA6078@localhost>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net> <552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net> <552EEB0E.4050709@adversary.org>
<20150420091731.GA6078@localhost>
Message-ID: <5535A59C.8010208@adversary.org>
On 20/04/2015 7:17 pm, Guilhem Moulin wrote:
> On Thu, 16 Apr 2015 at 08:49:50 +1000, Ben McGinnes wrote:
>> On 16/04/2015 7:17 am, Daniel Kahn Gillmor wrote:
>>> Tor circuits to a particular endpoint are likely to be stable over the
>>> period of time it would take to fetch the whole keyring.
>>
>> In a country with a decent Internet connection, sure. Over here in
>> Australia, however, you can be pretty sure that you'll hit the ten
>> minute window more than once.
>
> Doesn't gpg use a single connection for the whole --refresh-keys? AFIK
> the 10min windows (?MaxCircuitDirtiness? in the torrc) is only relevant
> for new connections; I doubt tor client kills existing TCP connections
> when updating circuits.
Hmm, that's a good point, it means the only guaranteed way around that
is one of the lesser used current work arounds (a python script using
requests and python-gnupg to get the keylist and grab keys
sequentially).
> To force a circuit update each 10min, you could refresh your keyring one
> key at a time. Or use a tool like parcimonie [0], or simply use the
> gnupg-curl module with a different SOCKS5 username/password for each key
> (assuming the ?IsolateSOCKSAuth? flag is set in your torrc, which is the
> default):
The requests method above definitely works, with the tor socks
settings being used like any proxy parameter is with requests.
> gpg --http-proxy=socks5h://$FPR:$RANDOM at 127.0.0.1:9050 --recv-key $FPR
>
> Unfortunately this is broken with 2.1, because dirmngr currently doesn't
> honor --http-proxy (Issue1786).
Which means I could presumably adapt my proxychains rule to that
method in the mean time. I doubt there is much point, though, I
expect a number of these network related issues will be fixed before I
desperately need a full key refresh. Still, these bits are useful and
duly filed away for the future, cheers. :)
Hopefully one of the top ones on Werner's list is the TLS connections,
as that is almost certainly more important than an edge case like tor.
Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL:
From wk at gnupg.org Tue Apr 21 08:46:54 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Apr 2015 08:46:54 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <20150420120344.GA7010@localhost> (Guilhem Moulin's message of
"Mon, 20 Apr 2015 14:03:44 +0200")
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
<552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
<552EEB0E.4050709@adversary.org> <20150420091731.GA6078@localhost>
<87zj63ywh9.fsf@vigenere.g10code.de> <20150420120344.GA7010@localhost>
Message-ID: <87k2x6x9k1.fsf@vigenere.g10code.de>
On Mon, 20 Apr 2015 14:03, guilhem at fripost.org said:
> That would be awesome! Please beware DNS leaks, though. Also, do you
> plan to restore SOCKSv5 proxying (via --http-proxy and libcurl)? With
> 1.4 and 2.0 it's very convenient for fine-grained Tor circuit uses
> (E.g., with libcurl's ?socks5h://? and a custom username:password.)
That seems to be useful. I looked at the code and it seems that a
socks5h scheme can be added to our code without too much problems. But
I will start with socks4 and streamline the proxy options.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From bernhard at intevation.de Tue Apr 21 10:26:19 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 21 Apr 2015 10:26:19 +0200
Subject: wiki.gnupg.org theme?
Message-ID: <201504211026.21749.bernhard@intevation.de>
Hi there,
on the OpenPGP Summit last weekend, people suggested to me
that we could make the wiki look better.
Help with adding or creating a better theme is appreciated,
this is something you can do for the GnuPG Community. ;)
How do you like any of the 1.9 themes from https://moinmo.in/ThemeMarket ?
Best Regards,
Bernhard
ps.: please discuss on gnupg-users@ and cc me.
--
www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
From wk at gnupg.org Tue Apr 21 11:48:23 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Apr 2015 11:48:23 +0200
Subject: wiki.gnupg.org theme?
In-Reply-To: <201504211026.21749.bernhard@intevation.de> (Bernhard Reiter's
message of "Tue, 21 Apr 2015 10:26:19 +0200")
References: <201504211026.21749.bernhard@intevation.de>
Message-ID: <87vbgpx15k.fsf@vigenere.g10code.de>
On Tue, 21 Apr 2015 10:26, bernhard at intevation.de said:
> on the OpenPGP Summit last weekend, people suggested to me
> that we could make the wiki look better.
I'd appreciate if it looks similar to gnupg.org.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From kristian.fiskerstrand at sumptuouscapital.com Tue Apr 21 14:32:41 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Tue, 21 Apr 2015 14:32:41 +0200
Subject: [PATCH] dirmngr: Fix segfault in ldap engine
In-Reply-To: <87k2xga099.wl-neal@walfield.org>
References: <5529AE5F.7010109@sumptuouscapital.com>
<87k2xga099.wl-neal@walfield.org>
Message-ID: <55364369.9040903@sumptuouscapital.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 04/13/2015 10:41 AM, Neal H. Walfield wrote:
> Hi Kristian,
>
> Thanks for reporting these issues. I'll take a look at them soon.
>
> Neal
>
> At Sun, 12 Apr 2015 01:29:35 +0200, Kristian Fiskerstrand wrote:
>>
>> dirmngr: keyserver --help results in segfault, backtrace on [0].
>> Patch attached:
>>
>> (ks-engine-ldap.c) Fix segfault caused by missing check whether
>> uri is initialized
...
>>
>> References: [0]
>> http://download.sumptuouscapital.com/gnupg/gnupg-2.1.3-segfault.txt
Just
>>
a heads up that the segfault still persists in dirmngr as of
2.1.4-beta8.
With this patch (and a few other backports from the git master), GnuPG
2.1.3 has now been moved from experimental to testing (?~arch) in
Gentoo for amd64, hppa and x86 architectures. With the exception of
some reports related to claws mail requiring the socket specified in
GPG_AGENT_INFO[0] and some minor issues with smartcard keys, the
migration seems to have been relatively smooth so far.
References:
[0] http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3337
- --
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Donec eris sospes, multos numerabis amicos.
Tempora si fuerint nubila, solus eris.
As long as you are wealthy,you will have many friends.
When the tough times come, you will be left alone
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVNkNkAAoJEP7VAChXwav6WrEIAKXvGl49BI63oH5pJkAlc4oV
mMHDEKVw/2ncrrIevD8oqNyktsugxJpEOqVviajUXg5sx8nW2xVDXXu7yZ39AAk2
v/t5N18qv/IHx4N4wpwHv6n0iVykhZ5oKtIv8l7LRBFRRiSHxvZJsPbZk9ouXzHM
S5jxzZ1/rAoE7eBRiT+Hbu7Fns2FW5HJy7t1eflQrRRwdZyAHAEkTmXigFAtEgv6
OYD9V5YAZuAb7lCLL5ulz5KrdS0i/C3sn0dO7p8f2/gnZgBQoFPTApq1CoWeet22
v+eg7sTGYRzq3PRkPHDObpip7qGWPCai0vsS4XSIqhGGEY/NhnrOMIrYq1Pl9DE=
=XChx
-----END PGP SIGNATURE-----
From gniibe at fsij.org Wed Apr 22 03:31:18 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 22 Apr 2015 10:31:18 +0900
Subject: [PATCH] common: removal of t-support.c from t_jnlib_src
Message-ID: <5536F9E6.1070903@fsij.org>
Hello,
This patch is related to:
Building static GnuPG 2.1.2 fails due to multiply defined symbols.
https://bugs.gnupg.org/gnupg/issue1862
In common/, we have t-support.c as a replacement of functions in
libgcrypt and libgpg-error. It is used for t-stringhelp, t-timestuff,
and t-w32-reg.
Since those test programs are linked to libgcrypt and libgpg-error, we
don't need to link t-support.o.
diff --git a/common/Makefile.am b/common/Makefile.am
index 51923e8..4493ae7 100644
--- a/common/Makefile.am
+++ b/common/Makefile.am
@@ -171,7 +171,7 @@ endif
#
# Module tests
#
-t_jnlib_src = t-support.c t-support.h
+t_jnlib_src = t-support.h
jnlib_tests = t-stringhelp t-timestuff
if HAVE_W32_SYSTEM
jnlib_tests += t-w32-reg
--
From wk at gnupg.org Wed Apr 22 09:07:48 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 22 Apr 2015 09:07:48 +0200
Subject: [PATCH] common: removal of t-support.c from t_jnlib_src
In-Reply-To: <5536F9E6.1070903@fsij.org> (NIIBE Yutaka's message of "Wed, 22
Apr 2015 10:31:18 +0900")
References: <5536F9E6.1070903@fsij.org>
Message-ID: <87pp6wvdx7.fsf@vigenere.g10code.de>
On Wed, 22 Apr 2015 03:31, gniibe at fsij.org said:
> Since those test programs are linked to libgcrypt and libgpg-error, we
> don't need to link t-support.o.
Right. Remove it from the repo.
I am anyway considering to remove the special treatment of the former
jnlib library (named after the suffix of my HAM call sign) and make it a
proper part of libcommon.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Wed Apr 22 10:04:04 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 22 Apr 2015 10:04:04 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <20150420120344.GA7010@localhost> (Guilhem Moulin's message of
"Mon, 20 Apr 2015 14:03:44 +0200")
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
<552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
<552EEB0E.4050709@adversary.org> <20150420091731.GA6078@localhost>
<87zj63ywh9.fsf@vigenere.g10code.de> <20150420120344.GA7010@localhost>
Message-ID: <878udkvbbf.fsf@vigenere.g10code.de>
On Mon, 20 Apr 2015 14:03, guilhem at fripost.org said:
> That would be awesome! Please beware DNS leaks, though. Also, do you
DNS leaks a re a problem right now. Dirmngr does its own resolving to
be able to detect and then bypass dead keyservers in the pool. Thus we
need to find a way to get all A and AAAA records for a given pool name
as well as to retrieve PTR records for the IP addresses. Any hints on
how to do that without extra configuration work for the user?
It would also be useful to be able to fetch CERT records anonymously.
However this is a different problem and can be mitigated by other methods
of key lookup. If we add a --use-tor option it should disable all CERT
or DANE lookups.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From guilhem at fripost.org Wed Apr 22 13:04:05 2015
From: guilhem at fripost.org (Guilhem Moulin)
Date: Wed, 22 Apr 2015 13:04:05 +0200
Subject: gpg --refresh with large keyrings and hkps in 2.1.1
In-Reply-To: <878udkvbbf.fsf@vigenere.g10code.de>
References: <87h9wvrv4w.fsf@alice.fifthhorseman.net>
<87twwjs9sm.fsf@alice.fifthhorseman.net>
<552EB1A7.3010105@adversary.org>
<87mw29ozuy.fsf@alice.fifthhorseman.net>
<552EEB0E.4050709@adversary.org> <20150420091731.GA6078@localhost>
<87zj63ywh9.fsf@vigenere.g10code.de>
<20150420120344.GA7010@localhost>
<878udkvbbf.fsf@vigenere.g10code.de>
Message-ID: <20150422110405.GA6376@localhost>
On Wed, 22 Apr 2015 at 10:04:04 +0200, Werner Koch wrote:
> On Mon, 20 Apr 2015 14:03, guilhem at fripost.org said:
>> That would be awesome! Please beware DNS leaks, though. Also, do you
>
> DNS leaks a re a problem right now. Dirmngr does its own resolving to
> be able to detect and then bypass dead keyservers in the pool. Thus we
> need to find a way to get all A and AAAA records for a given pool name
> as well as to retrieve PTR records for the IP addresses. Any hints on
> how to do that without extra configuration work for the user?
The only things that comes to my mind ATM would be to add a
?dns-server=HOST[:PORT]? option to the dirmngr.conf. IMHO a user
configuring an ?http-proxy? wouldn't mind configuring a custom
resolver as well; they could point it to Tor's own resolver (specified
by ?DNSPort? in the torrc). Unfortunately it wouldn't be very useful
ATM, as it doesn't seem to handle multiple replies:
$ dig @127.0.0.1 -p 5353 +short pool.sks-keyservers.net
80.90.43.162
I'll file a bug in the Tor tracker to follow up on that. They might
also provide better to perform the resolving anonymously.
> It would also be useful to be able to fetch CERT records anonymously.
> However this is a different problem and can be mitigated by other methods
> of key lookup. If we add a --use-tor option it should disable all CERT
> or DANE lookups.
Right. Also, Tor's own resolver only supports A, AAAA and PTR records.
--
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From bjk at luxsci.net Sat Apr 25 23:38:07 2015
From: bjk at luxsci.net (Ben Kibbey)
Date: Sat, 25 Apr 2015 17:38:07 -0400
Subject: libgpgme and gpg genkey passphrase inquire
In-Reply-To: <1429052641-2728836.99318832.ft3EN36Bb008082@rs146.luxsci.com>
References: <1429052641-2728836.99318832.ft3EN36Bb008082@rs146.luxsci.com>
Message-ID: <1429997942-3685962.22968228.ft3PLc8Li032196@rs146.luxsci.com>
On Tue, Apr 14, 2015 at 07:03:05PM -0400, Ben Kibbey wrote:
> Hello,
>
> I'd like the ability to use a key-file as a passphrase when generating a
> new keypair. Attached are patches for both gpg and libgpgme. I'm not
> sure if the gpg patch will break anything since it implies --batch when
> --command-fd is set along with --gen-key. The gpgme patch just sets the
> passphrase command handler like the other gpgme crypto functions do.
I've created branches named "bjk/passphrase-inquire" for both gnupg and
gpgme and have been updated to make use of the INQUIRE_MAXLEN status
message.
One gotcha I noticed with the gpg patch is that --command-fd must be
specified before --gen-key but since it will probably only be used with
gpgme it wont matter much.
--
Ben Kibbey
From gniibe at fsij.org Mon Apr 27 04:12:19 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 27 Apr 2015 11:12:19 +0900
Subject: [PATCH] npth: npth-config should include -lrt for clock_gettime
Message-ID: <553D9B03.9080208@fsij.org>
Hello,
In the past, I got this issue, but forgot to report. For some old
systems (for example, GNU/Linux system with old glibc), -lrt is needed
for clock_gettime function. npth itself handles this. npth-config
should address this problem, too.
I encountered this problem (again) for Red Hat Enterprise Linux 5.11.
See: https://bugs.gnupg.org/gnupg/issue1862
Here is a patch to npth, so that npth-config --libs includes the library.
Ok to apply?
diff --git a/configure.ac b/configure.ac
index eb534d7..e503324 100644
--- a/configure.ac
+++ b/configure.ac
@@ -271,6 +271,7 @@ AC_SEARCH_LIBS([clock_gettime],[rt posix4])
if test "x$ac_cv_search_clock_gettime" != no; then
AC_DEFINE(HAVE_CLOCK_GETTIME,1,
[Define to 1 if you have the `clock_gettime' function.])
+ config_libs="$config_libs $ac_cv_search_clock_gettime"
fi
--
From dkg at fifthhorseman.net Tue Apr 28 19:01:13 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Apr 2015 13:01:13 -0400
Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of
read_password
Message-ID: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
* tty/pinentry-tty.c: reorganize, wrapping read_password in tty
open/close.
--
This patch sets the stage to simplify the subsequent fixes.
---
tty/pinentry-tty.c | 66 ++++++++++++++++++++++++++++--------------------------
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
index 8f680fd..1aeffbd 100644
--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -59,36 +59,13 @@ cbreak (int fd)
}
static int
-read_password (pinentry_t pinentry, const char *tty_name, const char *tty_type)
+read_password (pinentry_t pinentry, FILE *ttyfi, FILE *ttyfo)
{
- FILE *ttyfi = stdin;
- FILE *ttyfo = stdout;
int count;
- if (tty_name)
- {
- ttyfi = fopen (tty_name, "r");
- if (!ttyfi)
- return -1;
-
- ttyfo = fopen (tty_name, "w");
- if (!ttyfo)
- {
- int err = errno;
- fclose (ttyfi);
- errno = err;
- return -1;
- }
- }
-
if (cbreak (fileno (ttyfi)) == -1)
{
int err = errno;
- if (tty_name)
- {
- fclose (ttyfi);
- fclose (ttyfo);
- }
fprintf (stderr, "cbreak failure, exiting\n");
errno = err;
return -1;
@@ -113,11 +90,6 @@ read_password (pinentry_t pinentry, const char *tty_name, const char *tty_type)
}
tcsetattr (fileno(ttyfi), TCSANOW, &o_term);
- if (tty_name)
- {
- fclose (ttyfi);
- fclose (ttyfo);
- }
return strlen (pinentry->pin);
}
@@ -158,7 +130,9 @@ catchsig(int sig)
int
tty_cmd_handler(pinentry_t pinentry)
{
- int rc;
+ int rc = 0;
+ FILE *ttyfi = stdin;
+ FILE *ttyfo = stdout;
#ifndef HAVE_DOSISH_SYSTEM
timed_out = 0;
@@ -174,8 +148,36 @@ tty_cmd_handler(pinentry_t pinentry)
}
#endif
- rc = read_password (pinentry, pinentry->ttyname, pinentry->ttytype);
- do_touch_file (pinentry);
+ if (pinentry->ttyname)
+ {
+ ttyfi = fopen (pinentry->ttyname, "r");
+ if (!ttyfi)
+ rc = -1;
+ else
+ {
+ ttyfo = fopen (pinentry->ttyname, "w");
+ if (!ttyfo)
+ {
+ int err = errno;
+ fclose (ttyfi);
+ errno = err;
+ rc = -1;
+ }
+ }
+ }
+
+ if (rc == 0)
+ {
+ rc = read_password (pinentry, ttyfi, ttyfo);
+ do_touch_file (pinentry);
+ }
+
+ if (pinentry->ttyname)
+ {
+ fclose (ttyfi);
+ fclose (ttyfo);
+ }
+
return rc;
}
--
2.1.4
From dkg at fifthhorseman.net Tue Apr 28 19:01:14 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Apr 2015 13:01:14 -0400
Subject: [PATCH 2/4] pinentry-tty: fix segfault on MESSAGE or CONFIRM
In-Reply-To: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1430240476-27188-2-git-send-email-dkg@fifthhorseman.net>
* tty/pinentry-tty.c: avoid prompting for a PIN when one was not asked
for.
--
Before this, pinentry-tty would segfault when asked for MESSAGE or
CONFIRM:
0 dkg at alice:~$ pinentry-tty
OK Your orders please
SETDESC testing testing
OK
MESSAGE
testing testing
PIN? :
Segmentation fault
139 dkg at alice:~$
---
tty/pinentry-tty.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
index 1aeffbd..e2e0871 100644
--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -168,7 +168,14 @@ tty_cmd_handler(pinentry_t pinentry)
if (rc == 0)
{
- rc = read_password (pinentry, ttyfi, ttyfo);
+ if (pinentry->pin)
+ rc = read_password (pinentry, ttyfi, ttyfo);
+ else
+ {
+ fprintf (ttyfo, "%s\n",
+ pinentry->description? pinentry->description:"");
+ fflush (ttyfo);
+ }
do_touch_file (pinentry);
}
--
2.1.4
From dkg at fifthhorseman.net Tue Apr 28 19:01:15 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Apr 2015 13:01:15 -0400
Subject: [PATCH 3/4] pinentry-tty: make confirm actions work
In-Reply-To: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1430240476-27188-3-git-send-email-dkg@fifthhorseman.net>
* tty/pinentry-tty.c: treat the situation where no PIN is requested
and one_button is not set as a confirmation prompt.
--
When user confirmation is requested on a dumb terminal, we use the
value of the "OK" button followed with [y/N]? as the confirmation
prompt. User typing is echoed as normal, since a confirmation prompt
is not a password entry.
---
tty/pinentry-tty.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/tty/pinentry-tty.c b/tty/pinentry-tty.c
index e2e0871..bd58ae0 100644
--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -59,6 +59,24 @@ cbreak (int fd)
}
static int
+confirm (pinentry_t pinentry, FILE *ttyfi, FILE *ttyfo)
+{
+ char buf[32], *ret;
+ pinentry->canceled = 1;
+ fprintf (ttyfo, "%s [y/N]? ", pinentry->ok ? pinentry->ok : "OK");
+ fflush (ttyfo);
+ buf[0] = '\0';
+ ret = fgets (buf, sizeof(buf), ttyfi);
+ if (ret && (buf[0] == 'y' || buf[0] == 'Y'))
+ {
+ pinentry->canceled = 0;
+ return 1;
+ }
+ return 0;
+}
+
+
+static int
read_password (pinentry_t pinentry, FILE *ttyfi, FILE *ttyfo)
{
int count;
@@ -170,11 +188,13 @@ tty_cmd_handler(pinentry_t pinentry)
{
if (pinentry->pin)
rc = read_password (pinentry, ttyfi, ttyfo);
- else
+ else
{
fprintf (ttyfo, "%s\n",
pinentry->description? pinentry->description:"");
fflush (ttyfo);
+ if (! pinentry->one_button)
+ rc = confirm (pinentry, ttyfi, ttyfo);
}
do_touch_file (pinentry);
}
--
2.1.4
From dkg at fifthhorseman.net Tue Apr 28 19:01:16 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 28 Apr 2015 13:01:16 -0400
Subject: [PATCH 4/4] fix small memory leak in pinentry-curses
In-Reply-To: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <1430240476-27188-4-git-send-email-dkg@fifthhorseman.net>
* pinentry/pinentry-curses.c: free internally allocated local string.
---
pinentry/pinentry-curses.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c
index 4b7080e..043f8a9 100644
--- a/pinentry/pinentry-curses.c
+++ b/pinentry/pinentry-curses.c
@@ -199,6 +199,8 @@ utf8_to_local (char *lc_ctype, char *string)
memset (&ps, 0, sizeof(mbstate_t));
mbsrtowcs (wcs, &p, len, &ps);
+ free (local);
+
leave:
if (old_ctype)
{
--
2.1.4
From richard.purdie at linuxfoundation.org Wed Apr 29 11:54:26 2015
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Wed, 29 Apr 2015 10:54:26 +0100
Subject: Use of pkg-config
In-Reply-To: <87bnv0s1sx.fsf@vigenere.g10code.de>
References: <1399985729.31891.165.camel@ted>
<87y4y4s7y8.fsf@vigenere.g10code.de> <1400083173.31891.246.camel@ted>
<87bnv0s1sx.fsf@vigenere.g10code.de>
Message-ID: <1430301266.19130.13.camel@linuxfoundation.org>
On Wed, 2014-05-14 at 19:33 +0200, Werner Koch wrote:
> On Wed, 14 May 2014 17:59, richard.purdie at linuxfoundation.org said:
>
> > Its worth highlighting that pkg-config has now standardised on using its
> > own internal glib code so it no longer has that dependency, its handled
>
> Okay.
>
> > of sense. Since that is now addressed does that help improve the
> > situation to a point its use could be reconsidered?
>
> Request an addition to POSIX and I will reconsider it.
>
> > Alternatively, could pkg-config be added as an option? It could be used
> > by default and things could then fall back to the -config scripts?
>
> No. The configure script along with the autoconf macros is how the
> gnupg related stuff is to be build. If there is a problem, please file
> a bug. Frankly, I don't see the reason for the request to use
> pkg-config. The *-config script approach is much more flexible and
> easier to maintain.
This discussion was nearly a year ago. I just wanted to mention that
this hasn't been forgotten, we continue to patch the gnupg toolset to
use pkg-config instead of the -config files. At this point its the last
piece of the operating systems we build using -config files.
I live in hope that at some point the issue can be reconsidered.
Cheers,
Richard
From dkg at fifthhorseman.net Wed Apr 29 20:20:31 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 29 Apr 2015 14:20:31 -0400
Subject: excessive usage of /dev/random?
Message-ID: <87twvykd8w.fsf@alice.fifthhorseman.net>
Hi folks--
over on the bettercrypto mailing list [0], my attention was drawn to the
man page for random(4), which says:
The kernel random-number generator is designed to produce a small
amount of high-quality seed material to seed a cryptographic pseudo-
random number generator (CPRNG). It is designed for security, not
speed, and is poorly suited to generating large amounts of random data.
Users should be very economical in the amount of seed material that
they read from /dev/urandom (and /dev/random); unnecessarily reading
large quantities of data from this device will have a negative impact
on other users of the device.
The amount of seed material required to generate a cryptographic key
equals the effective key size of the key. For example, a 3072-bit RSA
or Diffie-Hellman private key has an effective key size of 128 bits (it
requires about 2^128 operations to break) so a key generator only needs
128 bits (16 bytes) of seed material from /dev/random.
While some safety margin above that minimum is reasonable, as a guard
against flaws in the CPRNG algorithm, no cryptographic primitive avail?
able today can hope to promise more than 256 bits of security, so if
any program reads more than 256 bits (32 bytes) from the kernel random
pool per invocation, or per reasonable reseed interval (not less than
one minute), that should be taken as a sign that its cryptography is
not skillfully implemented.
however, i noticed that using 2.1.3, the following command reads 300
bytes from /dev/random:
gpg --quick-gen-key 'test '
Should GnuPG be more sparing in its use of this blocking resource?
The full thread covers other good insights around system entropy as well.
--dkg
[0] applied crypto hardening
https://lists.cert.at/pipermail/ach/2015-April/001884.html
From gniibe at fsij.org Thu Apr 30 05:50:34 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 30 Apr 2015 12:50:34 +0900
Subject: [PATCH] scd: PC/SC reader selection by partial string match.
Message-ID: <5541A68A.9050609@fsij.org>
Hello,
I'm going to push following patch to GnuPG 2.1.x. This fix is
related to the issue 1618 and 1930.
https://bugs.gnupg.org/gnupg/issue1618
https://bugs.gnupg.org/gnupg/issue1930
For 1930, I put a patch for 2.0.x in the bug tracker, but I haven't
got response from the reporter. As I tested with GnuPG 2.1.x, this
patch is now for 2.1.x. I plan to backport to 2.0 (use the one in
issue1930), soon.
The card reader name by PC/SC service might include USB bus, which
varies (on some platform like GNU/Linux). Thus, it's better to match
partial string.
Original patch was submitted by anstein in 1930. I changed it to
fallback to the first reader if no match found.
Note that we need to change pcsc-wrapper.c in 2.0 backport.
It works for me with pcscd and libccid on GNU/Linux. The readers
are VASCO DIGIKEY 920 and Gnuk Token.
diff --git a/scd/apdu.c b/scd/apdu.c
index f6cca8c..189fd4a 100644
--- a/scd/apdu.c
+++ b/scd/apdu.c
@@ -1911,6 +1911,7 @@ open_pcsc_reader_direct (const char *portstr)
long err;
int slot;
char *list = NULL;
+ char *rdrname = NULL;
pcsc_dword_t nreader;
char *p;
@@ -1963,18 +1964,22 @@ open_pcsc_reader_direct (const char *portstr)
{
if (!*p && !p[1])
break;
- if (*p)
- log_info ("detected reader '%s'\n", p);
+ log_info ("detected reader '%s'\n", p);
if (nreader < (strlen (p)+1))
{
log_error ("invalid response from pcsc_list_readers\n");
break;
}
+ if (!rdrname && portstr && !strncmp (p, portstr, strlen (portstr)))
+ rdrname = p;
nreader -= strlen (p)+1;
p += strlen (p) + 1;
}
- reader_table[slot].rdrname = xtrymalloc (strlen (portstr? portstr : list)+1);
+ if (!rdrname)
+ rdrname = list;
+
+ reader_table[slot].rdrname = xtrystrdup (rdrname);
if (!reader_table[slot].rdrname)
{
log_error ("error allocating memory for reader name\n");
@@ -1983,7 +1988,6 @@ open_pcsc_reader_direct (const char *portstr)
unlock_slot (slot);
return -1;
}
- strcpy (reader_table[slot].rdrname, portstr? portstr : list);
xfree (list);
list = NULL;
--
From gniibe at fsij.org Thu Apr 30 07:13:41 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 30 Apr 2015 14:13:41 +0900
Subject: [PATCH] g10: fix cmp_public_key and cmp_secret_keys
Message-ID: <5541BA05.3060706@fsij.org>
Hello,
This patch is my attempt to fix GnuPG 1.4.x and 2.0.x for the issue
1962.
https://bugs.gnupg.org/gnupg/issue1962
The specific problem of issue 1962 is that comparison of subkeys
always fails in merge_blocks and it results calling append_key always.
Following patch is for 2.0.x but similar can be applied to 1.4.x, too.
This patch basically intend to fix a problem of ECC key handling with
1.4 and 2.0, but the patch itself can also be applied to 2.1.
When the public key algorithm is not known, pkey[0] field is set with
opaque MPI in the parse_key function. Thus, I think that the key can
be compared.
Actually, I got a report to me, my repeated subkey of secp256k1. I
think that this was the cause.
diff --git a/g10/free-packet.c b/g10/free-packet.c
index 85f23ce..9b42cfd 100644
--- a/g10/free-packet.c
+++ b/g10/free-packet.c
@@ -452,11 +452,14 @@ cmp_public_keys( PKT_public_key *a, PKT_public_key *b )
return -1;
n = pubkey_get_npkey( b->pubkey_algo );
- if( !n )
- return -1; /* can't compare due to unknown algorithm */
- for(i=0; i < n; i++ ) {
- if( mpi_cmp( a->pkey[i], b->pkey[i] ) )
- return -1;
+ if( !n ) { /* unknown algorithm, rest is in opaque MPI */
+ if( mpi_cmp( a->pkey[0], b->pkey[0] ) )
+ return -1; /* can't compare due to unknown algorithm */
+ } else {
+ for(i=0; i < n; i++ ) {
+ if( mpi_cmp( a->pkey[i], b->pkey[i] ) )
+ return -1;
+ }
}
return 0;
@@ -479,11 +482,14 @@ cmp_secret_keys( PKT_secret_key *a, PKT_secret_key *b )
return -1;
n = pubkey_get_npkey( b->pubkey_algo );
- if( !n )
- return -1; /* can't compare due to unknown algorithm */
- for(i=0; i < n; i++ ) {
- if( mpi_cmp( a->skey[i], b->skey[i] ) )
+ if( !n ) { /* unknown algorithm, rest is in opaque MPI */
+ if( mpi_cmp( a->skey[0], b->skey[0] ) )
return -1;
+ } else {
+ for(i=0; i < n; i++ ) {
+ if( mpi_cmp( a->skey[i], b->skey[i] ) )
+ return -1;
+ }
}
return 0;
--
From wk at gnupg.org Thu Apr 30 08:50:00 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 30 Apr 2015 08:50:00 +0200
Subject: excessive usage of /dev/random?
In-Reply-To: <87twvykd8w.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
message of "Wed, 29 Apr 2015 14:20:31 -0400")
References: <87twvykd8w.fsf@alice.fifthhorseman.net>
Message-ID: <87sibi5cvb.fsf@vigenere.g10code.de>
On Wed, 29 Apr 2015 20:20, dkg at fifthhorseman.net said:
> however, i noticed that using 2.1.3, the following command reads 300
> bytes from /dev/random:
All GnuPG versions do this. GnuPG has always used its own CSPRNG where
/dev/random is used only as a seed. A pool of 600 bytes is used and
pre-seeded from the ~/.gnupg/random_seed state file is available. Now
for key generation we do not want to rely on too much existing state and
thus require that 50% fresh entropy is mixed into the pool. Thus the
need for 300 bytes from /dev/random or whatever is used for the entropy
gatherer.
The Linux entropy collectors and thus the quality of /dev/random is
highly depending on the kernel version, hardware, and OS. Sometimes
/dev/random is very slow but sometimes way too fast on similar hardware.
Thus /dev/random is never used directly; better safe than sorry. The
Libgcrypt/GnuPG RNG design has been evaluated by the BSI for an internal
project where they only questioned the quality and version by version
changes of the entropy gatherer on Linux, i.e. /dev/random. The results
seem to be confidential, however I have some insight because I helped
them by answering questions and leading them through the source code.
Since Libgcrypt 1.6.0 an application may bypass the regular RNG and
directly use /dev/random using gcry_control:
'GCRYCTL_SET_PREFERRED_RNG_TYPE; Arguments: int'
These are advisory commands to select a certain random number
generator. They are only advisory because libraries may not
know what an application actually wants or vice versa. Thus
Libgcrypt employs a priority check to select the actually used
RNG. If an applications selects a lower priority RNG but a
library requests a higher priority RNG Libgcrypt will switch
to the higher priority RNG. Applications and libraries should
use these control codes before 'gcry_check_version'. The
available generators are:
'GCRY_RNG_TYPE_STANDARD'
A conservative standard generator based on the
"Continuously Seeded Pseudo Random Number Generator"
designed by Peter Gutmann.
'GCRY_RNG_TYPE_FIPS'
A deterministic random number generator conforming to he
document "NIST-Recommended Random Number Generator Based
on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES
and AES Algorithms" (2005-01-31). This implementation
uses the AES variant.
'GCRY_RNG_TYPE_SYSTEM'
A wrapper around the system's native RNG. On Unix system
these are usually the /dev/random and /dev/urandom
devices.
The default is 'GCRY_RNG_TYPE_STANDARD' unless FIPS mode as
been enabled; in which case 'GCRY_RNG_TYPE_FIPS' is used and
locked against further changes.
'GCRYCTL_GET_CURRENT_RNG_TYPE; Arguments: int *'
This command stores the type of the currently used RNG as an
integer value at the provided address.
GnuPG does not use it. Details about the RNG architecture can be found
in the Libgcrypt manual.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Thu Apr 30 09:00:00 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 30 Apr 2015 09:00:00 +0200
Subject: [PATCH] g10: fix cmp_public_key and cmp_secret_keys
In-Reply-To: <5541BA05.3060706@fsij.org> (NIIBE Yutaka's message of "Thu, 30
Apr 2015 14:13:41 +0900")
References: <5541BA05.3060706@fsij.org>
Message-ID: <87oam65cen.fsf@vigenere.g10code.de>
On Thu, 30 Apr 2015 07:13, gniibe at fsij.org said:
> When the public key algorithm is not known, pkey[0] field is set with
> opaque MPI in the parse_key function. Thus, I think that the key can
> be compared.
Ack. mpi_cmp works with opaque values since Libgcrypt 1.5.0. However,
for GnuPG 2.0 we only require Libgcrypt 1.4. Thus either update the
requirement for Libgcrypt or make the change depend on the Libgcrypt
version. I would suggest the former.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From gniibe at fsij.org Thu Apr 30 10:32:15 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 30 Apr 2015 17:32:15 +0900
Subject: [PATCH] g10: fix cmp_public_key and cmp_secret_keys
In-Reply-To: <87oam65cen.fsf@vigenere.g10code.de>
References: <5541BA05.3060706@fsij.org> <87oam65cen.fsf@vigenere.g10code.de>
Message-ID: <5541E88F.6050502@fsij.org>
On 04/30/2015 04:00 PM, Werner Koch wrote:
> Ack. mpi_cmp works with opaque values since Libgcrypt 1.5.0. However,
> for GnuPG 2.0 we only require Libgcrypt 1.4. Thus either update the
> requirement for Libgcrypt or make the change depend on the Libgcrypt
> version. I would suggest the former.
Thanks for your review.
For 1.4, I added the change for opaque MPI to mpi_cmp.
For 2.0, I changed configure.ac and added an entry in NEWS for
requirement of libgcrypt 1.5.
Those changes are pushed to the repository.
I'll forward-port it to 2.1, tomorrow.
--
From neal at walfield.org Thu Apr 30 13:49:09 2015
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 30 Apr 2015 13:49:09 +0200
Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of
read_password
In-Reply-To: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <874mnxg7ka.wl-neal@walfield.org>
Hi Daniel,
Thanks for these patches. I'm taking a look at them right now. I
have two questions so far:
I had a bit of trouble applying them to git head (due to differing
white space). What version did you base these patches on?
Also, you didn't update the copyright header. I'll fit this for you.
What's appropriate here?
Thanks,
Neal
From dkg at fifthhorseman.net Thu Apr 30 15:54:06 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 30 Apr 2015 09:54:06 -0400
Subject: [PATCH 1/4] pinentry-tty: handle designated tty outside of
read_password
In-Reply-To: <874mnxg7ka.wl-neal@walfield.org>
References: <1430240476-27188-1-git-send-email-dkg@fifthhorseman.net>
<874mnxg7ka.wl-neal@walfield.org>
Message-ID: <87wq0tiuwx.fsf@alice.fifthhorseman.net>
Hi Neal--
On Thu 2015-04-30 07:49:09 -0400, Neal H. Walfield wrote:
> Thanks for these patches. I'm taking a look at them right now.
Thanks!
> I had a bit of trouble applying them to git head (due to differing
> white space). What version did you base these patches on?
For me, they apply directly atop
9d2d8b6bfaf2d5b07e7fb5be7188516e4158ed98, which is what i see as the
main "master" branch at git://git.gnupg.org/pinentry.git. I just tested
that by piping each e-mail message through "git am" in sequence after
that commit.
You can also see these changes on the "tty-refactor" branch at:
git://lair.fifthhorseman.net/~dkg/pinentry
If you'd prefer to see the changes in some other form, please let me
know what is most convenient for you.
> Also, you didn't update the copyright header. I'll fit this for you.
> What's appropriate here?
Thanks! I think you're asking about attribution, so: you can credit the
changes to Daniel Kahn Gillmor . If you're
asking for some other detail, please let me know.
Regards,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL:
From dkg at fifthhorseman.net Thu Apr 30 16:48:11 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 30 Apr 2015 10:48:11 -0400
Subject: excessive usage of /dev/random?
In-Reply-To: <87sibi5cvb.fsf@vigenere.g10code.de>
References: <87twvykd8w.fsf@alice.fifthhorseman.net>
<87sibi5cvb.fsf@vigenere.g10code.de>
Message-ID: <87twvxises.fsf@alice.fifthhorseman.net>
On Thu 2015-04-30 02:50:00 -0400, Werner Koch wrote:
> On Wed, 29 Apr 2015 20:20, dkg at fifthhorseman.net said:
>
>> however, i noticed that using 2.1.3, the following command reads 300
>> bytes from /dev/random:
>
> All GnuPG versions do this. GnuPG has always used its own CSPRNG where
> /dev/random is used only as a seed. A pool of 600 bytes is used and
> pre-seeded from the ~/.gnupg/random_seed state file is available. Now
> for key generation we do not want to rely on too much existing state and
> thus require that 50% fresh entropy is mixed into the pool. Thus the
> need for 300 bytes from /dev/random or whatever is used for the entropy
> gatherer.
The argument that the man page makes (and that djb makes in
http://blog.cr.yp.to/20140205-entropy.html) is that for a proper CSPRNG,
you shouldn't really need more than 256 bits of true entropy to get a
properly unbreakable seed. "some safety margin above that minimum is
reasonable", but going from 32 bytes to 300 bytes is a rather large
safety margin.
> The Linux entropy collectors and thus the quality of /dev/random is
> highly depending on the kernel version, hardware, and OS. Sometimes
> /dev/random is very slow but sometimes way too fast on similar
> hardware.
is "way too fast" really an issue? If we had excellent entropy, we
wouldn't care about it showing up speedily, right?
> Thus /dev/random is never used directly; better safe than sorry.
FWIW, I am *not* complaining about not using /dev/random directly -- i
agree with the architecture of an internal CSPRNG seeded from the
outside. I'm asking about whether we really need 300 bytes (2400 bits)
of a seed, which random(4) suggests is overkill.
Regards,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL:
From pedro.msac at gmail.com Thu Apr 30 17:37:21 2015
From: pedro.msac at gmail.com (Pedro Coelho)
Date: Thu, 30 Apr 2015 16:37:21 +0100
Subject: Use of composed characters and altgr utf-8 symbols on passwords.
Message-ID:
Hi,
I have an issue that I've detected today and searched the entire mailing
list and did not find an answer.
I hope I'm not wasting anyone's time.
I use OpenSuSE 13.1 64bits as my main distribution on Linux.
I encrypt on that same computer some files and my passphrase always used
both composed characters as well as altgr symbols.
Meaning utf-8 characters.
In this particular case I used symmetric encryption on a file, like this:
gpg -c --s2k-mode 3 --s2k-count 65011712 --s2k-cipher-algo AES256
--cert-digest-algo SHA512 file.txt
All is ok to decrypt the file when I use OpenSuSE KDE desktop even on other
computers I have.
What I have noticed tho is a strange behavior that should be of some
concern.
When trying to decrypt the exact same file on Other distros I always get
the Bad Key message!
Once the Same file is encrypted with a passphrase with no composed
characters And No altgr characters everything is ok! the file is decrypted
with no problem.
I've done some testing and used Centos 6 CLI mode only, Centos 7 with x,
Ubuntu (several versions) , Kali Linux, Tails ... you name it.
Worst.
On my computer I switched to a new session with LXDE as the desktop and ...
the result was the same!
The file I could decrypt in my KDE session I was not able to decrypt on the
same computer o on the LXDE session.
Same old bad key error.
Of course this may be realted to the way those chars are "interpreted"
between different environments. Or could this be a gpg bug?
Also I must alert you good folks that this is for me of Paramount
importance since increasing the character space of a passwrod is Hugely
important to increase the security.
It's also a big big hurdle if I can not have inter-environment
compatibility.
It really really is annoying ... and higly curtails a lot of the power
contained in gnupg ..
Can anyone try to explain why this happening ?
Best regards,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: