From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: oss-gost-crypto@lists.altlinux.org References: <156149303063.31229.16267280637983942071.idtracker@ietfa.amsl.com> From: Paul Wolneykien Organization: ALT Linux Team Message-ID: <62c0725c-ff6c-cafd-437f-d61584e6d286@altlinux.org> Date: Tue, 9 Jul 2019 04:04:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: ru Content-Transfer-Encoding: 8bit Subject: Re: [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt 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: Tue, 09 Jul 2019 01:05:00 -0000 Archived-At: List-Archive: 26.06.2019 01:10, Dmitry Eremin-Solenikov пишет: > Коллеги, > > Еще IETF draft на вычитку. Есть, однако, замечание. Так, в этом документе несколько раз встречается H = HASH (r_c | r_s); Полученное значение (или его часть) потом используется в качестве UKM при вычислении ключа обмена. Спрашивается, если оно может быть вычислено как клиентом, так и сервером независимо и однозначно, то для чего тогда его передавать в явном виде в рамках структуры GostKeyTransport и GostKeyTransportBlob? Правда в первой, более новой, поле ukm помечено как OPTIONAL, но всё же для чего оно там вообще? А негодую я так потому, что из-за этой избыточности, уже есть расхождение в реализациях. Так, TLS соединение с КриптоПро не будет работать, если клиент выбрал UKM != HASH (r_c | r_s), а с OpenSSL будет! Потому что OpenSSL просто использует готовое значение key_agreement_info->eph_iv вместо того, чтобы самостоятельно вычислить UKM как HASH (r_c | r_s). > ---------- Forwarded message --------- > От: > Date: вт, 25 июн. 2019 г. в 23:03 > Subject: New Version Notification for draft-dolmatov-magma-00.txt > > > > A new version of I-D, draft-dolmatov-magma-00.txt > has been successfully submitted by Vasily Dolmatov and posted to the > IETF repository. > > Name: draft-dolmatov-magma > Revision: 00 > Title: GOST R 34.12-2015: Block Cipher "Magma" > Document date: 2019-06-25 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-dolmatov-magma-00.txt > Status: https://datatracker.ietf.org/doc/draft-dolmatov-magma/ > Htmlized: https://tools.ietf.org/html/draft-dolmatov-magma-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-dolmatov-magma > > > Abstract: > This document is intended to be a source of information about updated > version of the block cipher with block length of n=64 bits and key > length k=256 bits (RFC5830), which is also referred as "Magma" and is > described in the Russian Federal standard GOST R 34.12-2015, > containing also the description of block cipher "Kuznechik" > (RFC7801)/>. These algorithms are from the set of Russian > cryptographic standard algorithms (called GOST algorithms). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > >