Re: 2.1.10 with libgcrypt 1.7.0-beta300
On 01/23/2016 10:11 PM, Fulano Diego Perez wrote: > NIIBE Yutaka: >> Please note that you need to invoke gpg-agent with LD_LIBRARY_PATH, too. > > can explain how you mean to invoke ? Well, it seems terminology issue. I mean, to start, to kick the service, and to run the service. In general, there are multiple ways. In my case on Debian, I have a startup script, /etc/X11/Xsession.d/90gpg-agent, which invokes gpg-agent. > i export library path for gpg2 and shows expected libgcrypt version Exporting library path is also needed for gpg-agent. > i can clearsign with ed25519 EDDSA subkey This can be done with libgcrypt 1.6.4. > i have problem testing encryption with cv25519 subkey > > > tried to test with $ fortune | gpg2 --sign --encrypt -u abc --recipient > 123 --recipient 456 | gpg2 --decrypt > > gpg: ecdh failed in gcry_cipher_decrypt: Checksum error > gpg: ecdh failed in gcry_cipher_decrypt: Checksum error > gpg: encrypted with 256-bit ECDH key, ID test, created 2016 > "test" > gpg: public key decryption failed: Checksum error > gpg: encrypted with 256-bit ECDH key, ID test, created 2016 > test2 > gpg: public key decryption failed: Checksum error > gpg: decryption failed: No secret key > > i have secret key I know. The problem is the version of libgcrypt of gpg-agent. Public key handling is the role of gpg frontend, while secret key handling is done by gpg-agent. With no newer libgcrypt, gpg-agent can't handle CV25519 keys. > tried list-packets & -vvv - nothing more on errors Yes. > maybe this is conflict with persistent gpg-agent and ssh-agent > they are listed in htop with PID but no RAM use > > how can to figure this out ? If you can check the process's memory maps of gpg-agent, you can see the maps to libgcrypt. In my case, I can see the entries in /proc//maps like: b7617000-b76d5000 r-xp 08:01 35743 /usr/local/lib/libgcrypt.so.20.1.0 b76d5000-b76d9000 rw-p 000bd000 08:01 35743 /usr/local/lib/libgcrypt.so.20.1.0 b76e7000-b76ef000 rw-p 00:00 0 -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg: signing failed: Invalid IPC response
Hello! After upgrading my packages (now on gnupg 2.1.9), I am getting an error when trying to sign: $ echo "test"|gpg2 -sa gpg: signing failed: Invalid IPC response -BEGIN PGP MESSAGE- gpg: signing failed: Invalid IPC response gpg-agent.conf contains: pinentry-program /usr/local/bin/pinentry-gtk-2 and pinentry-gtk2 is asking for the passphrase properly. This is all on OpenBSD, and everything has been working fine prior to updating to 2.1.9. Here is some debug info from gpg-agent: 2016-01-24 09:26:33 gpg-agent[9415] listening on socket '/home/XX/.gnupg/S.gpg-agent' 2016-01-24 09:26:33 gpg-agent[13435] gpg-agent (GnuPG) 2.1.9 started 2016-01-24 09:26:34 gpg-agent[13435] handler 0x1817b661300 for fd 5 started 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK Pleased to meet you, process 12746 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- RESET 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION ttytype=xterm 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION display=:0 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION xauthority=/home/XX/.Xauthority 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION allow-pinentry-notify 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION agent-awareness=2.1.0 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- AGENT_ID 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> ERR 67109139 Unknown IPC command 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- HAVEKEY X 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- RESET 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- SIGKEY X 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22%22%0A256-bit+EDDSA+key,+ID+,%0Acreated+XXX+(main+key+ID+).%0A 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- SETHASH 10 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- PKSIGN 2016-01-24 09:26:34 gpg-agent[13435] starting a new PIN Entry 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK Pleased to meet you, process 13435 2016-01-24 09:26:34 gpg-agent[13435] DBG: connection to PIN entry established 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION grab 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION ttytype=xterm 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION allow-external-password-cache 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-ok=_OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-cancel=_Cancel 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-yes=_Yes 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-no=_No 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-prompt=PIN: 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-pwmngr=_Save in password manager 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-cf-visi=Do you really want to make your passphrase visible on the screen? 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-tt-visi=Make passphrase visible 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-tt-hide=Hide passphrase 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION touch-file=/home/XX/.gnupg/S.gpg-agent 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> GETINFO pid 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- D 14005 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435]
Re: Different SHA1 Checksum using Microsoft file checksum integrity verifier
## W Wong (wwongwong2...@gmail.com): > 4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe That is the MD5 checksum of the gpg4win-2.3.0.exe file, which has the SHA1 checksum 88d90ee9a1ea3e66b198ea866063140b882444d5. Regards, Christoph -- Spare Space ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SHA-1 vs. SHA-256 checksums (was: Different SHA1 Checksum using Microsoft file checksum integrity verifier)
On Sun 2016-01-24 13:55:38 -0500, Werner Koch wrote: > If you talk to people on how they verify SSH fingerprints (that is even > MD5 for most installations) SSH key fingerprints are a different thing than software distribution checksums because the material digested in ssh originates entirely from one party, whereas the software distribution checksums can potentially be influenced by multiple parties. > you will so often hear: “Oh, I look at the first and a few of the > last digits only”. right, this is not a cryptographically-strong verification :) > We can assume that this won't be different for SHA-1 checksums - does > anyone believe that by switching to SHA-256 they would check many more > digits? if they don't check more digits, then we can't help them. but it'd be nice to offer a way for people to do a cryptographically-strong check if they decide to do so. but in general, i agree with you that published checksums are stopgap measures at best, mainly fit for detecting corrupted downloads, and not particularly useful against a targeted attack. >> Also, the OpenPGP signature published at >> https://files.gpg4win.org/gpg4win-2.3.0.exe.sig itself uses SHA1 >> internally. This is also a bad idea. signatures published today should > > Yes, that should be fixed because it is easy and not subject to the UX > problems described above. FWIW, for GnuPG proper we switched to > SHA-256 in 2012 (gnupg 1.4.12). [...] > [1] Right, the GnuPG speedo build script with its signed and published > list of package versions also uses SHA-1 and that should be fixed > before 2.2. (filed as bug@2226) great, thanks! --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
SHA-1 vs. SHA-256 checksums (was: Different SHA1 Checksum using Microsoft file checksum integrity verifier)
On Sun, 24 Jan 2016 00:01, d...@fifthhorseman.net said: > fwiw, MD5 and SHA1 are both old digest algorithms, and are not as strong > as they should be. I recommend that anyone using checksums for file > integrity switch to SHA256 as soon as possible. That is correct for MD5 given how easy it is to create collisions. For SHA-1 the case is different because there is _currently_ no known way to create a collisions let alone creating a second pre-image. As soon as it will be possible to create collisions for SHA-1 the world does not break apart regarding the use of SHA-1 checksums to verify the integrity and origin of distributed files: Only those who are anyway distributing the file will be able to create two different files resulting in the same SHA-1 digest. Right, they could do interesting things with that capability (providing a different file for certain requesting IPs) but that is a pretty limited use case given that interesting targets would anyway not rely on simple checksums. Checksums are used as a stop-gap for those who are not able to verify a digital signature [1]. The problem is that there is no bulletproof way of verifying the checksum - we post it on the website and we distribute it via the announcement mail. Both are not very secure - if you are able to break SHA-1 today you will also be able to modify these resources. There are many easier ways to attack software distributions: I would start with one of the libraries or tools required in the build process where we have no way to check for tampering. It is wishful thinking that the development process of all the, say, several hundred developers with commit access to the software or the tools required in the build process would withstand a targeted attack. If you talk to people on how they verify SSH fingerprints (that is even MD5 for most installations), you will so often hear: “Oh, I look at the first and a few of the last digits only”. We can assume that this won't be different for SHA-1 checksums - does anyone believe that by switching to SHA-256 they would check many more digits? I would even postulate that we will often hear a “SHA-256 is more secure than SHA-1, thus I do not need to compare more digits”. Running empirical tests might result in an interesting paper. Such a research should then also look at the new hard to compare base-64 encoded SHA-256 fingerprints of OpenSSH). > Also, the OpenPGP signature published at > https://files.gpg4win.org/gpg4win-2.3.0.exe.sig itself uses SHA1 > internally. This is also a bad idea. signatures published today should Yes, that should be fixed because it is easy and not subject to the UX problems described above. FWIW, for GnuPG proper we switched to SHA-256 in 2012 (gnupg 1.4.12). Salam-Shalom, Werner [1] Right, the GnuPG speedo build script with its signed and published list of package versions also uses SHA-1 and that should be fixed before 2.2. (filed as bug@2226) -- 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 signing with non-primary UID
On Sat, 23 Jan 2016 12:29, prze...@gmail.com said: > I would like to sign someone's key with my non-primary UID. > Why? To reflect that given UID is the one I use when contacting owner You do not sign a key with a user id but with your key. Thus it does not make sense to declare which user id made the key-signature. There are too many cases which one would need to decide to make use of such a feature: What if the user id has been revoked or if the verifier does not got hold of that user id (it may be newer or removed later). Why should a key signature I once made with my revoked openit.de address gets void after the revocation of the address. It is still my key and thus me who certified your key+user-id. The Web-of-Trust as implemented by PGP and GnuPG can't make use of this info. You would need to come up with an extend WoT taking this in account. Given that the WoT does not really scale and is already complicated enough it is doubtful what the advantages of such a new trust model are. 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
