Finally moving from 2.0.22 to 2.2.x or higher
What do we need to know about using our existing keyring, and copious CLIs, that we use to encrypt, decrypt and administer our legacy GPG? As previously posted, we are on Centos 7.9.2009, which only supports GPG v2.0.x. Until we upgrade Centos later this year, I've been reviewing suggestions on how to upgrade to 2.2.17 and higher, which we're about to undertake. How can we "import" our existing keyring into newer GPG? What else do we need to know, and prepare for, for our production use? Please, advise. Thank you. ~ Mike ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: can't handle public key algorithm 18
Yes, I see that. However, our public key was generated by our GPG; and this file is encrypted with our public key, since there is NO missing "secret key" error. Why, then, the subject error message? On Sat, Apr 15, 2023 at 3:37 PM Todd Zullinger via Gnupg-users < gnupg-users@gnupg.org> wrote: > Mike Schleif wrote: > > $ gpg --version > > gpg (GnuPG) 2.0.22 > > libgcrypt 1.5.3 > > > > $ cat /etc/system-release > > CentOS Linux release 7.9.2009 (Core) > > Algorithm 18 is ECDH, which is not supported by gpg on > CentOS 7. You can confirm this in the Pubkey line of the > gpg --version output: > > $ gpg --version > gpg (GnuPG) 2.0.22 > libgcrypt 1.5.3 > [...] > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, ?, ?, ELG, DSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > On a newer Fedora system, ECDH is present: > > $ gpg --version --no-copyright > gpg (GnuPG) 2.4.0 > libgcrypt 1.10.1-unknown > [...] > > Home: /home/user/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > -- > Todd > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg: can't handle public key algorithm 18
$ gpg --version gpg (GnuPG) 2.0.22 libgcrypt 1.5.3 $ cat /etc/system-release CentOS Linux release 7.9.2009 (Core) On Sat, Apr 15, 2023 at 1:36 PM Bruce Walzer wrote: > On Sat, Apr 15, 2023 at 11:17:31AM -0500, Mike Schleif wrote: > > On trying to decrypt a file, we get the subject error on failure. > > What version of GnuPG are you using? Running on what platform? > > Bruce > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg: can't handle public key algorithm 18
On trying to decrypt a file, we get the subject error on failure. What does this mean? How ought we deal with this? Please, advise. Thank you. ~ Mike ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
With which key did I sign my encrypted file?
My company uses several keys for signing files encrypted with one of many recipient public keys. Once in awhile, we get pushback from a recipient that they cannot decrypt our file, and sometimes they claim it is because the encrypted file is signed. Yesterday, I took the same file, encrypted it and signed it, as well as encrypting it without signing it. $ /usr/bin/gpg --verify signed.pgp gpg: verify signatures failed: Unexpected error $ /usr/bin/gpg --verify NO-sign.pgp gpg: verify signatures failed: Unexpected error $ /usr/bin/gpg --version gpg (GnuPG) 2.0.14 What am I missing? Please, advise. Thank you. ~ helices ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PCI DSS compliance
Yes, our company has been doing all four of your suggestions for years, including written policies and procedures, and we passed all prior years of PCI DSS auditing without incident. Near as I can tell, nothing has changed in this regard in PCI DSS standards in the last twelve months, to which our auditor agrees. You can find his non-member post here: https://lists.gnupg.org/pipermail/gnupg-users/2016-November/057009.html He says that PGP has some mechanism that satisfies this requirement. I haven't touched PGP in more than four years. Do they have something new? ~ Mike On Wed, Nov 9, 2016 at 2:54 PM, F Rafi wrote: > Probably out-of-scope for this list but, if the process is automated you'd > want to reduce the number of people with access to the keys to only staff > with need-to-know. Usually that translates to IT support / administrators. > Beyond that safeguards against people (specifically administrators) cannot > be technical controls. They have to be policies, procedures, and > monitoring/audit. You should demonstrate that: > >- You are doing background checks against employees with access to the >keys >- Those background checks look at issues like debt >- You have security policies and procedures that dictate use of >well-known security best practices >- You have a security awareness program that ensures that employees >are reminded of best practices >- You keep a log of whoever is logging into the system to access the >key > > You just have to trust your employees at some point. None of this > mitigates a rogue insider with access to the keys. > > -Farhan > > > On Wed, Nov 9, 2016 at 11:16 AM, Mike Schleif > wrote: > >> During our current annual PCI DSS audit, our auditor complains that a >> human being can access the company's private key and, thus, a human being >> can decrypt sales files containing credit card information. >> >> All production processes are fully automated and run as non-privileged >> user. >> >> We use GPG encryption for all file exchanges between this company and >> banks, and between vendors/clients and this company. The latter is the >> issue. >> >> What can be done about this? >> >> Please, advise. Thank you. >> >> ~ Mike >> >> >> >> >> ___ >> 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
PCI DSS compliance
During our current annual PCI DSS audit, our auditor complains that a human being can access the company's private key and, thus, a human being can decrypt sales files containing credit card information. All production processes are fully automated and run as non-privileged user. We use GPG encryption for all file exchanges between this company and banks, and between vendors/clients and this company. The latter is the issue. What can be done about this? Please, advise. Thank you. ~ Mike ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
PCI DSS compliance
During our current annual PCI DSS audit, our auditor complains that a human being can access the company's private key and, thus, a human being can decrypt sales files containing credit card information. All production processes are fully automated and run as non-privileged user. We use GPG encryption for all file exchanges between this company and banks, and between vendors/clients and this company. The latter is the issue. What can be done about this? Please, advise. Thank you. ~ Mike ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG cannot import public key
GPG version trying to import: gpg (GnuPG) 2.0.14 Header from shared armored public key: Version: Encryption Desktop 10.3.0 (Build 8741) GPG error on import: # gpg --import /tmp/imps.asc gpg: key 845F5188: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 Other GPG import: # gpg --allow-non-selfsigned-uid --import /tmp/imps.asc gpg: key 845F5188: accepted non self-signed user ID "Concerto Support Key < concerto.supp...@impact-ps.com>" gpg: key 845F5188: public key "Concerto Support Key < concerto.supp...@impact-ps.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) Then: # gpg --list-keys 845F5188 pub 0s/845F5188 2013-03-05 uid Concerto Support Key # gpg --edit-key 845F5188 gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 0s/845F5188 created: 2013-03-05 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Concerto Support Key Command> sign User ID "Concerto Support Key " is not self-signed. Unable to sign. Nothing to sign with key 31A070A8 No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust: gpg: 845F5188: skipped: Unusable public key gpg: /tmp/test.txt: encryption failed: Unusable public key The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature What am I missing? Please, advise. Thank you ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
