Re: get OpenPGP pubkeys authenticated using German personal ID
On Wed, 14 Jun 2023 10:22:36 +0200, Andre Heinecke via Gnupg-users wrote: > And the link to the website how to get a PGP Software linking to that fishy > "openpgp.org" website which lists Gpg4win as "Outlook software" on the same > level with Gpg4o? And which links to Claws mail as PGP software to get a Key? > WTF.. has no one even checked how a user with no technical understanding > should navigate this? I mean would 2-3 Screenshots how to generate a PGP key > be too much to ask instead of loosing the user on a confusing website that > lists PGP Mail clients? What do you mean by fishy? openpgp.org is maintained as a community project by Dominik, one of the developers of Open Keychain. Anyone can suggest improvements, and 159 people have contributed over the years. https://github.com/OpenPGP/openpgp.org/graphs/contributors That hardly seems to be shady or suspicious. I don't disagree that the text could use improvement. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --auto-key-retrieve fails for some keys
On Tue, 02 Nov 2021 18:35:01 +0100, Phil Pennock via Gnupg-users wrote: > On 2021-11-02 at 16:05 +0100, Tadeus Prastowo via Gnupg-users wrote: > > The signature on a Linux kernel can be verified successfully using > > `--auto-key-retrieve', but the signature on an Emacs cannot be > > verified in the same manner because gpg is unable to retrieve the > > needed public key automatically. > > > Any idea why the --auto-key-retrieve feature fails for some keys? > > % gpg --list-packets < emacs-27.2.tar.xz.sig > # off=0 ctb=89 tag=2 hlen=3 plen=284 > :signature packet: algo 1, keyid 91C1262F01EB8D39 > version 4, created 1616673188, md5len 0, sigclass 0x00 > digest algo 2, begin of digest 77 61 > hashed subpkt 2 len 4 (sig created 2021-03-25) > subpkt 16 len 8 (issuer key ID 91C1262F01EB8D39) > data: [2048 bits] > > % gpg --list-packets < linux-5.11.tar.sign > # off=0 ctb=89 tag=2 hlen=3 plen=563 > :signature packet: algo 1, keyid 38DBBDC86092693E > version 4, created 1613380292, md5len 0, sigclass 0x00 > digest algo 8, begin of digest dc ca > hashed subpkt 33 len 21 (issuer fpr v4 > 647F28654894E3BD457199BE38DBBDC86092693E) > hashed subpkt 2 len 4 (sig created 2021-02-15) > subpkt 16 len 8 (issuer key ID 38DBBDC86092693E) > data: [4096 bits] > > The shorter keyids are known to be spoofable if someone is willing to > put enough effort into repeatedly generating keys. So I can well > believe that without the full issuer fingerprint, gpg declines to > automatically retrieve the key. This doesn't make sense to me. Sure, someone could do a second pre-image attack on a 64-bit key id. But, when gpg downloads the bad certificate and checks the signature, it will consider the signature bad. At that point, gpg could just throw the downloaded certificate away. But if the signature is good, then gpg can be certain that it has the right certificate for the signature. (Whether the certificate is authentic is another matter, of course.) :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust-model and federated lookups
Hi Phil, On Fri, 22 Oct 2021 17:00:11 +0200, Phil Pennock via Gnupg-users wrote: > When evaluating the trust we have in the identity attached to a key, I > often see "WARNING: We have NO indication whether the key belongs to the > person named as shown above"; at the same time, `--with-key-origin` for > the very same key will show "origin=wkd". > > GnuPG uses the trust-model option to decide how to evaluate the trust we > have in a key. I've looked through the options, and checked the release > notes for the 2.3.x series to confirm nothing new there. > > I'm currently using "trust-model tofu+pgp"/"tofu-default-policy unknown" > > I think what I _want_ is `trust-model pgp+federated+tofu`, which means, > in order: (1) any sigs from the WoT; (2) origin information from the > key, if the origin shows the key was safely retrieved from a federated > origin in a provable way (WKD, various DNSSEC storage options, etc); (3) > TOFU as a fallback if there's nothing better. > > I might even just want `trust-model pgp+federated` if I'm feeling more > cautious. But in reality tofu helps a little. > > Does this make sense to people? Is there a security problem with this? > Does this seem like a reasonable feature request? This absolutely makes sense. One way to model this in the web of trust is to imagine that you have a "WKD key," which you consider a partially trusted introducer, and which certifies keys that you retrieve via WKD. Practically, it's a bit more complicated using the available mechanisms. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate
On Fri, 19 Mar 2021 08:33:17 +0100, Robert J. Hansen via Gnupg-users wrote: > > > The next default is ECC (ed25519+cv25519) which is supported by most > > OpenPGP implementations. Only if you have a need to communicate with > > some niche implementaions you need to use rsa3072. > > Last I checked, Thunderbird 78 did not support ed25519+cv25519 > keys. That's not a niche implementation. Thunderbird 78's default OpenPGP implementation is rnp. According to the interoperability test suite, rnp is able to use the "Alice" key from the "OpenPGP Example Keys and Certificates" I-D. https://tests.sequoia-pgp.org/#Encrypt-Decrypt_roundtrip_with_key__Alice_ https://tools.ietf.org/html/draft-bre-openpgp-samples-00#section-2 The "Alice" certificate uses: Primary key algorithm: Ed25519 Subkey algorithm: Curve25519 Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Fri, 22 Jan 2021 23:59:36 +0100, Andrew Gallagher via Gnupg-users wrote: > On 22/01/2021 17:29, Daniel Kahn Gillmor via Gnupg-users wrote: > > this is a non-backward-compatible change to the format, so i think > > that's probably not a great outcome. > > I can't help thinking that length fingerprinting and padding oracles are > a general concern, and therefore more appropriately solved at a lower > layer of the network stack. Padding needs to happen as close to the application as possible. Consider the case where an application has two possible responses: a 1 bit response and a 100 MB response. Most padding schemes won't obfuscate these two responses. Using dkg's suggestion, all 1-bit responses would be padded to 4k and hence all responses would still be fully distinguishable. For a padding scheme to be useful, many different types of messages must end up in the same size bucket. Ensuring that requires application-specific knowledge. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Thu, 21 Jan 2021 17:10:31 +0100, Daniel Kahn Gillmor wrote: > For WKD services which cannot control their webserver to disable > compression, and automate padding, a better approach would be to pad > each published key with an OpenPGP literal data packet, whose content is > filled with a high-entropy (uncompressable) stream. > > Implementations that can parse OpenPGP packets will identify and discard > this packet (it is not part of any legitimate OpenPGP certificate); it > can't be easily compressed (due to the high entropy); and there won't be > any confusion about where the certificate ends, if the actual > certificate itself happens to end with any trailing nul octets. Please don't do this. This is the format of a TPK: https://tools.ietf.org/html/rfc4880#section-11.1 It doesn't allow arbitrary packets to follow it, as far as I can see. Let's stick to it. Now, there are few things we could do: we could inject a bad signature. Some implementations won't discard bad signatures, so this is probably a bad idea. We could append a public key packet with fixed creation time and MPIs, and a direct key signature, which is filled with junk. Implementations would detect this as an invalid key for several different reasons (no valid self signature, for instance). And, implementations in the know could recognize the public key packet as being padding and no even emit a warning about an invalid certificate. >If the Literal Data packet padding mechanism is used, it SHOULD be >filled with high-entropy randomness, in case some HTTPS server, >reverse proxy, or other element in the data transmission chain tries >to compress the certificate. Another approach to make the data uncompressable would be to encrypt the keyring with, say, AES and include the key. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD Checker
On Mon, 18 Jan 2021 17:12:56 +0100, Stefan Claas wrote: > I repeat here once again GitHub has a *valid* SSL cert. You're right. github has a valid TLS certificate. But that valid TLS certificate is not valid for openpgpkey.sac001.github.io. That's just the way it is, sorry. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Mon, 18 Jan 2021 16:47:38 +0100,
Ángel wrote:
> So, while in the first case a bad certificate would be a critical
> failure, in the second the right thing would be to fetch the key
> *even if the certificate was invalid*, as it is used purely for
> discovery.
When you look up the openpgpkey.example.org domain, you are revealing
to anyone snooping DNS traffic that you are using OpenPGP and are
looking for a key related to example.org. That's a privacy issue.
When you send the HTTP GET request, you reveal what email address you
are interested in (yes, it is obfuscated by the hash, but that can
often be broken using a dictionary attack). That's an even bigger
privacy issue.
Given how easy it is to get a valid TLS certificate using Let's
Encrypt, I think it is better to flatout reject invalid TLS
certificates.
> - Should the client attempt to detect openpgpkey wildcard records and
> ignore the advanced method in such case? (this also covers ISP
> hijacking NXDOMAIN, which I also thought in)
> While it's easy to detect when this seems to be the case, that's still
> an heuristic, and why should I be prevented from serving WKD from a
> wildcard dns record if I want to ?
It's an interesting idea. But I'm afraid that it really complicates
the WKD client's implementation for marginal security improvements.
> - An idea that seems worth considering, inspired by the way flowcrypt
> does its check, is to fall back to the direct method if the openpgpkey
> subdomain exists but it doesn't serve a policy file.
>
> This would solve the issue of non-malicious NXDOMAIN hijackings or DNS
> wildcards (assuming the certificate was valid).
That's a neat idea.
> How do you envision the users to use WKD? I would generally expect key
> retrieval to be a manual action, performed either from command line or
> a GUI client, but in both cases it would be possible to show a
> diagnostic about the non-working WKD.* And, even if the MUA was
> configured to automatically fetch the recipients key every time, it
> still needs a way to report back whether the message will be sent
> encrypted, there is no key or it isn't trusted. Unless OpenPGP is being
> used in a purely opportunistic way.
First, I'd regularly refresh keys in the background using all
available methods (WKD, multiple keyservers, gpg sync-style key lists)
using something like parcimonie:
https://github.com/EtiennePerot/parcimonie.sh
Second, for key discovery, there are two main types of users. For
security-sensitive users (people whose threat model includes dying if
this type of information is revealed), we should probably make key
discovery via WKD a manual operation. For privacy-sensitive users,
I'd just transparently, and automatically look for a key when the user
types in an email address. For a bit more privacy, one could wait
until the user presses send so that any WKD lookup will normally
immediately be followed by an SMTP connection to the same domain. If
key discovery fails, the MUA could show an error ("can't encrypted,
because..."), or just send the message unencrypted, like Signal.
:) Neal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
On Mon, 18 Jan 2021 13:42:52 +0100, André Colomb wrote: > On 18/01/2021 10.14, Neal H. Walfield wrote: > > In short: I understand the motivation for the subdomain. I understand > > why one should first check there. But, I think we do our users a > > disservice by not falling back to the direct method in the case of > > DNS errors. > > I suppose you mean other errors besides DNS? Right, sorry! > We need to remember that WKD is only a convenience mechanism for > discovery, not any kind of authentication. Sending encrypted e-mail to > a domain which was also used to retrieve the encryption public key adds > no protection against MITM, but only transport obscurity. But that > might still be better than no encryption at all, e.g. to set up an > out-of-band key verification. I agree. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
Hi Angel, On Thu, 14 Jan 2021 01:47:12 +0100, Ángel wrote: > On 2021-01-13 at 10:12 +0100, Neal H. Walfield wrote: > As such, I do think sequoia is non-conformant, although I'm > more interested in determining the proper behaviour of a WKD client. > > ... > I think it would be good that sq stopped after processing > > openpgpkey.foo.com, mainly to follow the principle of least surprise. > > If the key can only be placed in one place, then it MUST be good (or > bad, but it will be consistent). I've given this issue some more thought. First, I don't think WKD is a strong authentication method. It is sufficient for doing key discovery for opportunistic encryption (i.e., it's a reasonable guess), but I wouldn't want someone to rely on it to protect them from an active adversary, or phishing attempts. If you consider WKD to be a strong authentication mechanism, then you are basically relying on X.509 plus a bit of brittleness (the certificates aren't signed, only the TLS session is). So, if that's your position, then just use S/MIME. One way to increase protection for certificates is to certify them in the usual OpenPGP manner. Of course, this begs the question: if you certify them before you get them via WKD, is WKD really helping with key discovery? Well, OpenPGP doesn't only have certifications, it also has trusted introducers, i.e., CAs. So, a certificate could be certified by someone else. Isn't that just X.509? Well no, X.509 de facto relies on a few hundred global CAs (Symantec, TurkTrust, etc.), but in OpenPGP everyone is by jure a CA. So, a domain administrator could just set up a CA for their own domain. (In fact, OpenPGP CA [1,2] makes this pretty easy.) This results in a federated system! Now, individuals "just" need to designate a few CAs. Yes, it is still work, but it is much less work. As admins are more technically sophisticated, there are other things that they can do to improve security. But, that's getting a bit off topic. [1] https://gitlab.com/openpgp-ca/openpgp-ca [2] https://openpgp-ca.gitlab.io/openpgp-ca/ Second, the attack that I'm most worried about with repect to WKD is a DoS. It is trivial for an attacker to block WKD. They just need to filter the DNS. In the privacy world, there are a lot of tools to do just that. For instance, pi hole [3] blocks ads at the DNS level. It could just as well be used to force the openpgpkeys subdomain to revolve to localhost. Comcast, a major US ISP, used to do this type of interception as a way to increase revenue: if a user typed in an invalid domain, instead of return NXDOMAIN, Comcast would resolve it and show the user some ads instead [4]. AIUI, they stopped doing this due to general outrage, but that is little solace. [3] https://docs.pi-hole.net/main/post-install [4] https://www.pcworld.com/article/169723/article.html This attack is likely to go unnoticed, firstly because most key discovery is done in the background, and probably shouldn't actively show errors messages to the user. But, more importantly, because nothing else uses the openpgpkeys subdomain, everything else will still appear to work! In short: I understand the motivation for the subdomain. I understand why one should first check there. But, I think we do our users a disservice by not falling back to the direct method in the case of DNS errors. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD proper behavior on fetch error
Hi Stefan, On Sun, 17 Jan 2021 19:41:44 +0100, Stefan Claas via Gnupg-users wrote: > Please try to accept that GitHub (and maybe in the future others as well) > has *no* bad certificate! As others have tried to explain: the certificate that github uses for sub.sub.github.com is invalid for sub.sub.github.com; that certificate is only valid for sub.github.com and github.com. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
WKD Checker
On Sun, 17 Jan 2021 19:27:05 +0100, Ángel wrote: > I feel there is a need for a proper wkd test suite (as well as a > clarifying on the draft itself the things that are coming up). FWIW, there is Wiktor Kwapisiewicz's wkd checker: https://gitlab.com/wiktor-k/wkd-checker https://wkd.sequoia-pgp.org/ This is more for checking a WKD setup than checking a WKD client. I'm sure he'd be open to issues for things that he missed. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD & Sequoia
Hi Andre, On Tue, 12 Jan 2021 20:13:42 +0100, André Colomb wrote: > It has also been pointed out repeatedly in this thread that Sequoia > apparently does not properly check the TLS certificate, which you have > proven with your example setup. That could be called "modern" or > "insecure". It has nothing to do with the ordering of the two methods. I'd like to clarify what Sequoia is doing (wrong). As per the I-D, sq first tries the advanced method. If that fails for any reason, it falls back to the direct method. You can see the three relevant lines of code here: https://gitlab.com/sequoia-pgp/sequoia/-/blob/c80d2ab0/net/src/wkd.rs#L288 If I remove the "or_else", which falls back to the direct method, then sq shows the following error when fetching ste...@sac001.github.io: $ sq wkd get ste...@sac001.github.io Error: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) Caused by: 0: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) 1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: So, the hostname mismatch is correctly identified, and it correctly returns an error. Where sq's behavior diverges from gpg's is that sq then tries the direct method, but gpg does not. The latest WKD I-D says: 3.1. Key Discovery There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 (FWIW, this was added to revision 7, which was published in Nov. 2018.) The I-D says "Only if the required sub-domain does not exist, they SHOULD fall back to the direct method." The text doesn't say: "If there is an error, they SHOULD fallback to the direct method unless the required sub-domain does not exist, in which case they MUST NOT fall back to the direct method." So, strictly speaking, I don't think Sequoia is violating the specification. But, I don't want to be overly pedantic. Even if the spec were to prohibit falling back to the direct method when the subdomain exists, what exactly would this prohibition gain us? We thought about this question, but we couldn't figure out a satisfactory answer. The worst attack we could come up with is: an attacker could force a WKD client to use an illegitimate WKD via the direct method instead of a legitimate WKD via the advanced method by: - Taking over foo.com's https, AND - Preventing a WKD client from correctly using the advanced method. But the attacker is NOT able to: - Take over openpgpkey.foo.com's https, OR - Prevent the WKD client from resolving openpgpkey.foo.com. So sure, that's possible, but it seems like WKD shouldn't foo.com's biggest worry in that case. (If we overlooked possible attacks, I'd be happy to hear about them.) On the other hand, implementing this prohibition means that a DNS server can prevent its clients from using WKD by forcing all openpgpkey subdomains to resolve to 127.1. That's hard to notice, because everything else still appears to work. Practically speaking, we helped an organziation deploy WKD, and they had a similar problem to what Stefan is observing: the admins setup the direct method, but it didn't work, because their DNS automatically resolved all unknown subdomains to serve a 404. Unfortunately, they had outsourced management of their DNS and couldn't (or didn't know how) to disable this behavior. IIRC, in the end, they spun up an https server for openpgpkeys.domain. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WKD for GitHub pages
Hi Stefan, On Fri, 08 Jan 2021 23:05:52 +0100, Stefan Claas via Gnupg-users wrote: > On Fri, Jan 8, 2021 at 10:21 PM Stefan Claas > wrote: > > > I guess the only way to fix it (for many people) would be > > that, as of my understanding (now) the WKD check > > and SSL cert check would be a bit more flexible, either > > in allowing subdomains, like the github.io ones in form > > of a fix in the code or as setting in GnuPG' config file. > > > > I could be totally wrong of course, so let's see what > > Werner says. > > Well, I guess I am right, just did a gpg --debug-level guru > under cmd.exe: > > ... > gpg: DBG: chan_0x0254 -> WKD_GET -- ste...@sac001.github.io > gpg: DBG: chan_0x0254 <- S SOURCE https://openpgpkey.sac001.github.io > gpg: DBG: chan_0x0254 <- S NOTE tls_cert_error 285212985 bad cert > for 'openpgpkey.sac001.github.io': Hostname does not match the > certificate > gpg: Hinweis: Der Server benutzt eine ungültiges Zertifikat > gpg: DBG: chan_0x0254 <- ERR 285212985 Falscher Name It appears that gpg is trying the advanced lookup method, gets an error, and then doesn't fallback to the direct lookup method. This is consistent with the I-D: 3.1. Key Discovery ... There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07 It appears that github.com's DNS is configured such that all domains under github.com resolve to github.com's web server, even subsubdomains. For instance, https://asdflkjasdfj.asdflkjasdflkj.github.com/ resolves to a 404. So, it seems that you'll need to create openpgpkey.sac001.github.com. Further, you'll have to figure out how to get a valid certificate for it. At least Firefox considers github.com's certificate to be valid for foo.github.com, but not bar.foo.github.com. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Avoid recipient-compatibility SHA1
Hi Stefan, A chosen-prefix collision attack works as follows: an attacker chooses two message prefixes, and then uses near collisions blocks (in the SHA-1 is a Shambles paper they needed about 10 such 512-bit blocks) to align the internal state of the two hashes. Since SHA-1 is a streaming function, the attacker can also append a common suffix. That is, we want: Hash(prefix #1 || near collision blocks #1 || suffix) = Hash(prefix #2 || near collision blocks #2 || suffix) And the attacker can choose prefix #1, prefix #2, and suffix, but cannot control near collision blocks #1 or near collision blocks #2. One way to exploit this is to create a pair of colliding documents (e.g., something benign and a will), and then convince Alice to sign the benign one. If successful, the signature can be transferred to the other document, and it appears that Alice has sign it too! This attack requires the attacker to hide the near collision blocks in the documents. This is often straighforward: most formats have provisions for comments, or metadata, which the user does not see. The difficulty is to get Alice to sign the first document: if she modifies it (e.g., adds any context), then the hash will be different. But, if Alice is a signing service, then this may be possible even if Alice modifies the document as long as the modifications are predictable. On Wed, 18 Nov 2020 14:30:12 +0100, Stefan Claas via Gnupg-users wrote: > Mallory has managed to listen to the clear text communications from > Alice and Bob's online devices. Alice and Bob always use GnuPG > to digitally sign their messages. > > Mallory is *not* in possession of the private keys from Alice and Bob. > Mallory has created a document which causes a collision and was > signed with his own key. This is currently not possible. What you describe is a preimage attack, not a collision attack. A preimage attack is when you can create a document with the same hash as an existing document. Right now, it is possible to find two documents that collide, but you can only partially control the content of each of them (i.e., you need to add the near collision blocks to both to actually create the collision). :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Show that an encrypted message was signed, without decrypting it
Hi Teemu, On Sun, 11 Oct 2020 11:02:00 +0200, Teemu Likonen wrote: > * 2020-10-11 02:40:28+02, Stefan Claas wrote: > > > I was reading old GnuPG threads were people were asking if it's > > possible to extract a signature from an encrypted message. > > It seems that there is a visible signature packet in encrypted and > signed messages. See the output of this command: > > echo message | gpg --encrypt --sign --default-recipient-self | \ > gpg --list-packets The signature information is normally (that is, when doing sign then encrypt) completely encapsulated by the encryption container. What I think you are seeing is gpg caching something. If you replace 'gpg --list-packets' with 'pgpdump', then you probably won't see any signature information. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Which keyserver
Hi Andrew, On Sat, 19 Sep 2020 21:38:22 +0200, Andrew Gallagher wrote: > Hagrid “solves” the vandalism problem by abandoning > decentralisation. This is not strictly true. When we think about updating keys, there are two types of information that can be updated: - Identity Information (User IDs) - Operational Information (Revocations, Subkey Rotations, Metadata (self-sig) updates, etc.) Identity information in privacy sensitive, and we think people should be able to control where their details are published, and have the ability to retract them, if desired. This requires some type of centralization. Operation Information does not require the same protection, and can and should be widely published. It would be possible to create a network of keyservers that synchronize this type of information in a similar way to how SKS worked. But, we know from experience with SKS that this is not easy (the set of filters needs to be synchronized, etc., which is a type of centralization). So far, no one has taken the time to think through this problem, and implement a solution for Hagrid. But, I think that we'd welcome a patch that adds such functionality. :) Neal ___ 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
At Tue, 20 Feb 2018 16:08:35 +0100, Werner Koch wrote: > > Yet another complementary approach might be to aggressively police the > > ecosystem by finding other software that deends on GnuPG in any of the > > aforementioned brittle ways, and either ask those developers to stop > > That is what our plan for the time after 2.2 was. Unfortunately, this > seems to be a boring job for some hackers and thus some of them opted to > leave gnupg to work on cool new stuff instead. Nevertheless, this is > still high on my task list. I'd rather not air dirty laundry, but I feel it necessary to correct misinformation. I did not leave g10code, because working on gpg was "uncool". I left because we (Werner and I) could not work well together. This is the same reason that Justus, Kai and Marcus left. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Expected behaviour setting TOFU policy
Hi, At Thu, 15 Feb 2018 17:20:14 -0500, Konstantin Ryabitsev wrote: > But wait, now I can omit --trust-model from the command line and I get the > same > TOFU-based result, implying that trust-model tofu+pgp now sticks, even though > I've modified no config files: If you don't explicitly set the trust model, then gpg uses the trust model that is saved in the trust db. Using --tofu-policy doesn't use the trust db (it only updates tofu.db), but --verify does. Hence after calling --tofu-policy, the trust mode is not saved, but after calling --verify it is. In general, it is better to set the trust-model in your gpg.conf file and never set it on the command line if only because rebuilding the trust db is very expensive for large key rings. I suspect that there are other bugs of this sort, and I'm not sure it is worth fixing. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ and GNU
At Wed, 11 Oct 2017 17:47:29 +0200, Werner Koch wrote: > On Wed, 11 Oct 2017 09:15, n...@walfield.org said: > > > I'm aware of an effort that tried to port GnuPG to Android. bionic > > was a source of several problems. As far as I know, the work is > > Actually we solved the Bionic problems a long time ago. The major > problem was actually custom pinentry for android. That has been > written and I have seen reports that everything worked. That's great to know, thanks! Unfortunately, it appears that there have either been regressions or the people that I spoke with made some mistakes. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ and GNU
At Wed, 11 Oct 2017 08:26:21 +0200, Werner Koch wrote: > On Tue, 10 Oct 2017 20:55, b...@adversary.org said: > > > Has anyone managed to get any part of the GPG libs to compile on > > Android/Linux? As far as I'm aware no one has and all OpenPGP > > There might be a problems with the current release but GnuPG is expected > to build for Android just fine. And on AIX and HP/UX. There might be > build problems but that are bugs we need to fix. I'm aware of an effort that tried to port GnuPG to Android. bionic was a source of several problems. As far as I know, the work is currently stalled. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ and GNU
At Tue, 10 Oct 2017 23:55:32 -0400, Robert J. Hansen wrote: > > > Amazing how much people want to comment on the color of this > > particular bikeshed! > > I agree. Bikeshedding frustrates me: I'll leave it at that. > > Reviewing the last forty-odd emails on the subject, there are a small > number of regular contributors to the community who are in favor, a > small number opposed, and a smaller number of mostly-lurkers who have > exceptionally strong feelings. > > I do not see a community consensus one way or another. I'll continue > with my original plan. I didn't realize that there was a vote. FWIW, I agree with dkg, although I'm not particularly passionate about it. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU db corruption detected
Hi, Unfortunately, there isn't enough information in this report to reproduce your issue. If you feel comfortable sending me your TOFU db and your pubring.gpg / pubring.kbx per private mail, as well as telling me which key that is causing the problem, then I will take a look. Key: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Thanks, :) Neal On Sat, 05 Aug 2017 16:56:02 +0200, MFPA wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > gpg: TOFU db corruption detected. > gpg: (further info: user id '[jpeg image of size 24800]' not on key > block 'Fingerprint') > > > I see the above message when encrypting to the key whose fingerprint I > have redacted above. The copy of that key on my keyring does contain > an image, which I can view by > gpg --list-options show-photos --list-keys Fingerptint. > > > How do I "rebuild" the TOFU database to get rid of the corruption? > > > - -- > Best regards > > MFPA
Re: Test symmetrically encrypted files for errors - make sure they can be decrypted
At Sat, 22 Jul 2017 00:01:45 +0200 (CEST), wrote: > I am using GnuPG 1.4.x to symmetrically encrypt files before I > transfer them to "the cloud" for backup reasons. > Is there any way to test these encrypted files for errors, i.e. to > make sure they can be decrypted correctly without actually having to > decrypt them again? > Providing the passphrase again etc. is no problem, I only want to > avoid to write the whole file to my disk a third time (unencrypted > original, encrypted backup, decrypted test). > If I can test the file somehow will I get back an errorlevel on > success or error? > In short I am searching for something like the test option for packed > files that most archivers offer. Probably the easiest solution is to sign and encrypt, and then verify the signature. If the encrypted data is somehow corrupted, then the signature will be wrong. This, of course, embeds the signature in the OpenPGP message, which might not be desired. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP Notations
Hi,
I'm collection examples of notations. If you somehow use notations,
I'd love to hear how you are using them. (If you prefer to remain
anonymous, please feel free to reply privately.)
Also, I'm curious if anyone has a good use for unsigned ("unhashed")
notations.
Thanks!
:) Neal
Key: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are TOFU statistics used for validity or conflict resolution?
At Fri, 23 Jun 2017 13:45:39 +0300, Teemu Likonen wrote: > I don't know whether my thinking is common but perhaps it would be > helpful if gpg's man page made clear that on conflict situation both > keys go to "ask" mode. A quote from my gpg 2.1.18 manual: I tried to improve the documentation in 243b2a570. Thanks for the suggestion. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
At Tue, 27 Jun 2017 09:27:57 +0100, MFPA wrote: > On Monday 26 June 2017 at 10:31:04 AM, in > , > Goddess: Primal Chaos wrote:- > > > > Dear player, Thank you very much for contacting us > > by mail. > > > I've seen several of these messages on this list lately. It looks like > somebody has subscribed a customer helpline email address > to the list. These should now be disabled. Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
At Mon, 26 Jun 2017 11:27:30 +0200, martin f krafft wrote: > > Martin, I think --no-auto-check-trustdb and a cron job will > > already make it much more bearable, with the current state of > > things. That's what I'd suggest. > > I've been doing that for a long time already, and yes, it mitigates > the issue a little bit. I still think that the interface doesn't > exactly invite people to invest time into the WoT, which directly > translates into lesser quality. I disagree that this is the bottleneck. Two very strong arguments against the WoT, IMO are: 1. Key signing is too hard to do right. 2. Key signing exposes the social graph. 1 means that people primarily interested in protecting their privacy don't bother. 2 means that organizations like the Organized Crime and Corruption Reporting Project (OCCRP) can't use the WoT, because it places their reporters and sources in danger. We could perhaps fix 1 by doing more red teaming (i.e., fake attacks so that people see the actual utility of checking keys), but I'm not sure that's the best way forward. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU
At Fri, 23 Jun 2017 02:07:19 +0100, MFPA wrote: > On Wednesday 21 June 2017 at 7:49:42 PM, in > , Peter > Lebbing wrote:- > > > I think it's a bad UX choice to > > name an invalid > > signature "UNTRUSTED Good" and a valid signature > > "Good". I think it > > suggests they both have some credibility, which is a > > false suggestion. > > I thought "good signature" just meant the message has not been > altered in transit. Nope. A MitM could have intercepted the message and replaced the body with some other signed text (text that it possibly signed with a "fake" key). HTH, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
At Fri, 23 Jun 2017 13:04:02 -0400, Brian Minton wrote: > > [1 ] > On Fri, Jun 23, 2017 at 03:50:27PM +0200, Neal H. Walfield wrote: > > > > Ensuring that a cache is consistent is *hard*. I don't think we want > > to add complexity (nevermind a cache!) to this security-critical > > functionality. > > > > Neal (or Werner), what executable is responsible for maintaining the trustdb? > Is that handled by gpg itself? gpg does it, yes. See gnupg/g10/trustdb.c:validate_keys ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
At Fri, 23 Jun 2017 15:35:05 +0200, martin f krafft wrote: > also sprach Werner Koch [2017-06-22 19:02 +0200]: > > For a key listing this means computing it for every listed key. And the > > majority of frontends first do a key listing and show the validity of > > the keys before you can encrypt something. > > Obviously, one could work with caching here… > > Running --check-trustdb in the background once a day is doable, for > sure. > > I guess what I'd really like is a way to run --update-trustdb just > for a specific key, and a way to do that automatically when using > a key, e.g. to verify or encrypt to… Ensuring that a cache is consistent is *hard*. I don't think we want to add complexity (nevermind a cache!) to this security-critical functionality. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are TOFU statistics used for validity or conflict resolution?
At Fri, 23 Jun 2017 13:22:23 +0200, Peter Lebbing wrote: > On 23/06/17 12:56, Neal H. Walfield wrote: > > It's up to the GPG client to interpret it. This document (authored by > > Andre and me) has some recommendations for MUAs: > > Ah! Thanks for the information. > > I was thinking about how GnuPG handled it, i.e., on the gpg command line > or as a backend for some frontend. I got the impression the "validity" > field affected the text of the gpg command line but nothing else > (g10/tofu.c:show_statistics() returns "show_warning" asserted for > valdities below 3). You're right: gpg also uses this information to display some information. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are TOFU statistics used for validity or conflict resolution?
At Fri, 23 Jun 2017 12:52:48 +0200, Peter Lebbing wrote: > > [1 ] > On 23/06/17 11:14, Neal H. Walfield wrote: > > No, both keys are set to ask. The key with a lot of observed > > signatures could be bad. This could occur, if there is a MitM, but > > the MitM has a small lapse, because, perhaps, you've used an > > unintercepted network path to retreive the "new" signature & key. > > So if I understand correctly, the "summary"/"validity" field merely > affects the text that is displayed to the user when displaying TOFU > statistics? It's up to the GPG client to interpret it. This document (authored by Andre and me) has some recommendations for MUAs: https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are TOFU statistics used for validity or conflict resolution?
At Thu, 22 Jun 2017 20:32:48 +0300, Teemu Likonen wrote: > Teemu Likonen [2017-06-22 09:42:50+03] wrote: > > Does the SUMMARY field's value (0-4) have effect on how key's validity > > is calculated or how TOFU conflicts are resolved or presented to a > > user? > > I didn't get answers yet but I'll speculate a bit on the subject. This > is all about "trust-model tofu" and assume that I have _not_ set > "--tofu-policy" manually. > > Let's say that I have a key which has been used to verify a couple of > signatures. Then there comes another key with conflicting email address. > It seems that tofu goes to "ask" mode for _both_ keys (user ids). User > needs to decide and set the tofu policy for both. Correct. > Then let's say I have a key which has been used to verify hundred or so > signatures. In --status-fd's TOFU_STATS it gets higher value, > say 4. Then the keyring gets a new key with conflicting email address. > Does gpg again set both keys (user ids) to tofu's "ask" mode or does > this higher number of good verifications automatically keep the first > key in "auto" mode and only the new key is set to "ask" mode? No, both keys are set to ask. The key with a lot of observed signatures could be bad. This could occur, if there is a MitM, but the MitM has a small lapse, because, perhaps, you've used an unintercepted network path to retreive the "new" signature & key. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are TOFU statistics used for validity or conflict resolution?
At Thu, 22 Jun 2017 09:42:50 +0300, Teemu Likonen wrote: > It _seems_ to me that > > - Field 3 :: validity - A number with validity code. > > is the same thing as SUMMARY in TOFU_STATS. Am I right? > > And here's my question again: Does the SUMMARY field's value (0-4) have > effect on how key's validity is calculated or how TOFU conflicts are > resolved or presented to a user? TOFU influences validity. By default, all known keys are marginally trusted in the TOFU model. (This is more or less the "first use" bit of "trust on first use".) In TOFU, the validity of a key is set to unknown if there is an unresolved conflict. The user can resolve a conflict either positively (in which case the validity is full) or negatively (in which case the validity is never). Note: this means that it is possible to make negative assertions when using TOFU, which is not possible when using WoT. The summary field in TOFU_STATS is a summary of the key's use. The basic idea is that in the absence of facts to the contrary, at the limit (an infinite number of uses), a given key must have been the right one (or is indistinguishable from the correct key, which is just as good, because it means that nothing bad ever happened). In other words, a key that has been used for years is more likely to be the correct one, then one that I've only used once. In the former case, I've had many more opportunities to detect a MitM attack. The summary field captures this using a simple scale that applications can then somehow display to the user. This is currently used by kmail and the Outlook plug-in. HTH, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
Hi, I didn't say that it is not possible to have a better algorithm. It is possible. But, it is not as easy as you suggest (and what you suggest doesn't sound trivial). For instance, adding or updating a key doesn't necessarily result in equal or more trust. An update could cause a key to be revoked. In that case, if 0xdeadbeef is marginally trusted, we now need to identify keys that were considered valid because of 0xdeadbeef, but no longer are. :) Neal At Thu, 22 Jun 2017 15:00:52 +0200, martin f krafft wrote: > > [1 ] > also sprach Neal H. Walfield [2017-06-21 14:00 +0200]: > > It starts with the set of ultimately trusted keys. But let's say > > that you start with key X, which is not ultimately trusted. What > > should GnuPG do with the result? Or, let's say that X is > > ultimately trusted and it decides that key Y is only marginally > > trusted, but Y would have been fully trusted if you started with > > all ultimately trusted keys. How do you intelligently merge that? > > As far as I understand, the parameters --marginals-needed and > --completes-needed can be used to define a maximum search depth D, > so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd > envision it to > > 1. enumerate all keys reachable within D steps > > 2. iterate all these keys > > 3. backpropagate the trust/validity level towards 0xdeadbeef > > 4. update the nodes touched by this walk in trustdb > > 5. do this for every key when it changes > > 6. do this for every key upon use, such that missing information > can be interactively provided, and expired keys pruned > just-in-time. > > 7. --check-trustdb could still be used to do overall cleaning at > regular intervals. > > Given how the keygraph is essentially a singly-linked graph with > keys containing pointers to other keys that signed them, while there > exists no such information implicitly about all the keys that have > been signed *by* a given key (e.g. one that's ultimately trusted), > the approach I've sketched actually seems more intuitive, don't you > think? > > -- > @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ > > "here i was all convinced that if i sleep all day, bug counts go > down, and if I work all day, they go up, so much for that theory." >-- lars wirzenius > > spamtraps: madduck.bo...@madduck.net > [2 Digital GPG signature (see > http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) > ] > No public key for 9C9D6979AE941637 created at 2017-06-22T15:00:47+0200 using > RSA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
At Wed, 21 Jun 2017 13:55:52 +0200, martin f krafft wrote: > > also sprach Neal H. Walfield [2017-06-21 11:53 +0200]: > > > 3. Is there a way to run --check-trustdb or --update-trustdb not > > >over the entire key graph, but only traversing to a certain depth > > >starting from a specific key? Then I could tell parcimonie to run > > >--check-trustdb for every key it imports, or have mutt run > > >--update-trustdb for every key I want to use. This would > > >iteratively achieve the job with the benefit that no cycles would > > >be wasted processing trust for keys I never use. I understand > > >--edit-key can be used to change the ownertrust, but I don't > > >think it recomputes the WoT on change, does it? > > > > > >If there's no way to do this yet, would this be a useful addition > > >to the UI, assuming it's technically possible? > > > > This isn't easy given the current implementation: GnuPG doesn't store > > the graph, but traverses the graph and only saves whether a particular > > key is trusted. > > It's gotta start somewhere, though, right? Can't it pick the leaf > where to start? It starts with the set of ultimately trusted keys. But let's say that you start with key X, which is not ultimately trusted. What should GnuPG do with the result? Or, let's say that X is ultimately trusted and it decides that key Y is only marginally trusted, but Y would have been fully trusted if you started with all ultimately trusted keys. How do you intelligently merge that? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Managing the WoT with GPG
Hi, At Tue, 20 Jun 2017 15:34:44 +0200, martin f krafft wrote: > I've spent some time trying to figure out how to make actual use of > the web-of-trust (the "pgp" trust-model), and I am turning to this > list for some advice, related to a couple of questions: > > 1. My public keyring has several thousand keys and "weighs" almost >500Mb. Every couple of runs, I'm told to run --check-trustdb, >which takes several minutes to complete, then tells me that the >next run will be in like 2 weeks, but three operations later, I'm >again being asked to run --check-trustdb. The funny thing is that >these operations are just message signing and authentication, >sometimes decryption. However, parcimonie is running in the >background, updating the keyring one key at a time. Is that the >reason? If yes, is there any way to mitigate this? I've sketched >out an idea under (3.) below, but maybe there's another way…? You figured it out: whenever your keyring is updated, 'gpg --check-trustdb' needs to be run. This is normally done on demand, which is annoying for even moderately sized keyrings. You can disable this behavior by setting no-auto-check-trustdb in your gpg.conf file. In that case, you'll want to run 'gpg --check-trustdb' periodically to integrate new keys, expiry information, revocations, etc. You can do this in the background via e.g. a cron job. > 2. I've also tried running --update-trustdb, but it seems that this >process is *endless*. I have no idea how many keys remain, and >I also got the impression that I keep seeing keys I already >processed. How do you approach this? Or does everyone just use >tofu these days? Since I don't trust most people to sign keys correctly, I just invoke 'gpg --edit-key' (and use the trust subcommand) on the specific keys that I want to have as trusted introducers. > 3. Is there a way to run --check-trustdb or --update-trustdb not >over the entire key graph, but only traversing to a certain depth >starting from a specific key? Then I could tell parcimonie to run >--check-trustdb for every key it imports, or have mutt run >--update-trustdb for every key I want to use. This would >iteratively achieve the job with the benefit that no cycles would >be wasted processing trust for keys I never use. I understand >--edit-key can be used to change the ownertrust, but I don't >think it recomputes the WoT on change, does it? > >If there's no way to do this yet, would this be a useful addition >to the UI, assuming it's technically possible? This isn't easy given the current implementation: GnuPG doesn't store the graph, but traverses the graph and only saves whether a particular key is trusted. > 4. Is there a tool to visualise or explain the computed validity of >a key? I.e. one saying that e.g. Werner's key is valid because >Daniel signed it, and I fully trust Daniel? There's wotsap, but >I want to analyse my own keyring, not a .wot file… See my answer to #3: this is not currently possible. > 5. Has anyone come up with a smart way to keep pubring/trustdb >synchronised between multiple workstations? This is a pain. Something along the lines of the following should work: gpg --export | ssh host gpg --import :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: some beginner questions
Hi, At Sun, 2 Apr 2017 18:23:14 -0500, Will Senn wrote: > but at the end of > the day, I don't seem to be able to sign anything with the signing > subkey if the master key is not present (with sec instead of sec#). Do > you know how I get it to use the subkey (the manual says it will default > to a signing subkey, but that's not my experience). It would be good if you good show us what you are doing. Specifically, what your key looks like (gpg -k KEYID), and the commands you are using to sign a message, and the actual output. Also, it might be helpful for us to know the version of the gpg and what OS you are using. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: some beginner questions
At Sun, 2 Apr 2017 11:20:16 -0700, Doug Barton wrote: > On 04/01/2017 07:10 AM, Will Senn wrote: > > 3. I've read > > https://superuser.com/questions/466396/how-to-manage-gpg-keys-across-multiple-systems > > and other such pieces proclaiming the value of having the master key in > > a safe place and having subkeys on your actual devices. > > What do you think a master key is, and why do you think it's important > to protect it? What kind of devices do you want to put signing subkeys > on? Why do you think that your use of PGP will be more secure if you > have a signing subkey on a device, instead of your "main key?" Your main key is a unique global identifier. It is what you write on your business card and what you compare to validate a key. If it is compromised, then you need to revoke your main key and generate a new one. This means you have to throw away your old business cards and inform all of your contacts that you have a new key. If a subkey is compromised, then you only need to rotate the subkey, not the whole key. In other words, you don't have to throw away your business cards or inform your contacts that something has changed: their OpenPGP implementation will automatically learn about the changes the next time your key is refreshed. In short, the main key acts as a level of indirection, which separates your identity from your encryption/signing keys. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1.19 crashing when listing keys, if tofu-default-policy is "ask"
Hi, At Wed, 15 Mar 2017 00:38:45 +, MFPA wrote: > I have been having GnuPG crash with the following message when listing > keys:- > > gpg --list-keys > gpg: O j: Assertion "conflict_set" in get_trust failed > (/home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.19/g10/tofu.c:2787) > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > > > > An internet search on the message leads me to a Debian bug report [0]. > > I am using GnuPG version 2.1.19 on Windows, running the pre-compiled > Windows binaries linked from the release announcement. > > I have the "with-fingerprint" option in gpg.conf; commenting it out > makes no difference. > > I also have "tofu-default-policy ask"; changing "ask" to "unknown" > makes the problem go away. Thanks for the report and the analysis. I've just (hopefully) fixed this in b1106b4. Sorry about that! :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG and Mailinglists using IBCPRE
On Sun, 17 Jul 2016 15:53:47 +0200, Richard Höchenberger wrote: > we've been using Schleuder2 for many years now, and it has always > worked flawlessly on a medium-traffic mailing list as long as everyone > used OpenPGP/MIME. Inline PGP will cause trouble from time to time. Scleuder requires that the mail server decrypt the messages. My solution doesn't, which is what I think the OP was looking for. Of course, Schleuder is straightforward to deploy whereas mine is still a prototype. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG and Mailinglists using IBCPRE
Hi, On Sat, 16 Jul 2016 16:38:27 +0200, Martin Konold wrote: > what is currently the recommended setup for running encrypted mailing lists. > > I am thinking about some IBCPRE mechanism. see also https://en.wikipedia.org/ > wiki/Identity-based_conditional_proxy_re-encryption > > I think this would allow the mailing list software act as a proxy > reencrypting > without directly having the private key of the mailing list on the mailing > list server. > > What do you think about IBCPRE. There is some highly experimental support in a GnuPG branch for mailing list support that doesn't require that the server access the plain text. You can read about it here: http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Decrypting multiple encrypted blocks on one stream using GPG
On Thu, 07 Jul 2016 11:32:30 +0200, Fiedler Roman wrote: > I'm trying to use gnupg to solve a usecase similar to the one depicted in > [1], but the workaround from [1] is not suitable, because: > > * Each file I have is larger than the machine holding the keys > * The keys cannot be moved > * The streams will take hours/days to decrypt so no interruption is > possible. You might be able to use gpg's --extra-socket feature to solve your problem. Using this feature, gpg could do the asymmetric crypto on your small box (this just costs some KB of network traffic) and the symmetric on some other box. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Perform only asymmetric encryption/decryption
On Mon, 11 Apr 2016 10:49:32 +0200, Erik Nellessen wrote: > > If I understand it correctly, --override-session-key does not allow me to set > the session key before encryption. It allows me to set the session key when > decrypting, so I can do it without using the private key. The option is used > to reveal the content of messages without revealing the private key. > > See: > http://security.stackexchange.com/questions/115231/how-to-decrypt-a-message-using-only-session-key > > But following this approach, I would need to be able to change the session > key before encryption. So I think this does not solve the problem yet. Am I > right? Any other ideas? You're right. If you are willing to modify GnuPG, this is easy to change, however. (Look at seskey.c:make_session_key and have it use the contents of opt.override_session_key rather than generate a random key.) :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Perform only asymmetric encryption/decryption
On Sun, 10 Apr 2016 12:56:09 +0200, Erik Nellessen wrote: > No, this is not about encrypting large amounts of data with asymmetric > encryption. ;) It is about encrypting and decrypting small strings, which are > still way smaller than the public/private key. So I guess this could be > possible using the interfaces for encrypting/decrypting a data encryption > key. What is the best way in OpenPGP to encrypt/decrypt small strings using > asymmetric encryption/decryption directly? You can extract the session key using --show-session-key and set the session key using --override-session-key $ echo | gpg2 --no-options -c | gpg2 --show-session-key -d gpg: session key: '7:7BF4443B3652BD25CEC2BA641135AC58' The format of the session key is algorithm id and the hex-encoded data. The created message has the following form: echo | gpg2 --no-options -c | gpg2 --list-packets # off=0 ctb=8c tag=3 hlen=2 plen=13 :symkey enc packet: version 4, cipher 7, s2k 3, hash 2 salt 6E31D6F821C697BD, count 24117248 (231) # off=15 ctb=d2 tag=18 hlen=2 plen=54 new-ctb :encrypted data packet: length: 54 mdc_method: 2 # off=36 ctb=a3 tag=8 hlen=1 plen=0 indeterminate :compressed packet: algo=1 # off=38 ctb=cb tag=11 hlen=2 plen=7 new-ctb :literal data packet: mode b (62), created 1460360139, name="", raw data: 1 bytes That is, it has an SK-ESK packet and a symmetrically encrypted packet. You just want the SK-ESK, which should be relatively straightforward to extract. Unfortunately, IIRC, if GnuPG doesn't have an encrypted body, it won't show the session key when --show-session-key is used. But, this can be changed relatively easily. A more fundamental problem is that GnuPG will warn (or perhaps error out?) if the provided session key is weak. Good luck! :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pubring.kbx, no secring?
On Tue, 22 Dec 2015 15:08:46 +0100, Matthias Apitz wrote: > > El día Tuesday, December 22, 2015 a las 03:03:39PM +0100, Neal H. Walfield > escribió: > > > > Just to make sure: there have been no v1.x keys (I move away the old > > > .gnupg dir), why are the new v2 keys in a dir named > > > .gnupg/private-keys-v1.d? > > > > I don't really understand your question, but I'll try to answer what I > > think you are asking: > > > > secring is the old format; private-keys-v1.d is the new format. GnuPG > > 1 doesn't know about the new format; GnuPG 2 only uses the new format, > > but the first time it is run it will migrate any existing keys from > > the old format to the new format. > > I understand the migration of the old v1 keys to a new form/directory; but > why the new keys of v2 are stored in a dir private-keys-v1.d and not in > a dir for example private-keys-v2.d; don't you think that such name *v1.d* > confuses > people (like me)? v1 is the version of the format, which is independent of GnuPG's format. I can see how it would be confusing, sorry about that. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pubring.kbx, no secring?
On Tue, 22 Dec 2015 14:45:59 +0100, Matthias Apitz wrote: > El día Tuesday, December 22, 2015 a las 02:41:24PM +0100, Neal H. Walfield > escribió: > > > Hi Matthias, > > > > On Tue, 22 Dec 2015 13:28:28 +0100, > > Matthias Apitz wrote: > > > Question: Why I do not have a file .gnupg/secring.kbx (as I have had > > > with v1.x)? And, why are the keys stored in .gnupg/private-keys-v1.d? > > > > The short answer is that we are using a new format. > > > > Note: GnuPG 2 will automatically migrate keys from secring.kbx to > > .gnupg/private-keys-v1.d the first time it is run. > > Hi Neal, > > Just to make sure: there have been no v1.x keys (I move away the old > .gnupg dir), why are the new v2 keys in a dir named .gnupg/private-keys-v1.d? I don't really understand your question, but I'll try to answer what I think you are asking: secring is the old format; private-keys-v1.d is the new format. GnuPG 1 doesn't know about the new format; GnuPG 2 only uses the new format, but the first time it is run it will migrate any existing keys from the old format to the new format. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pubring.kbx, no secring?
Hi Matthias, On Tue, 22 Dec 2015 13:28:28 +0100, Matthias Apitz wrote: > Question: Why I do not have a file .gnupg/secring.kbx (as I have had > with v1.x)? And, why are the keys stored in .gnupg/private-keys-v1.d? The short answer is that we are using a new format. Note: GnuPG 2 will automatically migrate keys from secring.kbx to .gnupg/private-keys-v1.d the first time it is run. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgkey2ssh and Ed25519 key
Hi, On Mon, 21 Dec 2015 10:28:47 +0100, perillamint wrote: > I'm having trouble setting up ssh auth using Ed25519 key. > > I tries to convert it using gpgkey2ssh and it returns > > Unsupported algorithm: 22 > > Is there any version of gpgkey2ssh or other tool which allows converting > ed25519 pubkey for ssh use? gpgkey2ssh has been decprecated for a while. In fact, it was only intended as a debugging aid. (See https://bugs.gnupg.org/gnupg/issue1610) Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPA - unsupported certificate
On Tue, 08 Dec 2015 13:16:29 +0100, Peter Lebbing wrote: > Again, no. Lots of programs get vague problems. It's just that it used > to be that GNOME Keyring said "those problems are in GnuPG", whereas the > GnuPG project said "those problems are caused by GNOME Keyring breaking > our software". The result is that nobody fixed it. I hope that when > Debian Stretch is released, we can finally put this behind us, as the > problem has been fixed in recent versions that are unfortunately too > recent for Jessie AFAIK. The problem has been fixed in Gnome 3.18 (IIRC) and is already shipping in the latest version of Fedora, for instance. The fix will appear in the next Debian version, but the changes are too large for them to be considered a Jessie point release. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.10 released
On Mon, 07 Dec 2015 01:05:51 +0100, MFPA wrote: > > * gpg: New trust models "tofu" and "tofu+pgp". > > > * gpg: New command --tofu-policy. New options > > --tofu-default-policy and --tofu-db-format. > > Should these be available in the Windows version? I get:- > > gpg: unknown trust model 'tofu+pgp' > gpg: unknown TOFU policy 'ask' TOFU depends on libsqlite, which you are probably missing. If GnuPG doesn't find it, then it disables TOFU. Can you check whether this is the case? Thanks! :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent prompt slow to show up
Hi, At Fri, 27 Nov 2015 16:43:09 +0800, Charlie Brown wrote: > I'm new to gpg, and I'm trying the agent. > > I noticed that when gpg needs to prompt me for pass phrase, the prompt > shows up about 15 seconds after I issue the command (e.g. gpg > --decrypt or git commit -S). The problem exists with both gpg > --use-agent and gpg2. > > I then tried the --no-use-agent flag of gpg, and the cli prompt showed > up instantly, but sadly it doesn't not use the agent by its nature. > > My colleagues say that they do not have such problem. Any idea, or how > can I look into this problem? First, how did you install GnuPG? What OS / distribution are you using? What configuration options are you using (gpg-agent.conf and gpg.conf)? Thanks, Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Thu, 5 Nov 2015 17:29:22 +, MFPA wrote: > On Thursday 29 October 2015 at 2:06:51 PM, in > , Neal H. Walfield wrote: > > Note: GpgME has not yet been extended to support TOFU > > so these messages might not be shown. > > I would think that was quite important, for users whose email client > uses GPGME. Sure :). But, it was less important than implementing TOFU in GnuPG first. Thanks! :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
Hi, At Tue, 03 Nov 2015 16:56:27 +0100, Andre Heinecke wrote: > On Tuesday 03 November 2015 16:34:39 you wrote: > > At Tue, 03 Nov 2015 16:10:24 +0100, > > > > Andre Heinecke wrote: > > > Don't we need to lookup the new key anyway to make validity decisions? > > > Until then we assume "Unknown" trust. > > > > In the verify case, yes. But what about the sign case? We just see > > that the old key has been revoked, but we don't know what the new key > > is. > > I assume you mean the encrypt case (I don't see how this affects sign)? But > still I don't see a problem there. If you don't have a valid key to encrypt > to. You need to get a different key. How is the trust model involved in that? > > Once you have that new key you can do the UID / Signature checks I suggested. You're correct, I meant the encrypt case. Let's say you want to send an email to Alice and she has revoked her key. Best practice dictates that you should run something like Parcimonie to keep your keyring up to date. So, let's assume that Parcimonie has also updated Alice's key. Now, when you try to encrypt an email to Alice, GnuPG won't let you, because the key is revoked. The question then becomes: how do you discover her new key? If we had a machine readable field, as I propose, GnuPG could tell you the new key id and even automatically fetch it for you. If we are using signature cross checking, then GnuPG can't help the user, because the new key is necessarily available locally. Note: the trust model is not relevant here. The issue of determining the new key is only relevant insofar as the TOFU code can suppress spurious conflict messages if it has this information. Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Tue, 3 Nov 2015 15:37:06 +, MFPA wrote: > On Tuesday 3 November 2015 at 3:29:02 PM, in > , Neal H. Walfield wrote: > > > > The bindings are between user id and key. So, a new > > binding will be created. > > Will it flag up to the user that it is creating a new binding for a > known key? Or will there only be a prompt in the case that the new uid > matches one already stored in a binding to a different key? It will only flag an error if there is a conflict. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Tue, 03 Nov 2015 16:10:24 +0100, Andre Heinecke wrote: > Don't we need to lookup the new key anyway to make validity decisions? Until > then we assume "Unknown" trust. In the verify case, yes. But what about the sign case? We just see that the old key has been revoked, but we don't know what the new key is. Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Tue, 3 Nov 2015 15:18:57 +, MFPA wrote: > On Tuesday 3 November 2015 at 2:38:04 PM, in > , Neal H. Walfield wrote: > > > > In this case, we store the whole user id (lower cased). > > Only if the user id is the empty string do we not store > > a binding. > > > How will TOFU react if a key for which bindings are already stored > acquires a new UID? The bindings are between user id and key. So, a new binding will be created. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
Hi Andre, At Fri, 30 Oct 2015 13:23:14 +0100, Andre Heinecke wrote: > On Thursday 29 October 2015 22:28:54 Neal H. Walfield wrote: > > At Thu, 29 Oct 2015 18:48:43 +0100, > > > > Johannes Zarl-Zierl wrote: > > > Out of curiosity: Does the TOFU implementation for gpg already allow for > > > key transition statements / is this planned for some point in the future? > > Unfortunately, it doesn't. This is because there is currently no > > standard way to communicate the id of the new key. I've proposed a > > solution for this for the next OpenPGP version, which is currently > > being work on. There appears to be some interest, but unfortunately I > > haven't had time to work on that recently. > > I don't fully understand why you need formalized transition statements. > Couldn't you just treat Key / UIDs that are signed by each other as "two > valid > keys for this UID"? > > So when I transition to another key I just sign it with the old key and GnuPG > can detect that and not show a warning about it? > > This would also solve the problem that some users may have multiple keys with > the same UID's which are both valid. This could work if both keys are available locally. If you need to look up the new key, this is not so easy. Another problem is that this assumes that the new key has the exact same user ids. Oftentimes some emails will have been dropped or the person's name changed (e.g., marriage, new title, etc.). Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Tue, 3 Nov 2015 14:32:56 +, MFPA wrote: > On Friday 30 October 2015 at 12:09:51 PM, in > , Neal H. Walfield wrote: > > The user ids are used. These are authorative. If > > there are N user ids, then N bindings are maintained. > > Presumably if no user-id contains a readable email address, no binding > is stored at all. In this case, we store the whole user id (lower cased). Only if the user id is the empty string do we not store a binding. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
Hi, At Sun, 1 Nov 2015 10:50:33 +, MFPA wrote: > Another thought. New signatures from a key that has long been inactive > may arouse suspicion. Perhaps it would be useful to output how long > ago was the last message verified. For example:- > > "66 messages signed over the past 3 years. The last was 1 year 10 > months ago." This sounds like a good idea. I'll add it. Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Sat, 31 Oct 2015 11:57:05 +, MFPA wrote: > > First, some statistics are displayed, namely, that > > we've verified 5 messages signed by this key in the > > past last hour. > > > Would it say the same if it were not five unique messages? For > example, we read the same email five times and verified it each > time. N is the number of unique signatures. If you verify the message signature multiple times, it will only count once. > And would an option to limit the time period make sense? Meaning that > if the limit were set to X days, it would use the actual time period > if shorter but only say how many messages were verified in the last X > days if the binding were older. (Having thought this sounded like a > good idea, I am struggling to think of a use case.) I'm sure we could do something like this, but it sounds like adding complexity, which doesn't seem justified. Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Fri, 30 Oct 2015 14:32:07 +, MFPA wrote: > On Friday 30 October 2015 at 11:51:27 AM, in > , Neal H. Walfield wrote: > > > > Sure. But your point is a red herring. There is > > *currently* no way to do this. However, the next > > version of the OpenPGP spec should have a way to do > > this. > > My point was "there is already a way to do this: use signature > notations". Is that a red herring? It's not standardized. Sure, GnuPG could use a particular notation for this purpose, but we want to interoperability, which is why this should be standardized in RFC 4880bis. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Fri, 30 Oct 2015 12:06:14 +, MFPA wrote: > On Thursday 29 October 2015 at 2:06:51 PM, in > , Neal H. Walfield wrote: > > > > When you verify a > > message from some user for the first time, GnuPG saves > > the binding between the user id (actually, the > > normalized email address) and the key. > > The email address in the user-id, or the email address the message > appears to come from? > > If it's the email address in the user-id, what happens if the key has > multiple UIDs covering several email addresses? Or if the user-ids > contain no readable email addresses? The user ids are used. These are authorative. If there are N user ids, then N bindings are maintained. > > When you verify > > another message from that user, the saved bindings with > > that user's address are retrieved. If there is at > > least one such binding, but none of them include the > > signer's key, then either the signer is using a new key > > or someone is attacking you. In this case, GnuPG > > displays a warning and prompts you to verify the key > > and set an appropriate policy (e.g., the key should be > > considered untrusted). > > How does it handle a new signing sub-key? The primary key is always used in the binding. Thanks, :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Fri, 30 Oct 2015 11:43:28 +, MFPA wrote: > On Thursday 29 October 2015 at 9:28:54 PM, in > , Neal H. Walfield wrote: > > > > > Unfortunately, it doesn't. This is because there is > > currently no standard way to communicate the id of the > > new key. I've proposed a solution for this > > Wouldn't a signature notation (in a self-signature) be sufficient for > this? Something like:- > > new...@domain.example.com=[fingerprint] > > And for key transition statements, perhaps a second notation:- > > transitionstatem...@domain.example.com=[URL] Sure. But your point is a red herring. There is *currently* no way to do this. However, the next version of the OpenPGP spec should have a way to do this. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
Hi Peter, At Thu, 29 Oct 2015 19:57:29 +0100, Peter Lebbing wrote: > > On 29/10/15 17:23, Daniel Baur wrote: > > isn’t it a little bit problematic that GPG now logs how often I received > > emails by someone else? > > I would think that in most situations, that is not a problem. If you > exclusively > use webmail, there isn't such a record directly on your computer's disk, but > you > also can't use GnuPG with webmail, AFAIK. If you use a regular e-mail program > that works with GnuPG, that information is already on your disk and accessible > to the user account you run it as, so duplicating that information in the > GnuPG > home directory adds nothing. > > Do you know of a scenario where this information is not already available from > the e-mail program? Even if the user deletes the mail after they read it, I > wouldn't be at all surprised if this just marks the data as deleted rather > than > that it scrubs the data from the disk. This would muddy the statistics, but > hardly be a security feature. I think this mostly reflects our thinking. Thanks for the good summary. FWIW, we have thought of aging the data or just storing the hash of the most recent X signatures. But, we decided to defer that discussion until later since it should be easy to add on. > Also, you could just disable TOFU if you're worried by it, but you would lose > the functionality as well... > > Maybe there's a use case for optionally not gathering these statistics if key > validity is already established through the WoT. That way, if you want to keep > the frequency of correspondence a secret, you could use the WoT to establish > validity. > > An option to not gather statistics for specific keys rather calls out those > keys > as interesting, and an option to disable the statistics for all TOFU keys > seems > like losing a very valuable tool in assessing which key is the One Key. To keep the code simple, I'd prefer to avoid adding options that few people will use and are of questionable utility. In particular, I think if someone's security requirements are such that having a list of the hashes of previously seen messages is too big of a security risk, then they should probably just disable TOFU. Indeed, TOFU itself probably violates their security requirements. Thanks! :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: TOFU for GnuPG
At Thu, 29 Oct 2015 18:48:43 +0100, Johannes Zarl-Zierl wrote: > Out of curiosity: Does the TOFU implementation for gpg already allow for key > transition statements / is this planned for some point in the future? Unfortunately, it doesn't. This is because there is currently no standard way to communicate the id of the new key. I've proposed a solution for this for the next OpenPGP version, which is currently being work on. There appears to be some interest, but unfortunately I haven't had time to work on that recently. Thanks! :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
TOFU for GnuPG
Hi, Last week, I checked in the TOFU code for GnuPG. This code will be part of the next release. It would be great to get some additional testing before this happens! Background -- TOFU stands for Trust on First Use and is a concept that will be familiar to anyone who regularly uses ssh. When you ssh to a host for the first time, ssh asks you to verify the host's key (most people just say yes here). When connecting to the same host in the future, ssh checks that the key hasn't changed. If it has, ssh displays a warning. TOFU for GnuPG works similarly. When you verify a message from some user for the first time, GnuPG saves the binding between the user id (actually, the normalized email address) and the key. When you verify another message from that user, the saved bindings with that user's address are retrieved. If there is at least one such binding, but none of them include the signer's key, then either the signer is using a new key or someone is attacking you. In this case, GnuPG displays a warning and prompts you to verify the key and set an appropriate policy (e.g., the key should be considered untrusted). In contrast to the Web of Trust (WoT), TOFU's security guarantees are rather weak. When using the WoT correctly, you can have high confidence that if GnuPG says a given key is controlled by a specific user, then it probably is. TOFU, on the other hand, is only able to detect when the key associated with an email address has changed. In other words, TOFU detects inconsistencies. Despite this, TOFU will be more secure than the WoT for most users in practice. This is because using the WoT requires a lot of effort. First, you have to actively exchange fingerprints with other users and sign their keys. Most people can't be bothered to take the time to do this. Second, in order to actually use the WoT to verify keys that you have not directly signed, you need to tell GnuPG how much you trust other people to correctly verify keys the keys that they sign (i.e., you need to set the owner trust). In practice, even fewer people do this. But, even if you do do this, you can only confidently set the owner trust for people that you've actually met. Thus, the WoT can only really be used to verify the keys of friends of friends. This seriously limits the number of people you can securely communicate with. Happily you don't need to choose between TOFU and the WoT. It is possible to combine them using the tofu+pgp trust model. In this model, the trust level for a key under each model is computed and then the maximum is taken according to the following ordering: unknown < undefined < marginal < fully < ultimate < expired < never For users who want TOFU's ability to detect conflicts, but don't like that TOFU assigns positive (marginal) trust to new keys without prompting, it is possible to change the default policy to unknown or to always prompt the user for the policy for new keys using the --tofu-default-policy option. When setting the default policy to unknown, the WoT will be used for all trust judgments unless TOFU detects a conflict. How-to -- In general, there is no reason to use the bare tofu model. Instead, tofu+pgp is the recommended model. If you've never signed a key, then this effectively degrades back to the tofu model. To set the trust model to tofu+pgp, add the following to your ~/.gnupg/gpg.conf file: trust-model tofu+pgp If you don't want TOFU to assign positive trust to new keys by default, then you should also add the following to your gpg.conf file: tofu-default-policy unknown These and a few other new options are described in detail in the manual (search for tofu). There isn't much more to do. Verifying a message works as usual: $ gpg2 --verify EE37CF96-6.txt gpg: Signature made Fri 18 Sep 2015 03:16:17 PM CEST using RSA key ID EE37CF96 gpg: Good signature from "Testing (insecure!)" [unknown] gpg: Verified 5 messages signed by "Testing (insecure!)" (key: 362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96, policy: auto) in the past 42 minutes, 59 seconds. gpg: Warning: if you think you've seen more than 5 message signed by this key, then this key might be a forgery! Carefully examine the email address for small variations (e.g., additional white space). If the key is suspect, then use 'gpg --tofu-policy bad "362D 3527 F53A AD19 71AA FDE6 5885 9975 EE37 CF96"' to mark it as being bad. Here, the only change are a few additional messages. First, some statistics are displayed, namely, that we've verified 5 messages signed by this key in the past last hour. Further, a warning is printed that the number of messages that we've verified is rather small and we should be suspicious of this binding. This information is displayed to make it easier to recognize forged keys. Unlike with ssh where the user types the name of the host to connect to, an attacker is able to control the content of the user id field. To work around t
Re: Direct signatures
Hi Lachlan, At Fri, 23 Oct 2015 10:58:22 +0200, Lachlan Gunn wrote: > Is there any way make GNUPG or libgpgme generate a signature from an > externally-computed hash? My justifications for this are twofold: In theory yes, in practice no. To generate an OpenPGP signature, the OpenPGP implementation hashes the concatenation of the data and some metadata. That is, it computes: H(data || metadata). Thus, to do what you want you'd need to give GnuPG not the hash of the data, but the internal state of the hash function before it appends the metadata. Unfortunately, the internal state is implementation and platform dependent. If OpenPGP computed signatures as follows: H(H(data) || metadata), then what you wanted would be straightforward to implement. > 1. Isolation---by removing the need for gpg to see the original data, > it becomes possible to perform signatures on a system that is > completely isolated, at least as far as incoming data goes. > > 2. Process separation---I have ideas involving SELinux that I would > like to experiment with, and doing so requires that tasks be split at > the process level as I understand. There are two ways around this: - You can run gpg on one machine / user account and gpg-agent on another. (Look up the extra-socket option in the GnuPG manual.) Note: I briefly cover this in my "An Advanced Introduction to GnuPG" presentation, which was recorded at RMLL: https://2015.rmll.info/introduction-avancee-sur-gnupg?lang=en - Have GnuPG sign the hash of the data. That is, use something like sha256sum to compute a hash of the data, transfer the hash to the machine running gpg and sign that data. This adds a level of indirection, which the person verifying the hash needs to deal with. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Portable version of modern GnuOG
At Mon, 5 Oct 2015 14:22:30 -0500, Anthony Papillion wrote: > I'm working on a project that requires a portable version of GnuPG and > I'd like to use a modern version of it. As far as I can tell from > searching, GnuPG stopped being portable somewhere in the 1.4.x branch. GnuPG 2.x is still portable. What platform are you targetting? What issues are you running into? :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: default-ttl not honoured
Hi, At Tue, 22 Sep 2015 11:07:22 -0400, SGT. Garcia wrote: > > hello, > this is my gpg-agent.conf: > > allow-preset-passphrase > default-cache-ttl 31536000 > > this has stopped working! i'm getting asked for password every 20 minutes or > so. > anyone else hitting this bug? hopefully i don't have to go: What version of gpg / gpg-agent are you using? Thanks, Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
At Wed, 29 Jul 2015 15:14:07 +0200, Ingo Klöcker wrote: > If you replace "validation server" with "keysigning party participant" then > you get one of the ways participants of keysigning parties get their > signatures to the key owners. So, it's already done and people do upload > their > signed keys. I don't see why people should behave differently for validation > servers. Key signing parties are a surprisingly good example that demonstrate my point. Key signing parties are a bizarre geek ritual. Most people don't do it. And, I think, most people won't use the validation servers. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
At Wed, 29 Jul 2015 14:05:49 +0100, MFPA wrote: > On Wednesday 29 July 2015 at 1:09:54 PM, in > , Neal H. Walfield wrote: > > > > Personally, I think c is the killer in this plan: > > people aren't going to bother to upload it (assuming > > they even get that far)! > > They have gone to the effort of sending it to the validation server > to obtain the validation signature. It is up to them whether they > publish it to a server, publicise it in some other way, send > it to their contacts directly, or just do nothing. I suspect that >95% of users won't bother. This would defeat the entire scheme, which requires widespread buy in to be successful. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
At Wed, 29 Jul 2015 02:30:47 +0100, MFPA wrote: > On Monday 27 July 2015 at 1:15:57 PM, in > , Neal H. Walfield wrote: > > > > Regarding the design: personally, I wouldn't have the > > user follow a link that includes a swiss number, but > > have the user reply to the mail, include the swiss > > number and sign it. > > > Why not simplify the workflow:- > > 1. key reaches validation server. > > 2. for each UID containing an email address, validation server creates >a copy of the key stripped of all other UIDs. > > 3. validation server signs that copy of the key. > > 4. validation server pastes the signed key into an email, encrypts the >email to that key, and sends it to the email address in the UID. > > 5. user receives each email, decrypts it, and updates their local copy of >their key. > > 6. user uploads key now bearing the validation server's signatures to >a keyserver. > > > There is still the same level of assurance that the email address and > private key are controlled by the same entity. Advantages are:- > > a. Nobody is asked to click links or reply to emails. > > b. The validation server does not need to manage a "stack" of keys >awaiting feedback from the validation emails. > > c. Changes to the user's key are uploaded to the keyserver by the >user, not by the validation server. Personally, I think c is the killer in this plan: people aren't going to bother to upload it (assuming they even get that far)! Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
At Wed, 29 Jul 2015 01:03:53 +0100, MFPA wrote: > On Tuesday 28 July 2015 at 11:46:10 PM, in > , Neal H. Walfield wrote: > > At Tue, 28 Jul 2015 19:22:29 +0100, MFPA wrote: > >> It also eliminates any attempt to to establish a link > >> between the key and the email address in the UID. > > > I'm not so sure. Recall that we are not attempting to > > protect against attacks by nation states. As such, > > performing a week of computation each year is going to > > be too much to maintain for those who upload fake keys. > > And too much for people with multiple email addresses. It doesn't have to be per-email address. It is sufficient to attach it to the primary key. > This still seems less rigorous to me than having to receive an email > sent to that address and decrypt it with that key. I guess it's a case > of swings and roundabouts. Well, I don't like the CA model and that's what Nico is basically proposing (with less rigorous checks). Another huge disadvantage is that user's have to actively participate by replying to emails / visiting a link. Using PoW, no human intervention is required and there is no central authority. PoW relies on the assumption that conducting an attack is too expensive to do / maintain. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
At Tue, 28 Jul 2015 19:22:29 +0100, MFPA wrote: > On Tuesday 28 July 2015 at 8:22:23 AM, in > , Neal H. Walfield wrote: > > > Did you consider user a proof-of-work scheme? For > > instance, the user does a 1 week PoW, signs the result > > and attackes it to the key. These would be refreshed > > about once a year. > > Would this one-week PoW pause when the user shuts down and continue > when they boot it up? There are plenty of email users who do not leave > their computer running all the time. Of course. A simple proof of work scheme is to find a hash that starts with X zeros. This requires 2^X steps. In our case, the prefix of the text would be the primary public key. > > This eliminates the verification servers and the > > problems associated with them (namely, people need to > > trust them and there can't be too many of them). > > It also eliminates any attempt to to establish a link between the key > and the email address in the UID. I'm not so sure. Recall that we are not attempting to protect against attacks by nation states. As such, performing a week of computation each year is going to be too much to maintain for those who upload fake keys. Moreover, this will automatically purge old keys (or at least rank them very low in search results). In other words, only people who actually use a given key will bother performing the work. > > gpg (or the email clients) don't need to know about > > special verification keys / signatures. They just > > check the proof of work and sort the returned keys > > appropriately. > > Instead of one special signature notation type, we have another that > will be much larger? What do you mean? A PoW is just a few dozen bytes large... Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
Hi, Did you consider user a proof-of-work scheme? For instance, the user does a 1 week PoW, signs the result and attackes it to the key. These would be refreshed about once a year. This eliminates the verification servers and the problems associated with them (namely, people need to trust them and there can't be too many of them). It also increases usability: there are no emails. This can be done completely by, say, gpg-agent in the background. gpg (or the email clients) don't need to know about special verification keys / signatures. They just check the proof of work and sort the returned keys appropriately. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
At Mon, 27 Jul 2015 17:51:56 +0200, Patrick Brunschwig wrote: > > On 27.07.15 14:15, Neal H. Walfield wrote: > > Hi, > > > > I guess you mean this: > > > > The idea I have in mind is roughly as follows: if you upload a key to > > a keyserver, the keyserver would send an encrypted email to every UID > > in the key. Each encrypted mail contains a unique link to confirm the > > email address. Once all email addresses are confirmed, the key is > > validated and the keyserver will allow access to it just like with any > > regular keyserver. > > > > This approach is not going to stop a nation state. A nation state can > > intercept the mail, decrypt it and follow the link. > > If the email can be decrypted, then any email can be decrypted, which > would turn OpenPGP useless. Sorry. This was definately unclear. What I meant is: a nation state can create a "fake" key, upload it to the key server and intercept the mail encrypted to the fake key thereby validating the fake key. > In any case, the target users are not the Edward Snowdens of this world, > but the 99% of people who just want to communicate easily with each > other and don't want to be bothered too much with key complicated key > lookup/verification scenarios. This is a worthy goal :). :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
Hi Nico, At Mon, 27 Jul 2015 19:21:10 +0200, n...@enigmail.net wrote: > > Thanks, Neal for the feedback. > I will try to answer. > > Am 27.07.2015 um 14:15 schrieb Neal H. Walfield: > > Hi, > > > > I guess you mean this: > > > > The idea I have in mind is roughly as follows: if you upload a key to > > a keyserver, the keyserver would send an encrypted email to every UID > > in the key. Each encrypted mail contains a unique link to confirm the > > email address. Once all email addresses are confirmed, the key is > > validated and the keyserver will allow access to it just like with any > > regular keyserver. > > > Hmm, not quite right, there are two major points where I think > there is some misunderstanding: If this is not right please point me to the proposal. The above is just a quote from the single source in your original email. After I read that I will respond to your other questions / comments. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proposal of OpenPGP Email Validation
Hi, I guess you mean this: The idea I have in mind is roughly as follows: if you upload a key to a keyserver, the keyserver would send an encrypted email to every UID in the key. Each encrypted mail contains a unique link to confirm the email address. Once all email addresses are confirmed, the key is validated and the keyserver will allow access to it just like with any regular keyserver. This approach is not going to stop a nation state. A nation state can intercept the mail, decrypt it and follow the link. For the same reason, it is not going to stop a user's ISP. Given Microsoft's et al.'s willingness to cooperate with the NSA, these are not very good starting conditions. The approach also has another problem: which key servers are going to do this? There are 100s of key servers. I'm not going to reply to mails from each one, sorry. This also seems like a nice way to spam someone. Generate a key, upload it to a key server and they have a bunch of mails from the key server. Based on this, I suspect that it won't take long for the key servers to be blacklisted? Have you considered these issues? Do you have any thoughts about how to avoid these problems or do you think they are not real problems? Regarding the design: personally, I wouldn't have the user follow a link that includes a swiss number, but have the user reply to the mail, include the swiss number and sign it. I'd also consider having the key servers publish the validations. If you chain the validations (include the hash of the previous validation in the current validation) you can detect if the key servers serve a fake key to a specific user. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Parse LISTKEYS output
Hi, At Thu, 04 Jun 2015 12:06:42 +0300, Dmitry Falko wrote: > Is there a common way to parse data returned from LISTKEYS > command. Callback function receives buffer with colon-separated > information about certificate, > i need fingerprint to use it with IMPORT --re-import command. Are you running: gpg --list-keys --with-colons or doing something else? If you are doing this from C then you should use gpgme rather than try and parse the output yourself. (If you aren't using C, then look to see if there are any bindings to gpgme.) If this isn't helpful, please try to describe your problem more thoroughly. :) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Notes from the first OpenPGP Summit
At Tue, 28 Apr 2015 17:38:53 +0200, Werner Koch wrote: > On Tue, 28 Apr 2015 17:02, n...@walfield.org said: > > > I've added a checkbox to pinentry that asks: "Cache password with GKR" > > and it is only shown if GKR is present. So it's opt-in. > > Good. While you are at it: Please also add a checkbox to not hide the > passphrase in the entry field. Being able to see what one types is very > convenient for long passphrases if you are anyway below a sheet while > typing I can do this. But, I'll do it as a separate patch. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Notes from the first OpenPGP Summit
At Tue, 28 Apr 2015 10:26:05 -0400, Robert J. Hansen wrote: > > The solution is to fix Gnome Keyring :). I've spoken with Stef, the > > main developer of GKR, and he confirmed that the only reason GKR > > MITMs GPG Agent is so that it can intercept prompts for the password > > to supply any cached value. > > This doesn't seem like a good reason. It never has. If I configure > gpg-agent to cache for 20 minutes, but forget to configure > gnome-keyring-daemon, then it's possible that 25 minutes later I'll do > something requiring a passphrase, gpg-agent will ask me for my > passphrase, but gnome-keyring-daemon will silently intercept it and use > the cached value, etc., etc., leaving me wondering why gpg-agent isn't > respecting the timeout I've given it. I've added a checkbox to pinentry that asks: "Cache password with GKR" and it is only shown if GKR is present. So it's opt-in. > This also means passphrases are cached in two places, not one -- in > gpg-agent and in gnome-keyring-daemon. In my day job I work in digital > forensics, with a good bit of memory forensics work in my past. > Speaking as a forensicist, if you keep two copies of a sensitive > passphrase in memory you're making things much easier for me. There are so many attack vectors that providing this opt-in hardly seems to make a difference to me. If we actually had process isolation, I might agree with you. But, as things stand, we don't. I wouldn't allow GKR to cache my passphrase either, but other people disagree. In particular, the maintainer of GKR, which is widely used and practically a hard requirement even on Xfce. > I don't understand GKD's choices here. I never have. They've always > seemed foolish. If GKD wants to implement gpg-agent's protocol and run > as a replacement gpg-agent, that's one thing... but the current setup > just does not strike me as wise. I don't understand this "if". GKR is implementing (a subset of) gpg agent's protocol. > I'm sorry, but I don't think this is a good solution. GNOME is asking > for privileges other desktop environments haven't asked for and don't > get. KDE doesn't get KDE-specific functionality added to pinentry. Nor > does XFCE, nor does Enlightenment. If GNOME gets to have GNOME-specific > enhancements folded into GnuPG, then what's to prevent KDE, XFCE, > Enlightenment, Windows, OS X, and all other desktop environments from > demanding the same? Actually, the secrets API is a desktop standard and I was told KWallet speaks it. So, this enhancement will work with KWallet as well. Also, the GPG Tools people (Mac OS) do something similar to GKR (but less invasive) so the modifications to the gpg core will help them as well. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Notes from the first OpenPGP Summit
Hi Simon, We've documented the problem at http://wiki.gnupg.org/GnomeKeyring . At Tue, 28 Apr 2015 14:45:22 +0200, Simon Josefsson wrote: > Werner Koch writes: > > > I appreciated the opportunity to meet the GPG Tools developers, who > > are very dedicated to make GnuPG working well on OS X. I stressed the > > importance to actively participate on the GnuPG mailing list to keep > > information in sync. One example may illustrate this: For years the > > adaption of GnuPG-2 on GNOME based systems has been hampered by the > > fact that the gnome-keyring-manager (GKR) tries to emulate gpg-agent > > and thus inhibits proper working of any advanced function of GnuPG > > (e.g. smartcards and gpgsm). With Debian’s release of Jessie that > > problem will even be worse due to other desktop environments now also > > using GKR. Given that the GKR developers are not willing to change > > their defaults, Neal, dkg, and me came up with a pragmatic solution > > for this problem on Saturday morning. > > What is this solution? > > I am working around the bug in Jessie [1], but GKR's bug/design is a > real pain if you want to convince others to start to use GnuPG with > smartcards. I recently noticed that my fix doesn't even work on Ubuntu, > so each OS need their own fix... :-( The solution is to fix Gnome Keyring :). I've spoken with Stef, the main developer of GKR, and he confirmed that the only reason GKR MITMs GPG Agent is so that it can intercept prompts for the password to supply any cached value. The solution is to enhance pinentry so that if GKR is available it caches the password with GKR. This requires a few modifications to GnuPG proper as well as enhancements to pinentry. I'm working on this and it should be done shortly. The GPG Tools people also need this functionality in GPG 2.0 so it will also be backported. We hope to coordinate with Debian to get the fixed versions of GPG and GKR in the next point release of Jessie. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: wiki.gnupg.org theme?
At Tue, 21 Apr 2015 10:26:19 +0200, Bernhard Reiter wrote: > on the OpenPGP Summit last weekend, people suggested to me > that we could make the wiki look better. > > Help with adding or creating a better theme is appreciated, > this is something you can do for the GnuPG Community. ;) > > How do you like any of the 1.9 themes from > https://moinmo.in/ThemeMarket ? I like Solenoid, if only because it appears to impose a maximum width on the main content, which is my main complaint with the current theme. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: wiki.gnupg.org (Re: LDAP-based Keyserver)
At Mon, 2 Mar 2015 12:35:30 +0100, Bernhard Reiter wrote: > On Saturday 28 February 2015 at 12:27:05, Neal H. Walfield wrote: > > http://wiki.gnupg.org/LDAPKeyserver > > and while you were at it, you have also went through a number of wiki pages > correcting and improving the format and language! I was found out :) > Thanks and welcome to the club of wiki.gnupg.org helpers! > (We are always looking for more members! :) ) wiki.gnupg.org has the potential to be a great resource. But, it needs a lot more content. I think this would be a good place for recipes, such as , how to generate keys offline [1] or key signing related practices. Neal [1] http://blog.josefsson.org/2014/06/23/offline-gnupg-master-key-and-subkeys-on-yubikey-neo-smartcard/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
LDAP-based Keyserver
Hi, Nearly a decade ago, Walter Haidinger posted a how to describing how to setup an OpenLDAP PGP keyserver. http://lists.gnupg.org/pipermail/gnupg-users/2006-February/028058.html In that time, OpenLDAP configuration has gotten a lot more complicated. I've modernized and significantly expanded his tutorial. You can find it here: http://wiki.gnupg.org/LDAPKeyserver I did my best to provide a recipe that requires little prior knowledge about OpenLDAP while also explaining the reasoning behind the actions and high-level concepts. I'd appreciate it if someone could try to reproduce the steps and report any bugs. I used Debian. There are probably differences on other platforms that are worth noting. I'd also appreciate any improvements to the text. Thanks! Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GNUPG 2.* and AIX - questions
At Sun, 15 Feb 2015 12:16:58 +0100, Michael Felt wrote: > My key question is about the difference between v1.X and v2.X - are there > security elements in v2 that are missing/weaker in v1 - or are the > differences mainly that v2 supports/is always GUI while v1 is always CLI. gpg2 is a more extensible rewrite of gpg classic. gpg2 supports some crypto algorithms that gpg does not support (e.g., ECC starting with version 2.1). gpg2 is still for the CLI and makes some CLI operations easier than gpg. > The first wall I run into with gnupg-2.0.26 is that it wants gnu threads - > so, the question is: is there something inherently wrong with POSIX > threads, or even specifically with AIX pthreads that configure does not > attempt to use them (by default). npth uses cooperative threading rather than preemptive threading. This has the advantage of simplifying code: if you don't explicitly yield (or use a function that yields), then you can't be preempted. This can significantly reduce synchronization bugs. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Analogien um das Prinzip von PGP zu erklären
At Thu, 03 Jul 2014 12:50:50 +0200, Daniel Krebs wrote: > da ich das gerade mit Matthias von der FSFE im Rahmen von > #EmailSelfDefense diskutiere, mal eine Frage: Welche Analogien benutzt > ihr, wenn ihr Menschen das Prinzip von PGP/GPG erklärt? > Ich verwende ich meistens folgende Version: > > Es gibt ein Schloss mit zwei Schlüssellöchern. Jeder Schlüssel > funktioniert nur in eine Richtung, also entweder Geöffnetes schließen > oder Geschlossenes öffnen. Daran kann man dann auch das signieren > erklären, was ja bei der "klassischen Metapher" (öff. Schlüssel = > Schloss, priv. Schlüssel = Schlüssel) nicht funktioniert. Also: > Verschlüsseln: > Jemand verschließt mit meinem öffentlichen Schlüssel, ich öffne mit > meinem geheimen. > Signieren: > Ich signiere mit meinem privaten Schlüssel, jemand anders überprüft mit > meinem öffentlichen. > > Anregungen, Meinungen? You might want to take a look a this: https://freedom-to-tinker.com/blog/randomwalker/why-king-george-iii-can-encrypt/ Email encryption, although cryptographically straightforward, appears too complicated for laypeople to understand. In our project, we aimed to understand why this problem has eluded researchers for well over a decade and expand the design space of possible solutions to this and similar challenges at the intersection of security and usability. ... In PGP’s metaphors, each user posses two items, a private key and a public key. Have you inferred how the protocol works yet? Unless you have previous exposure to cryptography, likely not. Why do I have two keys? What do these keys open? Aren’t all keys private? When you want to send a message to someone, you encrypt it with his public key, which is known to everyone. The recipient can decrypt it with his private key, which only he possesses. But can’t anyone use the public key to decrypt the message again? Nope. A public key can only encrypt, not decrypt. Just trust us on that one. You’re probably starting to understand why secure email is so hard to use. Bear with us for one paragraph longer. ... We decided to test whether better metaphors might be able to close this gap between security and usability. Specifically, we wanted metaphors that represented the cryptographic actions a user performs to send secure email and were evocative enough that users could reason about the security properties of PGP without needing to read a lengthy, technical introduction. We settled on four objects: a key, lock, seal and imprint. To send someone a message, secure it with that person’s lock. Only this recipient has the corresponding key, so only they can open it. To prove your identity, stamp the message with your seal. Since everyone knows what your seal’s imprint looks, it’s easy to verify that the message came from you. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: mascot_p
FWIW, I was thinking of a stylized version of something like this: http://i76.photobucket.com/albums/j24/joebnfran/blog%20pics2/octopus.jpg (Found here: http://hideousseacreatures.tumblr.com/post/61030684038/octopi-will-keep-trying-to-kill-you-after-theyre-dead) Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: mascot_p
At Tue, 17 Jun 2014 09:00:52 -0400, Mark H. Wood wrote: > > On Tue, Jun 17, 2014 at 12:04:20PM +0200, Neal H. Walfield wrote: > > At Tue, 17 Jun 2014 11:36:11 +0200, > > Werner Koch wrote: > > > the guy I am working with on a new website, recently asked why we do not > > > have a mascot like many other projects. What's your opinion on that? > > We have one, but it's a secret. :-) > > > How about an Octopus? As I understand it, they like to try and open > > locks. > > Alas, the octopus is already associated with GitHub: > > https://octodex.github.com/original/ That looks more like a cat... Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: mascot_p
At Tue, 17 Jun 2014 11:36:11 +0200, Werner Koch wrote: > the guy I am working with on a new website, recently asked why we do not > have a mascot like many other projects. What's your opinion on that? How about an Octopus? As I understand it, they like to try and open locks. Neal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
