generate key using specific cipher

[Eugene M. Zheganin]

Hi,

I'm trying to learn how to use gpg/libgcrypt with GOST cryptography 
(actually I'm moving from openssl, where GOST is deprecated due to poor 
code quality to the gpg/libgcrypt software, where GOST is present since 
1.7.0), and since the entire crypoto subsystem is (from my point of 
view) is overcomplicated, I'm lacking some simple skills - for instance, 
how do I generate an x509 csr/key with GOST (is it even possible) ? In 
openssl I would do something like "openssl req -newkey gost2001 -pkeyopt 
paramset:A -keyout foo -out bar" and this would do the trick. In 
gnupg well, I'm looking at the documentation right now but just 
cannot find the clue.


Thanks.

Eugene.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How can we utilize latest GPG from RPM repository?

[Ben McGinnes]

On Thu, Feb 22, 2018 at 08:09:31AM -0800, Dan Kegel wrote:
> 
> https://www.open-scap.org/download/ shows they provide an
> open source tool which is in repositories for four redhat-ish distros and
> two debian-ish distros; on Ubuntu, I was able to walk down the
> path of using it a bit, looks a bit rusty, but see
> https://github.com/OpenSCAP/scap-security-guide
> So it doesn't seem to be RHEL-only.  (They have a value-added tool
> that is, of course.)

Interesting and good to know if I'm ever in the unfortunate position
of needing to deal with it directly again.


Regards,
Ben


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Removing expired keys

[Jerry]

On Sun, 25 Feb 2018 14:48:23 +0100, Dirk Gottschalk via Gnupg-users stated:

>Hello.
>
>Am Samstag, den 24.02.2018, 07:20 -0500 schrieb Jerry:
>> Kleopatra Version 3.0.2-gpg4win-3.0.3
>> 
>> Running the command from Kleopatra  > Certificates> on a  
>> Windows 10 PRO amd64 machine, displays numerous expired certificates.
>> The
>> complete output is available here: https://seibercom.net/GPG-Expired-
>> Keys.txt
>> 
>> Is there any command that I can run from either Kleopatra or the
>> Windows'
>> command line that will remove all of these expired certificates? I
>> would
>> really love to clean up system and removed expired or revoked
>> certificates.  
>
>I run under Linux and have a shell script for this. AFAIK there is no
>way to do this automatically from gpg itself.
>
>
>> Also, how do I deal with "signatures not checked due to missing keys"
>> warnings?  
>
>You could turn on automatic key retieval in gog.conf. add the following
>to the keyserver-options parameter:
>
>auto-key-retrieve

It is already there.

>This will automatically download missing keys when you try to verify a
>signature.
>
>Regards,
>Dirk



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: enigmail with pgp 2.2.4

[Dmitry Gudkov]

Hi Peter,

i thought you forgot about me)
thank you for your very detailed response

I have a confession to make, too. Not only I'm not a developer, but I'm
a fresh convert from os to linux). And it all started last year when I
stumbled upon gnupg just looking for a proper way to encrypt a flash drive)

Correct me if I'm wrong but the best conclusion I could make for your
letter is that unless I locally build a Debian package myself (the
epitome of thoroughness!), I can't be 100% sure everything works as it
should.

If that's the case. I do want to give it a shot but I doubt I can do it
without step-by-step guide without breaking something). I guess it must
be boring for you to dedicate more of your time on this, but I can't
help but asking to provide one for me in hope that there are some more
inexperienced GNU/Linux users on this mailing list who might be very
much interested in building the epitome of thoroughness themselves but
just too shy to ask for guidance)

respectfully,
Dmitry

On 25.02.2018 15:24, Peter Lebbing wrote:
> On 22/02/18 21:50, Dmitry Gudkov wrote:
>> my bad, I should have started a new thread, well noted
>>
>> on the other hand that's probably why I suddenly had all the big gnupg
>> minds helping me)
> Hehe, I think this is all just pure chance, it depends who has the time
> to read and respond. I don't think it's related to threading. What does
> make a difference, possibly a large one, by the way, is when the
> question is accompanied by much useful contextual information. If I'm
> reading a mail here and can already get a long way towards the solution
> by all the information in a question, I'm more inclined to respond then
> when my response would still be asking a lot of questions back. But this
> is just some general musing on my part. And it is also unrelated to your
> specific mail, it's a general observation.
>
> And by the way, my knowledge of GnuPG is not exceptional, I'm not a
> developer, just an enthousiast who has made it a hobby to try and help
> people here on the list :-).
>
>> seriously now ...
> Yes, let's :-).
>
>> it was a fresh ubuntu 16.04 install
>>
>> it came with gnupg 1.4.20 and 2.1.11
>>
>> i compiled gnupg 2.2.4
> Ah! I see. I didn't know or had forgotten that Ubuntu 16.04 forked
> Debian at a time when the gnupg2 package was a 2.1. AFAICT, looking at
> .deb files, /usr/bin/gpg is GnuPG 1.4 from the gnupg package and
> /usr/bin/gpg2 is 2.1 from the gnupg2 package in Ubuntu, which
> corresponds to what you say.
>
> Now let's list problems and solutions:
>
> - Programs invoking "gpg" (or explicitly /usr/bin/gpg) expect it to be a
> 1.4 installation.
>
> This should be fixed by having your locally installed GnuPG 2.2.5
> provide a "gpg2" binary, not a "gpg" binary:
>
> ./configure --enable-gpg-is-gpg2
>
> (include whatever other configure options you want, but also include
> that one).
>
> Since it requires recompilation, let's pick the latest and greatest
> 2.2.5 :-).
>
> Since in Ubuntu 16.04, anything invoking "gpg2" or "/usr/bin/gpg2" is
> either working with a 2.1 version or is not working as shipped by the
> distribution, you won't create more breakage (anything working with 2.1
> should work with 2.2).
>
> - You have a GnuPG 2.1.11 in /usr/bin/gpg2 and a 2.2.4 in
> /usr/local/bin/gpg2. A similar situation occurs with any locally
> compiled libraries and stuff.
>
> The best solution would be to create Debian packages yourself, based on
> the Ubuntu packaging but utilising the latest GnuPG 2.2 instead of the
> 2.1.11 of Ubuntu that was last updated 2 years ago (on 8 April 2016, to
> be precise) and contains known bugs.
>
> That is some work, but doable. It requires looking at how Ubuntu
> packaged it, and create something equal but using a vanilla 2.2.5
> instead of a 2.1.11 with backported fixes. Well, with a 2.1.11 that had
> backported fixes 2 years ago. I think it's unfortunate they stopped
> backporting fixes once they released 16.04.
>
> I'm not 100% sure about other good solutions. I think it's not a good
> idea to have 2.1.11 in /usr and 2.2.5 in /usr/local. But if it works for
> you, you could see if it keeps working for you. I'll come back to this.
>
> Another solution is installing the stuff in /usr/local like you did, but
> with some additional actions:
>
> Make sure everything has /usr/local/bin in its PATH and ld.so is looking
> for libraries in /usr/local/lib. On Debian, I think this is already in
> place.
>
> And then replace the gnupg2 package, the gpg-agent package and all the
> others for which you just installed a /usr/local package by an equivs
> package. Just have a look at each file you installed in /usr/local with
> your local compile, and do something like:
>
> You see:
> /usr/local/bin/gpg2
>
> You inquire:
> dpkg -S /usr/bin/gpg2
>
> And dpkg tells you it is part of package gnupg2, so you need to build an
> equivs for that. Etcetera.
>
> Install the "equivs" package. Read its manual, and create packages named
> "gnupg2" 

Re: Subkey Usage, Expire Date and Preferences problem

[Yan Fiz]

Oh, sorry. I made a mistake in 'Key-Type:' line. Right one :

Key-Type: eddsa

On Sun, Feb 25, 2018 at 2:16 AM, Yan Fiz  wrote:

> Hello,
>
> When I create unattended key with cv25519 or ed25519 as subkeys, GnuPG
> doesn't apply 'encrypt' usage, expire date and preferences. There is no
> problem with RSA.
>
> Regards.
>
> (PS : My example key numbers were padded with X and Y)
>
> $ gpg --batch --gen-key
> Key-Type: ecdsa
> Key-Curve: ed25519
> Key-Usage: sign auth
> Subkey-Type: ecdh
> Subkey-Curve: cv25519
> Subkey-Usage: encrypt
> Passphrase:
> Name-Real: Yan Fiz
> Expire-Date: 1y
> Preferences: twofish sha512 zlib
>
> $ gpg --edit-key  showpref quit
> gpg (GnuPG) 2.2.5; Copyright (C) 2018 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.
>
> gpg: key : 2 bad signatures
> gpg: key : Warning: errors found and only checked
> self-signatures, run 'check' to check all signatures.
> Secret key is available.
>
> sec  ed25519/
>  created: 2018-02-24  expires: never   usage: SCA
>  trust: ultimate  validity: ultimate
> ssb  cv25519/
>  created: 2018-02-24  expires: never   usage:
> [ultimate] (1). Yan Fiz
>
> [ultimate] (1). Yan Fiz
>  Cipher: 3DES
>  Digest: SHA1
>  Compression: ZIP, Uncompressed
>  Features: Keyserver no-modify
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Removing expired keys

[Dirk Gottschalk via Gnupg-users]

Hello.

Am Samstag, den 24.02.2018, 07:20 -0500 schrieb Jerry:
> Kleopatra Version 3.0.2-gpg4win-3.0.3
> 
> Running the command from Kleopatra   Certificates> on a
> Windows 10 PRO amd64 machine, displays numerous expired certificates.
> The
> complete output is available here: https://seibercom.net/GPG-Expired-
> Keys.txt
> 
> Is there any command that I can run from either Kleopatra or the
> Windows'
> command line that will remove all of these expired certificates? I
> would
> really love to clean up system and removed expired or revoked
> certificates.

I run under Linux and have a shell script for this. AFAIK there is no
way to do this automatically from gpg itself.


> Also, how do I deal with "signatures not checked due to missing keys"
> warnings?

You could turn on automatic key retieval in gog.conf. add the following
to the keyserver-options parameter:

auto-key-retrieve

This will automatically download missing keys when you try to verify a
signature.

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350

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: enigmail with pgp 2.2.4

[Peter Lebbing]

On 22/02/18 21:50, Dmitry Gudkov wrote:
> my bad, I should have started a new thread, well noted
> 
> on the other hand that's probably why I suddenly had all the big gnupg
> minds helping me)

Hehe, I think this is all just pure chance, it depends who has the time
to read and respond. I don't think it's related to threading. What does
make a difference, possibly a large one, by the way, is when the
question is accompanied by much useful contextual information. If I'm
reading a mail here and can already get a long way towards the solution
by all the information in a question, I'm more inclined to respond then
when my response would still be asking a lot of questions back. But this
is just some general musing on my part. And it is also unrelated to your
specific mail, it's a general observation.

And by the way, my knowledge of GnuPG is not exceptional, I'm not a
developer, just an enthousiast who has made it a hobby to try and help
people here on the list :-).

> seriously now ...

Yes, let's :-).

> it was a fresh ubuntu 16.04 install
> 
> it came with gnupg 1.4.20 and 2.1.11
> 
> i compiled gnupg 2.2.4

Ah! I see. I didn't know or had forgotten that Ubuntu 16.04 forked
Debian at a time when the gnupg2 package was a 2.1. AFAICT, looking at
.deb files, /usr/bin/gpg is GnuPG 1.4 from the gnupg package and
/usr/bin/gpg2 is 2.1 from the gnupg2 package in Ubuntu, which
corresponds to what you say.

Now let's list problems and solutions:

- Programs invoking "gpg" (or explicitly /usr/bin/gpg) expect it to be a
1.4 installation.

This should be fixed by having your locally installed GnuPG 2.2.5
provide a "gpg2" binary, not a "gpg" binary:

./configure --enable-gpg-is-gpg2

(include whatever other configure options you want, but also include
that one).

Since it requires recompilation, let's pick the latest and greatest
2.2.5 :-).

Since in Ubuntu 16.04, anything invoking "gpg2" or "/usr/bin/gpg2" is
either working with a 2.1 version or is not working as shipped by the
distribution, you won't create more breakage (anything working with 2.1
should work with 2.2).

- You have a GnuPG 2.1.11 in /usr/bin/gpg2 and a 2.2.4 in
/usr/local/bin/gpg2. A similar situation occurs with any locally
compiled libraries and stuff.

The best solution would be to create Debian packages yourself, based on
the Ubuntu packaging but utilising the latest GnuPG 2.2 instead of the
2.1.11 of Ubuntu that was last updated 2 years ago (on 8 April 2016, to
be precise) and contains known bugs.

That is some work, but doable. It requires looking at how Ubuntu
packaged it, and create something equal but using a vanilla 2.2.5
instead of a 2.1.11 with backported fixes. Well, with a 2.1.11 that had
backported fixes 2 years ago. I think it's unfortunate they stopped
backporting fixes once they released 16.04.

I'm not 100% sure about other good solutions. I think it's not a good
idea to have 2.1.11 in /usr and 2.2.5 in /usr/local. But if it works for
you, you could see if it keeps working for you. I'll come back to this.

Another solution is installing the stuff in /usr/local like you did, but
with some additional actions:

Make sure everything has /usr/local/bin in its PATH and ld.so is looking
for libraries in /usr/local/lib. On Debian, I think this is already in
place.

And then replace the gnupg2 package, the gpg-agent package and all the
others for which you just installed a /usr/local package by an equivs
package. Just have a look at each file you installed in /usr/local with
your local compile, and do something like:

You see:
/usr/local/bin/gpg2

You inquire:
dpkg -S /usr/bin/gpg2

And dpkg tells you it is part of package gnupg2, so you need to build an
equivs for that. Etcetera.

Install the "equivs" package. Read its manual, and create packages named
"gnupg2" etcetera. Replace all real Ubuntu packages by these dummy
equivs package.

What did I just propose doing?

I don't like the situation where there is a full real GnuPG in /usr and
another one in /usr/local. The one in /usr might interfere with what you
intend with the one in /usr/local. But you can't just deinstall the
Ubuntu packages, because stuff depends on it. It would force
deinstallation of all packages depending upon gnupg2, gpg-agent etcetera.

With equivs, you can build an empty package. It doesn't install anything
in /usr, so there will no longer be a /usr/bin/gpg2 at all. But any
package that depends on "gnupg2" will see the empty equivs package named
"gnupg2" and be happy that it is installed.

I have done this myself with other packages, but never with GnuPG.

> it worked just fine in terminal and after configuring Enigmail with the
> new gpg location works there as well

You could just see if it gives you any issues. I'm slightly worried
about silent issues, though, where you think everything is working fine
but it is failing in some subtle but nefarious way. I'm also slightly
worried about the 2.1.11 Ubuntu 16.04 users have installed, which hasn't
seen any maintenance