Re: Vanity Keys
On Tue, Jan 13, 2015 at 8:10 AM, Werner Koch wrote: > On Mon, 12 Jan 2015 21:51, gn...@lists.grepular.com said: > >> Apparently some of the funds will be donated to the GnuPG project. I suspect >> he hasn't been in contact, and I imagine the funds would not be welcome? > > I have not heard about it but given that the Wau Holland Stiftung is > collecting GnuPG donations also via Bitcoin, it is likely that this > can't be tracked. > > However, if that processing power is used to find many dups for long > keyids we will sooner or later neet to invest work to mitigate the > effect of this (e.g. adding a fingerprint as signed attribute to each > signature). Or a new revision of the standard, I suppose. But I think that one or the other would be worth doing in any case given the way things are moving. It is best to be ahead of the game. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: photo-ID
On Thursday, 1 January 2015, Robert J. Hansen wrote: > > I’ve discussed this attack vector on the keyserver mailing list. The > general consensus is that the attack that I’m concerned about is real, and > would result in serious disruption to the global keyserver network for an > extended period until we developed countermeasures — but those > countermeasures would fundamentally transform the keyserver network and > force us to radically redefine our expectations of service. > > Before people think I’m overreacting — > No. It is a realistic attack. Key servers might legitimately strip photo ids if it were ever a problem, IMHO. But in fact, a UID packet can contain arbitrary data anyway, can't it? Isn't that just the same problem. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: My Conclusions
David, I've read most of your emails about this, and I don't see any description of the command you have entered or the error you are getting. Trying to diagnose "it doesn't work" error reports is a little like trying to type blind: you might get it right, but you'll probably just frustrate anyone trying to read what you've written. The standard way to report errors is: 1. What are you trying to do? 2. What command(s) did you enter exactly? 3. What did you expect to see? 4. What did you actually see? So far, I can only see the answer to question 1. N. On Fri, Nov 14, 2014 at 5:11 PM, da...@gbenet.com wrote: > On 14/11/14 11:56, Nicole Faerber wrote: >> Oh please, I am using gnupg with the same keys on at least five >> machines with no issue. >> >> I simply copied the .gnupg directory, end of story. >> >> Cheers >> nicole >> >> >> Am 14.11.2014 um 12:45 schrieb da...@gbenet.com: >>> On 14/11/14 11:34, Nicholas Cole wrote: >>>> David, >>>> >>>> I'm sorry you are having problems, but I think this is just >>>> nonsense. Of course people move keys between machines all the >>>> time. I have done it myself often. I don't think that anyone >>>> deserves that level of abuse -- certainly not someone who has put >>>> years of work into a program that is an industry standard and >>>> released it for free. >>>> >>>> Nicholas >>>> >>>> On Fri, Nov 14, 2014 at 10:42 AM, da...@gbenet.com >>>> wrote: >>>>> Hi All, >>>>> >>>>> After spending 62 hours on what I thought would be a simple >>>>> task namely to get a fully functioning gnupg mirror on my 64 >>>>> bit Linux system - I realise this is an impossible task to do. >>>>> In the past I've ended up creating a new set of certificates - >>>>> but this time round I thought that I would apply some effort. >>>>> >>>>> My conclusion is It IS Impossible To Transfer Your Keys From >>>>> The Same O/S To Another Machine. >>>>> >>>>> There is no one in the entire universe that has ever attempted >>>>> it. And if they have THEY HAVE FAILED. Not one person on this >>>>> list knows how to do it successfully. No one. NOT ONE OF YOU >>>>> can transfer a mirror image of your .gnupg folder and expect it >>>>> to work. >>>>> >>>>> This tells me what I have long suspected - yes it's good at >>>>> encryption and signing but the programme is fundamentally >>>>> flawed as to make it utter crap. My keys are PERFECT but the >>>>> software is CRAP. Werner Koch knows it's crap. Every one knows >>>>> it's crap. >>>>> >>>>> So, If I want to go on signing and encrypting my emails I HAVE >>>>> TO CREATE ANOTHER SET A BLOODY KEYS >>>>> >>>>> I am not a happy bunny!!! >>>>> >>>>> David >>>>> >>>>> >>>>> >>>>> >>>>> -- “See the sanity of the man! No gods, no angels, no demons, >>>>> no body. Nothing of the kind.Stern, sane,every brain-cell >>>>> perfect and complete even at the moment of death. No delusion.” >>>>> https://linuxcounter.net/user/512854.html - http://gbenet.com >>>>> >>>>> ___ Gnupg-users >>>>> mailing list Gnupg-users@gnupg.org >>>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >>>> ___ Gnupg-users >>>> mailing list Gnupg-users@gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >>> I have done everything correctly - and my conclusions are still the >>> same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR >>> .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION >>> PROGRAMME THAT WORKS. >> >>> THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU >>> HAVE NEVER EVER DONE IT. >> >>> David >> >> >> >> >> Viele Grüße >> nicole faerber >> >> >> ___ >> Gnupg-users mailing list >> Gnupg-users@gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > That does not work > > David > > -- > “See the sanity of the man! No gods, no angels, no demons, no body. Nothing > of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment of > death. No > delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: My Conclusions
David, I'm sorry you are having problems, but I think this is just nonsense. Of course people move keys between machines all the time. I have done it myself often. I don't think that anyone deserves that level of abuse -- certainly not someone who has put years of work into a program that is an industry standard and released it for free. Nicholas On Fri, Nov 14, 2014 at 10:42 AM, da...@gbenet.com wrote: > Hi All, > > After spending 62 hours on what I thought would be a simple task namely to > get a fully > functioning gnupg mirror on my 64 bit Linux system - I realise this is an > impossible task to > do. In the past I've ended up creating a new set of certificates - but this > time round I > thought that I would apply some effort. > > My conclusion is It IS Impossible To Transfer Your Keys From The Same O/S To > Another Machine. > > There is no one in the entire universe that has ever attempted it. And if > they have THEY > HAVE FAILED. Not one person on this list knows how to do it successfully. No > one. NOT ONE OF > YOU can transfer a mirror image of your .gnupg folder and expect it to work. > > This tells me what I have long suspected - yes it's good at encryption and > signing but the > programme is fundamentally flawed as to make it utter crap. My keys are > PERFECT but the > software is CRAP. Werner Koch knows it's crap. Every one knows it's crap. > > So, If I want to go on signing and encrypting my emails I HAVE TO CREATE > ANOTHER SET A > BLOODY KEYS > > I am not a happy bunny!!! > > David > > > > > -- > “See the sanity of the man! No gods, no angels, no demons, no body. Nothing > of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment of > death. No > delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1 and Mailpile (LWN comments) about GPGME
On Tue, Nov 11, 2014 at 2:21 PM, Bernhard Reiter wrote: > In https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html > the Mailpile developers would like to replace GnuPG with something better > and for the short term propose to extend GnuPG with a command line JSON > interface in the short term. > > I've commented the article under the LWN news about GnuPG 2.1.0 release > https://lwn.net/Articles/619337/ as following: I actually disagree with the assumption here. The --with-colons --command-fd --status-fd interface has been remarkably stable. The last major incompatible change was in 1.4.9 and 2.0.11 when the order in which subkey algorithms were presented was changed. Other than that, it is an incredibly well-designed an easy to parse interface. The only way in which it can trip you up is that you need to keep a careful watch on whether you are expecting further data from gpg or not. The stability and utility of this interface is one of my favourite aspects of the gnupg project, and I really admire Werner for his work here. Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1 Unattended EC Generation
I'm so sorry, Werner. I thought I'd checked the manual. Huge apologies.
On Tuesday, 11 November 2014, Werner Koch wrote:
> On Tue, 11 Nov 2014 12:56, nicholas.c...@gmail.com said:
>
> > Is that still possible? In version 2.1, if no password is specified,
> > gpg2 tries to call pin-entry and ask for a passphrase.
>
> A quick look into the manual (for me the source, but you may want to use
> the online version) gives:
>
> @item %no-protection
> Since GnuPG version 2.1 it is not anymore possible to specify a
> passphrase for unattended key generation. The passphrase command is
> simply ignored and @samp{%ask-passpharse} is thus implicitly enabled.
> Using this option allows the creation of keys without any passphrase
> protection. This option is mainly intended for regression tests.
>
> Thus by adding
>
> %no-protection
>
> to the parameter files you can create a key without a passphrase.
>
> > The second problem is that if gpg is called with a non-standard
> > --homedir the whole thing fails with:
> >
> > gpg: agent_genkey failed: No pinentry
>
> Install a pinentry. I guess you put usually have a
> "pinentry-program" line in your gpg-agent.conf. With a different home
> directory the gpg-agent.conf of that home directory is used. I suggest
> to install a symlink to pinentry into the installation dir of gnupg and
> not to use "pinentry-program".
>
>
> Shalom-Salam,
>
>Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1 Unattended EC Generation
On Mon, Nov 10, 2014 at 4:41 PM, Werner Koch wrote: > On Mon, 10 Nov 2014 12:52, nicholas.c...@gmail.com said: > >> How does unattended generation of elliptic curve keys work? As far as >> I can see, that section of the manual has not been updated for the new >> EC options, but I presume that it has to work slightly differently. >> Am I right that key-length is now a no-op? And how do you specify the > > Right, you need to use "Key-Curve" or "Subkey-Curve". Curve names are > as supported by Libgcrypt, for example: "nistp256" or "ed25519". Thanks Werner! Two smaller problems. Under previous versions, failing to provide a Passphrase: would create a key without a passphrase. This was useful for testing purposes. Is that still possible? In version 2.1, if no password is specified, gpg2 tries to call pin-entry and ask for a passphrase. The second problem is that if gpg is called with a non-standard --homedir the whole thing fails with: gpg: agent_genkey failed: No pinentry gpg: key generation failed: No pinentry I'm sure this means that I'm invoking the new gpg2 and gpg-agent combination incorrectly. Sorry for all the flood of questions. gpg2 "modern" is very exciting, but getting all the pieces to work as they used to (and making changes for the new system) is going to take a bit of time! Best wishes, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Detached signature ambiguity
On Mon, Nov 10, 2014 at 12:25 PM, Peter Lebbing wrote: > On 10/11/14 13:03, Nicholas Cole wrote: >> But in fact, it is the fact that scripts depend on this that made me >> think that this might be a case where things *should* get broken, >> because this is actually a serious security flaw, and the scripts in >> question need fixing. In many cases, no one is going to be around to >> read the warning you suggest. > > Hmmm, very solid point... unfortunately :(. Not a pretty situation to be > in at all... > > It still suggests to me it should only break when normally there would > be a detached signature verified (i.e., without the .sig extension) but > it is not because it is not a detached signature. I suppose these > scripts wouldn't work anyway when files are named as in my problematic > example: > > gnupg_2.1.0.tar.bz2 > gnupg-2.1.0.tar.bz2.sig > > So simply returning error in the case where there /is/ a full match > seems to fix the scripting case. It still leaves the user-driven case, > because the user can still be foiled by a single-character change. > > It might be possible for an attacker to force a signature verification > failure of a script if he can name files in the same directory. Suppose > a script is supposed to verify ledger.csv.asc, which is /not/ a detached > signature, but simply has the data embedded. An attacker could create a > file in the same dir with the name ledger.csv and cause the ambiguity > detecting mechanism to trigger falsely, leading to signature > verification failure. Whether this is a real issue, I don't know. In my view, the long experience of bugs like this suggests that it is better to live with the short-term pain of breaking things in order to get a robust solution, than to fix a solution in various ingenious ways that themselves introduce a whole series of corner-cases and opportunities for exploitation. I hate breaking backwards compatibility normally, but this seems like such a fundamental problem I don't know what to do about it. I *suppose* a fix would be to: - introduce two new commands along the lines I suggested. - make the old verify command: 1. Refuse to verify a detached signature without a .sig extension 2. Refuse to verify a non-detached-signature contained in a file with a .sig extension. But I don't like the solution, really. It introduces code that has to be maintained, and sill leaves users vulnerable to tricks involving unicode etc., so that the security it provides is itself an illusion. In my view it is much better just to break the old --verify command completely. Scripts that are maintained will have a simple fix, and scripts that are not will no longer give a completely false sense of security. Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
DSA key sizes
Just out of curiosity: DSA key sizes are now rounded to one of 3 values, whereas RSA keys are available in a range of sizes between two limits. Why the difference? Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Detached signature ambiguity (was: [Announce] GnuPG 2.1.0 "modern" released)
On Mon, Nov 10, 2014 at 11:59 AM, Peter Lebbing wrote: > On 10/11/14 12:02, Nicholas Cole wrote: >> So the confusion is >> that you have one single command that deals with verifying both a >> detached signature and with a file that contains a signature? > > Yes. > >> Is the best fix for this to introduce two new commands > > That seems extreme. Although you could add commands that make it > explicit what you want, removing the existing, ambiguous one would cause > massive breakage of deployed scripts. Werner is always very cautious > about doing that. > > Maybe this avenue of thought can help come up with a good solution. When > people verify a detached signature, they usually have two files named: > > file.ext > file.ext.sig > > If GnuPG encounters this situation, but file.ext.sig is not a detached > signature, it could display a big fat warning: > > WARNING: file.ext.sig is NOT a detached signature; the file file.ext is > NOT VERIFIED! Yes, Werner is very good at not breaking things that don't need to be broken. But in fact, it is the fact that scripts depend on this that made me think that this might be a case where things *should* get broken, because this is actually a serious security flaw, and the scripts in question need fixing. In many cases, no one is going to be around to read the warning you suggest. Just a thought. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
ECDSA vs EDDSA
In the new gpg2 --version lists both ECDSA and EDDSA as supported algorithms, but that doesn't seem to correspond to options in the --expert --full-gen-key command. I presume that --full-gen-key creates an ECDSA by default. Is that right? Perhaps someone who knows about EC could write an FAQ on the wiki for those of us who are confused by all the new options? Yes, I know that for ordinary use we should all just use the defaults, but I'd still like to know what is going on, for interest's sake. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG 2.1 Unattended EC Generation
Dear List, How does unattended generation of elliptic curve keys work? As far as I can see, that section of the manual has not been updated for the new EC options, but I presume that it has to work slightly differently. Am I right that key-length is now a no-op? And how do you specify the curve? Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
On Fri, Nov 7, 2014 at 9:21 PM, Simon Nicolussi wrote: > The announcement read: >> If you already have a version of GnuPG installed, you can simply >> verify the supplied signature. For example to verify the signature >> of the file gnupg-2.1.0.tar.bz2 you would use this command: >> >> gpg --verify gnupg-2.1.0.tar.bz2.sig > > Invoking GnuPG that way is insecure without knowing the contents of the > signature file. An attacker could have replaced it by something that's > not, in fact, a detached signature. > > I've attached an exemplary signature file (named gnupg-2.1.0.tar.bz2.sig > for your convenience) that demonstrates the problem: >> $ echo evil stuff > gnupg-2.1.0.tar.bz2 >> $ gpg2 --verify gnupg-2.1.0.tar.bz2.sig >> gpg: Signature made Fri Oct 31 07:55:15 2014 CET using RSA key ID 4F25E3B6 >> gpg: Good signature from "Werner Koch (dist sig)" [full] > > Future announcements should call --verify with two files as arguments; > the same goes for https://www.gnupg.org/download/integrity_check.html: >> gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2.sig Is the point that you can have a signed file that makes you THINK you have verified a file when in fact you haven't? So the confusion is that you have one single command that deals with verifying both a detached signature and with a file that contains a signature? Is the best fix for this to introduce two new commands --verify-detached (requires two arguments) and --verify-file and then to make everything that simply calls the old command --verify break? Or is that too radical? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1.0 for Mac OS X Available
Hi Patrick, Thanks for this! It's a really useful resource. Are you able to explain how you managed to get GnuPG-2.1 to compile? N. On Sun, Nov 9, 2014 at 6:39 PM, Patrick Brunschwig wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I'm happy to announce the first release of the "GnuPG for OSX" project > - - a new distribution of GnuPG 2.1 for Mac OS X ready to download and > install. > > I started "GnuPG for OSX" to provide up to date distributions of GnuPG > on Mac. Unlike GPG Tools, this project "only" provides the complete > standard gpg tool suite, and no additional software. > > The distribution requires Mac OS X 10.7 or newer and a 64-bit processor. > > The software is available from: > http://sourceforge.net/projects/gpgosx/files/GnuPG-2.1.0.dmg/download > > - -Patrick > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUX7T6AAoJEMk25cDiHiw+Kq8IAL2u1dYTniPOpFHvPg5JFM5D > EN2ebaLhOfpic6/xZ0BEtaeYWDYa09QaIKsQzRH9q0n03dLEdzrjpLJFSQLuNH4o > xjSoJCM3PYtWg7d6ySHPyfePhAKal5u+jQ3z6zsoWccyaNKiHVYvXebU0Nanjr+R > RKEi6qdTSD4KcVOVbb0T/wvRjRaJz8lRwFaCXm9nxViaudXko/hQuO3Dl4UY2m/C > vGbDMSN4qyICMi7B3uLD/uC1gXnn3zYgXRaZVS3MSkKmAgsHUgsDAEGvzXXhcGmn > i7s+JjOrkhStufpahPpDjAsnOXG8Jk12+3GFhRsxTv9RPU5qXdcpfGzv7ZGdt4w= > =/cuU > -END PGP SIGNATURE- > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.0 "modern" released
Hi Werner, Building on OS X using make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local gets what looks like most of the way and then fails with the error shown below. Am I the only person experiencing this, or are others hitting the same problem? Best wishes, N. Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[5]: *** [t-sexputil] Error 1 make[5]: *** Waiting for unfinished jobs make[4]: *** [all] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/nicholas/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 On Thu, Nov 6, 2014 at 9:01 AM, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a > new release: Version 2.1.0. > > The GNU Privacy Guard (GnuPG) is a complete and free implementation of > the OpenPGP standard as defined by RFC-4880 and better known as PGP. > > GnuPG, also known as GPG, allows to encrypt and sign data and > communication, features a versatile key management system as well as > access modules for public key directories. GnuPG itself is a command > line tool with features for easy integration with other applications. > A wealth of frontend applications and libraries making use of GnuPG > are available. Since version 2 GnuPG provides support for S/MIME and > Secure Shell in addition to OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > Three different versions of GnuPG are actively maintained: > > - GnuPG "modern" (2.1) is the latest development with a lot of new > features. This announcement is about the first release of this > version. > > - GnuPG "stable" (2.0) is the current stable version for general use. > This is what most users are currently using. > > - GnuPG "classic" (1.4) is the old standalone version which is most > suitable for older or embedded platforms. > > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. > > > What's New in GnuPG-2.1 > === > > - The file "secring.gpg" is not anymore used to store the secret > keys. Merging of secret keys is now supported. > > - All support for PGP-2 keys has been removed for security reasons. > > - The standard key generation interface is now much leaner. This > will help a new user to quickly generate a suitable key. > > - Support for Elliptic Curve Cryptography (ECC) is now available. > > - Commands to create and sign keys from the command line without any > extra prompts are now available. > > - The Pinentry may now show the new passphrase entry and the > passphrase confirmation entry in one dialog. > > - There is no more need to manually start the gpg-agent. It is now > started by any part of GnuPG as needed. > > - Problems with importing keys with the same long key id have been > addressed. > > - The Dirmngr is now part of GnuPG proper and also takes care of > accessing keyserver. > > - Keyserver pools are now handled in a smarter way. > > - A new format for locally storing the public keys is now used. > This considerable speeds up operations on large keyrings. > > - Revocation certificates are now created by default. > > - Card support has been updated, new readers and token types are > supported. > > - The format of the key listing has been changed to better identify > the properties of a key. > > - The gpg-agent may now be used on Windows as a Pageant replacement > for Putty in the same way it is used for years on Unix as > ssh-agent replacement. > > - Creation of X.509 certificates has been improved. It is now also > possible to export them directly in PKCS#8 and PEM format for use > on TLS servers. > > A detailed description of the changes can be found at > https://gnupg.org/faq/whats-new-in-2.1.html . > > > Getting the Software > > > Please follow the instructions found at https://gnupg.org/download/ or > read on: > > GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found > at https://gnupg.org/mirrors.html . Note that GnuPG is not available > at ftp.gnu.org. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig > > This is the GnuPG 2.1 source code compressed using BZIP2 and its > OpenPGP signature. > > ftp://ftp.
Re: encrypting to expired certificates
I'll admit that I hadn't actually realised how hard it is to make GnuPG change the expiry dates of subkeys at the same time as changing the expiry date of the main key. What is the approved way to do this? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tuesday, 16 September 2014, Peter Pentchev wrote: > On Tue, Sep 16, 2014 at 03:04:08PM +0100, Nicholas Cole wrote: > > Can anyone explain to me why one would want to continue using a key > > and yet not simply change the expiry date? I really find all of the > > examples being given to be incredibly contrived. > > Uhm, are you sure that you really mean to say "incredibly contrived" as > in "you guys must have tried your imagination really hard to come up > with these examples, none of which will happen in the real world", or do > you really mean "highly unlikely except in isolated use cases"? Because > what people are showing you are real use cases, ones that have happened > with real people in the real world. "Unlikely" and "isolated", yes, but > I wouldn't use "contrived" in this case. > I apologise for my poor choice of language. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
Can anyone explain to me why one would want to continue using a key and yet not simply change the expiry date? I really find all of the examples being given to be incredibly contrived. It takes no time at all these days to change the date and distribute the new key. As I've said, if the tools to do this kind of thing easily do not exist, they need to be created. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Tue, Sep 16, 2014 at 1:12 AM, Robert J. Hansen wrote: >> That does not seem like an argument to me for telling the user what >> is best for him. > > Hauke, this entire argument is what I meant when I talked about gilding > the lily repeatedly. If you can find half a dozen *real users* who are > being *really impacted* by this, I'd love to hear about them. But so > far, all the discussion is so hypothetical that it's hard for me to take > it seriously. > > I get that you view the current situation as in need of changing. I > don't agree, and I won't agree until I see six real life users whose > usage of GnuPG would be made significantly better by making this change. > > Until then, all I can do about this 'problem' is yawn. ^ The six-real-user test should really be applied to all features in all software! Hauke, you make one strong case and one weak one. Yes, I agree that GnuPG already lets you override so many things, why shouldn't it let you override this? It's not exactly logical (though I think that one can reconstruct the logic). But you are on weak ground when you try to say that expiration dates are only a warning, or draw a distinction between 'strong' and 'weak' statements that a key should not be used. That maybe how you use them, and it may be that expiry dates on milk are only warnings, but I have always read an 'expiry date' on a key to mean 'Do not use after this date', just like an expiry date on an ID card. Yes, perhaps you do use them in other ways, but still. I can see you've hit a key-management problem. That is really the thing that needs fixing, and if easy tools to do that are not available, then they need to be. Robert is right, I think. A little more 'policy', at least in the sense of software assisting a shared sense of good practice, would really help. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Monday, 15 September 2014, Robert J. Hansen wrote: > > Sorry. I've confused too issues. Yes, it is hard to enforce expiry > > dates in a 'secure' way. I wasn't meaning to suggest it was > > something openpgp should try to do. I don't think we should make it > > easy to ignore them, that's all. > > Well, I still respectfully disagree, because -- oh, that's a rant. > > Then again, when has something being a rant ever stopped me? > > Okay: hang tight for some heresy. > > (Snip) > But if you want to start waving the banner of, "POLICY! GET SOME!", > well, the line starts behind me. :) > I enjoyed that rant so much that I don't even mind that you have misinterpreted what I said and attributed to me ideas I don't hold: for which I'm prepared to take 50% of the blame! Just for the record: all I've ever said in this thead is that I don't think there is a compelling case to add an option to gpg to ignore expiration dates. That's all. Although, gosh! It already lets users do so many silly things perhaps one more doesn't matter. Your rant was a good one. I agree with much of it. Frankly, as a community we haven't developed the tools and culture that might have assisted users to develop good policy and good practice. I also despair a little. PGP made more sense, in some ways, in the early 1990s when most home and business computers were offline most of the time. Maybe not been then. Nowadays, I'm not at all sure I would trust openpgp to protect me if I were really worried about my privacy being under any kind of targeted attack: frankly I can't think of an OS platform I really trust to be secure, and if you can't trust the platform then a bets are off. Even Apple, who have every incentive to do so and control of both hw and sw, can't manage to keep their platforms secure. Of course, an air gap might help, but that really is a very major hassle and I don't have cause. I'm interested in the user interface problems that OpenPGP presents. That's kept my interest in it alive for all these years. I don't have any high hopes it will ever be widely adopted though: for most people, most of the time, there is limited benefit, if any. Nicholas. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, Sep 15, 2014 at 6:19 PM, Robert J. Hansen wrote: >> Respectfully, Hauke, we just disagree on this. But your last >> comment raises a crucial point that I think has bugged OpenPGP for >> far too long: the software we use for OpenPGP has actually been far >> too liberal about letting people use "not valid" keys. > > If by "too liberal" you mean "it's possible to do it," then I don't see > how to avoid it. You'd need a trusted timestamp on the certificate and > a trusted timestamp on the machine using the certificates, and trusted > timestamps are a hard, *hard* problem. > > Yes, OpenPGP is quite permissive about letting people encrypt to expired > certificates, but I think that's more a factor of it being incredibly > hard to prevent it than it is any neglect on the part of the OpenPGP > authors. Sorry. I've confused too issues. Yes, it is hard to enforce expiry dates in a 'secure' way. I wasn't meaning to suggest it was something openpgp should try to do. I don't think we should make it easy to ignore them, that's all. No the other issue I was pointing to was that many users (probably) never bother to certify the keys of the people they communicate with and just ignore the fact that the keys are invalid. Because it is easy (though unwise) to use PGP/GPG in this way, I don't think developers have really paid enough attention to encouraging users to certify the keys they are trying to use or to use keys that are in a web of trust (nb. a web of trust not The Web Of Trust). Instead, we've actually had endless threads about when to 'sign' keys (only if three passports produced that have been certified by unicorns etc) that are probably very off-putting to new users. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, Sep 15, 2014 at 5:13 PM, Hauke Laging wrote: [snip] > I have created his certificate. That is an offline mainkey and he is > probably not capable (or willing) to extend the validity period. He is > not going to replace the key. It is not considered compromised. We(?) > even talked on the phone today. > > It is far from a serious assessment of the situation to claim that the > key owner want me not to use this key any more. And this situation is > far less strange than the other ones offered in this thread. > > If you set an expiration date (no matter whether with GnuPG or the well- > known GUIs) then the software does not tell you that senders were not > allowed / not capable to use this key after that date. It says something > about "How long shall it be valid?". Respectfully, Hauke, we just disagree on this. But your last comment raises a crucial point that I think has bugged OpenPGP for far too long: the software we use for OpenPGP has actually been far too liberal about letting people use "not valid" keys. This has taken pressure off the writers of user interfaces to find ways of encouraging users to use the software properly, and at the same time the web of trust has been shrouded in far too much mystique and mystery! If a user sets up a key and sets the flag on the key that explicitly means, "Do not use it after this point" I think the software should enforce that. I can see that it creates a (small?) potential for a DoS attack, and I can see that there might be cases you want to override it in special circumstances. As it happens though, it isn't exactly a strong protection for someone willing to delete revocation signatures and so on to make things work. The work-around is simple: wind your computer clock back and you'll be fine in this case. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Mon, Sep 15, 2014 at 1:10 PM, Hauke Laging wrote: >> If a key has an expiry >> date, GPG can be very very certain that that key should not be used > >> You can't make assumptions for the reason a key has an expiry date. > > Do you think these two statements are consistent? >> It could be that after that date it would be insecure to send >> encrypted data to that key. > > How is that possible without anything encrypted to this key before the > expiration date becoming insecure, too? If a key has become insecure > then it is to be revoked. I don't know. If a key says on it "You can use this key for these email addresses up until this date" I think that tools SHOULD NOT use the key beyond that date or for other email addresses. I think in the case of the expiry date, I'd see a strong case for MUST NOT. The expiry date is there exactly so that users do not have to explicitly revoke keys. Or do you think one should be able to encrypt to revoked keys too? I do see a difference with merely NOT VALID keys, because those keys might be checked using some external trust system, though it is bad practice 99% o the time, I suspect. I can't see any justification for encrypting to a key past its expiry date. Either your correspondent is in a position to update the key, or he/she isn't. In the latter case, the key should not be used. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encrypting to expired certificates
On Monday, 15 September 2014, Hauke Laging wrote: > Hello, > > after filing a bug report for my mail client because it does not allow > me to encrypt to an expired certificate (neither does Enigmail) I was > surprised to notice that I didn't manage to encrypt to an expired > certificate with gpg in the console (2.0.22). > > Is this not possible (what about gpgme?) or am I just not aware of how > to get that done? > > I would consider not being able to encrypt to an expired key a severe > security flaw because it may force the sender to send the message > unencrypted. It is OK to warn the user but it must be possible to > override this warning. Expiration is not a security problem (let alone a > severe one). > > It does not even work with --encrypt-to. And the man page says about > this command: > > "No trust checking is performed for these user ids and even disabled > keys can be used." > > Non-valid keys are OK, disabled keys are OK but the least severe case > expiration is not OK? > > > Hauke > Opportunistic encryption with a fall-back mode to plain text, which seems to be your model, is dangerous. Yes, it is always dangerous to have a protocol that sends in plain text if encryption is impossible. However, I don't think the fault is with GPG. If a key has an expiry date, GPG can be very very certain that that key should not be used after a particular date. In fact, I don't think that user interfaces should ever have encouraged people to encrypt to 'not valid' keys at all, but if they key itself says that it should not be used, then it really should not be used. You can't make assumptions for the reason a key has an expiry date. It could be that after that date it would be insecure to send encrypted data to that key. I think that implementations should respect the expiry dates on keys. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: So on & so forth
On Fri, Aug 15, 2014 at 6:54 PM, Richard Outerbridge wrote: > Still waiting for my email address, yet my blackphone is already in > my hands. Keep up the good work. > > I’m not going to bother with 2.1 until the Mac guyz come to their > senses about not forking the crypto. Could be a long wait. They've made a fork? I hadn't realised that. Why on earth? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's time for PGP to die.
On Sun, Aug 17, 2014 at 10:14 PM, Robert J. Hansen wrote: >> Leaving aside the issue of how popular encryption of mail is - we are >> faced with the fact that 98 per cent of computer users are completely >> ignorant about software and hardware. But even if they weren't, the problem is that OpenPGP protects such a small part of the problem that it is hard to justify the additional time and effort to users. If the revelations of the last year have proved anything, it is that most computer systems are vulnerable at a very deep level to all kinds of sophisticated attacks. In that context, where the underlying operating systems themselves are so vulnerable, OpenPGP really doesn't solve very much for most users. Supposing the following threat model (which I think corresponds to how must people use email): - physical security of hardware. - the need for secure communication contents (but the fact of the communication is not secret). - connection of the computers to the internet. - attackers who are interested in the content of the communication and who are willing to launch electronic attacks to get it. OpenPGP would be an ideal solution for the actual transmission in this scenario -- except that there is simply no operating system that can be trusted to be a secure platform upon which to run OpenPGP. There will always be a weaker link than the encryption, and so the right solution for most users is not to send confidential information by email at all. Now, there are still plenty of uses for OpenPGP, but they tend to be niche ones with particular threat models and especially motivated users. To expect mass-adoption of a tool with only niche uses is not reasonable. It doesn't mean that the project is a failure. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: It's time for PGP to die.
On Sun, Aug 17, 2014 at 12:08 AM, Robert J. Hansen wrote: > On 8/16/2014 1:14 PM, Kristy Chambers wrote: >> Sorry for that crap subject. I just want to leave this. > > Meh. Color me unimpressed. This was a terrific post. Thank you, Robert. [snip] > * "No forward secrecy." Not everyone needs PFS, and frankly, obsession > with PFS is one of those things I really wish people would grow out of. > Before complaining about what OpenPGP needs or where it's lacking, try > looking at where OpenPGP has been broken in the real world. Hint: PFS > ain't a panacea. I agree people are obsessed with this, and it is unhealthy. I think the name doesn't help. I've seen various definitions. http://en.wikipedia.org/wiki/Forward_secrecy "This means that the compromise of one message cannot lead to the compromise of others". In the case of PGP, of course, it is true that the compromise of the Public key would compromise all messages, but in other ways PGP does help. It is possible, for example, to surrender just the session key, in the case that it is necessary to do so to comply with a legitimate law-enforcement request. But I don't see how PFS could really apply to something like email, as opposed to something like an http request. > * "So what should we be doing?" There are 25 years invested in making PGP work. Many subtle bugs and security errors in the protocol and the gnupg implementation have been worked out. Throwing out PGP would be a bit like making this mistake: http://www.joelonsoftware.com/articles/fog69.html > OpenPGP's biggest problem, BTW, which goes *completely unmentioned* in > this blogpost: OpenPGP can't protect your metadata, and that turns out > to often be higher-value content than your emails themselves are. > Further, exposed metadata is inherent to SMTP, which means this problem > is going to be absolutely devilish to fix. That is true. But perhaps it would be a start if email clients actually put the actual email (with subject and references headers etc.) as an attachment to a bare email that contained only the minimal headers for delivery. It wouldn't be a perfect solution, but it would at least fix a certain amount of metadata analysis. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: card reader (was: riseup.net OpenPGP Best Practices article)
On Sat, Jun 28, 2014 at 9:18 AM, Werner Koch wrote: > On Fri, 27 Jun 2014 21:44, ds...@jabberwocky.com said: > >> I do admire the Neo form factor though. > > The SCT3512 [1] with an OpenPGP card is also quite convenient: > > http://werner.eifzilla.de/sct3512.jpg > > I have taken off the ID-000 form factor card for the picture. The label > is also non-standard but easy to apply. I have that reader in daily use > for about a year now. kernelconcepts distributes pre-punched cards but > it is also possible to cut an ID-000 out off a regular sized card. > Price for the reader w/o card is in the 20 Euro range. I can't find a UK source for this, but it does look good. Speaking of which, is there an alternative source for GnuPG Smartcards? KernelConcepts is out of stock until August. Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] A new Beta of GnuPG 2.1 is now available
On Thu, Jun 5, 2014 at 4:55 PM, Werner Koch wrote: > Hello! > > I just released the fourth *beta version* of GnuPG 2.1. It has been > released to give you the opportunity to check out new features and > a new beta was due anyway after 30 months. Dear Werner, Congratulations on this. I just wonder if anyone would have time to put together a HOW-TO for people building GnuPG 2.1 and all of its associated libraries from source. For those of us who don't do this often, this is currently a rather frustrating process, and a mini-how-to explaining what all the pieces are and which order to build them would be really welcome. Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trust Signature REs
On Wed, May 21, 2014 at 9:47 AM, Werner Koch wrote:
> On Wed, 7 May 2014 19:23, nicholas.c...@gmail.com said:
>
>> Is there any way to tell gnupg that I am actually entering a raw re
>> and do not wish it to do any conversion?
>
> No.
>
> FWIW, here is a comment describing how gpg uses the RE:
>
> /* There are basically two commonly-used regexps here. GPG and most
> versions of PGP use "<[^>]+[@.]example\.com>$" and PGP (9)
> command line uses "example.com" (i.e. whatever the user specfies,
> and we can't expect users know to use "\." instead of "."). So
> here are the rules: we're allowed to start with "<[^>]+[@.]" and
> end with ">$" or start and end with nothing. In between, the
> only legal regex character is ".", and everything else gets
> escaped. Part of the gotcha here is that some regex packages
> allow more than RFC-4880 requires. For example, 4880 has no "{}"
> operator, but GNU regex does. Commenting removes these operators
> from consideration. A possible future enhancement is to use
> commenting to effectively back off a given regex to the Henry
> Spencer syntax in 4880. -dshaw */
>
> I have no concerns on adding an option to allow setting an arbitrary RE.
> The easiest way of implementing this would be by prepending a flag to
> the prompt. For example
>
Dear Werner,
Thanks for this. The comment in the code was very helpful, and I used
it to construct a way to reverse-engineer the original domain and then
feed that back to gpg which works fine. All the same, a leading way
to say |raw| would be even better.
Best wishes,
N.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Trust Signature REs
If I tell gnupg to make a trust signature limited to the domain: nowhere.com it converts this into <[^>]+[@.]nowhere\\x5c.com>$ I see the logic. However, if I am trying to copy this re from one signature to another, and I tell gnupg to limit a trust signature to " <[^>]+[@.]nowhere\\x5c.com>$ ", it does not recognise this as a regular expression, but instead converts it to " <[^>]+[@.]\x5c<\x5c[\x5c^\x5c>\x5c]\x5c+\x5c[\x5c@\x5c.\x5c]nowhere\x5c\x5cx5c\x5c.com\x5c>\x5c$>$ " Is there any way to tell gnupg that I am actually entering a raw re and do not wish it to do any conversion? Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)
On Sat, May 3, 2014 at 8:54 AM, NdK wrote: > Il 03/05/2014 01:10, Daniel Kahn Gillmor ha scritto: > >> Having such an assertion cryptographically bound to the OpenPGP >> certificate in parseable form implies in some sense that you think a >> mechanical process (e.g. WoT calculated validity) should be able to make >> use of it. But how would that work? > Making WoT calculator avoid looking for keys signed by that user if > reached throught my certification. > >> It sounds like you'd want to ask >> an OpenPGP to introduce an additional concept on top of the notions of >> validity and ownertrust (which are already confusing): > They work: I'm *really* confused. :) > >> some sort of meta-ownertrust: instead of ownertrust's question of: >> "how much am i willing to rely on NdK's identity assertions", > Well, if ownertrust answers that, it's what I need: a way to say "I am > sure this key belongs to X, but I don't want it to be used to introduce > more keys in the WoT". But it doesn't work like that anyway. Unless you are using Trust signatures (and few people do) then a signature on a key does not encourage a 3rd party to trust signatures made by that key. Even if a key is recognised as authenticated/validated/certified for association with a particular email address, the signatures made by that key will not be trusted by anyone who has not made an active decision to make a particular key a trusted introducer. In fact, this is a reason (though one of many) why the web of trust has never quite lived up to its promise. No UI that I am aware of sets even marginal trust by default on newly imported keys. Most users (I suspect) will only ever end up trusting keys that they themselves have signed. That is the default position. It is interesting to speculate whether the WoT would have been more effective if there had been a culture of marginally trusting new keys by default, allowing users to make an active choice either to not trust someone or to fully trust someone. As it is, the inertia of the system works against the idea of a web of trust.[*] In any case - there is no need for what you are suggesting. 3rd parties are not (by default) going to infer from your signature that they should then trust the key you sign as an introducer. N. [*] I'm aware there are problems with "marginal trust" related the fact that the requirement of three marginally trusted signatures to confer validity may in fact be fairly weak. The three signatures may not, in fact, be made independently of each other (consider three keys owned by the same person which all introduce a third key, for example, or multiple signatures made a single key-signing party). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's 2014. Are we there yet?
On Sat, Apr 19, 2014 at 3:35 PM, One Jsim wrote: > > from: > > > http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-public-key-forgery > > > at 2014-04-19T14:49+1 > > > I retrieve > > > "Yes, it is possible to create a public key with the same fingerprint as an > existing one, thanks to a design misfeature in PGP 2.x when signing RSA > keys. The fake key will not be of the same length, so it should be easy to > detect. Usually such keys have odd key lengths" > > > How percentage of PGP (or GPG?) users, do you think, know that checking > fingerprint only is not an assurance against fake signatures? Did you know? I *thought* [citation?] that this problem was fixed with version 4 keys. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: V3 key lookup
On Sun, Jan 5, 2014 at 1:24 PM, Nicholas Cole wrote: > Dear list, > > I've been implementing a local version of > > http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 > > for some experimenting. > > I have a server working listening on local host and replying with the > correct formats to the defined requests. > > Everything works fine with version 4 keys, but if gpg (version 1 or 2) > attempts to download a version 3 key, it simply exits with an error about no > valid data found. > > The odd thing is that the request doesn't even show up in the server logs. > As far as I can tell, gpg doesn't even attempt the request. > > What could be going wrong? Is it that for some reason the v3 code doesn't > like a local host? At the risk of answering my own question experiments on the console (rather than using a front-end) revealed the helpful message: """ gpg: requesting key ?v3 fpr? from hkp server localhost gpgkeys: HKP keyservers do not support v3 fingerprints gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: keyserver internal error """ Thanks Werner for making your error messages so clear. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
V3 key lookup
Dear list, I've been implementing a local version of http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 for some experimenting. I have a server working listening on local host and replying with the correct formats to the defined requests. Everything works fine with version 4 keys, but if gpg (version 1 or 2) attempts to download a version 3 key, it simply exits with an error about no valid data found. The odd thing is that the request doesn't even show up in the server logs. As far as I can tell, gpg doesn't even attempt the request. What could be going wrong? Is it that for some reason the v3 code doesn't like a local host? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Where is ECC in gpg2 (specifically gnupg-2.0.21
On Thu, Sep 19, 2013 at 6:44 PM, Werner Koch wrote: >> to create the key (if that is possible) so that people can make a >> judgement about that kind of thing when they certify keys -- assuming > > If Bobs decides to use NIST curve, why don't you want to send a mail to > him. It his his decision whether he want to keep stuff confidential. > > OTOH, for key signing, the use of certain curves may well be a data > point on how far you trust someone else to sign a key. Thus, I concur > that gpg should print a notice which curve has been used. We may be > able to reuse the key size field for this (a curve specifies the key > size). That sounds ideal. And I am sure you are right that for private use it makes little to no difference. But on the other hand, if gpg is being used where people are trying to comply with different national standards, it might be important that they know the curve being used. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Where is ECC in gpg2 (specifically gnupg-2.0.21
On Wed, Sep 18, 2013 at 9:33 AM, Josef Schneider wrote: > On Wed, Sep 18, 2013 at 9:06 AM, Werner Koch wrote: > >> The standard already allows for all kind of curses. They are specified >> by an OID and I offered DJB to assign OIDs from the GnuPG arc. The >> original reason why I wanted an OID based design is so that it will be >> possible to use Brainpool curves which are preferred by some European >> institutions. I rejected the idea to make them the default in GnuPG to >> support better interoperability but also told people that we change the >> default as soon as we see people are using other curves. Meanwhile I >> don't think that we need a pool to settle on a different default. > > Is there a way to say someone should under no circumstances send a > message to me that is encrypted with a NIST curve? > Even if that means, that he can't find a encryption for the message? If I understand correctly, the curve is used to create the Public/Private Keypair. So GPG probably needs to display clearly (in the --with-colons output and in the user-facing output) the curve used to create the key (if that is possible) so that people can make a judgement about that kind of thing when they certify keys -- assuming it matters to them. Or have I got that wrong? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: lsign produces exportable signatures when used for self-sigs
On Fri, Sep 13, 2013 at 3:42 PM, Daniel Kahn Gillmor wrote: > On 09/13/2013 09:49 AM, Peter Lebbing wrote: >> On 2013-09-13 14:24, Nicholas Cole wrote: >>> The correct way would be to have keyservers >>> honour the no-modify flag, or perhaps have some notation on the ID >>> that prevents uploading to a public keyserver. I myself would favour >>> the latter approach. >> >> The latter has the same problem as the no-modify flag: it can be >> subverted by someone as long as the keyservers do not do crypto. > > yes, pretty much anything can be published as long as the keyservers do > not do crypto. That's something that the keyservers need to fix, as it > would prevent other problems as well. > > In the meantime, we can produce certifications that won't be > misinterpreted by the keyservers as they currently exist, and can be > validated by any future keyservers that do proper cryptographic checks. Well. Why not trust your circle of contacts (because anyone using this scheme must be in a small circle) not to upload the keys to keyservers? Perhaps if there is enough demand gpg could even have a "Never send these keys to keyservers" option in the config file, taking a list of fingerprints. Just a thought. I'm against doing something that goes against the standard when there are other ways to achieve it. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: lsign produces exportable signatures when used for self-sigs
On Fri, Sep 13, 2013 at 3:29 PM, Daniel Kahn Gillmor wrote: > On 09/13/2013 08:24 AM, Nicholas Cole wrote: > >> I don't think this is sensible. What is the point of a UID that >> cannot be used by someone else? If the UID is shared with anyone else >> (even privately), it must have a self-signature, and so that signature >> must be exportable. > > It is possible to share non-exportable signatures between private users. > see --import-options import-local in gpg(1). I know there are GnuPG > users who prefer to avoid having their keys on the public keyservers > entirely, and who are willing to accept the costs of doing manual key > distribution using non-exportable certifications. > >> If gpg starts --exporting keys with >> non-self-signed UIDs, this will be a step backwards. > > those keys will not be accepted by anyone as valid, and users will have > had to jump through hoops to create them as such, so they know what > they're getting themselves into. > >> I see what you are trying to achieve, but I don't think this is the >> right way to do it. The correct way would be to have keyservers >> honour the no-modify flag, > > Nearly every key created by GnuPG in the last decade has had the > no-modify flag set. There was never consensus about exactly what it > means, or how to interpret it: does it mean that keyservers need primary > key approval before publishing a third-party certification on an OpenPGP > cert? if so, how does the primary keyholder express that approval? And > no keyservers ever implemented it, because there was no unambiguous > mechanism *to* implement. > > interpreting it to mean "do not publish on the keyservers at all" would > mean almost no keys would be on the keyservers. > >> or perhaps have some notation on the ID >> that prevents uploading to a public keyserver. > > We have that already. It's having the "exportable" subpacket included > in the certification, with the content set to 0, meaning > "non-exportable". That's what i'm trying to do. > >> I myself would favour the latter approach. I'll admit your solution is ingenious. But all the same, I think you are trying to overload one clearly defined feature of the openpgp spec - a non-exportable signature - to try and force keyservers not to store UIDs. I really don't favour this approach at all. Section 5.2.3.11. (Exportable Certification) of the openpgp spec very clearly defines what "local" signatures are to be used for. Your solution works only because gpg provides a way to export even non-exportable signatures, but that is not guaranteed by the spec. If the no-modify flag is a dead-end, then (as I suggested) I think a new notation that keyservers could honour is the the way forward on this. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: lsign produces exportable signatures when used for self-sigs
On Fri, Sep 13, 2013 at 12:22 AM, Daniel Kahn Gillmor wrote: > GnuPG is currently not able to create a non-exportable self-sig. If you > try to do this, it gives an error: > > WARNING: the signature will not be marked as non-exportable. > > But: some people might never want their keys to be published to the public > keyservers, or have some User IDs that they keep locally that they do > not want to be transmitted via the keyserver network. > > AIUI, keyservers should reject keys that do not have a self-signature. > Keyservers should also honor the "non-exportable" marker by rejecting > OpenPGP certification packets that have the "exportable" subpacket > included and set to 0. > > So the sensible thing for a keyholder who wants their key to stay off > the keyservers would be to issue a non-exportable self-signature. I don't think this is sensible. What is the point of a UID that cannot be used by someone else? If the UID is shared with anyone else (even privately), it must have a self-signature, and so that signature must be exportable. If gpg starts --exporting keys with non-self-signed UIDs, this will be a step backwards. I see what you are trying to achieve, but I don't think this is the right way to do it. The correct way would be to have keyservers honour the no-modify flag, or perhaps have some notation on the ID that prevents uploading to a public keyserver. I myself would favour the latter approach. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES256 & AES192. (Was: Can I revitalise an old key-pair?)
On Tuesday, 3 September 2013, Nicholas Cole wrote: > On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson > > > wrote: > > On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole > > > > wrote: > >> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit > >> > wrote: > >> > >> [snip] > >> > >>> > >>> Paradoxically, AES256 & AES192 had > >>> weaknesses that made them less safe than AES (AES-128) several > >>> years back. May I humbly suggest TWOFISH or one of the > >>> CAMELLLIA ciphers as a first choice UNTIL you determine whether > >>> or not the fixes for AES-256 and AES-192 are retroactive? DID > >>> THEY GET THEM FIXED? I am just assuming they did but that means > >>> I HOPE the older implementation and the newer one can easily be > >>> discerned when you do the decipher. > >> > >> > >> [snip] > >> > >> I was curious about this. The wikipedia page mentions the "Related Key > >> Attack" on these cyphers, but is vague about whether they were ever > >> fixed. > >> > >> Does anyone know? > >> > >> And did fixes make it into the version used by Gnupg? > > > > Even more importantly, were they ever an issue with GnuPG in the first > place? > > > > That is, does GnuPG generate related keys? > > > > I was always under the impression that GnuPG randomly generated > > session keys rather than creating related session keys; if true, > > wouldn't this mean that the related-key attack doesn't apply? > > And if that were true, I presume that would mean that the "AES is > stronger than AES256" argument would also fall. Or have I > misunderstood? > While reading up on all of this I found this piece (concerning a very widely used piece of software for Mac OS and iOS) on the switch to AES256. I thought others would find it useful. http://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES256 & AES192. (Was: Can I revitalise an old key-pair?)
On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson wrote: > On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole wrote: >> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit >> wrote: >> >> [snip] >> >>> >>> Paradoxically, AES256 & AES192 had >>> weaknesses that made them less safe than AES (AES-128) several >>> years back. May I humbly suggest TWOFISH or one of the >>> CAMELLLIA ciphers as a first choice UNTIL you determine whether >>> or not the fixes for AES-256 and AES-192 are retroactive? DID >>> THEY GET THEM FIXED? I am just assuming they did but that means >>> I HOPE the older implementation and the newer one can easily be >>> discerned when you do the decipher. >> >> >> [snip] >> >> I was curious about this. The wikipedia page mentions the "Related Key >> Attack" on these cyphers, but is vague about whether they were ever >> fixed. >> >> Does anyone know? >> >> And did fixes make it into the version used by Gnupg? > > Even more importantly, were they ever an issue with GnuPG in the first place? > > That is, does GnuPG generate related keys? > > I was always under the impression that GnuPG randomly generated > session keys rather than creating related session keys; if true, > wouldn't this mean that the related-key attack doesn't apply? And if that were true, I presume that would mean that the "AES is stronger than AES256" argument would also fall. Or have I misunderstood? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AES256 & AES192. (Was: Can I revitalise an old key-pair?)
On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit wrote: [snip] > > Paradoxically, AES256 & AES192 had > weaknesses that made them less safe than AES (AES-128) several > years back. May I humbly suggest TWOFISH or one of the > CAMELLLIA ciphers as a first choice UNTIL you determine whether > or not the fixes for AES-256 and AES-192 are retroactive? DID > THEY GET THEM FIXED? I am just assuming they did but that means > I HOPE the older implementation and the newer one can easily be > discerned when you do the decipher. [snip] I was curious about this. The wikipedia page mentions the "Related Key Attack" on these cyphers, but is vague about whether they were ever fixed. Does anyone know? And did fixes make it into the version used by Gnupg? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Recommended key size for life long key
On Sun, Sep 1, 2013 at 12:12 PM, Josef Schneider wrote: > I just use 4096 bit because that is the biggest size my OpenPGP Cards can > handle. In my opinion using a smart card instead of online keys increase > security far more than strange large key sizes! > I also see no point using less than 4096 because modern hardware is fast > enough. Maybe my keys last longer that way. > > One of the problems that this kind of discussion highlights is that moving to new keys is a real pest. People keep keys long after they really should and are reluctant to change keys because getting a given key certified and trusted is a pain - even with the web of trust. In a more ideal world, no one would want a key to last longer than a few years, and replacing keys at regular intervals would be the norm. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] [security fix] GnuPG 1.4.14 released
On Fri, Jul 26, 2013 at 2:40 AM, Richard Outerbridge wrote: > Werner: > > No problems. > > MacBookPro9,1; Mountain Lion OS X 10.8.4 (12E55) > Xcode 4.6.3 > __outer > For some reason I get the following error when trying to build on Mountain Lion OS X: gcc -g -O2 -Wall -Wno-pointer-sign -o gpg gpg.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o cardglue.o tlv.o card-util.o app-openpgp.o iso7816.o apdu.o ccid-driver.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv -lresolv ../intl/libintl.a -liconv -Wl,-framework -Wl,CoreFoundation -lz -lbz2 -L/sw/lib -lusb -Wl,-framework,IOKit -Wl,-framework,CoreFoundation -Wl,-prebind Undefined symbols for architecture x86_64: "_iconv", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) __nl_find_msg in libintl.a(dcigettext.o) "_iconv_close", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) _set_native_charset in libutil.a(strgutil.o) "_iconv_open", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) _set_native_charset in libutil.a(strgutil.o) __nl_find_msg in libintl.a(dcigettext.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [gpg] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] [security fix] GnuPG 1.4.14 released
Cancel that. My fault ... I'd missed that I had some old libraries installed. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Enterprise Key Management?
On Mon, Mar 18, 2013 at 9:14 AM, Werner Koch wrote: > On Sat, 16 Mar 2013 12:36, a...@guardianproject.info said: > > > This seems like a better application of S/MIME as it, by design, is > > centralized in the manner you describe. > > Hwever, with S/MIME you can _only_ do a centralized key management. > OpenPGP allows to implement an arbitrary key management policy. > > The OP mentioned signing subkeys. This could for example be used to > allow several employees to sign data using the same key and the > recipient will notice a valid signature with a published fingerprint > from the company. A closer inspection would reveal which subkey has > been used for signing and this can be used for internal audit processes > (similar to the QA labels with an employer number on all kind of > products). Revocation of a certain subkey would also be pretty easy. I > assume this would easily scale to new dozen subkeys. > It's clever. Given careful management / dissemination it would allow a group to share an encryption key but have separate signing key. I don't know if any software exists that operates in this way. I do wonder if what the poster really meant, however, is not "subkeys" per se but Trust-Signature certified keys. I guess what is needed for most enterprise use is a system where the company generates employee's keys and keeps a copy of them. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP Authentication Protocol?
Dear List, Is there a protocol documented anywhere for using PGP Keys for client-server authentications? I assume that various naive approaches have all sorts of serious problems. Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Seperate RSA subkeys for decryption and signing or one for both?
Meant to post this to the list. Blame gmail. -- Forwarded message -- From: Nicholas Cole Date: Tue, Dec 4, 2012 at 7:10 PM Subject: Re: Seperate RSA subkeys for decryption and signing or one for both? To: Hubert Kario > How do you propose an attacker could force me to sign data I already > encrypted? I think the attack merely specifies a chosen text - but at any rate, the point is that there might be a system (eg. a badly designed time-stamping service) that might naively sign data supplied by an attacker, and in those cases having a signing and encryption key that are the same would be a Bad Idea. Note, though, that PGP 2.6.3 did use the same key for both; the attack is a (mostly) theoretical one. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Seperate RSA subkeys for decryption and signing or one for both?
On Tue, Dec 4, 2012 at 5:32 PM, Hubert Kario wrote: > On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: >> On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario wrote: >> > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: >> >> Do any problems arise with the smartcard if the same key shall do >> >> different >> >> tasks? >> > >> > Keys can become "used up" so it entirely depends on how often you use it. >> > >> >> Do you have a reference for this? > > Sorry for double posting, here's some reference: > http://security.stackexchange.com/a/18242/3306 > Ah. That's an attack on the Hash function, not the key. And even then, it seems far too difficult to be realistic, assuming that I read it correctly and assuming it is correct! N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate RSA subkeys for decryption and signing or one for both?
On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario wrote: > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: >> Hello, >> >> are there arguments for preferring either >> >> a) having one RSA subkey for decryption only and one for signing only >> >> or >> >> b) having only one RSA subkey for both decryption and signing? >> >> Do any problems arise with the smartcard if the same key shall do different >> tasks? > > Keys can become "used up" so it entirely depends on how often you use it. > > What I mean by that, is that any signing operation leaks some information > about the key used for signing (generally far less than few tens of a bit). > If you have signed tens of thousands of documents with it, an attacker can > recover substantial portion of the key and speed up the key recovery. Do you have a reference for this? I thought the major reason to use separate signing/encryption keys was that if a user could be persuaded to sign a chosen encrypted text with the same key, the decryption key would be revealed. http://security.stackexchange.com/questions/1806/why-should-one-not-use-the-same-asymmetric-key-for-encryption-as-they-do-for-sig I've never read before that a key could be "used up" in this way. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [NOOB] Export subkey
On Monday, August 27, 2012, Arthur Rance wrote: > Hello, > > I'm a noob and I'm going to export a subkey : > > $ gpg --list-keys > > pub 2048R/12345678 2010-01-01 > uid Arthur Rance 'cvml', 'arthur_ra...@noob.com');> > > > sub 2048R/90123456 2010-01-01 > sub 2048R/78901234 2012-08-27 > > $ gpg --export --armor 78901234 > 78901234.txt > > $ gpg --export --armor 12345678 > 12345678.txt > > $ diff 78901234.txt 12345678.txt > > Why is there no difference between the subkey and my public key ? > > > Maybe I misunderstood something... > > --export exports your whole public key. It probably doesn't make sense to only export a public subkey -- public keys are supposed to be public - and various important bits of information are tied to the main key in any case. Your user id, for example, is stored on the main key. Secret subkeys are another matter, and if you look at the man page you will see there is a facility to export them. You would want it if, for example, you wanted to keep the main key on one computer and put only the secret subkey parts on another. But if you are new to gpg and just using it as an individual, my strong advice unless you have very particular needs is to ignore the subkey elements and treat them as part of the technical inner workings of the maths side of Gpg You almost certainly don't need to manipulate them for now. I don't say this to be condescending. One of the great strengths of OpenPGP and of gpg is that they provide very a by flexible tool that can be used in a huge number of situations. Subkeys were introduced partly as a technical implementation detail: it is bad security practice to use the same key for both signing and encrypting (and with some algorithms impossible), so PGP needed a way to tie groups of keys together and treat them as a single key. They do, however, introduce some benefits that can be useful in particular settings --- to occasionally change encryption keys, for example. The OpenPGP card can also be set up to use only subkeys, which can be useful in preserving the web of trust if a card is lost or damaged (though whether this is a good idea and worth the complexity is going to vary from situation to situation). I hope that helps. Best wishes, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Mac OS X 10.8 and OpenPGP Cards
On Thu, Jul 26, 2012 at 8:34 PM, Kevin Kammer wrote: > Well, the inevitable has happened, again. > > I just upgraded from Mac OS X 10.7 to 10.8, and my ZeitControl cards, > which were formerly working perfectly, are now inaccessible. > > ~ $ gpg2 --card-status > gpg: selecting openpgp failed: Card error > gpg: OpenPGP card not available: Card error > > Since I haven't had a lot more luck with using them on Fedora 17 either, > which is what I'm running at home, it looks like I'm in a bit of a bind. > > This is what I get for being an "early adopter." If it is any consolation, it is working for me (Gemplus GemPC Reader) Have you installed the smartcard libraries? Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: why is SHA1 used? How do I get SHA256 to be used?
On Wed, Jul 11, 2012 at 11:25 AM, Werner Koch wrote: > On Wed, 11 Jul 2012 07:56, r...@sixdemonbag.org said: > >> V5 discussions will not kick off in earnest until NIST announces the new >> hash standard, or so I've heard people from the working group say. > > And even then it will take 5 years or so until it it has been deployed > widely. Even GnuPG 1.2 is still in use; despite that it has been > declared EOL ages ago. > > The fingerprint and the special features building upon it > (e.g. revocation keys) are targets for an attack based on a SHA-1 > *pre-image* attack. We need to analyze the possible problems and if > needed deploy workarounds for them. SHA-256 for signatures is already > in widespread use - thus I don't see a problem right now. > > The real problem I see for GnuPG is that its maintenance is heavily > under-financed and the pool of volunteers, taking care of it, is quite > small. I am not sure whether PGP is in a better position; giving its > current owner. A bleak but realistic assessment. But one thing that might be helpful to explain is this: what needs to be in the V5 key format aside from the change in fingerprint hash? Aside from that issue, the V4 key format seems to have been resilient. What are the other issues that need to be addressed? Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Draft of nine new FAQ questions
>> There's a slight confusion in these answers that I think it would be >> really helpful to address in an FAQ. > > Yes, there is. Unfortunately, the answer is kind of messy. [ snip ] Thank you for a really good and useful answer. I hope some of that can make it into the FAQ. If I understand you correctly then the situation is this: - if you want longer symmetric cyphers, then you are asking for something that is a mathematical and physical nonsense. - if you use longer RSA keys, you are being unduly paranoid, and asking for something that would make life awkward for mobile devices, etc, but not asking for something that is a complete nonsense -- just unhelpfully paranoid. I think it would be good if the FAQ managed to capture that. Best, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Draft of nine new FAQ questions
> ---re #5: Is RSA-2048 really enough? > > ***start 2nd sentence : And other organizations to whom encryption > is important (such as RSA...*** [The world changes, and maybe > an explicit endorsement might not be so appropriate tomorrow, > but embarassing or similar to change then. Just mentioning them > is an implicit endorsement, IMHO of course] > According to NIST, yes. Further, other well-respected organizations (such as > RSA Security) have publicly supported NIST's recommendations. > > . . . > key recommendations have been superseded by those in Practical Cryptography, > which, to repeat, says ***replace "says" with > "estimates"*** RSA-2048 will be sufficient until the mid-2020s. > > > ---re #6: Can any of the ciphers in GnuPG be brute-forced? > . . . > ***In terms of current scientific understandings, the symmetric > ciphers used in GnuPG are utterly*** > The symmetric ciphers used in GnuPG are utterly immune to > brute forcing. The Second Law of Thermodynamics places strict > . . . and > 7.6 2048-bit keys are believed to be immune to brute-forcing until at > least 2030. There's a slight confusion in these answers that I think it would be really helpful to address in an FAQ. On the one-hand, this new FAQ suggests that attacking a 2048 key is already so unfeasible that to suggest that a 3072 key would provide additional security is a nonsense. On the other hand, there is a sense that 2048 keys might only provide adequate security until the mid-2020s / 2030. Is that because the break-through that is anticipated by the second statement is some kind of quantum computing success or some similar advance that completely breaks RSA (and all PKI)? In other words, what really is the status of a statement like "2048 RSA is believed safe until 2030"? Back in the 1990s, such predictions were based on a sense of increasing computing power, and it was possible to predict with reasonable accuracy when (for example) 512 bit RSA would look possible to factor at imaginable cost. Is the "safe until 2030" prediction of a similar quality or just a guess at when technologies that are currently science fiction might look possible? I only raise these points because this has become such a recurrent, sometimes even tiresome theme on this mailing list, that I'd really like the FAQ to be as comprehensive as possible. To put the question in the form that sometimes comes up on this list - what if one wants security until 2040? Would a 3072 key make sense in that case or not? Not that I think my own security needs, by the way, need anything more than a 512 RSA key, if that... ;-) Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG distribution signature
On Tue, Jan 31, 2012 at 8:15 AM, Werner Koch wrote: > On Tue, 31 Jan 2012 00:06, faramir...@gmail.com said: >> Hello, >> Is key D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 ( >> 0x4F25E3B6 ) the current key used for signing files? I suppose it is, > > Yes, it is. See my OpenPGP mail header for a list of all my keys and > their descriptions. > > There is a small error in the announcement: > > gpg --recv-key 4F25E3B6 > > The distribution key 1CE0C630 is signed by the well known keys > > It should say > > gpg --recv-key 4F25E3B6 > > The distribution key 4F25E3B6 is signed by the well known keys I've long thought that one nightmare scenario for OpenPGP would be an ISP or other network gateway that transparently scanned all data passing through it looking for specific key ids and fingerprints and which silently changed them in webpages, email etc to fraudulent values. I can't imagine that it would be that difficult, and it would be difficult to detect as well as tripping up anyone who relied on "well-known" keys. N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trying to create auth key on GPF CryptoStick
On Wed, Jan 4, 2012 at 1:01 PM, Werner Koch wrote: > On Wed, 4 Jan 2012 13:37, nicholas.c...@gmail.com said: > >> Is there any plan to back-port the ECC support? > > No. We definitely need to move forward with 2.1 and not keep on > updating 2.0. It would be quite some work to integrate that in 1.4 and > I see no reason to do that. Remember that this is not a one-time task > but requires continues maintenance. We don't have the resources to do > that. That is a shame, although I do completely understand the resources problem. Though gpg2.1 has lots of wonderful features, it IS a much bigger, much more complex package. I've always liked the fact that gpg1.4 can be built relatively simply, and the code-base looks relatively easy to understand. It really is a case of simply downloading and building. People using gpg2 often have to rely on third-party packagers. You said earlier that someone wanting really high security ought to be prepared to audit the different elements of the system. I'm no expert, but I'd have thought that would be easier if deploying 1.4. Perhaps that is wrong, and in fact people can have better confidence in the new version. I suppose I'd imagined that once the ECC code was written it would effectively be a module that could be integrated relatively easily into the old code. I do understand if that's not the case, but there are reasons why 1.4 is still so popular. Do you think those reasons are outdated and need to be confronted? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trying to create auth key on GPF CryptoStick
On Wed, Jan 4, 2012 at 11:22 AM, Werner Koch wrote: > On Wed, 4 Jan 2012 11:21, nicholas.c...@gmail.com said: > >> http://www.elliptictech.com/applications-suiteb.php (for example) >> >> requests will be more and more common until gpg is capable of >> supporting the latest "state of the art". Even then, it won't satisfy >> everyone, but at least we'll be able to say "if it's good enough for >> NIST." > > Well, 2.1 beta supports ECC with the Suite B compliant algorithms. I know - the gpg team is wonderful. :-) I wasn't criticising them, just suggesting that the pressure for longer/different keys was likely to grow, even if it doesn't really make a lot of sense for most users. Is there any plan to back-port the ECC support? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trying to create auth key on GPF CryptoStick
On Wed, Jan 4, 2012 at 9:33 AM, Werner Koch wrote: > On Tue, 3 Jan 2012 21:16, go...@fsfe.org said: > >> Werner, is that correct? The card you gave me at FSCONS back in 2009 >> states that 3072 Bits is the maximum key size. I use 2048 Bit keys at > > They state 3072 because that is what GnuPG supported at that time; the > cards supported 4096, though. Since 2.0.18 GnuPG supports 4096 with > those cards. > > There is still no reason to use it 2048 is more than sufficient. IF you > think you need more, you should ask yourself several questions. One of > these questions should be, whether you have checked the chip design and > the firmware of the card. Quite frankly, I don't think most people need anything more than a 512 bit key. :-) But all the same, to be serious, I suppose it is a bit (just a tiny bit) unsettling that NIST is recommending that everyone move to either very long keys for really secure data or else to ECC: http://www.elliptictech.com/applications-suiteb.php (for example) I know that the request for stupidly, idiotically long key sizes is as old as PGP itself, but all the same, I suspect that these sorts of requests will be more and more common until gpg is capable of supporting the latest "state of the art". Even then, it won't satisfy everyone, but at least we'll be able to say "if it's good enough for NIST." N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1 beta 3 released
On Friday, December 23, 2011, Werner Koch wrote: > On Fri, 23 Dec 2011 19:29, nicholas.c...@gmail.com said: > >> How will this interact with the --homedir option? Will --homedir be >> passed to gpg-agent or are the two entirely separate? > > No it won't. The gpg-agent has its own --homedir option which allows to > have a flexible configuration. By design the gpg-agent may even running > on a different box. However that is currently not supported. > >> I ask because at the moment it is possible to keep separate keyrings >> in different home directories, which might be useful to (for example) >> keep the large debian keyrings separate from personal keys, or to keep >> a set of keys for testing purposes separate from production keys. > > gpg --homedir is still used of the public keyrings. Dear Werner, It would be very good if there were still a way to completely 'sandox' (for want of a better term) an instance of gpg, so that it uses its own key rings and trust databases. I certainly find that for testing purposes it is very useful indeed. On previous versions --homedir does this nicely. I presume the new way will be to make sure that a separate copy of gpg-agent is running and to pass in GPG_AGENT_INFO as an environment variable, as well as specifying a --homedir. Or will there be a better way? Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1 beta 3 released
> * GPG does not anymore use secring.gpg but delegates all secret key > operations to gpg-agent. The import command moves secret keys to > the agent. How will this interact with the --homedir option? Will --homedir be passed to gpg-agent or are the two entirely separate? I ask because at the moment it is possible to keep separate keyrings in different home directories, which might be useful to (for example) keep the large debian keyrings separate from personal keys, or to keep a set of keys for testing purposes separate from production keys. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG 2.1 beta 3 released
On Tue, Dec 20, 2011 at 4:26 PM, Werner Koch wrote: > * GPG does not anymore use secring.gpg but delegates all secret key > operations to gpg-agent. The import command moves secret keys to > the agent. > > * The OpenPGP import command is now able to merge secret keys. I see that the man page still refers to the option --secret-keyring. Presumably this option now does nothing? Very exciting to see the new release! N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [gpgtools-users] [gpgtools-devel] Joint OpenPGP (JS) implementation
On Sat, Nov 26, 2011 at 7:10 PM, Werner Koch wrote: > On Sat, 26 Nov 2011 18:25, nicholas.c...@gmail.com said: > >> The GPG project itself must have hit many of these issues. Is there a > > No, we don't. GnuPG has originally been developed in Germany because we > have been able to do that without being affected by the US _export_ > restrictions. We had to reject any contributions from US citizens or > from people living the the US. That changed by end of 2000 when the > export restrictions were basically dropped for all kind of freely > available software. In the US you only need to send an announcement > mail to some address of the US Department of Commerce to contribute to a > crypto project. I don't have the details at hand, because I am not > affected ;-) > > We still keep the GnuPG infrastructure (e.g. the primary FTP server) in > Europe to be prepared for the case that the US start to restrict crypto > again. The rules seem so complicated that even from the UK (that is, within the E.U.) I can't work out what the rules for open source are! What a mess! Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [gpgtools-users] [gpgtools-devel] Joint OpenPGP (JS) implementation
It seems to be clear that there is a big demand of a single core > JavaScript OpenPGP implementation and we find more and more > projects and developers. Dear Lists, All these projects are very interesting. Forgive a slightly off-topic but important question that they raise, though. What are the legal implications of contributing to these sorts of wrapper projects? Do such projects count as "export" of "dual use" cryptography for the purpose of EU and USA laws? In the past, such questions have caused open source projects no end of headaches: http://www.debian.org/legal/cryptoinmain The "crypto law survey" attempts to answer some of these questions. Following the links for the UK and the USA, it looks to me as if *any* project that facilitates the use of cryptography would have to take legal advice, even if it is merely a wrapper for another program or library, and would have to be careful about where it was hosted, and who it accepted contributions from. Is that correct? The GPG project itself must have hit many of these issues. Is there a write-up anywhere of their conclusions? Something like that might be helpful for other people starting these sorts of projects. Best wishes, Nicholas (I am not a lawyer...) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
--min-cert-level and --auto-check-trustdb
Dear list, Why is changing the --min-cert-level not enough to trigger an update of the trust-db? Should it be? Supposing a scenario in which a user is prepared to accept lower-level certifications for low value communications, but requires higher level certifications for others. At present the user can specify --min-cert-level on the command line, but the trust database itself will not be updated for the purposes of listing/editing keys, verifying signatures or encryption. The user interface can become easily out of sync with the user's explicit trust model settings. The only solution is to explicitly order --check-trustdb. However, this creates further problems and possible security risks, because there is no guarantee that a temporary change will be reverted when the user stops specifying the --cert-level on the command line. I suspect this is little-used feature of gpg. On the other hand, it does look like an excellent way for the user to shoot himself in the foot without even realising it. (Senario to verify the problem at the end of this email) Best wishes, Nicholas = To verify problem: 1. Sign a key with a level 1 certification 2. Do gpg --min-cert-level=1 --check-db 3. Edit the key you have just signed, or try to encrypt to it, and the listing will show the uid as trusted EVEN if you do not specify the low cert level on the command line, and are therefore using the gpg default --min-cert-level=2. This is looks a security risk to me. (problem identified with gpg 1.4.11) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing multiple keys
On Sat, Aug 27, 2011 at 1:03 AM, Doug Barton wrote: > I have a particular concern that if I sign a key with "I checked > carefully" that I really did. Moreover, I have a philosophical prejudice > that if I *can't* say "I checked carefully," why bother? > > That said, I have in the past run across people who still have old > e-mail addresses that they no longer have access to on their keys, so > it's more than a theoretical issue, for me at least. I see. So your procedure is to check that the name on the key matches some ID, and THEN check separately that the key at least appears to control the email addresses it claims. Which does make a certain sense, I can see. :-) Thank you for explaining. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing multiple keys
On Fri, Aug 26, 2011 at 10:34 PM, Doug Barton wrote: > One could certainly argue that my doing this is verification step is > overly fussy (and you wouldn't be the first), but that's my policy. I honestly did not mean to be critical. I was just struggling to see the security benefit. After all, all security brings inconvenience, but not all inconvenience brings security. :-) Do you have a particular concern about orphan keys? Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Keyrings WAS Signing multiple keys
On Thu, Aug 25, 2011 at 7:21 PM, Doug Barton wrote: >> BTW, this is another one of the reasons that I find the ability to have > multiple keyrings useful, and would very much miss that functionality if > it disappeared from gnupg 2.1. I know Warner has said all this before, but I sometimes think that too few people chime in to say, "yes I agree". The problem with multiple keyrings is that they introduce all sorts of corner cases and unpredictable, ambiguous behaviour. And actually, gpg itself is very quick at handling even very large keyrings. I know that their removal would mean that some people have to adjust how they use gpg, but I am sure that the end of multiple keyrings would actually be for the best, and I think removing them is right thing to do. In fact, just as at the moment the handling of multiple files needs to be explicitly enabled, I would favour seeing an option to explicitly enable or disable multiple keyrings in the current versions, just because I think that unless users take particular care they can be harmful. I *do* see the uses for them. The debian keyring, for example is huge, and it is useful to be able to selectively include it or not in the gpg.conf file. But there more I've thought about this, the more I think that it would be better just to have entirely separate gpg home directories for this sort of purpose. For the case in question, there would be nothing to stop you having a home directory made specifically for a key-signing party, for example, importing your signing key into it and using it as your working directory. '--homedir', not multiple keyrings, seems to me to solve the problem addressed by multiple keyrings for almost all real-world cases. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing multiple keys
On Thu, Aug 25, 2011 at 7:21 PM, Doug Barton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 08/25/2011 11:02, Aaron Toponce wrote: >> On 08/25/2011 11:56 AM, Jameson Graef Rollins wrote: >>> Do you want to sign every key in your keyring? If so, it's not >>> hard to get gpg to enumerate all of your keys in a >>> machine-parsable format (see --with-colons output). If you just >>> want to sign a subset then you obviously have to enumerate all >>> the keys yourself, so either of the above solutions seems pretty >>> easy to me. >> >> If I have a public keyring of all the attendees of the party, then >> I will want to sign every key in that keyring. > > The script below is designed for generating challenges as opposed to > doing the signing, but you may find the bits that iterate the keys on a > ring interesting. > > BTW, this is another one of the reasons that I find the ability to have > multiple keyrings useful, and would very much miss that functionality if > it disappeared from gnupg 2.1. > > > http://dougbarton.us/PGP/gen_challenges.html Dear Doug, I don't mean this in a negative way, but I struggle to see the point of such challenges. The whole point of OpenPGP is the medium across which email is transmitted is insecure, and there is a possibility of a MITM attack. I don't see how this sort of challenge-response does anything other than confirm that the controller of a key that claims to belong to a particular email address is also able to intercept and send messages to and from that address. The only scenario that it would protect against is where key A claimed to belong to email address B, but actually did not, and the owner of key A was actually unable to read messages sent to address B. In that case, OpenPGP would be providing no security, but the security of the email system itself would be such that OpenPGP was unnecessary. To put it another way: if you trust the email network sufficiently for your challenge to be useful, doesn't that mean you don't need encryption. Have I missed something? Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trust model - trust level 1 and 2
On Thu, Aug 11, 2011 at 7:52 PM, David Shaw wrote: > There is really no practical difference between the two in the default trust > model of GPG - either way, you're not giving key signatures made by that key > any weight in your web of trust. Thanks, David. I had wondered if there was some difference in the way they interacted with some corner case or with trust signatures and the like, but since I couldn't see any documentation I assumed that they had the same practical effect on the way gpg calculates key validity. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trust model - trust level 1 and 2
On Thu, Aug 11, 2011 at 7:52 PM, David Shaw wrote:
> On Aug 11, 2011, at 10:49 AM, Nicholas Cole wrote:
>
>> Dear List,
>>
>> Is there any difference in the standard trust model between marking a
>> key level 1 ("I don't know or won't say") and level 2 ("I do NOT
>> trust")?
>
> Given the text strings you're quoting, I assume you're referring to
> ownertrust (i.e. "--edit-key . trust"). Ownertrust is how you express
> your confidence in how well the owner of the key checks other people's keys
> (or put another way, how much weight do you want to give key signatures made
> by that key).
>
> There is really no practical difference between the two in the default trust
> model of GPG - either way, you're not giving key signatures made by that key
> any weight in your web of trust.
>
> David
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Trust model - trust level 1 and 2
Dear List,
Is there any difference in the standard trust model between marking a
key level 1 ("I don't know or won't say") and level 2 ("I do NOT
trust")?
Best wishes,
Nicholas
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A better way to think about passwords
On Thu, Apr 21, 2011 at 1:38 PM, Robert J. Hansen wrote: >> In short: don't force a particular strategy on your users. Much >> better to explain to users the general problem, and then leave it up >> to them to pick a password. > > Historically speaking, this has shown not to work. I'll try to dig up the > HCI references if people really want, but the gist of it is people don't want > to have to learn and understand: they just want to get their work done. The > instant you make compliance voluntary and education-based, the vast majority > of users say "meh" and choose "password" as their login credential. > > The belief that security problems can be solved by educating users is a > common one: it is also a deluded one. It handwaves the very serious problem > of most users not wanting to be educated and being actively hostile to it. > "Why do I have to learn all this propellerheaded geek stuff? I just want to > get my work done!" You know, I worded the above poorly, and for that I have only myself to blame for the fact that you jumped on the obvious objection to a complete free-for-all. It probably is wise to have some sort of control in place to prevent very stupid passwords. Even in 1997 my university had a system in place that prevented the use of dictionary-words (including Latin and - IIRC - Greek words) or passwords that were merely dictionary words with a number added at the end. What I meant was rather this: there are several strategies that produce good passwords. Teaching them requires (at some employers) a 30 minute course or the reading of a web page. However, forcing any *particular* strategy onto users will dramatically reduce the time it takes to guess a password, since knowing the strategy reduces the number of possibilities dramatically. I thought we were talking about this particular proposal (the "use three dictionary words" one) and my point was that if everyone were to use this its security would be dramatically reduced. However, as one of several strategies available to those selecting passwords, it probably isn't a bad one in and of itself. Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: A better way to think about passwords
Isn't the real problem that *any* policy (suggested or enforced) reduces the complexity of guessing a password? The moment you start saying "pick three words separated by a space or dash" or "pick eight random letters" or the like you make it easier to attack a password. My employer insists on passwords that meet a defined and public set of criteria. I'm sure that in theory that actually makes them easier to crack, since many millions of possibilities can be discounted. In short: don't force a particular strategy on your users. Much better to explain to users the general problem, and then leave it up to them to pick a password. Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Group Membership Keyring
On Wed, Mar 23, 2011 at 12:27 PM, Mike Acker wrote: > I really liked the idea of having the Membership Secretary sign a Public > Keyring for the Group Members and then to circulate that keyring to the > membership. > > How to implement though, as members will need an additional keyring for > each group they have a membership with. Just to comment on this aspect of your proposal: Debian, for example, does circulate a keyring file in this way. But managing multiple keyrings is not easy, and can lead to some nasty corner-cases. What if you are using multiple keyrings and different versions of the same key exist on more than one keyring? [ as an aside, I think there is a fairly good case that multiple public keyring files are a menace rather than a help in most cases because of this problem ] It would probably be better for the membership secretary to circulate a keyblock (i.e. the results of an --armor --export) containing the members keys, which you could then import onto your own keyring. Unless the group features many hundreds of members you should not experience any noticeable slow-down at all. Depending on the nature of your group there are two potential models: - If memberships are renewed at regular intervals, the secretary can simply sign all keys with signatures valid for the standard period of membership and circulate the keyblock. - If members enter and leave at different times, the membership secretary will have to sign and revoke keys as appropriate (I'd still put an expiry date on the signatures to be on the safe side) and circulate the keys of all members who are current *or former members* (so that the revoked signatures are also circulated). - As a refinement of the second option, if you make the signatures only valid for a year, you would only need to circulate the keys of former members for the period during which the original signature was ever valid. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What is the benefit of signing an encrypted email
On Tue, Jan 11, 2011 at 10:04 AM, jimbob palmer wrote: > In Firefox I can sign or encrypt or encrypt+sign an e-mail. > > In what case would I want my encrypted emails also signed? Does it > provide any additional benefit over a pure encrypted email? It is, in fact, trivial to 'forge' email - that is to send email pretending to be someone else. All you need to do is tell your computer to send out email with a different "From:" line. Most smtp servers will forward an email from an authenticated user (or from anyone on the network) without checking that the From line matches their approved email address. This is, for the most part, a feature, not a bug. There are various schemes to prevent this from being possible (or at least undetectable) and OpenPGP offers one way - albeit one that places a great demand on the sysadmin or the user or both. In fact, email is forged every day in just this way - but most of it is such obvious spam that it is easier for the human eye to weed out than it is to set up an OpenPGP, which is why so few people have ever done so. Back when I was a student a friend of a friend of a friend got very drunk and started forging emails in this way pretending to be the Dean. But even these were such obvious forgeries, and the other email headers were so detailed, that it did not require OpenPGP to detect him. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What is the benefit of signing an encrypted email
On Wed, Jan 12, 2011 at 5:52 AM, David Shaw wrote: > On Jan 11, 2011, at 3:09 PM, Nicholas Cole wrote: > >> On Tue, Jan 11, 2011 at 12:19 PM, wrote: >>> >>> If one is a purist, then one wants sign>encrypt>sign >>> >>> See http://world.std.com/~dtd/#sign_encrypt >> >> That is a really interesting paper. Did the OpenPGP protocol ever >> include a fix for the attack they describe? > > No. It was generally felt that this was more of an attack on the user of > crypto, rather than on the crypto itself. > > See this thread from when the paper was first published: > http://www.mail-archive.com/cryptography@wasabisystems.com/msg00259.html That thread is clearly right about the bulk of the paper, which is clearly an attack on the user of the crypto. Signing ambiguous messages is not a good idea! But what about the suggestion they made in section 1.2 about not signing crypt texts? Am I right that openpgp always encrypts signed text, rather than signing encrypted text, and so is not vulnerable at all? Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What is the benefit of signing an encrypted email
On Tue, Jan 11, 2011 at 12:19 PM, wrote: > > If one is a purist, then one wants sign>encrypt>sign > > See http://world.std.com/~dtd/#sign_encrypt That is a really interesting paper. Did the OpenPGP protocol ever include a fix for the attack they describe? Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using gpg2 without pinentry?
On Mon, Jun 28, 2010 at 8:35 PM, Doug Barton wrote: > On Mon, 28 Jun 2010, Nicholas Cole wrote: > >> On Sun, Jun 27, 2010 at 8:55 PM, Dan Mahoney, System Admin >> wrote: >> >>> Is there some reasonable way that gpg can detect that it has a >>> controlling >>> termainal (or even, a config file option) and just ask me for my >>> passphrase >>> on stdin? >> >> Can you start gpg-agent separately - ie. before the passphrase is >> needed. If so, you should be fine, I think, if I have understood your >> problem correctly. > > That's not the issue. To simplify the problem somewhat, I'm on a windows > box. I ssh to my Unix system at home. My .bashrc sets up gpg-agent for me. > Now I want to sign something. The usual answer here is "pinentry-curses to > the rescue." But let's assume that pinentry-curses is not an option. Now how > do I enter my passphrase? Do none of the gpg-agent options such as: --xauthority string --keep-tty --keep-display help in this kind of case? N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using gpg2 without pinentry?
On Sun, Jun 27, 2010 at 8:55 PM, Dan Mahoney, System Admin wrote: > Is there some reasonable way that gpg can detect that it has a controlling > termainal (or even, a config file option) and just ask me for my passphrase > on stdin? Can you start gpg-agent separately - ie. before the passphrase is needed. If so, you should be fine, I think, if I have understood your problem correctly. http://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG private key resilience against off-line brute-force attacks (was: Re: Backup of private key)
On Sat, Nov 28, 2009 at 3:47 PM, David Shaw wrote: [snip] > I'd suggest starting with the various calculators on > http://www.keylength.com/ A very interesting website. I followed the links, and found this document: http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml It seems that the NSA is moving away from RSA/DH etc. cryptography, and now "only" approves their use for secret level material. They are instead pushing elliptic curve cryptography. I hadn't realised that there was such pressure to move away from traditional key exchange. Is this about the fear of quantum computing, or something else? EC in gpg is still some way off, it seems. N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Hash algo for signing - documentation
Dear David, Thanks for, as ever, excellent clarification. Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Hash algo for signing - documentation
Hi all. This is a query mostly for my own interest, but I think it might point to a change in the documentation being required. I was slightly confused by this message http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036361.html David suggests (as I read it) that an RSA key created with --cert-digest-algo sha256 will continue to use sha256 whenever it signs keys, whereas the documentation implies that you would have to specify --cert-digest-algo every time a key is signed. How does an RSA key choose a hash algorithm for this purpose? It might also be worth noting that (if I read http://lists.gnupg.org/pipermail/gnupg-users/2009-May/036379.html correctly) this option does not control what DSA2 keys use. Or have I misunderstood? Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA+RSA is now the default
On Mon, May 25, 2009 at 6:25 PM, John Clizbe wrote: > Nicholas Cole wrote: >> It's a small point and I don't mean to get side-tracked, but if any >> front-ends have used this menu, I rather fear that you have replaced >> one evil (not using the right default) with a worse one - presenting >> one thing in the front end and doing another behind the scenes! > > I think Werner has already pointed out that any program relying on the > menus is living in sin. The batch-file approach for generating keys has > been documented for quite some time. I completely agree for creating keys, for which there is the batch-file approach. Adding subkeys is another matter. And while I have never written anything that 'lives in sin' in the way you describe, I was just pointing out that if Warner was assuming such things exist (I am sure they do) then there could be unfortunate consequences as a result of the way this (entirely proper) change has been made! Best, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New results against SHA-1
On Mon, May 4, 2009 at 10:01 PM, John W. Moore III wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Nicholas Cole wrote: > >> How does GPG cope if two keys on the keyring have the same FP? AFAICS >> that would make things very difficult for most of the front-ends, >> especially if they had been relying on the uniqueness (in practice) of >> the FP to specify which key to operate on. > > Please show Me an example of this happening in the Real World. > > JOHN 8-) Well, I'm just not that lucky! Or is that unlucky? It is possible, though, that someone, somewhere will be. If the story reported earlier in this thread is right, someone already has been. Wouldn't a way around some of the (unlikely) problems be for gpg to give each key on the keyring a guaranteed unique number (guaranteed, for example, to be unique on that keyring), and allow users and front-ends to specify a key by that number? This might even be as simple as a number generated by pre-pending the number of the key in the standard --list-keys output to the fingerprint. Best, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New results against SHA-1
On Mon, May 4, 2009 at 9:24 AM, Werner Koch wrote: > On Fri, 1 May 2009 05:58, a...@smasher.org said: > >> so... when is the open-pgp spec moving beyond SHA1 hashes to identify >> public keys? what's next? will it have to be a bigger hash? > > OpenPGP does not claim that the fingerprint is a unique way to identify > a key. How does GPG cope if two keys on the keyring have the same FP? AFAICS that would make things very difficult for most of the front-ends, especially if they had been relying on the uniqueness (in practice) of the FP to specify which key to operate on. N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Probable cause of bad signature?
I've just noticed a curious signature on my own key - apparently one that I made myself a few years ago (2004), but which --check-sigs is now listing as "bad". It is the only signature on the key showing as bad. It probably doesn't matter at all, but I'm still curious to know what might have caused it. Does anyone have any ideas? The signature is class 10. All of the other self-sigs seem to be fine. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: guessing GPG_AGENT_INFO
On Tue, Sep 30, 2008 at 7:44 AM, Werner Koch <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Sep 2008 22:17, [EMAIL PROTECTED] said:
>
>> Is there any way to correctly 'guess' the settings for the
>> GPG_AGENT_INFO variable (for the case where gpg-agent has been called
>> with --use-standard-socket)?
>
> That is easy. With --use-standard-socket the socket used is
>
> ~/.gnupg/S.gpg-agent
>
> unless GNUPGHOME is set in which case it is
>
> ${GNUPGHOME}/S.gpg-agent
>
> The environment variable you want is thus
>
> GPG_AGENT_INFO="${GNUPGHOME:-${HOME}/.gnupg}/S.gpg-agent:-1:1"
>
> We do not actually need the PID, thus we set it to -1. The trraling 1
> is the protocol version (not checked, iirc).
>
> If you don't use --use-standard-socket you can try to write a scripts
> based on
>
> netstat -lx | awk '/\/S.gpg-agent$/ { print $8 }'
>
> but you need to figure out whether this is the socket for the desired
> user. Maybe -lxp would be helpful.
Fantastic, Warner. Thank you!
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
guessing GPG_AGENT_INFO
gpg-agent can tell whether gpg-agent is running, but if the environment variable has not been properly set, there seems to be no way to set it without killing the gpg-agent process and starting it again. Is there any way to correctly 'guess' the settings for the GPG_AGENT_INFO variable (for the case where gpg-agent has been called with --use-standard-socket)? It is very slightly frustrating that gpg-agent can report that it can connect to a gpg-agent daemon, and then be unusable when gpg tries to call it :-) Best, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
OT: RFC 3156 question
Apologies for a slightly OT question, since this is not gpg-specific, but I thought it would be a good place to ask. Section 4 of RFC 3156 (PGP/MIME) says: "Before OpenPGP encryption, the data is written in MIME canonical format (body and headers)." Am I right that an encrypted message should like: > From nobody Thu Sep 25 21:23:32 2008 > MIME-Version: 1.0 > Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; > boundary="===1328406624==" > > --===1328406624== > Content-Type: application/pgp-encrypted > > Version: 1 > --===1328406624== > Content-Type: application/octet-stream > > &Content-Type: text/plain; charset="us-ascii" > &Content-Transfer-Encoding: 7bit > & > &This is a test Message, > &With some text in it > > --===1328406624==-- with the part marked by '&' the data that is actually to be sent to gpg to be encrypted? Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --allow-multiple-messages in gpg 1.4.9
On Thu, Aug 7, 2008 at 10:49 AM, Werner Koch <[EMAIL PROTECTED]> wrote: > On Thu, 7 Aug 2008 14:37, [EMAIL PROTECTED] said: > >> The issue I was reporting was that this option doesn't seem to do >> anything at all, at least for armoured messages. I haven't done any >> further testing. Are you saying that this is a dummy option? > > Right, it has never worked with armoured messages. Or at least not for > a long time. You need to split the messages first. Thanks for the clarification. I wonder if it would be useful if there were a flag that would tell gpg to raise an error if it encounters data that it can't understand or is ignoring. Best, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --allow-multiple-messages in gpg 1.4.9
On Thu, Aug 7, 2008 at 3:06 AM, Werner Koch <[EMAIL PROTECTED]> wrote: >* By default, do not allow processing multiple plaintexts in a > single stream. Many programs that called GnuPG were assuming > that GnuPG did not permit this, and were thus not using the > plaintext boundary status tags that GnuPG provides. This change > makes GnuPG reject such messages by default which makes those > programs safe again. --allow-multiple-messages returns to the > old behavior. [CVE-2007-1263]. > > I'll change the documentaion to make this more clear. The issue I was reporting was that this option doesn't seem to do anything at all, at least for armoured messages. I haven't done any further testing. Are you saying that this is a dummy option? Best, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
--allow-multiple-messages in gpg 1.4.9
I don't know if this is a bug, or my own misreading of the documentation, but --allow-multiple-messages doesn't quite seem to do what the documentation leads me to expect: Allow processing of multiple OpenPGP messages contained in a single file or stream. If I create a file with two armored openpgp signed bocks, only the first one appears to be processed by gpg, even with this option provided. The second is silently ignored. The option appears to be ignored whether or not I read from the file or provide the blocks on stdin and whether or not I use the explicit --decrypt option. Best wishes, Nicholas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
batch create DSA2
Dear List, A quick question about key generation using --batch --key-gen. Am I right using the option --openpgp, a DSA2 key can be created just by using Key-Type: DSA and a key-size longer than 1024. I.e. there is no specific Key-Type for DSA2 keys? Or is it the case that if DSA2 keys are enabled, even a 1024 length key will be DSA2 (and use new hashes etc)? Best wishes, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Signing people with only one form of ID?
On Sat, Mar 1, 2008 at 11:46 AM, Richard Hartmann <[EMAIL PROTECTED]> wrote: > On Fri, Feb 29, 2008 at 6:40 PM, Brian Smith <[EMAIL PROTECTED]> wrote: > > > > > The basic assumption is that a key signing is good and that > > > you actually gain something from it. > > > > That is the assumption that I am challenging. > > You are not challengging the assumption, you are attacking the > implementation :) Well, let me attack this problem from another position. :-) I think we need to remember what the purpose of a signature on an OpenPGP is. It is there, first and foremost, to tell the computer "Yes, you should be happy encrypting to this key", for the purpose of avoiding Man in the Middle attacks. (And - as an aside - the purpose of OpenPGP is to make email and other electronic communication on the internet more secure). One of the early mistakes I think the _documentation_ of PGP made was to suggest that one day we might all live in a world where keys would be selected automatically from keyservers, with no effort on the part of the user, and with almost total security. It is with such a dream in mind that people set up key servers, go to key-signing parties and the like, and start worrying about how many passports they need to see before they sign a key. Actually, such a world is probably not possible. But for private users, most of the time, the most important thing is still to check the fingerprint of the key with the intended recipient of secure communications. It is, actually, simple. But that does not mean the web of trust is useless - far from it. OpenPGP lets you represent all sorts of trust models: you can choose trust the root key of a company, university or computer software project, and thereby "trust" all of the people involved in that organisation, for example. But I've never been convinced that the search for the "right" level of id to demand before signing a key is right, nor that going to random keysignings is very useful. OpenPGP can only represent "trust" that already exists. And the truth of the matter is that if I have just met a chap in a bar, I am unlikely to "trust" him to sign any more keys for me, no matter how much he tells me he always looks at passports. So even if I signed his key, I probably wouldn't then trust him to sign other keys that I depended upon. Sorry - that was rather more than I meant to write. Take home message: use OpenPGP to represent "trust" relationships that make sense for your situation, and don't worry about an ideal standard, because one doesn't exist, shouldn't exist, and probably couldn't ever exist. ;-) (I am reminded of this cartoon: http://xkcd.com/386/ ) Best, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADKs (was: Corporate use of gnupg)
On Tue, Feb 19, 2008 at 5:49 PM, David Shaw <[EMAIL PROTECTED]> wrote: > Even if the patent issue was resolved, it doesn't really solve much to > have GPG follow the ADK. GPG is distributed as source - easy enough > for someone to simply comment out the ADK code if they didn't want it > to take effect. Dear David, Thank you for your long and clear reply. I take the point about the patent issues completely. However, just for a moment assuming that the patent issue could be solved in a way that would not upset PGP... OpenPGP has done well in 'closed' environments (as you define them), but has always stumbled in more potentially open settings. This has always seemed to me a huge shame. There seem to be at least some settings where ADK makes sense and would encourage the use of PGP. Of course, it is simply a 'request', but it is a reasonable request and (as far as I can see) a much better way to handle these issues than saying to people 'please always encrypt to my corporate key manually'. The point about ADK being something that can be circumvented is not, I think, a real issue. It has always seemed to me that ADK is something much more akin to all the other preferences already stored on a key - a request to PGP-compatible programs to encrypt data in a particular way. Since it would encourage the use of encryption in environments where it is not currently used, I would see it as nothing but a good thing. Although, of course, if there really are patent issues, it can't happen, but perhaps PGP Corp would/could be flexible on this point. Best wishes, N. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Corporate use of gnupg
On Tue, Feb 19, 2008 at 1:23 PM, David Picón Álvarez <[EMAIL PROTECTED]> wrote: > > I know that ADK can be circumvented by a determined attacker, but it > > strikes me as a useful feature, and I have never quite understood the > > opposition to it. It would have made encryption more palatable in > > corporate settings, which surely would have been a good thing! > > IMO there are two possibilities: 1) your users are forgetful but honest, 2) > your users are dishonest. > > For case 1, an equivalent of ADK can be obtained with a line on GPG's > configuration file. > > For case 2, you are screwed, and ADK is only going to give you a false sense > of security. > > Thus ADK is either pointless or unnecessary. This just simply isn't true. Putting a line in a config file may be fine for internal mail, but does nothing to help you to be able to decrypt mail sent from outside your organisation. It also locks everyone into using gpg - I thought the whole point of gpg / opengpg was to be inter-operative. Secondly, there might be any number of reasons why a user might not be able to give you access to a key. He might be incompetent, he might be unexpectedly ill or worse. And so on, and so forth. But my real point is this: gpg in most areas says "This is a tool. Your threat models will vary, and we give you a tool which you can deploy". But in the area of ADK, even when for years people have said on this list and elsewhere, "ADK would help with the threat/organizational model we have", GPG refuses to help. "alter your config file" solves (at best) half of the problem. There may be very good technical reasons why ADKs are a bad idea, but I've never seen them explained. There was, I know, an attack on PGP which relied upon them a while ago, but IIRC that bug was easily fixed. Best wishes, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Corporate use of gnupg
Just to address the original point of the thread, though, could you not use sub-keys to achieve the most of the effect you want? Have everyone share an encryption/decryption subkey, but have their own separate signing keys. The disadvantage would be that anyone in the group (ie not just an administrator or the like) could decrypt anyone else's email - but in many settings that might be acceptable or even advantageous. Best, N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Corporate use of gnupg
On Sat, Feb 16, 2008 at 3:00 AM, Texaskilt <[EMAIL PROTECTED]> wrote: > > Looks like this is ADK. Is there any way to do this on gpg? GPG does not implement ADK. I think that, historically, it seemed too much like the kind of key escrow systems that governments have from time to time talked about wanting, although clearly there is a difference. I know that ADK can be circumvented by a determined attacker, but it strikes me as a useful feature, and I have never quite understood the opposition to it. It would have made encryption more palatable in corporate settings, which surely would have been a good thing! But I'm not an expert, and I'm probably missing a point somewhere... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
