Mailing List Archive

Paul Wolneykien:
> I'm working on adding the GOST (Russian EC crypto) support to GnuPG.

This one?
https://en.wikipedia.org/wiki/GOST_(block_cipher)#Cryptanalysis_of_GOST

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

19.03.2019 14:50, ilf ?????:
> Paul Wolneykien:
>> I'm working on adding the GOST (Russian EC crypto) support to GnuPG.
>
> This one?
> https://en.wikipedia.org/wiki/GOST_(block_cipher)#Cryptanalysis_of_GOST

And these ones too:

* https://en.wikipedia.org/wiki/GOST_(hash_function) ;
* https://tools.ietf.org/html/rfc5832 .
* https://tools.ietf.org/html/rfc4357 .

Note, that some of them are already in Libgcrypt:

*
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/gost28147.c
;
*
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/gostr3411-94.c
;
*
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/ecc-gost.c
.

I've added VKO (rfc4357) and modified gpg and gpgsm to support all of
that (for instance, the GOST R 3410 algorithm is already in Libgcrypt
but there was no way to sign a message with it due to lack of support
from gpg itself).

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

19.03.2019 12:40, Paul Wolneykien ?????:
>
> Hi!
>
> I'm working on adding the GOST (Russian EC crypto) support to GnuPG.
> Currently I have a version where sign/verify and encrypt/decrypt
> operations function properly (with some restrictions) in both PGP and
> S/MIME modes. I want to know what is the official procedure to include
> such a new functionality in GnuPG?

Hi again. My question is still unanswered. Are there some guidelines
about adding new key types, curves, ciphers, etc. to GnuPG I should keep
to when making such changes?


> My current set of patches are as follows:
>
> * GOST cases in g10, sm, common and the agent:
> https://packages.altlinux.org/en/sisyphus/srpms/gnupg2/patches/gnupg2-2.2.10-gost-1.0.0.patch
> * workaround for multi-URL CRLs in dirmngr:
> https://packages.altlinux.org/en/sisyphus/srpms/gnupg2/patches/gnupg2-2.2.10-issuers-1.0.0.patch
> * GOST VKO algorithm in Libgcrypt:
> https://packages.altlinux.org/en/sisyphus/srpms/libgcrypt/patches/libgcrypt-1.8.3-vko-1.0.0.patch
> * GOST ASN.1 in Libksba:
> https://packages.altlinux.org/en/sisyphus/srpms/libksba/patches/libksba-1.3.6-gost-1.0.0.patch

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 10/04/2019 19:56, Paul Wolneykien wrote:
> Hi again. My question is still unanswered. Are there some guidelines
> about adding new key types, curves, ciphers, etc. to GnuPG I should keep
> to when making such changes?

Well, all I can do is point you to this year-old message on gnupg-users:

<https://lists.gnupg.org/pipermail/gnupg-users/2018-February/060044.html>

I think the guideline is that it should be in a proposed new OpenPGP
standard first, but I'm not a developer.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

Hi!

On Wed, 10 Apr 2019 20:56, manowar@altlinux.org said:

> Hi again. My question is still unanswered. Are there some guidelines
> about adding new key types, curves, ciphers, etc. to GnuPG I should keep
> to when making such changes?

Aside from doc/HACKING there are no fixed rules. However adding new
algorithms etc requires that they are part of the implemented standard
and further we need to see whether it makese sense to implement and
_maintain_ them.

>> My current set of patches are as follows:

I briefly looked at your patches but concluded that this is a log of new
code for just another algorithm. Thus your patches requires a closer
look. Right now I do not have the time for this and unless there is a
reason to tag it at high priority, I doubt that I can look at it in the
next weeks.

A reason for this might be that we can foster deployment of OpenPGP in
certain domains. However, if it turns out that GOST as been weakened on
purpose, there is no chance that it can part of _gpg_ (ie. to OpenPGP).


Shalom-Salam,

Werner