<div dir="ltr">Сейчас нет никакого резона поддерживать ГОСТ 2001. <div><br></div><div>1. Нет его более ранних имплементаций (т.е. вопрос обратной совместимости не актуален)</div><div>2. На хеш ГОСТ Р 34.11-94, с которым он используется, есть атаки.</div><div>3. ГОСТ 2012 в 256-битном варианте с параметрами от КриптоПро - это тот же ГОСТ 2001, но с другим хешом</div><div>4. ГОСТ 2001 перестаёт поддерживаться с конца этого года.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2019 at 11:29 PM <<a href="mailto:manowar@altlinux.org">manowar@altlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Кажется, дело сдвинулось чуть вперёд --- руководитель проекта GnuPG согласился посмотреть патчи, правда неопределённо когда.<br>
<br>
Мне не совсем ясно, что он имеет в виду под словом "domains" в последнем абзаце. Это намёк на интерес расширить сферу (и географию) применения GnuPG или мне показалось?<br>
<br>
И ещё вопрос: можно ли говорить о ГОСТ 2001 как о, допустим, RSA 128 бит (или сколько там было вначале)? В том смысле, что даже устаревший и потенциально ненадёжный стандарт нужно поддерживать исходя из соображений обратной совместимости. Ну и ещё потому, что это закладывает кодовую (алгоритмическую) базу для более поздних стандартов, которые являются его развитием. <br>
<br>
Ссылка на письмо ниже: <a href="https://lists.gnupg.org/pipermail/gnupg-devel/2019-April/034293.html" rel="noreferrer" target="_blank">https://lists.gnupg.org/pipermail/gnupg-devel/2019-April/034293.html</a> .<br>
<br>
--- Исходное сообщение ---<br>
> Hi!<br>
> <br>
> On Wed, 10 Apr 2019 20:56, <a href="mailto:manowar@altlinux.org" target="_blank">manowar@altlinux.org</a> said:<br>
> <br>
> > Hi again. My question is still unanswered. Are there some guidelines<br>
> > about adding new key types, curves, ciphers, etc. to GnuPG I should keep<br>
> > to when making such changes?<br>
> <br>
> Aside from doc/HACKING there are no fixed rules. However adding new<br>
> algorithms etc requires that they are part of the implemented standard<br>
> and further we need to see whether it makese sense to implement and<br>
> _maintain_ them.<br>
> <br>
> >> My current set of patches are as follows:<br>
> <br>
> I briefly looked at your patches but concluded that this is a log of new<br>
> code for just another algorithm. Thus your patches requires a closer<br>
> look. Right now I do not have the time for this and unless there is a<br>
> reason to tag it at high priority, I doubt that I can look at it in the<br>
> next weeks.<br>
> <br>
> A reason for this might be that we can foster deployment of OpenPGP in<br>
> certain domains. However, if it turns out that GOST as been weakened on<br>
> purpose, there is no chance that it can part of _gpg_ (ie. to OpenPGP).<br>
> <br>
> <br>
> Shalom-Salam,<br>
> <br>
> Werner<br>
><br>
_______________________________________________<br>
oss-gost-crypto mailing list<br>
<a href="mailto:oss-gost-crypto@lists.altlinux.org" target="_blank">oss-gost-crypto@lists.altlinux.org</a><br>
<a href="https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto" rel="noreferrer" target="_blank">https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div>