MUA "automatically signs keys"? (was: Re: Non email addresses in UID)
Hi Steve, gnupg users, * Steve Jones [24. Jan. 2014]: > Which reminds me that I'd really like an email client that > automatically signs keys at level 1 (persona) of anyone who replies > with a signed email that quotes a significant portion of the text I > sent, as this effectively counts as a challenge response protocol in my > book. That's an interesting idea. But there is still the possibility of a man in the middle attac... The web of trust is supposed to counter MITM attacks by signing keys only if the verification was done directly (no middle person). Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: default (secret) key for gpg
>> "Werner" == Werner Koch writes: > (setq mml2015-signer "0x65AD077A") The correct setting is (setq mml2015-signers (list "0x65AD077A")) Just in case smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
Gregor Zattler: > Hi Steve, gnupg users, > * Steve Jones [24. Jan. 2014]: >> Which reminds me that I'd really like an email client that >> automatically signs keys at level 1 (persona) of anyone who replies >> with a signed email that quotes a significant portion of the text I >> sent, as this effectively counts as a challenge response protocol in my >> book. > > That's an interesting idea. But there is still the possibility > of a man in the middle attac... The web of trust is supposed to > counter MITM attacks by signing keys only if the verification was > done directly (no middle person). maybe you already discussed that, but what about sending someone an encrypted email (with the challenge) and wait for an encrypted reply with the signed challenge? (as you seem to talk only about sending a clear text challenge) Personally, I don't want such behaviour. When I'm making a certification, then it's me doing it manually as I have the responsibility. I don't want some program to be able to make automatized certifications with my key. Here's a quote from an email on a very similar topic: From: Robert J. Hansen Subject: Re: trust your corporation for keyowner identification? Date: 2013-10-17 13:54 -0700 >> In my proposed scenario, the corporation [e.g. HR] is doing nothing more than >> providing a means for the participants to know that Bob is actually Bob >> because the company has checked his id and said he is and providing an >> authenticated means (again, IT being a black-hat aside) to communicate >> with Bob and verify fingerprints, etc. > > Under this scenario, the entire thing is dangerously bogus. > > When I sign a certificate, I am sending a message: "I am vouching for the > identity of X." Under your scenario, I'm no longer vouching for the identity > of X. I would instead be saying, "Someone else who is not listed on this > signature has vouched for the identity of X. I am signing this without any > direct personal knowledge of X's identity." > > If you're vouching for X's identity, you need to take positive steps to > verify X's identity. If someone else is vouching for X's identity, then let > them sign X's certificate. Why should you get involved without doing your > own positive verification? Two replies later in the thread there was Stan Tobias who clarified: > [That] you vouch that the person told you "This is my key". Making a > certification is *not* a confirmation of an identity. I like the term "vouch" here, because it highlights the responsibility in the Web of Trust of the person doing the certification. Cheers, -- nb.linux ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] Libgcrypt 1.6.1 released
Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.1. This is a maintenance release to fix problems found in the recently released 1.6.0 version. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.6.1 (2014-01-29) * Added emulation for broken Whirlpool code prior to 1.6.0. * Improved performance of KDF functions. * Improved ECDSA compliance. * Fixed locking for Windows and non-ELF Pthread systems (regression in 1.6.0) * Fixed message digest lookup by OID (regression in 1.6.0). * Fixed a build problem on NetBSD. * Fixed memory leaks in ECC code. * Fixed some asm build problems and feature detection bugs. * Interface changes relative to the 1.6.0 release: GCRY_MD_FLAG_BUGEMU1NEW (minor API change). Download Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.bz2 (2413k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.gz (2872k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.gz.sig Alternativley you may upgrade using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0-1.6.1.diff.bz2 (244k) In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.1.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by the release signing key 4F25E3B6 which is certified by my well known key 1E42B367. To retrieve the keys you may use the command "gpg --fetch-key finger:w...@g10code.com". * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.1.tar.bz2 and check that the output matches the first line from the following list: f03d9b63ac3b17a6972fc11150d136925b702f02 libgcrypt-1.6.1.tar.bz2 fe6d442881a28a37d16348cdbf96b41b8ef38ced libgcrypt-1.6.1.tar.gz 35d002247186884ba3730c91f196a5de48c3fcf8 libgcrypt-1.6.0-1.6.1.diff.bz2 Copying === Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support === For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks == Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp50xpu5Bq1I.pgp Description: PGP signature ___ Gnupg-announce mailing list gnupg-annou...@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
On Wed, 29 Jan 2014 11:14:11 + "nb.linux" wrote: > Gregor Zattler: > > Hi Steve, gnupg users, > > * Steve Jones [24. Jan. 2014]: > > That's an interesting idea. But there is still the possibility > > of a man in the middle attac... The web of trust is supposed to > > counter MITM attacks by signing keys only if the verification was > > done directly (no middle person). > > maybe you already discussed that, but what about sending someone an > encrypted email (with the challenge) and wait for an encrypted reply > with the signed challenge? (as you seem to talk only about sending a > clear text challenge) Yes, the message being sent would have to be encrypted for the procedure to be valid, otherwise an attacker could read the mail and spoof a response (after having already spoofed your communication with the key server). > Personally, I don't want such behaviour. When I'm making a > certification, then it's me doing it manually as I have the > responsibility. I don't want some program to be able to make > automatized certifications with my key. Well, it could be semi-automatic. I'm only talking about persona certifications, which appear to be understood as verifying that the key and the email address are under the control of the same person. Having your mail client being able to determine that the key and the email address seem to match and offering you a one click (plus passphrase) option to verify that fact would be nice. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP key statistics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I got curious about the current distribution of keys available on the keyservers and wrote up a quick tool to dump some of this information[a] from SKS yesterday. Since this might be of interest for others as well I'll include some of the findings here. The full post with main results including some charts are posted in a blog entry on [0]. I hope to get around to digging a bit deeper into more information going forwards, in particular taking into consideration subkeys and expiration/revocations (I just have to figure some good metrics to look at for this), so please let me know if there are specific things that might be interesting. A snippet from the post: The overall majority (94.74%) were Version 4 keys c.f. RFC4880 with V3 keys representing 4.73% and V2 keys representing 0.53%. DSA keys represented 74.4%, while 25.6% were RSA keys and a minority ElGamal (0.03%), Elliptic Curve keys (35 keys) and keys in the experimental range (32 keys) . The key lengths spans from 3 keys in the experimental range key with algo id 103 of 224 bits to 32,768 bits (3 keys, two of which are RSA and one DSA). Due to the low occurrence of ECC keys (that have an expectation of lower key lenghts for similar expected security levels - - normally in the 256-521 bit range, although there is a strong possibility that the aforementioned 224 bits keys should also fit in this category) I have not done any adjustment for these. A full 77.4% of the keys are included when looking at the aggregate figures up to and including 1024 bits, roughly 2.7 million of the keys, and the corresponding number when looking at a 2048 and 4096 bits respectively are 95.3% and 99.95% of all keys included. Endnotes: [a] sksstats is available as a patch to the current SKS tip in my mercurial queue at https://bitbucket.org/kristianf/sks-keyserver-patches/src/tip/SKSStats?at=default References: [0] http://blog.sumptuouscapital.com/2014/01/openpgp-key-statistics/ - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Acta est fabula So ends the story -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJS6TyqAAoJEPw7F94F4TagdpkQAKyDGb3ExP7pbeEt37ObrQl1 25IFJQaHFiGr2e2qoLel8d2YiW5/COyqZgYM0sE2llDvJsTVA/nr1Wm3tAX19nV2 MmOE/WzZDs9JNT5HuWCc7Twm4M6NcbxLTvvbUQ4xsV2dfRQPNDRfTBY3HZw3VPgb P16uN6ryF6Xk5YubEkt3sm+5qFKw1AJmONmnDMSQjLqfKyKnTOLcXIVA3fFFJv0i gHPlblKAI4DP00kHaF1tGQtOqBHj5LbHH7f2UHsfJwvz75T/VLg2mElqQN6LfIJh TqZrilE2a9XNZEXaPvJlMKEseQJpaQsy7vlizPJxPrq9uPCK/svHLVH2u4PQsdGc PdSl3/5cFxsnr9Z4fwV2OijuWOpTBFucNI7VqhEjt212P/bQEPbTpe5hbkKcyGFp Q+cZvyjXH8YnQxigW8oQRZUS8in+BKcEW3/qkyo1S+ZOB54Ih6Qkcmx5f9WJZFP0 0Cy4JybQJhcAXPhCxkswQf2S0QCzHcg7q6jb16Tbze7NWAMsN++CrJgBo4osGa9Q g95DKuUndIELJUjUtuaVko0VjvxZuXVrTTntWqhqw+Cie+H3o1uRvbtmDCaxk1vr oc0FdFHOsNBIr+zBvkJ3GBS30jGYSw+e2aG/RSWENkSIQDIelFr8vVnVl1vU87uL 1zBFYvMyl1hKcCCtdZra =XRAs -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
Well, it could be semi-automatic. I'm only talking about persona certifications, which appear to be understood as verifying that the key and the email address are under the control of the same person. I suspect the majority of GnuPG and PGP users could not tell you what a persona-level verification means. Saying they appear to be understood as X appears to me to be a dangerous bit of conjecture. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
On Wednesday 29 January 2014 10:52:26 Robert J. Hansen wrote: > > Well, it could be semi-automatic. I'm only talking about persona > > certifications, which appear to be understood as verifying that the key > > and the email address are under the control of the same person. > > I suspect the majority of GnuPG and PGP users could not tell you what > a persona-level verification means. Saying they appear to be > understood as X appears to me to be a dangerous bit of conjecture. Since gnupg does equate trust level 1/persona certification to an untrusted one, that should not be a problem IMO. I like how this idea could mirror a "natural" web of trust - given proper MUA support. Under the assumption that an attacker can't reliably do a MITM attack on every message that is sent over an extended time period, you would place almost no trust in a fresh persona-certified key, but high trust in an old and frequently encountered key. The trust would grow with time (just like the trust into someone you know in real life). Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: BoF at FOSDEM ?
Hello all, I’ll be attending FOSDEM, and would be very interested in that. My interest in general is usability of PETs in general, mainly GPG and OTR enabled IM. I am interested in talking about a redesign of the HKP web interface presented to users. From reading the RFC it seems relatively straight forward in terms of interactions and so I’d like to make is slightly more informative to the lay GPG user. Saturday seems like a good day. All the best, Bernard -- Bernard / bluboxthief / ei8fdb If you’d like to get in touch, please do: http://me.ei8fdb.org/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
Hi nb.linux, * nb.linux [29. Jan. 2014]: > Gregor Zattler: >> * Steve Jones [24. Jan. 2014]: >>> Which reminds me that I'd really like an email client that >>> automatically signs keys at level 1 (persona) of anyone who replies >>> with a signed email that quotes a significant portion of the text I >>> sent, as this effectively counts as a challenge response protocol in my >>> book. >> >> That's an interesting idea. But there is still the possibility >> of a man in the middle attac... The web of trust is supposed to >> counter MITM attacks by signing keys only if the verification was >> done directly (no middle person). > > maybe you already discussed that, but what about sending someone an > encrypted email (with the challenge) and wait for an encrypted reply > with the signed challenge? (as you seem to talk only about sending a > clear text challenge) This would not help against a MITM -Attack. I want to send you an email, email program fetches a key with uid nb.li...@xandea.de from the server, evil organisation intercepts this, sends me key with uid nb.li...@xandea.de, I send a challenge encrypted to this key, evil organisation decrypts it rencryts it to you key, sends it to you, you sign-reply to my encrypted challenge, evil organisation intercepts it... > Personally, I don't want such behaviour. When I'm making a > certification, then it's me doing it manually as I have the > responsibility. I don't want some program to be able to make automatized > certifications with my key. me too. Ciao; Gregor ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 29 January 2014 at 7:57:12 PM, in , Johannes Zarl wrote: > Under the assumption > that an attacker can't reliably do a MITM attack on > every message that is sent over an extended time > period Why would that be assumed? In a corporate setting the MITM could be placed within the company's network, for a home user their ISP or email provider could be used, and for mobiles, the phone network. > , you would place almost no trust in a fresh > persona-certified key, but high trust in an old and > frequently encountered key. The older the key, the greater the opportunity for compromise. > The trust would grow with > time (just like the trust into someone you know in real > life). If a person I knew well in real life were "compromised" they are likely a poor enough actor for it to be easily-noticed. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net The second mouse gets the cheese -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlLplxVXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p/PAEAMLzMDuW9+rogvLcrYKTKPZOZDyfj3CwaG+l h5IjlkH1I+wsYooLti/c8hBklE1RxHXlbDjnmjph88IAK2+hHvBtC+HUra+2BZbp KxDeYvthnSeeZ7R1Ry3yX9c7OUO4J2xAZPCVTFmmBoX06jf/nBBHQGAelmnrTF5L dXkfQPTu =8zBv -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 29 January 2014 at 5:24:36 PM, in , Steve Jones wrote: > Well, it could be semi-automatic. I'm only talking > about persona certifications, which appear to be > understood as verifying that the key and the email > address are under the control of the same person. > Having your mail client being able to determine that > the key and the email address seem to match and > offering you a one click (plus passphrase) option to > verify that fact would be nice. So long as the certification applied were only a local signature, I see a niche for this functionality (and the individual user can invest the resulting local signatures with any meaning they wish). As soon as those signatures are exported, it dumps more "noise" to the web of trust for no obvious gain. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Don't talk unless you can improve on the silence -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlLpmmxXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pz1QD/1VQrX52KpK/kNfsZl4A3QZJWYN2CznnaZo+ d1D4y8OZ4zcQOh2fCsraR8sXHU5/U6ctgpX7sBT9BbTYFCI1zAkkpRGR3iTpXDFy RpzJ3B9LamYlS5GYR8EjK+n/wKVbPn44WcwCx17mampyk2QLq5j+g4W+xynvPc5G 6OESu2eg =8u5b -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Non email addresses in UID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 28 January 2014 at 11:37:25 PM, in , Steve Jones wrote: > A more sophisticated approach > would be for OpenPGP to include a new signature type > for this purpose. There are already more than enough signature types. Wouldn't this lend itself quite well to using a signature notation? - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net The greater the power, the more dangerous the abuse. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlLpmzZXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pOPoD/jfjg+2GAHzjy9XPrU7b5LR+HZuCNpP2nzcC EImp/7oEuWTEV1l/9nuUcK9mXzt0JSOsDvALilC9HEvhW82y3vj0kPWh3oz0BCo1 uo2W+n5Q8GDRsIBDXYKkHyBIwJKac2Z++QURPcADdYtf+IJchEJP2KUcbbk5UOtq nw75NoVs =nY4e -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Non email addresses in UID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 24 January 2014 at 11:08:16 PM, in , Steve Jones wrote: > I'd really like an email client > that automatically signs keys at level 1 (persona) of > anyone who replies with a signed email that quotes a > significant portion of the text I sent I'm guessing you would want the automation to skip keys that signed messages messages that were replies to your mailing-list postings. - -- Best regards MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net Live your life as though every day it was your last. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlLpnC5XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pSAgD/3eJUrZAsUf3C7geT9RhaHNkSyAf9gUvkCMg zymBKAfLuYmuACEdKsRgrgOQfkfE53dNBEHvRb2FAs+TCexut3y+qTxsA8/3dbMp pxaFnKuwubc9bUAXfAgzK1BsjMiq6zo7zjD0+1sKXDvgyuGMfL/YxqpH03VPXyyR 9JkWdZDr =RuXo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA "automatically signs keys"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 30 Jan 2014 00:04:17 + MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi > > > On Wednesday 29 January 2014 at 7:57:12 PM, in > , Johannes Zarl wrote: > > > > Under the assumption > > that an attacker can't reliably do a MITM attack on > > every message that is sent over an extended time > > period > > Why would that be assumed? In a corporate setting the MITM could be > placed within the company's network, for a home user their ISP or > email provider could be used, and for mobiles, the phone network. The advantage you have here though is the web of trust. 1 level 1 signature would probably be not enough, but 5, 10, 100..? There comes a point where you have to decide that a certain level of security is good enough. An attacker that can MITM not only your communications with the key server and your emails but that of all your friends can probably do a lot more than just MITM communications - like insert custom hardware into the supply chain rendering software based security useless. > > , you would place almost no trust in a fresh > > persona-certified key, but high trust in an old and > > frequently encountered key. > > The older the key, the greater the opportunity for compromise. Yes, I'd say it's the number of signatures rather than their age which would lend trust. > > The trust would grow with > > time (just like the trust into someone you know in real > > life). > > If a person I knew well in real life were "compromised" they are > likely a poor enough actor for it to be easily-noticed. Maybe, a lot of compromised actors have gotten away with it for a long time. But that's a different story, all the trust in a person's key and identity is useless if they're secretly working against you. - -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJS6aPEAAoJEEgVHtdrBwIA3cMIAOR684K06OPgZP30NeK7qu3u fdP9tq8TkwsIBRdZBFEgR6wkp9YfCu4+qGVqutn4txC+4qyVzbfhMDDFGb17DNHL PVZ3LS0w2jjjpYxU6GUbU6icn4otzqU7GUqsWjQxkjUvDeKW4vuuiz75+dLiXi5B 8SttzmogWzAazVtTVMk4h0PE3dDb8mfWuv02h/BhemfMeN10VT6YJfBhSqmevTiw 4An+GEmvMbtH0lPPRQHtTNvsz632Szp/6I3LObnDKrQWUtPVITqx8cPL3HXC0ozz BwMCaPLDlKO69qnhuzoaqkHBfJ4UuXTKBwfiI9+cmxiFUvyphYm6LBaw7ZmSnNQ= =WDKc -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Non email addresses in UID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 30 Jan 2014 00:22:08 + MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote: > On Tuesday 28 January 2014 at 11:37:25 PM, in > , Steve Jones wrote: > > > > A more sophisticated approach > > would be for OpenPGP to include a new signature type > > for this purpose. > > There are already more than enough signature types. Wouldn't this lend > itself quite well to using a signature notation? Yes, in fact a policy url may be even more appropriate. - -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJS6aWPAAoJEEgVHtdrBwIARAsH/18vWhC4H+9HZlf+t8/ITrkr gqs4nV9M30M3k3o6d/Zj0eCn15Wj0cuaAem5o3oW/owXmvaM1GBkkoqDcnNlfN8S SQwKqNW01KuFYYel9fa37ahgM6I6LrgeRj6R24MehNN1tzPas8RTCJb+WcGgaROY 9niJF0LlgqhHEptvvBgrzMRV5LY6/gXOkLULohyhG7Md4tud98TAPD68hUo/A+in wVWBnIu/Gjjva29Je5l68l40AhCRclCA6Jg2qV7pSqexkQMXHS6aJcTKuj64TKc6 u2UdUtQq+XdeP6/k3jGhTuMkxcZtq0p41RK4KTqLYF1F09e9EOq7bUK1Mtd02Ps= =Zaxx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Setting up shared access to gpg on a UNIX server
Hi, I'm looking for advice and comments about how I have set up a "shared" environment on our UNIX server for gpg operations. What I have certainly works but I thought I'd ask for any comments, suggestions, or criticism. I have gpg version 1.4.14 installed on my server. I have a large number of users who exchange encrypted files with external vendors. Users in my group come and go all the time. On my server, I created a directory named /opt/app/apps/dbmprod/gpg and set the permissions to global access (777). In that directory, I created a gpg instance and created a "group" key without a passphrase (DBMktg). The public key is sent to each vendor as an email attachment when we establish the file exchange procedure. I also added the public keys from all our vendors. I set the permission on all the files in this directory to allow global "read" access (744). Set up this way, any use on the system can decrypt a file intended for use using a command like this: gpg --homedir /opt/app/apps/dbmprod/gpg --batch --no-tty --quiet --local-user "DBMktg" --output --decrypt And to encrypt a file to a particular vendor, we use this: gpg --homedir /opt/app/apps/dbmprod/gpg --batch --recipient --encrypt As I said, this has worked well for use for several years. The main advantage is that I don't need to teach any of the other users about gpg and have a central point to contain all the keys from the many vendors we support. I only need to show users the above two command sequences and they can go on about their business. I suppose that my use of a private key without a passphrase might be of some concern, but I never figured out a better way to do this. In other words, if the single key required a passphrase, I'd have to give out that passphrase to everyone, so what would be the point? I will appreciate any and all comments. If there is a "better way" to do this, I'd love to learn. Bob ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Setting up shared access to gpg on a UNIX server
Il 30/01/2014 02:14, DUELL, BOB ha scritto: > I will appreciate any and all comments. If there is a "better way" to do > this, I'd love to learn. Every user in the group could "leak" the secret key. At least put it into a smartcard/token connected to the server: they'll just be able to *use* it. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Setting up shared access to gpg on a UNIX server
On 01/30/2014 01:59 AM, NdK wrote: > Il 30/01/2014 02:14, DUELL, BOB ha scritto: > >> I will appreciate any and all comments. If there is a "better way" to do >> this, I'd love to learn. > Every user in the group could "leak" the secret key. At least put it > into a smartcard/token connected to the server: they'll just be able to > *use* it. Every user in the group could also destroy the secret key, if the directory itself is still mode 777 -- write access on a directory means you can unlink files from that directory, even if you don't have write access to those files in particular. A user just has to do: rm /opt/app/apps/dbmprod/gpg/secring.gpg and it seems likely that you will be unable to decrypt any further messages (unless someone has already leaked the secret key as NdK suggests, in which case maybe you could ask them for a copy :P) --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
