Re: NXDOMAIN for hkps.pool.sks-keyservers.net
On 14.01.2020 22:39, wangqr via Gnupg-users wrote: > GnuPG uses hkps://hkps.pool.sks-keyservers.net as the default dirmnger > key server. But this domain does not exist. From > https://sks-keyservers.net/status/ I see no server in the pool supports > hkps. I wonder if this is the reason for the non-existence of the domain. > > I understand that user can always use --keyserver option to specify a > working key server. I'm just asking if we should change the default > value, if it is not working anymore. > Right.. there was an outage tonight affecting the hkps pool due to expiry of the CRL -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: libgcrypt license
On 22.10.2019 20:50, Werner Koch via Gnupg-users wrote: > There is no real reason > for this and we could change the license if that really makes a > difference for you. It would help me as a downstream packager at least; to the extent that otherwise we'll have to update license acceptance information in the package. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 22:45, Werner Koch wrote: > On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said: > >> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. >> Details need to be discussed, but it would be an optional solution, that > > Given that TB already has smartcard support it would be easy if the new > code just makes use of that code. Of course the code then needs to > touch the NSS part of Mozilla and can't just go with RNP. That would be > a more integrated solution than any other hack. > > Right, separate software will be required but that is the usual case > with smartcards. For example Scute can be used to provide card services > via GnuPG (and also allow for on-disk GnuPG. Note that GnuPG 2.3 will > be much more flexible in regard to smartcard use and how it can interact > with TB via Scute. Scute might very well be a good alternative to reach out to, but I'm not too optimistic regarding the likelihood of getting anything related to OpenPGP directly into NSS, hence expecting anything that requires development needs to be done through other vectors. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Future OpenPGP Support in Thunderbird
On 14.10.2019 18:54, Juergen Bruckner via Gnupg-users wrote: > Hello to all, > > well it's a good thing, that openPGP shall be included to TB directly. > > But ... as the Mozilla wiki [1] states in the FAQ-Section the following: > > > Q: Will OpenPGP cards be supported for private key storage ? > > A: Probably not, because we don't use the GnuPG software that's usually >required to access OpenPGP smartcards. I agree OpenPGP smartcard/token support is a must have, and brought this up during this during this weekend's OpenPGP summit; please see the [notes] section "Workshop: Thunderbird & OpenPGP" for some of the discussion, specifically """ Although RNP doesn't support smartcards currently, a potential solution was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. Details need to be discussed, but it would be an optional solution, that only works if the user has installed software (scd etc.) in addition to Thunderbird. How would this work? GnuPG as an optional dependency? Outsourcing smartcard handling to scdaemon (scd), which is available cross-platform through Unix socket or TCP/IP (windows) with usual user system protection? Or... extend the RNP library to talk to scd? Needs discussion and contributors, but that should wait until we're certain what library TB will use. """ References: [notes] https://wiki.gnupg.org/OpenPGPEmailSummit201910Notes -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What is the practical strength of DSA1024/Elgamal2048 (former GnuPG default)?
On 30.08.2019 01:02, Brian Minton wrote: > On Thu, Apr 25, 2019 at 11:19:15AM +0200, Kristian Fiskerstrand wrote: >> On 4/25/19 9:20 AM, Bernhard Reiter wrote: >>> Wikipedia points out a strong sensitivity of the algorithm to the quality >>> of >>> random number generators and that implementations could deliberately leak >>> information in the signature [3]. This alone probably is a reason to switch >>> keys. >> This isn't really a major point given rfc6979 ( >> https://tools.ietf.org/html/rfc6979 ): Deterministic Usage of the >> Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature >> Algorithm (ECDSA) >> > Does GnuPG use deterministic DSA / ECDSA? > Yes (at least for modern versions, iirc it was introduced in libgcrypt 1.6.0, but it has been used for 6 or so years) -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key"
On 12.08.2019 19:09, vedaal via Gnupg-users wrote: > Can this really be done? > > (Does not matter so much to me personally, as I grew up with v3 > keys, and even when using a V4 key, I don't generate a subkey, but > allow all the functions (sign, encrypt. certify) to be done with the > master key). > > Does matter a lot if I can't trust the subkey of someone whom I want > to encrypt to. > How real is this threat, and is it any threat at all, if simply > binding the subkey to a different master key, won't allow for anyone > else other than the 'real' owner, to decrypt messages encrypted to > that subkey? As you correctly point out its really not that relevant for encryption subkeys. It does have security implementations for signing subkeys; see [cross-certification section] for some details on that. References: [cross-certification section] https://gnupg.org/faq/subkey-cross-certify.html -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
On 7/3/19 3:20 PM, Andrew Gallagher wrote: > On 03/07/2019 13:45, Kristian Fiskerstrand wrote: >> There are various ways this can be used for other >> attack vectors as well, so they are mostly just ignored. > > Any of those attack vectors applicable to keyservers attempting to > refresh from it? > potential DoS vector? (probably not the most efficient one, but...) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New keyserver at keys.openpgp.org - what's your take?
On 7/3/19 10:17 AM, Andrew Gallagher wrote: > On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote: >> Beware: the HKP schema of paths is used with the keyserver in that >> field, in GnuPG at least. > OK, but what's the failure mode? If it's graceful, then we haven't lost > much. So long as key updates fall back to a keyserver somewhere it > should be transparent. > > This does of course need thorough testing, as not all clients will have > the same failure modes. > at least one issue that has been pointed out historically about relying on specification of TPK URI for refresh is privacy issues related to callbacks and/or DoS. There are various ways this can be used for other attack vectors as well, so they are mostly just ignored. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What is the practical strength of DSA1024/Elgamal2048 (former GnuPG default)?
On 4/25/19 9:20 AM, Bernhard Reiter wrote: > Wikipedia points out a strong sensitivity of the algorithm to the quality of > random number generators and that implementations could deliberately leak > information in the signature [3]. This alone probably is a reason to switch > keys. This isn't really a major point given rfc6979 ( https://tools.ietf.org/html/rfc6979 ): Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why Signing key part of Master key
On 2/24/19 8:34 PM, Farhan Khan via Gnupg-users wrote: > Hi all, > > I am still working on setting up the "perfect" setup. When I created the > master, it was [SC]. I > question, why is the signing key part of the master key? Why not have it be a > subkey? Almost > everywhere I looked, the two were a single key except this site > (http://openpgpblog.tumblr.com/post/219954494/photos-on-pgp-keys). In my own > tests the signing > functionality worked the same when they the signing key was a subkey versus a > part of the master. > > Are there any advantages of disadvantages either way? > > Thank you, its mostly a sensible default as people tend to keep key material on disk on online computers to begin with.. the benefits of a separate primary normally comes out in scenarios with stronger security requirement, at which point the manual interaction required to set it up isn't the biggest hurdle anyways, but actually keeping up with operational security is. (note, its not the SC capable primary that is the issue to begin with, but actually keeping it isolated, the primary will always be able to become signing-capable anyways by updating the flags on its self-signature) -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [openpgp-email] 4th OpenPGP Email Summit - Update
> On 17 Oct 2018, at 14:26, Sandro Knau� wrote: > > Hey, > >> - Friday evening: we will meet at the Winery (Trois Tilleuls Street 1, 1170 >> – Brussels, www.winery.be ). People from Mailfence will be there from >> 19:30, I will arrive a little later. I’ve arrived in brussels and checked into hotel so will leave soon to come and join as well.. will probably be there in 20-30 minutes. KF ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 9/7/18 9:19 PM, Daniel Kahn Gillmor wrote: > On Fri 2018-09-07 14:31:16 +0200, Kristian Fiskerstrand wrote: >> On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote: >>> I'm unable to replicate this. here's a transcript of my session, >>> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian >>> testing/unstable: >> >> which desktop manager / window manager? I can replicate on cleanly >> installed debian testing with Cinnamon selected during install. > > i wasn't testing on a full-blown desktop environment -- my test > environment was openbox, plus a typical dbus-user-session arrangement, > and a systemd --user manager connected to the session. (not that i > think any of that is likely to matter for testing pinentry-qt itself). Well, none of my systems ever touches systemd, so should never say never when it comes to potential conflicts :) But in this case it seems like a broader issue that at least is present in xfce and cinnamon window managers when DISPLAY is not present. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 9/7/18 2:31 PM, Kristian Fiskerstrand wrote: > On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote: >> I'm unable to replicate this. here's a transcript of my session, >> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian >> testing/unstable: > > which desktop manager / window manager? I can replicate on cleanly > installed debian testing with Cinnamon selected during install. > Done some more testing on debian unstable, and it is similar to what we see in Gentoo; 1 Gnome: works 2 xfce: fails 3 KDE: works 4 Cinnamon: fails (the initial bug report prompting my interest was from xfce) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "In politics stupidity is not a handicap." (Napoleon Bonaparte) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote: > I'm unable to replicate this. here's a transcript of my session, > testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian > testing/unstable: which desktop manager / window manager? I can replicate on cleanly installed debian testing with Cinnamon selected during install. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you cannot convince them, confuse them" (Harry S Truman) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 9/5/18 9:39 AM, Kristian Fiskerstrand wrote: > without DISPLAY env var, qt version automatically falls back to curses > variant despite the argument Wrote too quickly there; This is actually wrong, it never actually falls back to curses, it just fails. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Quidquid latine dictum sit, altum videtur. Anything said in Latin sounds profound signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 9/4/18 6:10 PM, Daniel Kahn Gillmor wrote: > or do you mean something else? without DISPLAY env var, qt version automatically falls back to curses variant despite the argument kristianf@ares ~ $ unset DISPLAY kristianf@ares ~ $ /usr/bin/pinentry-qt4 --display :0 (pinentry-qt4:6370): Gtk-WARNING **: 09:31:41.576: cannot open display: kristianf@ares ~ $ export DISPLAY=:0 kristianf@ares ~ $ /usr/bin/pinentry-qt4 --display :0 OK Pleased to meet you throwing in a simple wrapper around pinentry, #!/bin/bash env > /tmp/pinentry-log.txt echo "$@" >> /tmp/pinentry-log.txt exec /usr/bin/pinentry-qt "$@" and diffing the log between keep-display, shows that the difference is +DISPLAY=:0 btw, you say started, but this should also be updated when issuing UPDATESTARTUPTTY shouldn't it? In any case, it solved the issue for the user and I replicated it also on pinentry 1.1.0 on gnupg 2.2.10 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Credo quia absurdum I believe it because it is absurd signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 08/29/2018 12:41 AM, Kristian Fiskerstrand wrote:
> On 08/28/2018 08:22 PM, Daniel Kahn Gillmor wrote:
>> On Sat 2018-08-25 08:18:48 +0200, sunri...@gmx.com wrote:
>>> Hi all, since some days I'm having an issue with pinentry, I've set the
>>> default agent as pinentry-qt4
>>> from update-alternatives (I've also tried pinentry-qt and pinentry-gnome)
>>> but when I run gpg --decrypt file
>>> it's always falling on the cli for prompting the password. In
>>> .gnupg/gpg-agent.conf as the first line I have
>>> pinentry-program /usr/bin/pinentry-qt4 as well, but I don't get why it's
>>> ignoring it.
>>> There's a way to debug what's going on?
>>
>> can you give a little bit more information about your system (OS,
>> version, version of gpg, version of pinentry, etc), and how you're
>> accessing it (e.g. via ssh, via a graphical environment, etc)?
>>
>> have you terminated your gpg-agent program ("gpgconf --kill gpg-agent")
>> after updating your settings in ~/.gnupg/gpg-agent.conf so that the
>> settings would take effect?
>
> Not sure if it is related, but I'm currently also investigating an issue
> with the qt pinentry for Gentoo installations. no similar issues for the
> other ones.. I'm able to reproduce failures with the auto-spawned
> gpg-agent though, that doesn't materialize when calling the pinentry
> application directly in an environment.
>
> In this case the gtk2 pinentry works as expected though... but something
> is possibly off with the handling of DISPLAY (as far as I've gotten in
> my debugging that is the only diff in the env vars between the direct
> invocation and the bash propmpted one, it might not be ultimately relevant)
>
Just to have it mentioned, turned out this was an issue with missing
keep-display in gpg-agent.conf, without this the Qt4/5 pinentry fail
(although I've been told it is not an issue in KDE environment).
gpg-agent without keep-display still seems to send display as argument
in --display :0 style, but this does not seem to be honored.
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"Strength lies in differences, not in similarities."
(Stephen Covey)
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Issue with pinentry GUI agent
On 08/28/2018 08:22 PM, Daniel Kahn Gillmor wrote:
> On Sat 2018-08-25 08:18:48 +0200, sunri...@gmx.com wrote:
>> Hi all, since some days I'm having an issue with pinentry, I've set the
>> default agent as pinentry-qt4
>> from update-alternatives (I've also tried pinentry-qt and pinentry-gnome)
>> but when I run gpg --decrypt file
>> it's always falling on the cli for prompting the password. In
>> .gnupg/gpg-agent.conf as the first line I have
>> pinentry-program /usr/bin/pinentry-qt4 as well, but I don't get why it's
>> ignoring it.
>> There's a way to debug what's going on?
>
> can you give a little bit more information about your system (OS,
> version, version of gpg, version of pinentry, etc), and how you're
> accessing it (e.g. via ssh, via a graphical environment, etc)?
>
> have you terminated your gpg-agent program ("gpgconf --kill gpg-agent")
> after updating your settings in ~/.gnupg/gpg-agent.conf so that the
> settings would take effect?
Not sure if it is related, but I'm currently also investigating an issue
with the qt pinentry for Gentoo installations. no similar issues for the
other ones.. I'm able to reproduce failures with the auto-spawned
gpg-agent though, that doesn't materialize when calling the pinentry
application directly in an environment.
In this case the gtk2 pinentry works as expected though... but something
is possibly off with the handling of DISPLAY (as far as I've gotten in
my debugging that is the only diff in the env vars between the direct
invocation and the bash propmpted one, it might not be ultimately relevant)
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"The laws of Australia prevail in Australia, I can assure you of that.
The laws of mathematics are very commendable, but the only laws that
applies in Australia is the law of Australia."
(Malcolm Turnbull, Prime Minister of Australia).
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.gnupg.net is blocked by Palo Alto Wildfire
On 08/10/2018 02:20 AM, Tim Perkins wrote: > I did observe that at least one of the pool members seems to not be > configured properly (if I do a ‘curl -k -H 'Host: > http-keys.gnupg.net' https://37.191.226.104’ it displays a busted > Matomo page). This is actually my server, but why would it respond to such a host on port 80? it responds to keys.gnupg.net on 11371 (default HKP port) as it should. Fut for HKPS/HTTPS there aren't any expectations for certificates for the SNI etc, hkps.pool.sks-keyservers.net is used for that by default. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Audaces fortuna iuvat Fortune favors the brave signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Upgrading 2.0.20 to 2.2.24
On 06/18/2018 03:06 PM, fe...@crowfix.com wrote: > Says it imported the secret keys, but doesn't show them. Any chance they are expired? Try playing with --list-options, in particular the show-unusable-* variants Are they listed with --list-keys ? Try importing the public keyring separately, in case there is sync issue and that has been updated without secring being updated. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Excellence is not a singular act but a habit. You are what you do repeatedly." (Shaquille O'Neal) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Web of Trust and validation of keys
On 05/12/2018 06:09 PM, franek.wiertara wrote: > Hi > > I am sorry if you find my comment a little less understanding. English > is not my first language. Hopefully, I have described my problem clearly > enough :) > > I have two problems. > 1. I am not entirely sure what exactly marginally valid keys do and when > they become marginally valid. I thought keys would either be valid or not! marginally trusted isn't valid, the threshold is set using --marginals-needed n Number of marginally trusted users to introduce a new key signer (defaults to 3) i.e you need 3 signatures by default on a keyblock/uid for it to be treated as valid, if you don't have that it isn't. > 2. I am also not fully confident in understanding Web of Trust. I have > just got some bits today :) > > I realised, after reading the The GNU Privacy Handbook, if a key becomes > valid due to the Web of Trust or signed personally, it can "participate" > in validation of next keys, depending on my trust. What exactly happen > if a key is marginally valid? marginally valid -> not valid -> trust level doesn't matter (excluding ultimate trust that isn't to be used for other people's keys in these scenarios anyways) > > I also provided some scenarios based on the website and an example of a > network: > > .---> Blake ---. > / \ > Alice --- ---> Chloe ---> Elena ---> Geoff > \ / \ > *---> Dharma --* \ > \ \ > *--->*---> Francis. > > Let's say Blake's and Dharma's keys are always valid because they are > signed by Alice. In case any of those keys are fully trusted, Chloe's > and Francis' keys will be fully validated. If Both Blake's and Dharma's > keys are marginally trusted, Chloe's key will be still fully validated > but Franci's will only be marginally validated. For Chloe's key to be validated in this scenario you'd require a direct path from Alice since there isn't 3 marginally trusted signatories (unless you introduce one from outside the schema). > > Now, when Chloe's key is fully valid, what happen to Elenaa's key? Will > it become a fully or marginally valid key? I think it depends on whether > I fully or marginally trust Chloe's key. Presuming Chloe's key is valid, yes, what happens down the chain depends on the trust level of this keyblock. > > There is lot of situations when keys can become marginally valid. I am > guessing, marginal validation sort of blocks a further validation on the > path. I am wondering why we are not simply to say that a key can be Blocks, how? > either valid or not? What am I missing? What is the consequence of a > marginal validation? It has the potential of becoming valid if signed by more marginally trusted people (or directly by someone with full trust) > > Thanks > > PS. For the example, I followed the assumptions from the website: "... > two marginally-trusted keys or one fully-trusted key is needed to > validate another key. The maximum path length is three." > > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you are successful, you may win false friends and true enemies. Succeed anyway." (Mother Teresa) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pinentry problems
On 04/17/2018 10:48 PM, Paul H. Hentze wrote:
>
>
> On 17.04.2018 17:48, Daniel Kahn Gillmor wrote:
>> On Tue 2018-04-17 11:11:22 +0200, Kristian Fiskerstrand wrote:
>>> On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
>>>> Actually those commands
>>>>> find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>>>>> find ~/.gnupg -type f -exec chown 0600 '{}' ';'
>>>> didn't work.
>>>> The terminal responded: "chown: The owner of data XXX is going to be
>>>> changed. This is not allowed." and it did that with every file in that
>>>> folder.
>>>
>>> Seems like a mixup of chmod and chown there, although make sure the user
>>> is correct as well.
>>
>> yep, sorry, that should have been "chmod", not "chown" -- my mistake!
>>
>> --dkg
>>
> Ok, it did work with the chmod command.
> Have you got any further ideas?
remember to restart gpg-agent after doing that, gpgconf --kill gpg-agent
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
Acta est fabula
So ends the story
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgme_op_verify regression with gnupg 2.2.6?
On 04/16/2018 02:14 PM, Werner Koch wrote: >> Could gnupg 2.2.7 detect if gpgme is installed at all and if it is, >> make sure it's at least version 1.10.1 / 1.11.0? > :-) - No. Speaking for Gentoo we can do this on distribution level by adding a blocker on the lower version if needed. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "History doesn't repeat itself, but it does rhyme." (Mark Twain) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pinentry problems
On 04/17/2018 10:52 AM, Paul H. Hentze wrote:
> Actually those commands
>> find ~/.gnupg -type d -exec chown 0700 '{}' ';'
>> find ~/.gnupg -type f -exec chown 0600 '{}' ';'
> didn't work.
> The terminal responded: "chown: The owner of data XXX is going to be
> changed. This is not allowed." and it did that with every file in that
> folder.
Seems like a mixup of chmod and chown there, although make sure the user
is correct as well.
--
----
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"History repeats itself; historians repeat each other"
(Philip Guedalla)
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: having trouble checking the signature of a downloaded file
On 02/22/2018 11:13 PM, Kristian Fiskerstrand wrote: > On 02/22/2018 11:03 PM, Henry wrote: >> 2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand >> <kristian.fiskerstr...@sumptuouscapital.com>: >>> On 02/21/2018 11:53 AM, Peter Lebbing wrote: >>> Touché :) Indeed, didn't notice it was an old file/signature , then >>> gnupg 1.4 is the recommended official suggestion presuming established >>> validity of key material etc etc. >> gpg (GnuPG) 1.4.22 does give more information, but no success; see >> below. May I assume that nothing >> can be done other than to request the author to remedy the situation? >> Thanks all. >> > --allow-weak-digest-algos > Signatures made with known-weak digest algorithms are normally > allows the verification of signatures made with such weak algorithms. > MD5 is the only digest algorithm considered weak by default. > That was truncated; .B --allow-weak-digest-algos Signatures made with known-weak digest algorithms are normally rejected with an ``invalid digest algorithm'' message. This option allows the verification of signatures made with such weak algorithms. MD5 is the only digest algorithm considered weak by default. See also \fB--weak-digest\fR to reject other digest algorithms. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Varitatio delectat Change pleases signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: having trouble checking the signature of a downloaded file
On 02/22/2018 11:03 PM, Henry wrote: > 2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand > <kristian.fiskerstr...@sumptuouscapital.com>: >> On 02/21/2018 11:53 AM, Peter Lebbing wrote: >> Touché :) Indeed, didn't notice it was an old file/signature , then >> gnupg 1.4 is the recommended official suggestion presuming established >> validity of key material etc etc. > > gpg (GnuPG) 1.4.22 does give more information, but no success; see > below. May I assume that nothing > can be done other than to request the author to remedy the situation? > Thanks all. > --allow-weak-digest-algos Signatures made with known-weak digest algorithms are normally allows the verification of signatures made with such weak algorithms. MD5 is the only digest algorithm considered weak by default. > Henry > > result of using gnupg 1.4: > % gpg1 --import D5327CB9.key > gpg: key D5327CB9: "author <aut...@xxx.org>" not changed > gpg: Note: signatures using the MD5 algorithm are rejected > gpg: key D5327CB9: no valid user IDs > gpg: this may be caused by a missing self-signature > gpg: Total number processed: 2 > gpg: w/o user IDs: 1 > gpg: unchanged: 1 > > % gpg1 --verify ***6.4.tar.gz.sig ***6.4.tar.gz > gpg: Signature made Tue May 4 23:03:11 2004 JST using RSA key ID D5327CB9 > gpg: Can't check signature: public key not found > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The laws of Australia prevail in Australia, I can assure you of that. The laws of mathematics are very commendable, but the only laws that applies in Australia is the law of Australia." (Malcolm Turnbull, Prime Minister of Australia). signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: having trouble checking the signature of a downloaded file
On 02/21/2018 11:53 AM, Peter Lebbing wrote: > On 21/02/18 10:48, Kristian Fiskerstrand wrote: >>>gpg: Signature made Tue May 4 23:03:11 2004 JST >> [...] >> >> The author should sign the package using a more modern and secure keyblock. > Note that not the key, but the /signature/ is made 14 years ago. So > we're talking about verifying the integrity of a really old file. The > author might not be available anymore or willing to expend any effort. Touché :) Indeed, didn't notice it was an old file/signature , then gnupg 1.4 is the recommended official suggestion presuming established validity of key material etc etc. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Dura necessitas Necessity is harsh signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: having trouble checking the signature of a downloaded file
On 02/21/2018 10:37 AM, Henry wrote: > I downloaded a tarball ***6.4.tar.gz, it's signature file > ***6.4.tar.gz.sig, and the author's public key **.pgp from a > well-known site. > > I imported the public key: `gpg --import **.pgp`. > For some reason, two keys were "skipped": >gpg: key 0C0B590E80CA15A7: 2 signatures not checked due to missing keys >gpg: key 0C0B590E80CA15A7: "Author's Name <aut...@xx.org> >gpg: Total number processed: 3 >gpg: skipped PGP-2 keys: 2 ^ note this and see below >gpg: unchanged: 1 > > I tried to verify the downloaded file, but the check failed: > `gpg --verify ***6.4.tar.gz.sig ***6.4.tar.gz` >gpg: Signature made Tue May 4 23:03:11 2004 JST >gpg:using RSA key DC80F2A6D5327CB9 >gpg: Can't check signature: No public key > The above RSA key is in v3 format which is not supported in GnuPG >=2.1 for security reasons, hence not imported, and hence the output you see. > This is the first time for this to happen, so I have no idea what I > might be doing > wrong. Any help or suggestions much appreciated. TIA The author should sign the package using a more modern and secure keyblock. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aut disce aut discede Either learn or leave signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]
On 02/20/2018 01:18 PM, Dashamir Hoxha wrote: > If anybody is willing to give a try to any of these solutions I would > like to help. I would be generally cautious for both approaches without proper support in the surrounding infrastructure. In particular an upgrade to a depending library would need to automatically cause a rebuild of the container in the case of a security upgrade when such embedding happens, which is generally a bad thing unless you have a large scale deployment and defined QA processes for terminating and replacing containers with new deployments regularly. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Manus manum lavat One hand washes the other signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can't import public key
On 02/03/2018 04:15 PM, Pijus Kar wrote: > Is it something for the version incompatibility or in the key? As far as I can see the keyblock referenced is DSA2, which is specified in FIPS-186-3 from 2009, and you're using a gnupg version from 2002. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Knowing is not enough; we must apply. Willing is not enough; we must do." (Johann Wolfgang von Goethe) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[OT] Re: failed to convert unprotected openpgp key: Checksum error
On 01/22/2018 08:33 AM, Werner Koch wrote: > That is an acceptable user-id. I would have used a dot as delimiter but > that is a personal taste. Dot is a permitted part of username in POSIX though, while : is not :) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Don't be afraid to go out on a limb. That's where the fruit is." (H. Jackson Browne) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg-2.2.4: how to deal with failed tests
On 01/17/2018 07:50 AM, Henry wrote: > I finally got gnugp2 built without any fatal errors. > Most of the tests passed, but the following tests failed: > tests/openpgp/issue2346.scm > tests/openpgp/ssh-export.scm > tests/openpgp/export.scm > tests/openpgp/ecc.scm > tests/openpgp/armor.scm > > I am not hip on using a binary that fails its tests. > Grateful for any advice on how to configure/build gnupg2 so that > it passes all its tests. > Some observations on test * in Gentoo we've had to shorten the socket path length, max is 108 chars of which 42 is used by gpgscm by default. * Parallel tests fail if building without tofu support * sparc architecture has a failure in tests/openpgp/quick-key-manipulation.scm:219 on assert -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote: >> thanks for this post Daniel, my primary question would be what advantage >> is gained by this verification being done by an arbitrary third party >> rather by a trusted client running locally, which is the current modus >> operandus. Any keyserver action doing this would just shift >> responsibilities to a third party for something better served (and >> already happens) locally. > > the advantage is spam-abatement -- the keyservers have to keep track of > what is attached to each blob they transport/persist. if all signatures > that they transport for a given blob are cryptographically certified, > then only the original uploader of that blob can make assertions about > it; other people can't spam the blob to make it untransportable. All the certificates used in trollwot are technically correct. You can still use the same mechanisms as you control the other key material, and can use intentionally weak key material if wanting to speed things up. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]
On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote: > The keyserver network (or some future variant of it) can of course play > a role in parallel to any or all of these. for example, keyservers are > particularly well-situated to offer key revocation, updates to expiry, > and subkey rotation, none of which would necessarily involve names or > e-mail addresses. > > It would be interesting to see a network of keyserver operators that: > > (a) did cryptographic verification, and rejected packets that could not > be verified (also: required cryptographic verifications of > cross-signatures for signing-capable subkeys) > > (b) rejected all User IDs and User Attributes and certifications over > those components > > (c) rejected all third-party certifications -- so data attached to a > given primary key is only accepted when certified by that primary > key. > thanks for this post Daniel, my primary question would be what advantage is gained by this verification being done by an arbitrary third party rather by a trusted client running locally, which is the current modus operandus. Any keyserver action doing this would just shift responsibilities to a third party for something better served (and already happens) locally. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Bene diagnoscitur, bene curatur Something that is well diagnosed can be cured well signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: DRM?
On 01/16/2018 10:33 PM, Matthias Mansfeld wrote: > On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote: > >> On 01/16/2018 07:50 PM, Andrew Gallagher wrote: >>> Agreed. I was thinking more along the lines of having some method of >>> causing signature vandalism to expire. >> They don't really constitute an issue either for security or privacy, >> though. > They DO, if unwanted or rashly made signatures on pubkeys disclose > connections between people, groups etc.. by "vandalism", I'm taking trollwot cases into account, which doesn't affect anything to the extent it is DoS-able. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Happiness in intelligent people is the rarest thing I know." (Ernest Hemingway) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Remove public key from keyserver
On 01/16/2018 11:40 AM, Stefan Claas wrote: > Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand: > >> On 01/15/2018 09:23 PM, Stefan Claas wrote: >>> No? I for one would like to be sure that i am the only person who >>> can upload my public key to a key server directory. >> This seems to be based on a misconception whereby you're attributing >> properties of a certificate authority to the keyservers. OpenPGP already >> has a method for certification from CAs, and that is by providing a >> signature on the appropriate UID on the public keyblock. As long as the >> signature is propagated on the keyserver network, these roles can be >> appropriately isolated and the decision of whether or not to trust a >> specific CA is left to the user performing the trust calculation, >> incidentally also allowing for signatures from multiple CAs. >> > I'm not sure what you are talking about, a language barrier from my > side,sorry. > > The CA in Germany (Governikus) i have used sends me my certified key > back to my > email address and does not publish my pub key on key servers. I'm not sure how to put it more clearly, but this seems to bring the discussion into very specific territory. OpenPGP as a specification handles this nicely, and whether a CA signature is published publicly or not doesn't change the modus operandus. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The best way to predict the future is to invent it" (Alan Kay) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Remove public key from keyserver
On 01/16/2018 08:37 PM, Stefan Claas wrote: >> I know, but keybase.io's goal is (or was, back when I tested it) to >> use those connections to somehow prove an identity. It is a neat >> idea for the facebook generation. Privacy is something different. > Agreed. But the word privacy would then also mean to me that > users who uploaded their public keys on key servers would not > reveal that they know each other as shown with their signatures, > which the classical WoT somehow requires, instead of using local sigs. > A distinction need to be made here, "know each other" actually means ever having confidence that the public keyblock belongs to that person. That doesn't imply a very deep relationship except for having met at one point to exchange information. You don't really attribute anything except possibly having looked at a governmental issued ID at some point. But yes, this comes back to security != privacy -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 qui tacet consentire videtur He who is silent is taken to agree signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: DRM?
On 01/16/2018 07:50 PM, Andrew Gallagher wrote: > Agreed. I was thinking more along the lines of having some method of > causing signature vandalism to expire. They don't really constitute an issue either for security or privacy, though. If looking at keyserver directly (which you really shouldn't do, your client will filter unknown keys and actually verify the rest) you will see all kinds of interesting things like the Christmas present of ["funny sks"] on my keyblock some years ago. But it doesn't constitute an *issue* when OpenPGP is used correctly. References: ["funny sks"] https://sks-keyservers.net/pks/lookup?op=vindex=0x94CBAFDD30345109561835AA0B7F8B60E3EDFAE3 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A committee is a group that keeps minutes and loses hours." (Milton Berle) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: DRM?
On 01/16/2018 07:17 PM, Leo Gaspard wrote: > That said, thanks for the link! Just curious, I never saw information > about this in enigmail, do you know whether it has been implemented yet? First and foremost you'd have to establish the robot-ca with an API of some sort. I'm not aware of any production rollout, although I believe a proof of concept was written based on it for a thesis. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A government that robs Peter to pay Paul can always depend on the support of Paul." (George Bernard Shaw) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: DRM?
On 01/16/2018 07:12 PM, Andrew Gallagher wrote: > On 16/01/18 17:19, Leo Gaspard wrote: >> “on 2018-04-01, please expose only the master key and its revocation >> certificate(s) to clients” > > IF you wanted to go this route, it would be easier for keyservers to > only serve the master key + revocation cert for *all* cases where a > revocation cert exists. What does it matter who signed a key that has > been revoked, or what IDs it used to be tied to? It's dead, throw it away. The important thing would actually be that the data is retained in the database, as that wouldn't break sync. Aside from that the keyservers would have to implement cryptography and verify that the revocation certificate is accurate, this is within the scope of feasibility, although wouldn't do anything one way or the other with regards to security. Whether it would help privacy is also a questionable matter, as the full data store is downloadable, so anyone can download it containing the data wanting to be hidden. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: DRM?
On 01/16/2018 06:19 PM, Leo Gaspard wrote: > Also, there are flaws with this approach (like after a private key > compromise, it would allow to prevent dissemination of the revocation > certificate) [1], but fixes like allowing the statement to be “on > 2018-04-01, please expose only the master key and its revocation > certificate(s) to clients” would likely handle this particular issue. > > All I'm saying is that a system like this one is not a silver bullet > solution, but may handle a few of the current complaints against the SKS > network? Not really (and that is ignoring disagreement with the complaints to begin with). One issue with the first statement "please allow to be on keyserver" is that it doesn't provide any verification that the email in UID (or just the name) is accurate, so most of the complains regarding occurrence of multiple matches for a search would not be honored, as you could anyways create multiple keyblocks with this property. To answer that request for feature, you need to make the keyserver a de-facto CA instead of separating the roles, and performing some ID verification at upload point, for email this might be a simple robot-signing, but email addresses changes over time, and a key might be relevant even after changing email providers to verify historical signatures etc. But for OpenPGP this isn't an issue to begin with. No keyblock should be used without first verifying the material, which historically is mostly done through fingerprint exchanges / key signing parties. If wanting to introduce a CA in the system, nothing is stopping you, and you will find some discussion on robo-signers etc e.g at [0], but it doesn't require any changes on the keyserver side, exactly because that is just a data store and distribution point without any other responsibility. Obviously the same goes for a TOFU model and WKD, which still can use the keyserver network as distribution point for updates of expirations/revocations/etc... References: [0] https://wiki.gnupg.org/OpenPGPEmailSummit201512/EmailValidation?action=AttachFile=get=EmailValidation20151207.pdf -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aut dosce, aut disce, aut discede Either teach, or study, or leave signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Remove public key from keyserver
On 01/15/2018 09:23 PM, Stefan Claas wrote: > No? I for one would like to be sure that i am the only person who > can upload my public key to a key server directory. This seems to be based on a misconception whereby you're attributing properties of a certificate authority to the keyservers. OpenPGP already has a method for certification from CAs, and that is by providing a signature on the appropriate UID on the public keyblock. As long as the signature is propagated on the keyserver network, these roles can be appropriately isolated and the decision of whether or not to trust a specific CA is left to the user performing the trust calculation, incidentally also allowing for signatures from multiple CAs. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Fabricando fit faber Practice makes perfect signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/06/2018 12:23 AM, Lou Wynn wrote: > On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote: >> On 01/05/2018 05:29 PM, Lou Wynn wrote: >>> The auditing key is certified by the root key and stays with the latter >>> in my design. Only the administrator can make policy to turn on/off >>> auditing, the client plugin takes corresponding actions automatically. >>> End users don't need to do anything, namely, using or not using the >>> auditing key to encrypt is completely transparent to end users. As a >>> result, there is no such issue of "forgetting to add it." >> Can you please elaborate on how this would be compatible with existing >> implementations of RFC4880? >> >> > If you asked about the auditing key compatibility, then it is probably > not the right question because RFC4880 does not talk about it at all. My > client plugin takes automatic action to encrypt a message with two keys > and sends to one receiver, which I don't think violates the RFC. The primary issue would be requiring everyone to use your client for the scheme to work. There are ways to handle the issues you propose within the existing ecosystem that won't have this requirement, and as such will be superior. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/05/2018 05:29 PM, Lou Wynn wrote: > On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote: >> There are easily scenarios where a customer forgets to add the "auditing >> key", making the data unavailable to the organization, in particular in >> context of loss of employee. >> > The auditing key is certified by the root key and stays with the latter > in my design. Only the administrator can make policy to turn on/off > auditing, the client plugin takes corresponding actions automatically. > End users don't need to do anything, namely, using or not using the > auditing key to encrypt is completely transparent to end users. As a > result, there is no such issue of "forgetting to add it." Can you please elaborate on how this would be compatible with existing implementations of RFC4880? -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock 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) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How do you find out the Keygrip of a v3 key?
On 01/05/2018 02:59 PM, MFPA wrote: > These old keys are not supported in GnuPG 2.1/2.2 and the > - --with-keygrip option is not valid in GnuPG 2.0 or 1.4. > > I have googled, but could not come up with a search term that produced > any relevant hits. I'd start with libgcrypt's gcry_pk_get_keygrip() -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Excellence is not a singular act but a habit. You are what you do repeatedly." (Shaquille O'Neal) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/05/2018 10:13 AM, Andrew Gallagher wrote: > >> On 5 Jan 2018, at 08:41, Lou Wynn <lewis...@gmail.com> wrote: >> >> The only need for an >> organization to access their data is decrypting the encrypted data, >> which is satisfied by the auditing key. > > The standard way of doing this without allowing for impersonation is escrow > of the encryption subkey only. This can be done by encrypting the E subkey to > the auditing key, the private key of which is presumably well controlled. The issue with that is that as long as the employee has private key for primary the individual can create new subkeys, and the primary will always have signing capability (if not always specified as usage flag). In most setups the employee won't need/shouldn't have the private key info for the primary for this (and a few other) reasons. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The journey of a thousand miles begins with one step." (Lao Tzu) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/05/2018 09:41 AM, Lou Wynn wrote: > On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote: >> Businesses have reasonable need to access their data, so they need to >> have access to his private keys, which contradicts "which >> is meant to prevent others from using his private keys", although >> reading it again I presume you're limiting the statement to >> non-authorized personnel in the normal scenario? > This reason is vague and invalid. The purpose of a private key is > two-fold: encryption and message authorization. The only need for an > organization to access their data is decrypting the encrypted data, > which is satisfied by the auditing key. I don't see any valid reason to > damage message authorization. There are easily scenarios where a customer forgets to add the "auditing key", making the data unavailable to the organization, in particular in context of loss of employee. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Success is getting what you want. Happiness is wanting what you get" (Dale Carnegie) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/05/2018 01:46 AM, Lou Wynn wrote: > On 01/04/2018 04:15 PM, Kristian Fiskerstrand wrote: >> On 01/05/2018 01:12 AM, Lou Wynn wrote: >>> I guess that you've missed somewhere I said in my previous posts that >>> the end user chooses his own password to protect his key password, which >>> is meant to prevent others from using his private keys. >> At which point I'm wondering about your priorities, if the corporation >> doesn't have access to the data (without the specific encryption key >> being included) what is the value? > Sorry, I don't get it. Can you explain your question again? What data, > in which scenario? > Businesses have reasonable need to access their data, so they need to have access to his private keys, which contradicts "which is meant to prevent others from using his private keys", although reading it again I presume you're limiting the statement to non-authorized personnel in the normal scenario? -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "In politics stupidity is not a handicap." (Napoleon Bonaparte) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/05/2018 01:12 AM, Lou Wynn wrote: > I guess that you've missed somewhere I said in my previous posts that > the end user chooses his own password to protect his key password, which > is meant to prevent others from using his private keys. At which point I'm wondering about your priorities, if the corporation doesn't have access to the data (without the specific encryption key being included) what is the value? -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "At 18 our convictions are hills from which we look; At 45 they are caves in which we hide." (F. Scott Fitzgerald) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/05/2018 01:04 AM, Lou Wynn wrote: > On 01/04/2018 02:57 PM, Kristian Fiskerstrand wrote: >> On 01/04/2018 11:24 PM, Lou Wynn wrote: >> but you add the requirement that all end users sending email to you >> require to validate the auditing key as well (auditing is likely wrong >> word, archiving is more likely relevant). for auditing you certainly >> want gpg-agent monitoring of assuan channel in separate domain. > I don't get the exact meaning of this paragraph. > > I'll try to explain a little. If the administrator sets up the auditing > policy (which implies that the auditing is an option), then the plugins > of employees will also use the auditing key to encrypt a message besides > receiver's public key. This is a little different from what I said > earlier about users' plugins because this is a design decision which has > not been finalized: whether to make employees or employees plus partners > to use the auditing key. This might become an option too. But in the end it doesn't matter, as the organization anyways has access to the private key material of the employee. So a third party "auditing key" is irrespective of any access goals. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aut dosce, aut disce, aut discede Either teach, or study, or leave signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/04/2018 11:14 PM, Lou Wynn wrote: > Compared to using two CAs, my design introduces two properties to a > certificate. One is the certificate type, which is "p" for a partner and > "e" for an employee. why not make it compatible with rfc4880 directly? your proposal would require client handling of e.g notation data? -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Amantes sunt amentes Lovers are lunatics signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/04/2018 11:24 PM, Lou Wynn wrote: > I guess that you missed the auditing key part. I introduced it to meet > auditing requirements or scanning of messages without using end user's > private keys. but you add the requirement that all end users sending email to you require to validate the auditing key as well (auditing is likely wrong word, archiving is more likely relevant). for auditing you certainly want gpg-agent monitoring of assuan channel in separate domain. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Amantes sunt amentes Lovers are lunatics signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/04/2018 10:58 PM, Lou Wynn wrote: > It's doable, but I'd like to make sure that I understand what you > mean by "within corporate infrastructure?" Do you mean the client > plugin sends requests to the server to decrypt and verify received > messages? no, there isn't necessarily a client plugin, the gateway decrypts the message before it hits the internal email server, so end-user sees un-encrypted message, this is protecting transport, but security of on-site is ensures through different channels > This is definitely a trade-off between key security and performance. > But I don't see any obvious benefits given that the user's computer > that runs the client plugin also belongs to corporate infrastructure. > If the user's computer is compromised, then the administrator simply > clean up the computer and re-install or re-initialize user's email > client, which includes the client plugin. I don't see this as disagreeing, this means you don't have any benefit from storing the email in encrypted form once it hits the corporate network, so you're better off decryption it at gateway anyways. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A committee is a group that keeps minutes and loses hours." (Milton Berle) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/04/2018 10:38 PM, Lou Wynn wrote: > On 01/04/2018 03:02 AM, Kristian Fiskerstrand wrote: >> On 01/04/2018 02:34 AM, Lou Wynn wrote: >>> No, there is no business unit level certifying key. An enterprise only >>> has one root key, which is the ultimate certificate authority for its >>> own employees and business partners. >> I normally recommend separating those, as the value for external parties >> that might want to trust this CA for certifying employees but not other >> third parties. > I don't think it necessary to use business unit level certifying keys in > my design. It introduces management overhead which shadows its benefits. > If you understand the concept of trust realm/trust group and its > verification methods I described before, then there is no need for a key > hierarchy at all. Can you describe a use case that demands the use of > unit level certifying key? I'll try to explain how to implement it with > trust realm and groups. I didn't necessarily say businsess unit level CA, but separation between employee and business partner CAs. >> As for access to private key material, I normally recommend that the end >> user never has access to any secret key material, but only access to >> using subkeys (never the primary) using smartcard tokens. > I completely agree, and indeed in my system, an end user never needs to > directly access his secret key. Actually, he does not need to access his > public key either. This is what I mean by zero configuration on client > side, both for trust management and key management. > > Thanks, > Lou > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Carpe noctem Seize the night signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/04/2018 10:21 PM, Lou Wynn wrote: > After a client plugin logs in successfully, the server sends the user's > encrypted email key to the client. Aren't you better off with a gateway solution like PGP Universal / Symantec Encryption Server (or for that matter if GPGRelay is still alive) ? That never exposes key material to client, i.e always operates within corporate infrastructure and removes a lot of complexity and allows for easier indexing/searching. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Leadership is a potent combination of strategy and character. But if you must be without one, be without the strategy." (Norman Schwarzkopf) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Modernizing Web-of-trust for Organizations
On 01/04/2018 02:34 AM, Lou Wynn wrote: > No, there is no business unit level certifying key. An enterprise only > has one root key, which is the ultimate certificate authority for its > own employees and business partners. I normally recommend separating those, as the value for external parties that might want to trust this CA for certifying employees but not other third parties. As for access to private key material, I normally recommend that the end user never has access to any secret key material, but only access to using subkeys (never the primary) using smartcard tokens. Wrt your other discussion of ssh based scheme, an alternative for escrow is actually using gnupg 2.1's gpg-agent through SSH socket forwarding so key material never is available locally, a system could theoretically be set up in a restricted setup so user doesn't actually get access to the key material (but it would require some setup to ensure they don't have it, so smartcard is generally easier) -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Carpe noctem Seize the night signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to batch generate ECC key
On 12/29/2017 04:53 PM, Rezart Qelibari für GnuPG wrote: > - How did you find out the protocol names, especially the upper case „E“ > of „Ed25519“ and that „cv25519“ is actually named „Curve25519“? Although > „gpg --expert --full-generate-key“ correctly states „Curve 25519“, „gpg > -k“ still yields „cv25519“. I find this behaviour very strange and unwisely. The short answer is libgcrypt's cipher/ecc-curves.c , see line 45/46 for mapping of shortnames to OIDs. Now, I agree this should at least be case-insensitive, but there might be a feature request open for that already :) > > - Why do the algorithm ids (22 for „Ed25519“ and 18 for „Curve25519“) > not work? Algorithm IDs are not directly tied to curves, so that would be more related to Key-Type than Key-Curve (and corresponding subkey), not the OIDs. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you are successful, you may win false friends and true enemies. Succeed anyway." (Mother Teresa) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to batch generate ECC key
On 12/29/2017 01:18 AM, Rezart Qelibari für GnuPG wrote: > Does anyone know what exactly goes wrong here? try: $ cat config.txt Key-Type: eddsa Key-Curve: Ed25519 Key-Usage: sign Subkey-Type: ecdh Subkey-Curve: Curve25519 Subkey-Usage: encrypt Passphrase: somepassword Name-Real: Some Real Name Name-Email: m...@example.com Creation-Date: 20170801T18 Expire-Date: 0 %commit -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Cogito ergo sum I think, therefore I am signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/26/2017 03:51 PM, Andrew Gallagher wrote: > Not getting into an OS flame war here, but not everyone uses Android. That doesn't mean it doesn't exist, it just means different user preferences as represented by the weigths in the decision matrix when purchasing a new device. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/26/2017 03:38 PM, Andrew Gallagher wrote: > Yes. Unfortunately it's tricky to implement that on a smartphone. We > don't have card+phone working in gnupg yet either. We *barely* have > gnupg working on phones at all. But that's for another day. Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from OpenKeychain.. Not that it should be used too much, a smartphone is one of the least secure devices around. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Credo quia absurdum I believe it because it is absurd signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/26/2017 02:15 PM, Andrew Gallagher wrote: > Absolutely. None of this is an argument against users having to do > things right. But the way to get users to do things right is to train > them to do things right from the start - and you do that by railroading > them down the straight and narrow and not even have the option to do it > any other way. That way, if the opportunity to do it wrong arises in the > future their first instinct will be "this isn't how it's supposed to > happen". If you can't train people personally, you have to write your > software so that the software trains them. The users shoudn't browse keyservers at all, so it shouldn't really be an issue. Linking to get operation to get the public keyblock is just a convenience. > > WhatsApp gets the UX *very nearly* right. And since everyone and his dog > now uses it that's the new baseline. If it's easier to do it wrong than No, that actually is broken by design as it doesn't open up for proper operational security controls, in particular lack of private key separation on smartcard and airgapped computer. > >> being able to browse the >> keyserver directly is too useful for debugging to completely remove > Indeed, but is it necessary to display the untrustworthy user-ID on > signatures? The fingerprint should be sufficient. the name of the primary UID of a signature is irrelevant; if we follow this argument; (i) until it is verified everything is untrustworthy, so (ii) the signature itself shouldn't be shown, nor should any of the UIDs for the public keyblock itself, as the self-signature isn't verified, and (iii) and the keyserver can't verify it as it isn't a trusted part of the infrastructure so the user can't know that it isn't a malicious operator running the specific server. The only logical consequence from (i)-(iii) is to remove keyservers from the mix and let users do bilateral exchanges (good luck with revocation distribution), for the simple reason that SOME users can't do things right, it has to destroy any chance of a proper security for others. Which incidentally is similar to a lot of other over-simplification and interconnections throughout the world, but that is a separate discussion. Finding the least common denominator and simplify everything to the absurd, no matter the consequences. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Great things are not accomplished by those who yield to trends and fads and popular opinion." (Jack Kerouac) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/26/2017 01:07 PM, Andrew Gallagher wrote: > So SKS should just say "unverified signature from ". It > should not repeat the purported user ID, nor provide a search link that > returns completely unrelated keys that happen to have the same purported ID. No, that is also wrong, as it implies that anything is trusted unless otherwise stated. A malicious actor can claim it is verified all he/she wants (simply removing the disclaimer). The user's default position NEEDS to be that nothing is verified until it is done locally or by an explicitly trusted third party. Any kind of disclaimer is actually doing the user a dis-service and supporting a subset of the user base that lacks sufficient experience/knowledge to do anything securely to begin with, which is the root cause of the issue; the solution isn't a disclaimer it is more education. Fwiw I don't recommend anyone to directly link to vindex etc on keyservers, you'll notice that https://sks-keyservers.net only links to get operations for similar purposes (if you find a (v)index link it is a bug and you should report it separately), but being able to browse the keyserver directly is too useful for debugging to completely remove. It is a reason it is done on port 11371 for hkp and I would encourage only accessing it through a local client, but other than that it isn't much to do on the keyserver side. But the lesson here is that in order to avoid misuse by an unexperience userbase the protocol has to be a binary obfuscated mess instead of trying to re-use well-established protocols in text form, just in case the user walks into the maze for some reason. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you don't drive your business, you will be driven out of business" (B. C. Forbes) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing failed -- "No secret key", even though I have the key
On 09/24/2017 05:34 PM, azarus wrote: > ssb# rsa4096 2017-06-23 [SE] > > Can somebody explain what I'm doing wrong? A combined sign and encrypt capable subkey would be wrong #1, you likely want to revoke this one and generate separate subkeys for the various options. Aditionally, they are stubs, as indicated by the "#"-sign, so not available on the computer you're executing the signature operation on. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock 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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/22/2017 10:48 PM, Stefan Claas wrote: > On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote: >>> And in place of the fake sigs it says erroneous MPI value. :-) >> >> And what happens if you do gpg --import-options import-clean >> --recv-key ? is the bad MPI value sigs removed or still there in that >> case? > > Unfortunately still there. Well, it doesn't really do anything, as the signature will be checked when calculating the trust database for the web of trust, but indeed, need to use --check-sigs explicitly in your use case then. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Potius sero quam numquam Better late then never signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/22/2017 10:29 PM, Stefan Claas wrote: > On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote: >> On 09/22/2017 10:08 PM, Stefan Claas wrote: >>> Thanks for the information! Can you tell me please how to import >>> a pub key with a local client, so that invalid data get's removed >>> automatically? When doing a gpg --receive-key key-id the fake data >>> is not removed. >> >> What does gpg --check-sigs report? > > Ah... it reports (in german) 3 correct sigs and 2 not checked because of > errors. > > And in place of the fake sigs it says erroneous MPI value. :-) And what happens if you do gpg --import-options import-clean --recv-key ? is the bad MPI value sigs removed or still there in that case? -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Veni, vidi, vacatum I came , I saw, I left signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/22/2017 10:08 PM, Stefan Claas wrote: > Thanks for the information! Can you tell me please how to import > a pub key with a local client, so that invalid data get's removed > automatically? When doing a gpg --receive-key key-id the fake data > is not removed. What does gpg --check-sigs report? -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Primum ego, tum ego, deinde ego First I, then I, thereafter I. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/22/2017 09:40 PM, Kristian Fiskerstrand wrote: > So all is as it is supposed to be Just to add, the alternative if not considering WoT is a direct validation structure, a user in this case should only (locally) sign keyblock information of communication peers after a direct fingerprint exchange in person, that removes any need for adding ownertrust to keys not your own and simplifies the model. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Nunc aut numquam Now or never signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Houston, we have a problem
On 09/22/2017 09:34 PM, Stefan Claas wrote: >>> O.k. i just tested a bit and this is a bug int the Web Interface >>> and in GnuPG's CLI Interface. >> I don't see a bug here. > Now i am a bit confused... Then maybe a "funny" design flaw? I mean > what should users unfamiliar with the whole WoT procedure may > think when seeing a fake "sig3" (which they may not spot) and then > clicking on the key-id in question, which then links to the original > key? > No, its not a design flaw, it is valid design. OpenPGP keyblock information is based on an object based security model where packets are added, but don't carry any meaning until the signature has been verified. The public keyserver network is by design not a trusted third party, and can not be, so keyblock needs to be imported using a local client at which point invalid data, including invalid signatures, results in discarding of the data, which would filter out the signature in this case. So all is as it is supposed to be -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Prince Jones v US
On 09/22/2017 11:55 AM, Jerry wrote: > Can you cite the case #. All I could find is an old "local appeals court in > Washington, D.C." ruling. I found nothing under the US Supreme Court. See https://www.dccourts.gov/sites/default/files/2017-09/15-CF-322.pdf DISTRICT OF COLUMBIA COURT OF APPEALS No. 15-CF-322 09/21/2017 P RINCE J ONES , A PPELLANT , V . U NITED S TATES , A PPELLEE . Appeal from the Superior Court of the District of Columbia (CF1-18140-13) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Great things are not accomplished by those who yield to trends and fads and popular opinion." (Jack Kerouac) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Automating and integrating GPG
On 09/19/2017 03:53 PM, Andreas Heinlein wrote: > Handling of the passphrase is about one of the most sensitive > tasks when dealing with encryption. I currently can think of no way you > could handle passphrases on your own in python which I would call > 'secure'. In such a scenario I'd likely use a custom pinentry, that'd be the same recommendation for a password manager etc, as for security info is passed in the socket that is protected using regular unix user permissions / ACLs and anyways same as regular pinentry uses. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "To live is the rarest thing in the world. Most people exist, that is all." Oscar Wilde signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Operation not supported by device
On 07/27/2017 05:29 PM, Stefan Claas wrote: > On Wed, 26 Jul 2017 23:41:23 +0200, Kristian Fiskerstrand wrote: >> On 07/24/2017 04:27 PM, Stefan Claas wrote: >>> The file is signed and can be verified. Just wondering (after >>> googling) what this means, because i have no card reader etc. for >>> GnuPG. >> >> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2 >> > Thanks for the Info. A bit more verbosely, if no scdaemon exists you will get an error value that was not suppressed for a few versions, you can safely ignore the warning and it is fixed in alter versions again, or you can install/build gnupg with scdaemon even if not using a smartcard and it will get the necessary info and be silent. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Operation not supported by device
On 07/24/2017 04:27 PM, Stefan Claas wrote: > The file is signed and can be verified. Just wondering (after googling) > what this means, because i have no card reader etc. for GnuPG. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Amantes sunt amentes Lovers are lunatics signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent cache keygrip
On 07/26/2017 09:08 PM, Mario Figueiredo wrote: > On Wed, 26 Jul 2017 08:52:12 +0200 > Werner Koch <w...@gnupg.org> wrote: > >> There is a kludge in gpg and gpg-agent described in this comment: >> [...] > > Hello Werner, > > Thank you for the information and debug method. And hopefully this > problem will be fixed sometime in the near future. My brain is old > and tired and it can't just commit to yet another unique password of > any decent quality. > > The sharing of passwords between different keys becomes inevitable > after a certain threshold. And I suspect for everyone, not just old > people. And the gpg-agent just isn't dealing with this situation in an > acceptable way. > Have you considered using smartcards/tokens to ensure the secret key material is only available when you expect to do operations using the particular keys (as well as protecting against several other threat vectors)? -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Fabricando fit faber Practice makes perfect signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Access denied when using gpg4win via command prompt
On 07/04/2017 03:22 PM, S via Gnupg-users wrote: > My OS : Windows 10 (1607 version)Gpg4win version : 2.33 > Any help's appreciated. > Thanks > You seem to try to output the revocation certificate to c:\windows\system32 , does the error persist if not outputting to a system directory? -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "History repeats itself; historians repeat each other" (Philip Guedalla) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Technical contact for mailing list?
On 06/29/2017 12:50 AM, Pete Stephenson wrote: > Hi all, Hi, > > Who is the appropriate person to contact regarding technical issues with > the mailing list? > > Specifically, it appears that the list doesn't play nice with anti-spam > measures like DMARC, SPF, and DKIM and so messages sent from domains > with restrictive DMARC and SPF rules get flagged as spam as mail servers > think the mailing list server is forging messages for those domains. This is likely a a continuation of https://lists.gnupg.org/pipermail/gnupg-users/2017-March/057877.html -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Better to keep your mouth shut and be thought a fool than to open it and remove all doubt" (Mark Twain) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Cannot choose specific signing key with option --default-key
On 06/14/2017 07:38 AM, Yanzhe Lee wrote: > Maybe there was a priority when sign files with RSA and ECC keys? How > can I override it? Try adding a "!" suffix to the fingerprint specification of the subkey -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Be a yardstick of quality. Some people aren't used to an environment where excellence is expected." (Steve Jobs) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question for app developers, like Enigmail etc. - Identicons
On 06/04/2017 10:25 PM, Stefan Claas wrote: > With Thunderbird/Enigmail (i can't speak for other apps) a user new to GnuPG > and and not savvy with checking email headers and not carefully checking the > fingerprint (he must click addionally on the Details button) and who has > never > signed a public key before would in my opinion have it easier if he would be > presented with an additional visual fingerprint imho, because he would > imediately > spot after the second email if the pub-key, he not yet lsigned, that > there is > something wrong. > > If the visual fingerprint would be bullet-proof it would not hurt to > implement > such a feature, imho. Any talk about visual inspection of consistency in fingerprint seems like an implementation of a TOFU model rather than an actual trust model? So instead of doing a manual visual inspection, you'd want the tofu model in gpg 2.1? -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Action is the foundational key to all success" (Pablo Picasso) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question for app developers, like Enigmail etc. - Identicons
On 06/04/2017 11:21 AM, Stefan Claas wrote: > The reason why i ask, i started to use Thunderbird with Enigmail and > Enigmail shows me always Untrusted Good Signature with a 32bit key ID, > when i have not carefully verified the persons pub key and --lsign'ed > the pub-key. Showing only the long key id or the complete fingerprint > is imho more difficult to quickly memorize than an additionial shown > identicon (computed from the fingerprint). I'm likely missing something there, but if having a reasonable assurance the public keyblock in question should likely be lsigned by a local CAkey anyways? Doing a manual graphical verification doesn't seem to provide anythin in terms of security here. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Bene diagnoscitur, bene curatur Something that is well diagnosed can be cured well signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reviving a userid with revoked key
On 05/19/2017 08:36 PM, Marc Curry wrote: > Maybe a dumb question, but I'm looking for help thinking through how to > best "revive" an old gpg key's userid after I revoked it a few years ago, > thinking I wouldn't need to use it, again. > > 1) was at a company (e.g. m...@company-a.com) > 2) went to company-b and revoked key for marc@company-a > 3) now I'm back at company-a, and want to start using m...@company-a.com > userid again Nothing wrong with that, just add a new user id using adduid from --edit-key, it wont have the old signatures from other users, those got lost at the revocation point, but your new contacts can sign the new UID without issue. Deleting the old UID will have no practical effect if it has been distributed to a keyserver historically. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you choose to sail upon the seas of banking, build your bank as you would your boat, with the strength to sail safely through any storm." (Jacob Safra (1891–1963)) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Newbie can't get --passphrase option to work
On 05/12/2017 04:15 PM, Ryk McDorman wrote: > I've done a thorough search for a solution for this, but haven't come up with > much: a vague reference to a bug in 2.1.x that may have to do with it, and at > the end of my day yesterday I came across someone who used the > "--pinentry-mode loopback" option. Interestingly, when I add that to my > command, it DOES decrypt one file without prompting me, but then inexplicably > stops. (My program logic is fine, as without the -pinentry option, it prompts > me once for each file and decrypts each file.) I haven't yet had time to > investigate that option; it's my next action but I've literally been working > on this for days now and needed to send out a plea for help! And here you discuss it :p .. yes, pinentry-mode loopback is necessary for 2.1 use of --passphrase-fd and the likes , in earlier versions of 2.1 this requires allow-pinentry-loopback for the gpg-agent but in recent versions that is defaulted to on. Can you provide the information when this argument is used and the scenario that fails including explicit error messages? -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Amantes sunt amentes Lovers are lunatics signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Newbie can't get --passphrase option to work
On 05/12/2017 04:15 PM, Ryk McDorman wrote: > I was tasked with automating the decryption (and more) of files, so I've > written a PowerShell program that does everything I need it to do, except > that I can't get the decryption to decrypt without prompting for our > passphrase. I'm using a default installation of GnuPG 2.1.19 on Windows 7 (it > may go on a Win Server 2012 box for production). look into --pinentry-mode loopback -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Amantes sunt amentes Lovers are lunatics signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Signature Verification
On 04/21/2017 09:16 AM, Kristian Fiskerstrand wrote: > On 04/20/2017 09:17 PM, Paul Taukatch wrote: >> I've attached my public key and debug log but please let me know if there >> is any other information that might be helpful. > > The first reference that springs to mind is [RFC4880] Section 5.2.4. > Computing Signatures Of course you already mentioned this in your initial email :) Looks correct to me. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If your kids are giving you a headache, follow the directions on the aspirin bottle, especially the part that says "keep away from children." (Neil McElroy) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Signature Verification
On 04/20/2017 09:17 PM, Paul Taukatch wrote: > I've attached my public key and debug log but please let me know if there > is any other information that might be helpful. The first reference that springs to mind is [RFC4880] Section 5.2.4. Computing Signatures References: [RFC4880] https://tools.ietf.org/rfc/rfc4880.txt -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Security doubts on 3DES default
On 03/13/2017 01:47 PM, Ryru wrote: > Is my understanding correct or do I miss an important fact? What are > your thoughts about this behaviour? See section 13.2 of RFC4880, fyi the behavior changes in the context of RFC6637. My thoughts; concerns about 3DES are premature. The focus on algorithms in general likely so, the likelihood of operational security being the issue is far greater -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verify with missing public key: unexpected returncode
On 03/03/2017 06:04 PM, Gerd v. Egidy wrote: > When reading the gpg2 manpage on return codes: One quick observation, if using this in automated way and return code matters, you likely want to check out "gpgv", otherwise you should be parsing --status-fd output for more details -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG, subkeys smartcard and computer
On 02/21/2017 03:15 PM, Peter Lebbing wrote: > If Kristian Fiskerstrand says it's okay for SSH servers to refresh their > keyring every 20 or 30 minutes from the public keyserver netowrk, then I > guess it really is :-). I had estimated it as inappropriate. Keep in mind, the keyring in the scope of monkeysphere is normally one keyblock :) But yeah, the crontab frequency will depend a bit on system. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG, subkeys smartcard and computer
On 02/21/2017 02:21 PM, Peter Lebbing wrote: > Revoking the old A key and creating a new one needs to happen on the > system you have the primary key on, so you need to subsequently roll out Who said anything about creating a new one in this part of the process? each device has separate A subkeys already, you lost your device, you revoke the A subkey for it (this step is actually the most tricky, as revocation certificates can't be generated for subkeys - so you need to have pre-generated versions of pubkey with it revoked created carefully manually beforehand). > the new A key to the compromised device. Obviously I assume the primary > key was not available on the compromised device, because then the whole obviously > certificate would have to be revoked. I don't see much extra effort in > rolling it out to the few other systems you use as a client as well. not following, you don't have access to the primary key at this point (say you're travelling and the primary is on smartcard in a vault) > > Also, I think you need to have a way to notify servers that they need to > get an updated certificate including the revoked old key *right* *now*. > We're talking about a compromised A key! The attacker has full access to > your login account for the time that the servers haven't checked for a Whether need for "right now" depends on severity, the compromise is in most cases a lost device, not an active attacker, so a 20-30 min timeframe is likely sufficient in most cases anyways e.g from a regular crontab run of monkeysphere, this also should fit with most key propagation across network as using a single keyserver can create a SPOF and DoS the update > new key yet! Regular intervals just won't do. This looks to be the > painful step in the process. ... it depends... -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG, subkeys smartcard and computer
On 02/20/2017 05:49 PM, Peter Lebbing wrote: > So perhaps one key per device is superior, also for detecting which client > system was compromised by looking at the SSH auth logs on the server > (supposing > the attacker didn't gain root privileges and wiped his traces immediately). > But > I think it's not a very significant difference, or did I miss a scenario? Revocation of the specific subkey is automatically picked up by all systems due to automatic refresh of the public key on regular intervals, without losing access to the system from non-compromised devices. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG, subkeys smartcard and computer
On 02/19/2017 01:45 PM, Andrew Gallagher wrote: > And in the case of A and S, there next to no benefit - if one of your > subkeys is lost you should revoke it immediately anyway Wouldn't consider this accurate, the typical use case for multiple A subkeys is per-device usage, explicitly to avoid having to revoke all if one is compromised. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
On 02/17/2017 09:46 PM, si...@web.de wrote: > Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand: >> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: >> >> That change would also be consistent with >> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 >> > >> > Not quite sure I get this. > > So what this means is that effectively gnupg still uses plaintext > connections to update public keys by default, does it not? Yes (if not a tor configuration locally) > If the > change I suggested is not correct, shouldn't we find another way to > use secure connection by default whenever possible? Probably nitpick, but it would likely increase privacy - not security. > > As it is now, the default fallback mentioned in the referenced commit > never takes effect as long as the skel file is used. > Never would be inaccurate; kristianf@ares ~/workspace $ mkdir abc kristianf@ares ~/workspace $ gpg --homedir abc --recv-key 94CBAFDD30345109561835AA0B7F8B60E3EDFAE3 -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: > On 02/17/2017 07:00 PM, si...@web.de wrote: >> keyserver hkps://jirk5u4osbsr34t5.onion >> keyserver hkps://keys.gnupg.net >> >> would solve this I guess. > > No, that'd result in certificate errors and non-responsive servers > That said, you are indeed correct, and skel file is used to create dirmngr.conf on other systems as well (it has been a while since starting with a fresh homedir :) ) ... if wanting hkps the latter should be switched to hkps://hkps.pool.sks-keyservers.net ,the former is protected already as tor usage would be to an endpoint running a tor hidden service. That change would also be consistent with https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
On 02/17/2017 07:00 PM, si...@web.de wrote: > keyserver hkps://jirk5u4osbsr34t5.onion > keyserver hkps://keys.gnupg.net > > would solve this I guess. No, that'd result in certificate errors and non-responsive servers -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
On 02/17/2017 01:37 PM, si...@web.de wrote: > Is there something I missed or is this unintended? gnupg does not ship an installed dirmngr.conf, when no keyserver is specified it defaults to hkps://hkps.pool.sks-keyservers.net, the existence of a (I presume) arch installed dirmngr.conf changes this behavior. Whether that is intended or not is a question for your distribution's package maintainer. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Expanding web-of-trust with subkey
On 02/15/2017 03:27 PM, Adam Sherman wrote: > On 2017-02-15 06:51 AM, Kristian Fiskerstrand wrote: >>> Do I need access to my master key in order to expand my web of >>> trust? This seems like quite a restriction. >> Yes, although you can generate a local CA key to use for this purpose >> for short term validity considerations used for local signatures. > > How do you do that? Is there a type of sub-key you use? > No, just a completely separated primary key with C capability, no subkeys and is never published anywhere, rotated regularly to issue lsigns for short term use -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Expanding web-of-trust with subkey
On 02/15/2017 04:02 AM, Didrik Nordström wrote: > > So.. Do I need access to my master key in order to expand my web of > trust? This seems like quite a restriction. Yes, although you can generate a local CA key to use for this purpose for short term validity considerations used for local signatures. For the visible WoT (i.e one others can use in their determination), having this limited is a very good thing. And it is one of the constructs that makes it possible to rotate subkeys due to compromise (e.g loss of a smartcard) without needing to revoke the full primary key. > > How do you handle key management? Let's say you just want to send a > signed and encrypted email once to someone who announced their pubkey > over https? What type of trust would you assign? no trust, that goes to the ability to verify third parties. Local CA and local (non-exportable) signature -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: send-keys does not update my key
On 02/14/2017 07:51 PM, Marko Bauhardt wrote: > The trust level of my two IDs was `unknown` in the one public key and > `ultimate` in the other key. Trust level is not a property of the public key, it is stored out of band (in the local trustdb) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader
On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote: > p.s. in the meantime a made a script which tails the scdaemon.log and > waits for "Removal of a card:" > and then kills the gpg-agent. Not a proper solution - but working so far. Why not use udev rule to watch for removal event? -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Dura necessitas Necessity is harsh signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Meaning of "text user ID's"?
On 01/04/2017 03:00 PM, Peter Lebbing wrote: > On 04/01/17 14:56, Kristian Fiskerstrand wrote: >> What gives you the indication that the UAT is about to be signed? > > First and foremost, that it was actually signed when I agreed. I deleted the > signature afterwards. > > Secondly, I just posted again with a bit more readable text :-). You can > clearly > see it is proposing to do it. > Gotcha :) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Nil desperandum Never give up signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Meaning of "text user ID's"?
On 01/04/2017 02:53 PM, Peter Lebbing wrote: > So how come that the jpeg image is about to be signed as well? What does "TEXT > user ID" mean? I would have expected only the other UID's to be signed. Is > this > a bug in my head or in the code? What gives you the indication that the UAT is about to be signed? (can try it and not save/delete public key without publishing to see actual result) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Cogito ergo sum I think, therefore I am signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.17 released
On 12/20/2016 04:21 PM, Daniel Baur wrote: > PS: What’s “public key algorithm 22”? Elliptic Curves, specifically, EdDSA (in this case the warning is likely related to a signature on the key used for verification that is using Ed25519 which can't be verified by your client application) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Nulla regula sine exceptione No rule without exception signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
