Re: Is gpg-agent passphrase status query possible?
On Friday, October 31, 2014 12:33:13 AM Hauke Laging wrote: gpg-connect-agent GET_PASSPHRASE --data --no-ask 4F7E9F723D197D667842AE115F048E6F0E4B4494 t1 t2 t3 /bye D fubar OK It prints the GPG passphrase in plain text. Is the password cached in plain text? -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is gpg-agent passphrase status query possible?
On Fri, 31 Oct 2014 06:51, m...@sudhirkhanger.com said: It prints the GPG passphrase in plain text. Is the password cached in plain text? Catch-22. How would you protect the key used to decrypt the cache? Actually the content of the passphrase cache is stored encrypted in RAM but the key for that is stored in RAM too: /* The encryption context. This is the only place where the encryption key for all cached entries is available. It would be nice to keep this (or just the key) in some hardware device, for example a TPM. Libgcrypt could be extended to provide such a service. With the current scheme it is easy to retrieve the cached entries if access to Libgcrypt's memory is available. The encryption merely avoids grepping for clear texts in the memory. Nevertheless the encryption provides the necessary infrastructure to make it more secure. */ Salam-Shalom, 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: gpgsm signatures fail starting with 2.1.0-beta864
On 2014-10-29, Werner Koch wrote: The only changes for gpgsm since beta834 are related to the key storage. Without any log output I can't help very much. Please check that the correct gpg-agent is used and not some older version - has it been started and is still running after the test (gpg-connect-agent 'getinfo version' /bye) Indeed, I’ve got an older gpg-agent running as well. If I run beta834, it uses the old agent, and verifiable signatures are created. Newer betas, however, start their own gpg-agent, and incorrect signatures are created. (En- and decryption work, though.) For card access I’m using gnupg-pkcs11-scd. Which logfiles would help? On list or via personal e-mail? Thanks Jens ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] The maybe final Beta for GnuPG 2.1
On Fri, Oct 3, 2014 at 4:35 PM, Werner Koch w...@gnupg.org wrote: Hello! I just released another *beta* version of GnuPG *2.1*. It has been released to give you the opportunity to check out new features and to help fixing bugs. Hi all, I had a few minor issues/questions with GnuPG 2.1 beta895 that I thought would be good to report/ask here: 1. Default key prefs[1] don't seem to permit encrypting+signing a message to a brainpoolP512r1 key. Evidently that curve requires SHA512 only for signatures, and all other algorithms will fail. Since SHA256 and SHA384 are prioritized over SHA512 by default in the key prefs, an error occurs. Here's an excerpt of the terminal output, where AF25682B is a primary test key using brainpoolP512r1 while D74B165F is a test encryption subkey using the same curve: = pete@kaylee:~/gpg/gnupg-2.1.0-beta895/PLAY/inst/bin$ ./gpg2 --homedir ~/gnupg/ --encrypt --armor --sign -r AF25682B gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Hello world! gpg: ECDSA key D74B165F requires a 512 bit or larger hash (hash is SHA256) gpg: checking created signature failed: General error gpg: signing failed: General error -BEGIN PGP MESSAGE- Version: GnuPG v2 hL4DWouX3RbM7L4SBAMEbW91unR/0/0QZ9fxeeIo9StkO2c90E9RQT9Cxy4yM7pI dz3siYcAgzEtohdCcpy8BWCPRscqyUcD9iX/QDcxpj3CGG3RHJWdq8ezXVg2m460 ONeb1SnkQGxKsU7oDOo5lu6qQ+pAsvEqhKooyBxlIXPu/qqrtkx3DTvmCudld+Aw od3AWiOPPQOSAzkRDSfk12/FhrWsZUz/q7mq0W/DlYem+B0OvOD+n1dcPDuAJAXR gpg: [stdin]: sign+encrypt failed: General error = Is it normal/desired for 512-bit curves to only work with SHA512? If so, shouldn't a newly-minted key have default prefs appropriate for that key so it will work as expected? If a 512-bit digest is required for a 512-bit ECC key, shouldn't the signing system know that and be able to override the key prefs that might specify a non-512-bit digest? Similarly, brainpoolP512r1 curves seem unable to make a signature using digest algorithms other than SHA512. For example, if a brainpoolP512r1 key is encrypting+signing a message to another key with the default prefs, it uses SHA512. Is this intended? Signing/clearsigning a message with a brainpoolP512r1 curve also uses SHA512, even if one tries to override it. In this example, I try to override it by using SHA1 instead of SHA512: pete@kaylee:~/gpg/gnupg-2.1.0-beta895/PLAY/inst/bin$ ./gpg2 --homedir ~/gnupg/ --armor --clearsign -u AF25682B --personal-digest-preferences SHA1 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Test. -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Test. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iJ4EARMKAAYFAlRTekYACgkQRgJQM68laCuoDwH+KNKsSm01h6lJ659FDEGDoorM /TpWvaVyVbvRa4+8Xya6+c73jt6jSDAeJZMEFBBQYIx3tJy7T6eowYgx3P2eUAIA gvlSuuFVLqiV2Iujd0oa46PEnZZnxIz8Di6vUWqDq/WhhASDuQiidqc1zQ2VexP8 ET23riihBSBDTdTTR8Dp2Q== =sUNG -END PGP SIGNATURE- 2. While Curve25519-based keys can be used for signing using Ed25519, there doesn't seem to be any way to use Curve25519 for encryption. While one could use non-Curve25519 subkeys for encryption, that seems a little sub-optimal. I assume this is known already and will be resolved prior to the production release. 3. Curve25519 has a security level of 128-bits. In addition to the Brainpool curves, are there any plans to add other curves with higher security levels like Curve41417 (200-bits)? I ask simply because having various components (e.g. the symmetric, asymmetric, and hash algorithms) at similar security levels is logical: it wouldn't make sense to, for example, use 1024-bit RSA with SHA512 due to the wide difference in security levels, but using a 3072-bit RSA key with SHA256 would be logical. 4. Are there any plans to add user-specified arbitrary curves in addition to baked-in curves like the NIST, Brainpool, and Curve25519 curves? I realize that using arbitrary curves is something that is not for the faint of heart, but having options is nice. 5. Why are so many key-generating options hidden behind the --full-gen-key flag? The regular --gen-key flag makes a 2048-bit RSA key, which is fine. I understand hiding the ECC options, as support is not widespread, but why hide traditional algorithms like DSA/ELG? Cheers! -Pete [1] Cipher: AES256, AES192, AES, 3DES Digest: SHA256, SHA384, SHA512, SHA224, SHA1 Compression: ZLIB, ZIP, Uncompressed Features: MDC, Keyserver no-modify -- Pete Stephenson ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm signatures fail starting with 2.1.0-beta864
On Fri, 31 Oct 2014 12:19, lech...@wi.uni-muenster.de said: Indeed, I’ve got an older gpg-agent running as well. Don't do that. For card access I’m using gnupg-pkcs11-scd. Well, scdaemon is part of GnuPG. If you replace it with something else it might quite well happen that the systems breaks. 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: key length/size RSA discussion/recommendations in the wiki
Robert, On Wednesday 29 October 2014 at 19:00:39, Robert J. Hansen wrote: Because this gets asked quite often, I've started to capture some arguments of the debate how long RSAs could/should/can be at http://wiki.gnupg.org/LargeKeys I thought we largely addressed this in the FAQ, sections 11.1, 11.2, 11.3, 11.4 and 11.5. Do we need to address it in more depth? yes, I think that the recurring debate demands that the arguments are made visible so they can be tested by readers. You can see in the referred Debian issue tracker, that Werner has to repeat his arguments over and over again, there is not good place to refer to the chain of arguments. If so I'm happy to write an extension to the FAQ. From my point of view the wiki enables us to catch the debate and more in depth. And arguments with its sources. Also it can show the discussion of discenting views point. For example the FAQ does not cover the details of the support for larger keys like 8 KiB or 16 KiB. In my view this would be too much for an FAQ, which should be brief and more official and thus more stable. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: changing the user PIN for a smartcard in a script
On Wednesday 29 October 2014 at 22:29:07, Florin Andrei wrote: Ideally, I would run a script, have the user type in the new PIN, and the script would run gpg --change-pin, do another thing with the PIN string after that, then discard it. The problem, of course, is that pinentry is launched. Now the user has to type the PIN several times. It's cumbersome and error-prone. The idea of pinentry is that there is a most direct connection between the user and the gpg-agent, holding the secret key. It does not want to let other software do another thing with the PIN string. ;) And then, of course, if a user is to set a new pin, he or she should be able to easily type it in correctly a second time. :) You could develop your own pinentry application. Note that pinentry-0.9 in some variants can do the two entries in one dialog. Best, Bernhard -- www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
yes, I think that the recurring debate demands that the arguments are made visible so they can be tested by readers. The FAQ is discussed in public and changes are submitted to the community for comment and review before I make any changes. So far, no one on the list has raised a serious objection to the content -- some have said, I don't agree but I'm in the minority, but no one has said, I don't think the community is behind this. You can see in the referred Debian issue tracker, that Werner has to repeat his arguments over and over again, there is not good place to refer to the chain of arguments. The people who are most up in arms over this aren't going to be convinced by a chain of arguments. Holy wars are driven by articles of faith (vi is superior to emacs!), not by reason. [*] I agree that the FAQ is a bad place to present a chain of arguments and the wiki is the natural spot for it. My concern is that the FAQ and the wiki need to be kept in sync somehow, and I'm not going to be watching the wiki constantly to make sure we're giving consistent advice. My other concern is the false air of authority that wikis tend to get. When anyone can edit, wikis periodically wind up saying ... anything. If people are looking for a curated line of reasoning from cryptographers and/or cryptographic engineers, that may not be a good candidate for a wiki. All this said, though: how can I help? [*] emacs is *so* superior to vi, incidentally. I don't know how any right-thinking person could think otherwise. Heathens. They probably eat pork, too. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Help needed to setup Passphrase with GNUPG 2.0.26
On 10/31/2014 01:31 PM, SubramaniaRao, ravikumar wrote: Hello GNUPG Users, Help needed to setup Passphrase with GNUPG 2.0.26. We have installed the following. (a) libgpg-error-1.11 (b) libgcrypt-1.4.0 (c) libassuan-2.1.2 (d) libksba-1.3.1 (e) pth-2.0.7 (f) GNUPG 2.0.26. Then (1) % echo $PATH /u/ravikums/bin/bin.sun4:/u/ravikums/bin:/usr/openwin/bin/xview:/usr/openwin/bin:/usr/dt/bin:/netapp/bin:/netapp/gnu/bin:/usr/software/bin:/usr/software/utils/bin:/usr/software/rats/bin:/usr/software/test/bin:/usr/local:/usr/local/bin:/usr/ucb:/bin:/usr/bin:/usr/etc:/usr/games:/usr/lib/uucp:/etc:/usr/lib:/usr/sccs/bin:/usr/local/X11/sun4/bin:/usr/bin/X11:/r/frame/bin:/usr/sbin:/sbin:/opt/lotus/bin:/u/ravikums/notes:.:/usr/openwin/bin:/usr/openwin/bin/xview (2) echo $LD_LIBRARY_PATH /usr/openwin/lib:/usr/local/X11R5/sun4c/lib:/netapp/gnu/lib:/usr/openwin/lib:/opt/lotus/common/lel/r100/sunspa41:/usr/local/X11R5/sun4c/lib:/usr/local/lib:/usr/lib After that we are invoking the Command gpg2 --gen-key-The Screen Shot is pasted below: The issue is, after entering the Passphrase it stays there forever. your screenshot suggests that you're doing all of this on some remote machine via ssh (it looks like you're using putty on windows). You haven't mentioned what operating system you're using, though. Anyway, gpg might want to use pinentry to gather the passphrase from the user, and it's not clear that you have the right environment set up for pinentry. whatever package manager you have, can you install pinentry-curses and try again? --dkg PS Excellence is not an Adjective but a Verb -- it's actually a noun :) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Help needed to setup Passphrase with GNUPG 2.0.26
Anyway, gpg might want to use pinentry to gather the passphrase from the user, and it's not clear that you have the right environment set up for pinentry. One option would be to install GnuPG 1.4 on the host machine -- headless servers are some of the few uses I can still see for it. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Help needed to setup Passphrase with GNUPG 2.0.26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/31/14 2:28 PM, Robert J. Hansen wrote: | Anyway, gpg might want to use pinentry to gather the passphrase | from the user, and it's not clear that you have the right | environment set up for pinentry. | | One option would be to install GnuPG 1.4 on the host machine -- | headless servers are some of the few uses I can still see for it. That's true, although pinentry-curses actually does a pretty good job remotely unless the thing that you're calling GnuPG from is taking extreme control of the terminal. For instance, if you're ssh'ing into a remote system and running a simple shell script, or even doing gpg on the command line, pinentry-curses is fine. However if you're doing something more exotic (a mail client like Alpine for example) then all bets are off. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUVBV3AAoJEFzGhvEaGryE2zIIAJ1d573nr3crecng9hSwNstW usx9GMhx06Gh6ecqs8MnAtcs6F3ISl+GuYhL6kq8aDbo/Kmwn5TXdUii6J969Kgw +0647iAvZfsE0XkUSGIWisFUL5DGtaIWfLL1CNmAZbJxjeZy3nK/RBc7E3zshcAb EFoekXAew3JQ/fPmSjctry570P/cUM2KZCZKz5b+pOpcIp+osG/mL5bz0i/UbboL QcVy9zpOngYuXLwMKZBy9DRp+fmPE1SW/7Gs9MO33MW1LpUzuEW988FS1sf33DK+ Eg9UXEfUp+PqqMlsgtQ+Vmz+G/ETc6hP5qEX9FqSfegySgmoVviLt654S9KlHtk= =0ks6 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
