Re: WKD documentation (Re: Testing WKD setup?)
Am Freitag, 12. Juli 2019, 10:30:30 CEST schrieb Werner Koch via Gnupg-users:
> On Wed, 10 Jul 2019 21:47, johan...@zarl-zierl.at said:
> > ...except it isn't installed by default. Will this be part of
> > gpg-wks-client?
> Ooops. I meant gpg-wks-client. There is no gpg-wks-tool.
Thanks for the clarification.
> > won't be installed to libexec), it would still be beneficial to describe
> > the actual file system layout.
>
> You mean, where it gets installed? When running ./configure without any
> options gpg-wks-tool whill be installed under /usr/local/libexec as per
> GNU standards. Debian and other distors don't have this directory and
> install it under /usr/lib. You can of course use
Sorry, I should have separated this better from the previous sentence. What I
meant are two things:
1. If a user is ever to execute gpg-wks-client directly or through a script,
libexec should not be used: [1]
Right now I have the bizarre situation on Debian unstable that gpg-wks-server
is in /usr/bin even though it is meant to be executed by a service and not by
a user, but gpg-wks-client is located in /usr/lib/gnupg (Debian has no
libexec, I think).
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
2. It would still be beneficial to describe the actual file system layout of
the WKD.
This can either be done implicitly in the step-by-step guide ("After the call
to gpg-wks-client, 'find .well-known/openpgp' should list a directory
structure similar to this one: ..."). Or it can be documented separately on
the WKD page, also explaining different options (e.g. is there a different WKD
layout when WKD is deployed on a sub-domain, what are possible values for the
policy file) with links to the canonical reference documentation.
Cheers,
Johannes
signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD documentation (Re: Testing WKD setup?)
Am Mittwoch, 10. Juli 2019, 19:34:41 CEST schrieb Werner Koch: > On Tue, 9 Jul 2019 23:33, johan...@zarl-zierl.at said: > > Now that I have done it once, I think the setup without > > /usr/lib/gnupg/gpg- > > > wks-client isn't that complicated either: > Please use gpg-wks-tool instead; it is much easier and less error prone. ...except it isn't installed by default. Will this be part of gpg-wks-client? But in the future when it is installed by default, I 100% agree with you. Btw, and because we are on the topic of documentation: there is no mention of gpg-wks-tool anywhere in the WKD or WKDHosting pages. Anyways: whether you promote gpg-wks-client or gpg-wks-tool (which, hopefully, won't be installed to libexec), it would still be beneficial to describe the actual file system layout. > > b. Manually, using gpg: gpg --homedir "$(mktemp -d)" --locate-keys $KEYID > > With 2.2.17 use > > gpg --locate-external-key -v f...@example.org > > Granted it imports the key but after all that is what you want. That > new command does not check the local keyring so it can be used to > refresh from a WKD (or whatever has been configured in your AKL) That seems nice - I will take note for the time this enters Debian... Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD documentation (Re: Testing WKD setup?)
Hi, On Dienstag, 9. Juli 2019 15:02:26 CEST Bernhard Reiter wrote: > please make suggestions (or help with improving) > https://wiki.gnupg.org/WKD I think the problem with that page is that it is handed out as a starting point to users asking "how can I enable WKD for my key?". To give credit, the page does give a decent explanation of the concepts of WKD: What is a Web Key Directory? How does it work? These two sections are a good start. What does it mean for users? Here I got sidelined a little: Basically, everything's nice for users and we don't need to do anything, I guess? I think the example video shows that you can just write an email and the mail client encrypted it to the recipient. Having subtitles (or a narrator) would probably make the intent of the video clearer. For me as a user, it would also be nice to know if WKD "just happens" automatically, or if I need to enable it, or give it precedence over my configured default keyserver... How to set it up? This section is "lots" of text with the important info hidden behind a link. I say "lots" even though it's hardly a paragraph, because it's roughly a whole line with boilerplate text and the link is a single word. Just putting "See: WKDHosting" without the paragraph would be better. Maybe a bullet-list could do the job: - Simple deployment (just a webserver): WKDHosting - Deployment with automated updates (recommended for organizations): WKS Web Key Directory (WKD) / Web Key Service (WKS) what is the difference? This is literally a list of differences - why not make it a list? Technical Details Implementations (Nothing wrong with those two sections). > Note that on Wiktor's page a few details are missing: > * policy file is needed > * directory listing strongly recommend to be off > * minimum version of gpg that has --with-wkd (some versions don't). Wiktor's page gave me enough of a starting point so that I could figure out the missing details. Actually, just entering my email into the form and then working to fix every complaint until it works wasn't too bad a user experience ;-) > BTW, last week we've updated > https://wiki.gnupg.org/WKDHosting > with a how to use gpg-wks-client on Gnu and Windows systems > to create a flat file structure. That's definitely an improvement - previously, I only took passing note of the page, noting that there has to be an easier way than "download some code from mercurial somewhere, install python prerequisites, create specially crafted keyring, and then it's just a one-liner to create the WKD. Now that I have done it once, I think the setup without /usr/lib/gnupg/gpg- wks-client isn't that complicated either: Basic steps: 1. Create directory structure: mkdir -p .well-known/openpgp/hu 2. Create policy file: touch .well-known/openpgp/policy (explaining valid policies and why one would want one) 3. Identify your key hash: gpg --list-secret-keys --with-wkd $KEYID -> Make sure to omit the domain part starting with "@" 4. Export your key to the right place: gpg --export-options export-clean --export $KEYID > .well-known/openpgp/hu/ $WKD_HASH (I'm not sure about the export-clean - it just seemed like a reasonable default.) Webserver configuration: 1. Turn off directory listing for .well-known/openpgp unless you really want this 2. Enable those header things that are mentioned in the wkd checker (explain the rationale behind this) Testing: a. using Wiktors web wkd-checker, which also checks best-practice b. Manually, using gpg: gpg --homedir "$(mktemp -d)" --locate-keys $KEYID I hope this helps a little, Johannes P.S.: Now that I've read up on the other mails it seems that it is also possible to host the WKD on a subdomain - I guess this could also need some documentation (describe the lookup-procedure on the WKD page under "How it works"; describe the differences in setup on WKDHosting) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Testing WKD setup?
On Sonntag, 7. Juli 2019 20:48:12 CEST Wolfgang Traylor via Gnupg-users wrote: > > is there a service or similar where I can check if this email address is > > properly WKD-enabled? > https://metacode.biz/openpgp/web-key-directory Thank you! This is so much easier to comprehend than the official documentation... Cheers, Johannes signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Missing feedback when changing a card pin fails
Hi, I've just spent half an hour scratching my head over an issue that should have been simple: I initialized a new OpenPGP card (v2.1 from Zeitcontrol) and changed the (user) pin. After this, I used the verify command to check whether the pin was working: I put my pin into the pinentry dialog, and verified that the retry count afterwards was still "3 0 3". Still, when I was prompted the pin afterwards I got the error "wrong pin". Strangely enough, the retry counter did not decrease when entering the pin. Entering a different random pin resulted in the retry counter decreasing as it should. [Fast-forward through lots of head-scratching, mild swearing and asking myself whether the card was broken.] In the end the simple truth was that my pin code only had 5 digits, but the minimum length is higher. Yes, I know that I *should* know the minimum pin- code length for my card, and that I *should* use longer pins anyways. Is it possible to issue some kind of diagnostic for this? I.e. either a warning/error message when changing the pin, or at least the "verify" command issuing a warning on an incorrect pin? Btw. my gpg version is 2.2.5. Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is there a foolproof tutorial to start with gpgme?
On Tuesday 26 April 2016 12:44:44 Robert J. Hansen wrote: > Please note: since CMake doesn't have a plugin (yet) to automatically > detect GPGME The usual way is for a library to provide a PackageConfig.cmake file. The old- style FindPackage.cmake "plugins" are very much deprecated and it's hard to convince cmake maintainers to accept a new one... That being said, it shouldn't be too hard to create a working gpgme- config.cmake file using autotools Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
Hi Neal, Thanks for the heads-up on this. TOFU seems like a really big feature for everyday use! Out of curiosity: Does the TOFU implementation for gpg already allow for key transition statements / is this planned for some point in the future? Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: High resource usage when verifying a signature
On Sunday 19 July 2015 01:42:34 Daniel Kahn Gillmor wrote: I suspect what's taking a long time is an update to the trustdb. one workaround is to put no-auto-check-trustdb in ~/.gnupg/gpg.conf, and then have a nightly cronjob that runs gpg2 --check-trustdb. ...and sure enough gpg2 --check-trustdb takes around a minute, the same duration as the arbitrary lockups in kmail. Thanks again, this is very probably the cause! Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
High resource usage when verifying a signature
Hi, I've noticed that sometimes gpg2 will take around 1-2 minutes on my desktop PC attempting to verify an email signature. At first, I thought that maybe the increasing prevalence of really big keys would increase the computational complexity, or that the keyserver communication is taking so long, but this does not seem the case. I'm pretty sure this happens on different kinds of keys, but today I noticed it on a 1024 bit DSA key. Looking into top revealed that my email program had spawned a gpg2 process that was using 100% of a single CPU core: gpg2 --enable-special-filenames --batch --no-sk-comments --status-fd 22 --no- tty --charset utf8 --enable-progress-filter --display :0 --verify -- -23 -25 Opening the same email a second time happens more or less instantaneously (as far as I know, kmail does not cache the verification). Is this behaviour to be expected? Is this some computation that happens only the first time a new key is encountered? Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Talking about Cryptodevices... which one?
But I still have the impression about smartcards are supposed to prevent an attacker from stealing the private keys from the cards, right? Yes, I agree. Peter. But the threat is not fully mitigated if, as you said yourself in another message on this thread, the attacker can potentially sign/decrypt using the key on the smartcard. You're conflating two different threats here. A smartcard *does* protect you from anyone trying to steal your private keys. It does not prevent an attacker from stealing the pin. It does not prevent an attacker from deleting your key. It does not prevent an attacker from tricking you into signing or decrypting a message. Under some circumstances it does not even protect against key- revocation. Having said all that, I still think it is a worthwhile goal to protect the key-material itself using smartcard-like hardware / an HSM. The protection against key-theft does radically decrease your attack surface in many cases. Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Manually changing smartcard state
Is it possible to change the smartcard state after PIN is entered, so it would be back in the same state as it was when first inserted into the reader (and would require the PIN to be entered again also for decryption)? So without removing and re-inserting the card, possibly using some APDU instructions. You can tell gpg-agent to lock the card using the following command[1]: gpg-connect-agent 'SCD RESET' /bye [1] http://lists.gnupg.org/pipermail/gnupg-users/2011-January/040478.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Crypto device where I need to confirm every operation?
On Thursday 22 January 2015 17:00:44 Felix E. Klee wrote: However, there is one attack which I think could be easily prevented: With the card in the reader, the PIN entered, and Eve having remote access to my machine, she could sign and decrypt documents. Are you sure? On my setup, the smartcard seems to only allow one sign operation per pin-entry. Decryption, on the other hand seems to be allowed without re-authorisation until the card has been removed from the reader (or until it has been reset by another means). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The Facts:
Hi, On Saturday 15 November 2014 11:52:02 da...@gbenet.com wrote: Laptop-1 and laptop-2 are a mirror image of each. They contain the same software. I copied programmes like Thunderbird Firefox from laptop-1 to laptop-2 without any problems. It seems like the mirroring of laptop-1 to laptop-2 did not actually work as expected: (1) david@laptop-1:~$ gpg gpg: directory `/home/david/.gnupg' created gpg: new configuration file `/home/david/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/david/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/home/david/.gnupg/secring.gpg' created gpg: keyring `/home/david/.gnupg/pubring.gpg' created gpg: Go ahead and type your message ... The above command output tells you that no .gnupg folder exists in your home directory and that a new one is created. As some people pointed out before, you have to copy the .gnupg folder from your laptop-1 to your laptop-2. Maybe you forgot to restore your home directory when you migrated from laptop-1 to laptop-2? Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Help needed
On Friday 14 November 2014 17:05:12 da...@gbenet.com wrote: david@laptop-1:~$ sudo pkg install pinentry-gtk2 [sudo] password for david: sudo: pkg: command not found david@laptop-1:~$ sudo apt-get install pinentry-gtk2 Reading package lists... Done Building dependency tree Reading state information... Done pinentry-gtk2 is already the newest version. pinentry-gtk2 set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. david@laptop-1:~$ So that's a complete failure That seems a little harsh, doesn't it? ;-) After all, you now know that you do indeed have the pinentry-gtk2 installed, and we know that you use a Debian-based distro. Now, you could try to verify that pinentry-gtk2 is the pinentry program that you normally use: $ grep pinentry-program ~/.gnupg/gpg-agent.conf pinentry-program /usr/bin/pinentry-qt4 If not, you should ensure that the right pinentry program for your environment is installed (like you did before with pinentry-gtk2): $ sudo apt-get install pinentry-qt4 If you don't find the cause of the problem in this way, then there's still enough time left to despair if you so wish… Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: GNU hackers discover HACIENDA government surveillance and give us a way to fight back
On Thursday 21 August 2014 11:41:40 Robert J. Hansen wrote: If it escalates to an intrusion, then yes, that's definitely surveillance in my book. Compiling a collection of publicly available information is not. Compiling a collection of publicly available information is an almost perfect description of the term surveillance. E.g. a surveillance camera does exactly that: it collects publicly available information. Your initial example, That's like driving down the street and reporting on what colors people's houses are and whether they have their garage door open. , is also a nice example of surveillance. The information is not by definition harmful to anyone, yet has the potential to be used against someone. Mr. and Mrs. Smith always leave the garage door open in summer, except for one week a year, when they also close the bathroom window. is trivial, maybe even boring information to most people. To someone with bad intent this information might be a lot more interesting. Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications
On Saturday 28 June 2014 08:09:10 Johan Wevers wrote: On 28-06-2014 0:31, Johannes Zarl wrote: The way I see it compatibility between those two groups is a non-issue - they simply don't exchange messages. Why not? My assumptions were as follows: - When exchanging messages with untrusted parties it's a Bad Idea(tm) to use unmaintained software that is vulnerable to attacks. - PGP 8 is unmaintained software and must be assumed to be vulnerable to attacks (we know how many security related bugs gpg saw in the last 12 years) - Corporate environments do often use legacy systems, but are usually risk- aware and isolate vulnerable systems. I therefore assumed that PGP 8 is only used in closed environments, where the risk is manageable. I assumed it is just the same as with, say Internet Explorer 6: Since many intranet applications depend on it, is is still used - it is a sensible business decision for some companies to do so. Browsing the web using IE6 on the other hand is something no corporate environment would allow. If the lawyer example is a fitting one, then I guess I have an error in my assumptions. rant If I communicate with someone who must use PGP 8, anything stronger than 1024bit RSA, SHA1 and 3DES is probably wasted effort, anyways. /rant Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications
On Friday 27 June 2014 19:35:12 Robert J. Hansen wrote: On 6/27/2014 6:31 PM, Johannes Zarl wrote: 1. legacy PGP implementations in closed corporate environments Be careful about that phrase legacy. Too often it's used as a slur. It's more accurate to say, PGP installations in corporate environments. There's no reason to think these installations are closed, or that the IT departments are being unreasonable. I do not think of legacy as a slur, but as a descriptive term. Yes, it can have a negative connotation, but that largely depends on who you ask: the person using a legacy application that pre-dates the internet and holds 30+ years of distilled business-knowledge might have a vastly different take on the term legacy than the person who's task it is to couple a webshop with worldwide shipping to a database that uses 7-bit fixed length database fields. To me there is a simple legacy test: If X could sensibly used for a newly developed project that runs for at least the next 5 years, then it is not a legacy system; otherwise it is. Nobody (at least I assume nobody) goes around exclaiming: PGP 8 is just the tool that we want to base our future projects on. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: On the advisability of stronger digests than SHA-1 in OpenPGP certifications
On Friday 27 June 2014 20:51:00 Werner Koch wrote: On Fri, 27 Jun 2014 19:46, pe...@digitalbrains.com said: I however have no clue what you expose yourself to when you still use PGP 8.x. It could be possible that these guys take irresponsible risks, I don't know. They will tell you that they send the encrypted messages only within their VPN and that the company policy requires end to end encryption. Check box security. So basically there are (at least) two user groups: 1. legacy PGP implementations in closed corporate environments 2. people who want to exchange messages over the internet Group 1 can afford not to have frequent security updates since the systems are isolated from the internet and don't upgrade because this would incur a significant cost with little benefit. Group 2 is willing to keep their software up to date, but are in a generally more attackable environment. They push for more secure standards and defaults (whatever that means). The way I see it compatibility between those two groups is a non-issue - they simply don't exchange messages. Arguing that internet-users should not adopt SHA-x because SHA-1 is the only thing supported by legacy systems makes about as much sense as arguing that legacy-users should throw money into upgrading their isolated systems. Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: mascot_p
Hi, A project mascot is certainly a great idea. In my opinion a mascot and a logo have different purposes and can beautifully complement each other. The logo stands for the product and has to follow certain rules in its design. A mascot, on the other hand stands more for the whole community and can create ties between several projects much more easily. On Tuesday 17 June 2014 09:45:03 Robert J. Hansen wrote: First -- yes, I would love to see Terry the Tinfoil-Hatted Terrapin become our mascot. We've got a very businesslike logo; a mascot is an opportunity for playfulness. And what better way to poke a little good-natured fun at ourselves? I was going to suggest a hedgehog (it's likeable, generally favours security over speed, and knows to protect itself), but a terrapin sounds great. Now I just have to find out the difference between a terrapin and a turtle… Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: mascot_p
Learn something new every day. Indeed. Thank you both for teaching me about the subtleties of the English language *and* some biology! Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Could not extend expiration date
Hi, It looks like you use an offline master key and use subkeys for signing and decryption. You can check this by looking at your secret keyring: gpg2 -K sec# 4096R/DEADBEEF 2013-10-25 [expires: 2018-10-24] uid Some Body some...@example.com jz...@fsfe.org ssb 2048R/08152323 2013-10-25 ssb 2048R/42424242 2013-10-25 In this case, the '#' sign after the sec means that the private key is not available. On Monday 10 February 2014 20:36:15 Pericle Unico wrote: C:\Users\me\Downloadsgpg -vvv -s volterra_saggi_scientifici.epub gpg: using character set `CP850' gpg: using PGP trust model gpg: key 3D2B665D: accepted as trusted key gpg: using subkey 658682A5 instead of primary key 3D2B665D If I read this correctly, your master key is 658682A5, but you usually use the subkey 3D2B665D. HTH, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA automatically signs keys?
On Friday 31 January 2014 01:28:20 MFPA wrote: mid:1703510.WrKrPo3DPU@mani, Johannes Zarl wrote: If the same email-address is used together with the same key for a long time, it effectively ties the email-address to a person for all practical concerns. After all, you are communicating via email with someone you have never seen. Didn't two or three people on this list all use the same key to sign messages to this list a few years ago, for quite a while before anybody noticed? If a mail program were to implement this automatic-persona-signature scheme, that wouldn't prevent this kind of fooling around. But I still think it could improve the awareness for this sort of thing (beyond the current state as described in xkcd: https://xkcd.com/1181/) If the initial communication was subject to a MITM-attack, the key would change as soon as the MITM attack stops or gets sidestepped. The quality of this canary improves with the number of signatures over an extended time. If the MITM attack lasts an extended time all the signatures would be on the key of the MITM-attacker... You are right - that's the implicit problem in a system without trust-anchor: you only ever can prove that a problem occurred, not that everything is fine. Basically it's a physical approach instead of a mathematical one: in mathematics you can prove everything from a few axioms (the trust-anchor). In physics you can never be certain, but we keep watching the world and whenever we spot an inconsistency with our model we investigate. In either scenario, you would notice that something was afoul as soon as the key changes and investigate. You _might_ notice. If a mail program implements this (and automatic signing would need explicit support from the mail program), then it would also implement a notification. Implementing the auto-signing part without using the information for spotting problems is like implementing PGP without support for key expiration and revocation ;-) Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA automatically signs keys?
Hi, I've meanwhile seen that others assumed the automatic-persona certification to use exportable signatures. To clarify: As far as I understood the original idea, it would use local signatures only (preferably done with a special purpose local key only used for these signatures). If one would export these signatures, that would just DDoS the key server infrastructure for no gain. Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA automatically signs keys?
On Friday 31 January 2014 16:09:39 Steve Jones wrote: Well I was thinking of exporting at first, but it's too fraught with problems. I would in general like to see more use of persona signatures as certifying keys as good enough. Essentially I see the requirements for certifying keys as a massive barrier to entry for common use. My thoughts, exactly. After I tried out gpg for the first time I abandoned it mostly because there was no way I could establish a trust path between me and anyone outside my immediate physical neighborhood. Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Setting up shared access to gpg on a UNIX server
On Thursday 30 January 2014 11:49:47 Peter Lebbing wrote: If you're trying to achieve by the 744 what I think you're trying to achieve, namely that users can't change the files, I think you're mistaken[1]. Look at the following session I just did[2]: The thing is, you're not allowed to change any files, but you are allowed to replace those files by your own. Just in case this isn't clear to everybody already: The write-permission on the directory are the problem here, not the 744 on the file. gpg does stuff with a bunch of files in the homedir, and I suspect that some might need the permission to overwrite files one of your other users created. If one really wanted to use a shared secret key in this way (as opposed to a token), I would only share the keyrings, not the home directory. Like that (only a mockup): ls -la /opt/app/apps/dbmprod/gpg -rwxr-x--- 1 root gpgusers . -rw-r- 1 root gpgusers secring.gpg -rw-r- 1 root gpgusers pubring.gpg Limiting readability to a user group would at least limit the access to the key material w.r.t. unprivileged processes running on the same machine. gpg --secret-keyring /opt/app/apps/dbmprod/gpg/secring.gpg --keyring /opt/app/apps/dbmprod/gpg/pubring.gpg ... As to what Bob wrote in the original message: I suppose that my use of a private key without a passphrase might be of some concern, but I never figured out a better way to do this. In other words, if the single key required a passphrase, I'd have to give out that passphrase to everyone, so what would be the point? It might not make much of a difference, but having a strong passphrase would still protect copies of your key lying on some backup. Other than that, I guess Diego's advice is sound -- limiting the potential damage by using a token/smartcard. Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA automatically signs keys?
[resent, this time to the mailing list] Hi, On Thursday 30 January 2014 21:09:45 MFPA wrote: mid:20140130005844.1f0f5b54@steves-laptop, Steve Jones wrote: The advantage you have here though is the web of trust. 1 level 1 signature would probably be not enough, but 5, 10, 100..? If the signatures are made automatically be email software without verifying identity, where is the web of trust? Lots of such signatures would tie the key to the email address but not to a person. If the same email-address is used together with the same key for a long time, it effectively ties the email-address to a person for all practical concerns. After all, you are communicating via email with someone you have never seen. Otherwise, you would have exchanged keys in person. Just take this list: I don't give a damn whether Werner Koch is the real name of that guy working on that awesome piece of software. I do care about that awesome piece of software being signed by the same Werner Koch as last year. If I needed to clarify a legal issue pertaining to the German citizen Werner K., I would prefer a key that I can link to a government-issued id. Email addresses, just like phone numbers, may be re-used by a different person today to who used them last year. If someone else hijacks (maliciously or not) the email address without also infiltrating that person's PC and stealing the secret key, then the key would change. If the initial communication was subject to a MITM-attack, the key would change as soon as the MITM attack stops or gets sidestepped. The quality of this canary improves with the number of signatures over an extended time. In either scenario, you would notice that something was afoul as soon as the key changes and investigate. The result is not perfect glorious privacy, just pretty good for the average(tm) user. Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA automatically signs keys?
On Wednesday 29 January 2014 10:52:26 Robert J. Hansen wrote: Well, it could be semi-automatic. I'm only talking about persona certifications, which appear to be understood as verifying that the key and the email address are under the control of the same person. I suspect the majority of GnuPG and PGP users could not tell you what a persona-level verification means. Saying they appear to be understood as X appears to me to be a dangerous bit of conjecture. Since gnupg does equate trust level 1/persona certification to an untrusted one, that should not be a problem IMO. I like how this idea could mirror a natural web of trust - given proper MUA support. Under the assumption that an attacker can't reliably do a MITM attack on every message that is sent over an extended time period, you would place almost no trust in a fresh persona-certified key, but high trust in an old and frequently encountered key. The trust would grow with time (just like the trust into someone you know in real life). Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: time delay unlock private key.
On Thursday 23 January 2014 15:34:17 Uwe Brauer wrote: A Long time ago, IBM's proprietary OS, called CMS had a particular feature for the login: It gave you three attempts to login in. If you failed there was a time delay of 20 min, if you failed again, the time delay was prolonged to one hour, and then I think to one day. The same feature is implemented in some form in many/most contemporary login systems as well, and it makes great sense for a login system. The main reason this makes sense is that as a regular user you can't just bypass the login screen and get direct access to the hashed password value. My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. Could a time delay be implemented similar to the one I just mentioned? In contrast to the login screen example, a delay implemented by gnupg won't help you in this case. Once an attacker has access to your private key, he or she can try a brute-force attack against the passphrase using a patched version of gnupg that does not implement the delay. So in short: - a delay won't help you - protect your private key so this won't happen - always use a strong passphrase Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reusing signed user ID or attribute
On Friday 17 January 2014 13:28:50 Hauke Laging wrote: IIRC then GnuPG accepts a later self-signature (overriding the revocation). IMHO that makes most sense. As long as the mainkey isn't revoked or expired why shouldn't one change one's mind? Wouldn't that have huge implications for the security(*) of the whole system? If the revocation is a final act, as long as I can make sure that the revocation certificate reaches my communication partners I can be sure that nobody can compromise the key and reenable it and start impersonating me. If, however, the revocation is only a temporary act until a newer self- signature supersedes it, it would be almost impossible to effectively and permanently revoke a key. One would either (as long as the private key is not yet compromised) have to destroy the private key, or make sure that all communication partners somehow prevent the key from receiving further updates... Johannes (*) please excuse the blanket-use of the term signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On Sunday 05 January 2014 03:10:48 Leo Gaspard wrote: Well... I, personally, would attach more importance (no more validity, just importance, like in listen to me very well or whatever english people say to others to get them to listen carefully) to a message signed to an offline main key that might wait for a month than to a message sent in cleartext. For I would assume the sender designed his message to be important enough to make me move to my safe deposit box so as to read it. In my feeling this is a rather subjective (to the sender) thing: some people encrypt *every* message no matter how trivial. Other people only encrypt those messages that match some rather specific criteria. Both kinds of people have good reasons for their behaviour. That's the reason why I don't attach an intrinsic importance or anything else to the fact that a message is encrypted. I can see your reasoning behind that message feels more important, and I'm quite sure that many people feel that way. It's just that it went away for me some time after receiving the n'th encrypted grocery list. Of course, without encryption-checking, this assumption is wrong, and this is emphasized in one of my previous messages on this thread, with the We got to talk tomorrow taking importance for the receiver that is unexpected to the sender, thus leading to a security flaw. Yeah. That's definitely what I meant when I said that one should not act differently. Though if you want a really fancy policy you could require non-encrypted messages to be discarded and use the signed-but-not-encrypted communications for counter-intelligence. *g* (Yes, I know the flaw here is not-so-subtle...) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign encrypted emails
On Saturday 04 January 2014 16:09:51 Leo Gaspard wrote: On Fri, Jan 03, 2014 at 07:31:29PM -0500, Daniel Kahn Gillmor wrote: In your example, the fact that a message was encrypted makes the recipient treat it as though the sender had indicated something specific about the message because it was encrypted. This is bad policy, since there is no indication that the sender encrypted the message themselves, or even knew that the message was encrypted. Which is exactly the reason for which Hauke proposed to sign the encrypted message in addition to signing the cleartext message, is it not? Wouldn't one have to encrypt the signed-encrypted-signed message again to prevent an attacker from stripping away the outer signature? What would the recipient then do with the simple signed-encrypted message? Sure, there might be other ways: add a message stating to which key the message is encrypted, etc. But this one has the advantage of requiring AFAICT no alteration to the standard, and of being easily automated, for humans are quite poor at remembering to always state to which key they encrypt. Anyway, wouldn't you react differently depending on whether a message was encrypted to your offline key or unencrypted? One should certainly not act differently depending on the encryption of a message. Maybe with the one exception of timeliness: If a message is encrypted, you'll probably be ok with me reading the mail when I'm at my home computer. If a message is encrypted to my offline key, you'll be prepared to wait for a month or so (many people have their offline-key in a safe deposit box). Of course this opens way to subtle timing attacks (delaying reading a message until it is no longer relevant), but these subtle attacks can be done using simpler means (holding the message in transit). Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG launches crowdfunding campaign
Hi, Maybe my English is a little rusty, but what exactly is a spanking server? From the goteo page: The world's most trusted data encryption tool gets a new website with spanking server, platform and design. Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG launches crowdfunding campaign
On Thursday 19 December 2013 10:09:22 Robert J. Hansen wrote: Maybe my English is a little rusty, but what exactly is a spanking server? They omitted the word new. Ah! I should have thought of this. The phrase as a whole is known to me, but without the new it was only nonsense to me... it comes from the tradition of spanking a newborn child in order to spur the child into taking its first breath. ...and I have learned something new today ;-) Thanks, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Renewing expiring key - done correctly?
On Wednesday 04 December 2013 00:20:10 Hauke Laging wrote: Am Mi 04.12.2013, 00:00:21 schrieb Johannes Zarl: Sorry for asking a possibly stupid question, but how exactly does a shorter validity period get you more security? This is the security against the possibility that a) the key has been compromised and revoked and you don't know that (because your last certificate update was before the revocation publishing) Ok. b) the key has been compromised and cannot be revoked (because the owner has lost access to the secret mainkey and has neither a revocation certificate nor a (usable) designated revoker) Isn't that just a false sense of security? After all, if the key has been compromised, the attacker can just prolong the validity like the real owner would do (I guess even after the key has been expired). Imagine a certificate which is always prolonged for just one day. If this gets compromised then it will not be prolonged any more (at least not by its owner but we all love our highly secure offline mainkeys, don't we?) so everyone will notice that within hours. I'm not sure if I get that example. To me it seems either that the attacker can just renew the key as the owner would (entire key is compromised), or that the owner can just issue a revocation certificate (only subkey is compromised). On the other hand imagine a certificate which never expires and a lazy user (who seldom uses that key). Even a year after its revocation the lazy user may not have noticed the revocation yet. And thus encrypts critical information to the compromised key. Or worse (because the key owner wouldn't notice): Uses it to validate software. Ok, I can see the benefit here. So in summary, the short validity period is essentially a reminder for people to regularly check whether the key has been revoked. And the security lies not in the expiry in itself, but in forcing people to refresh their keyrings. Thanks! Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing keys on a low-entropy system
Thank you both for your detailed answers - they were really helpful for me! Johannes On Friday 08 November 2013 19:01:34 Peter Lebbing wrote: On 08/11/13 18:07, Tapio Sokura wrote: Nope, OpenPGP uses EMSA-PKCS1-v1_5, which is completely deterministic. I /think/ GnuPG doesn't need any randomness for RSA signatures. Obviously, this is all conjecture. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing keys on a low-entropy system
The hardware-RNG somehow slipped under my radar. Thanks for pointing that out. Out of curiosity: how does GnuPG deal with a system where entropy is scarce (or worse yet, where the RNG is partly predictable)? Cheers, Johannes On Friday 08 November 2013 08:31:09 René Puls wrote: Hi, On Fri, 08 Nov 2013 00:11:38 +0100 Johannes Zarl johan...@zarl.at wrote: I'm currently thinking about using a raspberry pi as a non-networked stand- alone system for signing keys. Since I haven't heard anything to the contrary, I'm pretty sure that entropy is relatively scarce on the pi. The Raspberry Pi has a hardware RNG that is supported by rng-tools, which is more than most desktop PCs have: http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis -hardware-random-number-generator/ Not sure about its quality though... René ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Signing keys on a low-entropy system
Hi, I'm currently thinking about using a raspberry pi as a non-networked stand- alone system for signing keys. Since I haven't heard anything to the contrary, I'm pretty sure that entropy is relatively scarce on the pi. How is GnuPG affected by such a low-entropy system? Will operations just take a bit longer, or can this affect the quality/security of generated keys or signatures? I heard that low entropy or a bad entropy source is generall less of a problem for RSA. Is this true? Does this affect me in practice? Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: make gpg-agent forget the PIN
Thanks! That was exactly what I was looking for. Johannes On Friday 01 November 2013 20:17:41 Peter Lebbing wrote: Hi Johannes, Is there any way to explicitly tell gpg-agent to forget the pin as well? Based on a post once made by Werner, I have this script: ---8-8--- #!/bin/sh gpg-connect-agent 'SCD RESET' /bye ---8-8--- It's called 'scforget' here. HTH, Peter. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quotes from GPG users
On Wednesday 30 October 2013 11:58:56 Sam Tuke wrote: I'll collect them and pick the best for use now and in future. Stimuli: You trust GPG with what? It's the only app that does what for you / your business? Without it you couldn't do what? I wonder why not more respondents have written about authenticity? I'm not terribly good with this sort of thing, but I'll try: My handwriting is unique. With GPG, so is my email. Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
make gpg-agent forget the PIN
Hi, I'm trying to get gpg-agent to automatically forget my credentials as soon as I leave the PC/the screen is locked. So far, I only got it half working: When I send a SIGHUP to the gpg-agent, it correctly forgets cached passphrases. The cached PIN of my OpenPGP card, however remains available. Is there any way to explicitly tell gpg-agent to forget the pin as well? Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Problems with keypad on Cherry ST-2000U card reader
Hello again, I'm just pushing this thread so it might get some attention. I'm not quite sure whether the lack of replies means that I did not formulate my question clearly or that nobody knows an answer. If it's the former: I'll gladly try to refine my question once I know what part is unclear. If it's the latter: What is the right place to ask questions regarding card reader support in gpg? Kind regards, Johannes P.S.: I did try again with gpg version 2.0.22, but the results are the same. On Friday 27 September 2013 13:36:44 Johannes Zarl wrote: Hi, I recently got my fellowship card and now try to get a working setup. My first tries with a ReinerSCT cyberjack that I had lying around did not get me anywhere, so I bought a Cherry ST-2000U which looked like it should work with the internal CCID driver. The reader is mostly working, i.e. I can't get the pin entry via internal keypad to work. Symptoms: Using pcscd (and therefore pinentry on my pc), the reader works flawlessly. Using the internal driver (after stopping pcscd), gpg --card-status works fine. When an operation needs the pin, the reader switches correctly into pin entry mode (judging by the leds). Regardless of whether I enter the correct pin or an incorrect one, after pressing the ok/green key, the operation is aborted. Using gpg (not gpg2), I get the following message after hitting ok: gpg: sending command `SCD PKDECRYPT' to agent failed: ec=6.55 Except for this additional message, gpg and gpg2 behave exactly the same. I'm using the following versions (on Debian sid): gpg (GnuPG) 1.4.14 gpg (GnuPG) 2.0.21 libgcrypt 1.5.3 Card info: Version ..: 2.0 Manufacturer .: ZeitControl Card reader (lsusb): Bus 006 Device 003: ID 046a:003e Cherry GmbH SmartTerminal ST-2xx Any idea what could be the problem or how I can debug the issue? Thanks, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Problems with keypad on Cherry ST-2000U card reader
Hi, I recently got my fellowship card and now try to get a working setup. My first tries with a ReinerSCT cyberjack that I had lying around did not get me anywhere, so I bought a Cherry ST-2000U which looked like it should work with the internal CCID driver. The reader is mostly working, i.e. I can't get the pin entry via internal keypad to work. Symptoms: Using pcscd (and therefore pinentry on my pc), the reader works flawlessly. Using the internal driver (after stopping pcscd), gpg --card-status works fine. When an operation needs the pin, the reader switches correctly into pin entry mode (judging by the leds). Regardless of whether I enter the correct pin or an incorrect one, after pressing the ok/green key, the operation is aborted. Using gpg (not gpg2), I get the following message after hitting ok: gpg: sending command `SCD PKDECRYPT' to agent failed: ec=6.55 Except for this additional message, gpg and gpg2 behave exactly the same. I'm using the following versions (on Debian sid): gpg (GnuPG) 1.4.14 gpg (GnuPG) 2.0.21 libgcrypt 1.5.3 Card info: Version ..: 2.0 Manufacturer .: ZeitControl Card reader (lsusb): Bus 006 Device 003: ID 046a:003e Cherry GmbH SmartTerminal ST-2xx Any idea what could be the problem or how I can debug the issue? Thanks, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
