Re: Toggle the authenticate capability

[Roy A. Gilmore]

Hi Andrew,

I didn't think that it would actually hurt anything, but, I wasn't sure
about the internals. I'm a little bit OCD (or anal, or whatever
neo-psychobabble term applies), and having the authentication capability
on the signing key, after creating a authentication subkey just LOOKED
wrong to me, whether it is wrong, is another story...

Thank you,

Roy A. Gilmore


On 12/04/2016 03:09 PM, Andrew Gallagher wrote:
> Hi Roy,
>
> You normally don't need to remove the A capability from a signing key. By 
> default, gnupg will use the most recently created valid subkey with the 
> appropriate capability, so all you need to do is create a new A subkey and it 
> will be used in preference to the old one. Mathematically, authentication is 
> just a special case of signing, so having both S and A on a subkey does not 
> introduce extra vulnerabilities (that we know of). 
>
> It is technically possible to change the capability flags on any key, but you 
> can't do it with a vanilla version of the software. There is a patch 
> somewhere in the archives of this list but I would recommend against it. The 
> only use case where it would be necessary to remove a capability flag would 
> be if you had created an encryption key that also had S or A capability - but 
> it's almost impossible to do it by accident and in such cases it's safer to 
> revoke the key and start again.
>
> Andrew Gallagher
>
>> On 4 Dec 2016, at 21:29, Roy A. Gilmore  wrote:
>>
>> Hi,
>>
>> I have a keypair that was initially generated with the defaults, so the
>> signing key also has the authenticate capability enabled. I want to add
>> a separate authentication subkey for use with an OpenPGP smartcard. Is
>> there any way to turn the authenticate capability off on the signing
>> key? It doesn't sound like it should be that difficult, but I've
>> searched using several different search terms, and I can't seem to find
>> a way to do this.
>>
>> Roy A. Gilmore
>>
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

Re: Toggle the authenticate capability

[Andrew Gallagher]

Hi Roy,

You normally don't need to remove the A capability from a signing key. By 
default, gnupg will use the most recently created valid subkey with the 
appropriate capability, so all you need to do is create a new A subkey and it 
will be used in preference to the old one. Mathematically, authentication is 
just a special case of signing, so having both S and A on a subkey does not 
introduce extra vulnerabilities (that we know of). 

It is technically possible to change the capability flags on any key, but you 
can't do it with a vanilla version of the software. There is a patch somewhere 
in the archives of this list but I would recommend against it. The only use 
case where it would be necessary to remove a capability flag would be if you 
had created an encryption key that also had S or A capability - but it's almost 
impossible to do it by accident and in such cases it's safer to revoke the key 
and start again.

Andrew Gallagher

> On 4 Dec 2016, at 21:29, Roy A. Gilmore  wrote:
> 
> Hi,
> 
> I have a keypair that was initially generated with the defaults, so the
> signing key also has the authenticate capability enabled. I want to add
> a separate authentication subkey for use with an OpenPGP smartcard. Is
> there any way to turn the authenticate capability off on the signing
> key? It doesn't sound like it should be that difficult, but I've
> searched using several different search terms, and I can't seem to find
> a way to do this.
> 
> Roy A. Gilmore
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


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

Toggle the authenticate capability

[Roy A. Gilmore]

Hi,

I have a keypair that was initially generated with the defaults, so the
signing key also has the authenticate capability enabled. I want to add
a separate authentication subkey for use with an OpenPGP smartcard. Is
there any way to turn the authenticate capability off on the signing
key? It doesn't sound like it should be that difficult, but I've
searched using several different search terms, and I can't seem to find
a way to do this.

Roy A. Gilmore

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

Re: Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing wrote:
>On 25/11/16 00:03, Carola Grunwald wrote:

>I think it would be better to implement the proxy on the client machine,
>instead of on a server machine. That way, all secrets stay on the client
>machine, and you could still use regular e-mail clients, just with an
>IMAP server at the localhost. This seems *so* much better than a server
>which can decrypt all client data! But let's take for granted that you
>want to do it as you want to do it, on a server.

You can do it either way. For several years now I myself run the proxy
server on my laptop computer, holding a few dozen nyms for different
purposes.

>
>I doubt you would run into any trouble just using a separate homedir per
>user account. I don't think agents take a lot of resources. When the
>user logs out, you make the agent quit as well. You could remove its
>socket; it will notice and quit within a short while. There's also the
>Assuan command KILLAGENT which does what it says on the tin. I don't
>know what interface to GnuPG you were planning to use, but I would
>strongly suggest GPGME; it's the official way of programmatically using
>GnuPG. That said, I don't know if GPGME offers a way to issue the
>KILLAGENT command.

It's not about planning, the proxy system is in use for years.

I started the project in 2006, for a short time with PGP 6.x DLLs, then
moved to GnuPG 1.4, which, apart from the missing --faked-system-time
option still works great, very reliable, extremely stable. Three months
ago I thought it was time to adapt it to GnuPG 2.1, and the problems
began. Just at the moment I have seven (!) gpg-agent.exe entries sharing
the same HomeDir listed in the Windows Task-Manager, six of them frozen,
one hopefully still alive. The system is up now for no more than 48
hours. You can't run a server this way. Users ask what's going on. I'm
in trouble, seriously considering to return to 1.4.

I don't use the GPGME interface, rather call gpg.exe directly. I don't
think it makes any difference concerning performance. On program
shutdown I terminate gpg-agent.exe based on its ProcessID.

>
>A separate homedir per user means you get the separation you wanted.

So first of all I have to give every keyring its separate homedir to
avoid the side effect of unintentional secret key deletion across
keyrings, and to address the passphrase caching flaw I even have to keep
each single secret key isolated in its own directory.

>
>I don't see the purpose of using the password of the user account for
>encrypting the private key, though. It doesn't seem to add security and
>does seem to add problems. If you're worried about seizure of the data
>at rest, you could use a single server-wide passphrase to encrypt all
>private keys used by GnuPG. You could use disk encryption, that seems
>like an easy way out and would protect other sensitive data as well. Or
>you could use a specialized pinentry implementation, that always returns
>the same passphrase, which could be seeded when the server boots up.
>Pinentries are easy to write.

Full ACK. User accounts usually are LAN accounts, not that much under
attack as the encrypted message, which needs a strong key and
passphrase.

>
>If you really want to cut down on the number of running agents, I'd
>first discuss this with the GnuPG developers. Is the agent well suited
>to serve dozens, hundreds of private keys? If the design never accounted
>for this possiblity, it might be horribly inefficient or expose
>unexpected issues.

Works fine with 1.4.

>
>(You could take the middle road and serve, say, 32 clients per agent.)
>
>However, that still presents a serious issue with private key ownership,
>both in the case of multiple recipients and with --throw-keyids, which
>you would not have with an agent per user.
>
>GPGME tells you which private key was used to decrypt the message.
>However, if there are multiple recipients on the same proxy and they
>share an agent, GnuPG will only use the first one that succeeds. If your
>proxy software would inspect the recipient and only allow the owner of
>the indicated key to read the message, the other recipients wouldn't be
>able to read the message, because the agent never needed to use their
>key in the first place. Argh.
>
>For hidden recipients, it would be a serious resource hog to try all
>keys, and would additionally have the same problem with multiple recipients.
>
>An option --only-try-secret  would solve both (your software
>would know which to try for a given nym account), but such an option is
>not available. You could try to make the case that such an option would
>be a good idea to implement. It would serve more scenarios than just
>yours. For instance, people with smartcards could use it when a message
>is also encrypted to an on-disk key, when they can't or don't want to
>insert their smartcard. And if somebody knows which key is the hidden
>recipient, but has multiple secret keys, it would save them declining
>all the dialogs for the keys that aren't 

Hybrid keysigning party, your opinion?

[Peter Lebbing]

Hi all,

In just a few weeks, the 33C3 will be held in Hamburg, the 33th Chaos
Communication Congress organized by the Chaos Computer Club. I intend to
organize a keysigning party, just because they are fun.

I am asking for your thoughts on a variant of the organization of the
keysigning party. I'll explain my reasoning and intentions, and I would
like to know if you think I forgot to think of something important. Is
there a way a malicious party could get people to sign the wrong UID,
because I didn't think of that way? I'm not interested in ways people
could cheat at the usual "informal" keysigning party model, with
exchanging paper keyslips. This is because this would be my fallback
model, if the proposed model doesn't work out. So I'm only interested in
cases where the proposed model introduces extra issues compared to the
informal exchanging keyslips model.

There are several methods to do a keysigning party. One of them is the
"Sassaman efficient" version. It requires preparation, and this
preparation must be done in time that everybody can print out their copy
of the list. With a congress spanning several days, this means the
preparation should probably be done before the congress, since in
general you shouldn't print your list on a printer you don't completely
trust, and most people don't bring a printer (I did! :).

Now Sassaman efficient has a very big issue. There will always be people
who also wish to attend the keysigning party who did not participate in
the preparations. As far as I can see, these people could just
participate as equals with printed out keyslips to hand out to the other
people. However, I've seen multiple times that these late guests were
treated as second-class participants. I've actually seen them delegated
to the corridor outside the room where the party was held, told to wait
until the others were done! I never got a chance to exchange
fingerprints with these people because of course they left a long time
before the party inside was done. I can't imagine this was a very
pleasant experience for them.

The common denominator of the Sassaman efficient and the informal method
is that you form a line of people that folds in on itself. Now, as I see
it, you can just form a line beginning with the people on the list and
ending with the people who joined late.[1] With the people on the list,
you only check ID's and place a checkmark on your list when satisfied.
Once you get to the part with the late attendants[2], you instead
exchange key slips. I don't see why the people who are not on the list
should not be allowed to be in the same line, yet it is what I've seen
happening.

Anyway, so, Sassaman efficient has a major problem. It also has
advantages. At the bottom line, there is only one advantage I find relevant.

With Sassaman efficient, you actually only have to check one SHA256 hash
and your own fingerprint.

No matter how many attendees, you don't have to check anyone else's
fingerprint manually. Just the two!

This is because you have a SHA256-protected list of fingerprints already
in digital form; no need to compare to printed out digits on paper. All
attendees who participated in the preparation have gotten a text file
which contains all fingerprints of the participants, and they print out
this list as well as compute its checksum. Additionally, they check that
their *own* fingerprint in this list is correct. At the event, the
SHA256 checksum of the text file is read aloud and everybody compares it
to the checksum on their piece of paper. Next, each participant on the
list is asked in turn whether their fingerprint checked out.[3]

After the event, you'll go home and sign keys, using the verified text
file that has the correct SHA256 checksum. Now when you use CA - Fire
and Forget, caff, all you have to check are the UID's you are signing.
The SHA256 checksum has already ascertained that the fingerprints in the
text file are correct; anyone altering a fingerprint will necessarily
alter the checksum of the file. And caff checks the fingerprint for you
from the known-correct file! As long as all participants verified that
their own fingerprint is correct in the file with the correct SHA256
hash, all fingerprints have been verified already.

It will still be *very* important to verify the UID's manually. What if
the official list had a key with fingerprint X and UID
, but once you download the key with fingerprint X,
there's instead an UID ? You need to check that you
only sign UID's carrying Alice's name that you verified from her
passport or similar thing.

I quite like it that I don't have to verify dozens of fingerprints
manually; I'd like to keep the list if possible. So can we improve on
the party where there is a line of both people on the list and people
with keyslips? I think we can.

I think ideally, the participants who only joined after the preparations
should also be able to use the list for the people that are on it, 

Re: Proof for a creation date

[Stephan Beck]

MFPA:
> 
> 
> On Friday 2 December 2016 at 1:46:00 PM, in
> , Stephan Beck
> wrote:-
> 
> 
> 
>> gpg's signature timestamp (on a given file) would NOT
>> be a real proof of
>> a document being allegedly signed at that specific
>> date or (prior to a
>> determined date).
> 
> 
> Maybe use a digital timestamping service, such as
> ?
> 
> Or publish an encrypted (or not) copy in the small ads of a newspaper.
> 
> 
> 
Yes, that's it, publish it in the papers. Everyone would agree on that
this would be a "real" proof, i.e. one that would be accepted in the
courtroom.
Luckily, communicating (as via email, as among humans) you do not always
need to have that degree of certainty. :-)

Cheers

Stephan





0x4218732B.asc
Description: application/pgp-keys


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

Re: Still trying to troubleshoot --refresh-keys error

[Stephan Beck]

Anthony Papillion:
> For the last few weeks, I've talked about how, when I try to refresh the
> keys on my ring, I get an error from GnuPG. Today, I noticed a message
> that I hadn't noticed before and I strongly suspect this might be the
> cause of the problem I'm having.
> 
> When I issued the
> 
> gpg2 --refresh-keys
> 
> command, GnuPG connected to the SKS pool and sent a request for all the
> keys on my ring. At the end of the refresh attempt, I saw the following:
> 
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0
> gpg: keyserver communications error: keyserver helper internal error
> gpg: keyserver communications error: General error
> gpg: keyserver refresh failed: General error
> 
> IIRC, Stephen mentioned something about the helper program the last time
> I posted. This seems to confirm that.  However, since it's not giving me
> much information, I can't really troubleshoot further.
> 
> This is GnuPG 2.0.3 (GpG4Win 2.3.3) on Windows 10.  This issue DOES NOT
> happen on Linux.
> 
> Can anyone offer a bit of insight?

Ah, you're using gpg4win! So you already do have activated Kleopatra's
log files following instructions given in chapter 23.1 of the Gpg4win
Compendium?

Cheers

Stephan



0x4218732B.asc
Description: application/pgp-keys


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