From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 5 Dec 2018 10:42:14 +0300 From: Vitaly Chikunov To: Open-source aspects of GOST Cryptography Message-ID: <20181205074214.ngzjimityihawzlq@sole.flsd.net> References: <20181204065445.gcaguhhvh7z6gajf@sole.flsd.net> <87bm60qvdi.fsf@asia.home.dd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87bm60qvdi.fsf@asia.home.dd> User-Agent: NeoMutt/20171215-106-ac61c7 Subject: Re: [oss-gost-crypto] EC-RDSA and a key substitution attack X-BeenThere: oss-gost-crypto@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Open-source aspects of GOST Cryptography List-Id: Open-source aspects of GOST Cryptography List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 07:42:15 -0000 Archived-At: List-Archive: Дмитрий, Большое спасибо за подробную информацию! Виталий, On Wed, Dec 05, 2018 at 10:35:05AM +0300, Дмитрий Державин wrote: > Вт, 04 дек 2018, 09:54, Vitaly Chikunov: > > > NOTE 5 The mechanisms of EC-DSA, EC-GDSA. EC-RDSA and EC-FSDSA may be > > vulnerable to a key substitution attack[10]. […] > > > > Где EC-RDSA это ГОСТ Р 34.10-2001 (а значит и 34.10-2012). > > > > На сколько эта атака актуальна для ГОСТа или это очередной наговор на > > российскую криптографию в стиле Н. Куртуа? > > Вопрос неоднократно обсуждался. Например, по-моему, тут: > https://events.yandex.ru/lib/talks/2970/ > > > Добавить signing key к message не сложно, но я исхожу из того, что > > этого делать не надо, так как в ГОСТе такого нет. Но если бы был > > рекомендованный метод формирования подписи с учетом этой атаки, то > > другое дело. > > В общем, это, видимо, и есть рекомендованный метод. Спросил у Смышляева, > вот что он ответил: > > «Да, это известное свойство схем на основе конструкции Эль-Гамаля, в > т.ч. нашего ГОСТ Р 34.10. > > В российской литературе иногда встречается как "атака Грунтовича". > http://itsec.ru/articles2/crypto/sertifitsirovannye-skzi-chto-nuzhno-znat--chtoby-pravilno-ih-vybrat > > Фактически при использовании на практике ландшафт для проведения атаки > создать не удастся по следующим причинам: > > 1) Сертифицированные СКЗИ не дают возможности через API фиксировать > значение закрытого ключа, он создается только с помощью встроенных > ДСЧ. Хотя, конечно, под отладчиком нарушитель вполне может это обойти. > > 2) Электронная подпись имеет смысл в документообороте только как ЭП, > формируемая на ключах, на открытые компоненты которых выданы > сертификаты в УЦ (аккредитованном в случае квалифицированной ЭП или УЦ > с внутренним регламентом в случае, например, внутренней подписи в > банке). А УЦ как правило работают по схеме, предполагающей генерацию > ключа на АРМе на территории самого УЦ. > > 3) На практике в документообороте ЭП применяется не абы как, а в > форматах CAdES, PAdES и пр. - расширенных форматах, предоставляющих > информацию о сертификатах. > > 4) Массово распространяемая сейчас облачная подпись (см. КриптоПро DSS > или SafeTech myDSS) - средство, которое гарантировано устраняет эту > проблему, так как ключи генерятся в HSM и не извлекаются из него. > > Конечно, при всем при этом сама реализация примитива остается как бы > без мер защиты против такого рода атак. Но и применяют ее не в чистом > виде, а в системах. Собственно, защита против подобных атак на систему > и является одним из вопросов, рассматриваемых в процессе сертификации > СКЗИ (с прикладными компонентами) и контроля встраивания в ФСБ России. > > Защищаться от этого на нижнем уровне, вводя некий самописный формат > (при том, что и так есть упомянутые выше CAdES и прочие, защищающие от > такой атаки и подобных ей) полагаю малоосмысленным.» > > От себя добавлю, что вариант «2» с генерацией ключа в УЦ выглядит, > по-моему, просто ужасно. В отличие от «3». Кстати, CADES мы умеем > генерировать. Ну почти умеем. ;) > > -- > Дмитрий Державин, > BaseALT/Базальт СПО > _______________________________________________ > oss-gost-crypto mailing list > oss-gost-crypto@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto