Open-source aspects of GOST Cryptography
 help / color / mirror / Atom feed
* [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt
  @ 2019-06-25 22:10 ` Dmitry Eremin-Solenikov
  2019-07-09  1:04   ` Paul Wolneykien
  0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Eremin-Solenikov @ 2019-06-25 22:10 UTC (permalink / raw)
  To: Open-source aspects of GOST Cryptography

Коллеги,

Еще IETF draft на вычитку.

---------- Forwarded message ---------
От: <internet-drafts@ietf.org>
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



-- 
With best wishes
Dmitry


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt
  2019-06-25 22:10 ` [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt Dmitry Eremin-Solenikov
@ 2019-07-09  1:04   ` Paul Wolneykien
  2019-07-09  1:10     ` Paul Wolneykien
    0 siblings, 2 replies; 6+ messages in thread
From: Paul Wolneykien @ 2019-07-09  1:04 UTC (permalink / raw)
  To: oss-gost-crypto

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 ---------
> От: <internet-drafts@ietf.org>
> 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
> 
> 
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt
  2019-07-09  1:04   ` Paul Wolneykien
@ 2019-07-09  1:10     ` Paul Wolneykien
    1 sibling, 0 replies; 6+ messages in thread
From: Paul Wolneykien @ 2019-07-09  1:10 UTC (permalink / raw)
  To: oss-gost-crypto

09.07.2019 04:04, Paul Wolneykien пишет:
> 26.06.2019 01:10, Dmitry Eremin-Solenikov пишет:
>> Коллеги,
>>
>> Еще IETF draft на вычитку.
> 
>   Есть, однако, замечание. Так, в этом документе

  Так, не в этом документе. Я просто заметил, что в
https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites недавно
появилась новая версия [05] и подумал, что здесь тоже про него было.

> несколько раз встречается
> 
> 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 ---------
>> От: <internet-drafts@ietf.org>
>> 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
>>
>>
>>
> 
> _______________________________________________
> oss-gost-crypto mailing list
> oss-gost-crypto@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt
  @ 2019-07-09 10:00       ` manowar
    0 siblings, 1 reply; 6+ messages in thread
From: manowar @ 2019-07-09 10:00 UTC (permalink / raw)
  To: oss-gost-crypto

Вторник, 9 июля 2019 г получено от Dmitry Belyavsky:
> Привет
> 
> Это скорее всего живущая у меня с незапамятных времён ошибка.

Это понятно. Но если бы ukm вообще не передавался, то и ошибки бы не было. Вот и вопрос, зачем в RFC так сделано.

 
> On Tue, Jul 9, 2019 at 4:05 AM Paul Wolneykien <manowar@altlinux.org> wrote:
> 
> > 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 ---------
> > > От: <internet-drafts@ietf.org>
> > > 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
> > >
> > >
> > >
> >
> > _______________________________________________
> > oss-gost-crypto mailing list
> > oss-gost-crypto@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
> >
> 
> 
> -- 
> SY, Dmitry Belyavsky
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt
  @ 2019-07-09 11:08           ` manowar
    0 siblings, 1 reply; 6+ messages in thread
From: manowar @ 2019-07-09 11:08 UTC (permalink / raw)
  To: oss-gost-crypto

Вторник, 9 июля 2019 г получено от Dmitry Belyavsky:
> Для защиты от чего-нибудь. Глпого прокси.

Дык, если ты сам посчитаешь UKM и он окажется другим, то у тебя просто KEK не сойдётся и всё. Насколько я понимаю. 

 
> On Tue, Jul 9, 2019 at 1:00 PM <manowar@altlinux.org> wrote:
> 
> > Вторник, 9 июля 2019 г получено от Dmitry Belyavsky:
> > > Привет
> > >
> > > Это скорее всего живущая у меня с незапамятных времён ошибка.
> >
> > Это понятно. Но если бы ukm вообще не передавался, то и ошибки бы не было.
> > Вот и вопрос, зачем в RFC так сделано.
> >
> >
> > > On Tue, Jul 9, 2019 at 4:05 AM Paul Wolneykien <manowar@altlinux.org>
> > wrote:
> > >
> > > > 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 ---------
> > > > > От: <internet-drafts@ietf.org>
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > oss-gost-crypto mailing list
> > > > oss-gost-crypto@lists.altlinux.org
> > > > https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
> > > >
> > >
> > >
> > > --
> > > SY, Dmitry Belyavsky
> > >
> > _______________________________________________
> > oss-gost-crypto mailing list
> > oss-gost-crypto@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
> >
> 
> 
> -- 
> SY, Dmitry Belyavsky
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt
  @ 2019-07-09 12:03               ` Paul Wolneykien
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Wolneykien @ 2019-07-09 12:03 UTC (permalink / raw)
  To: oss-gost-crypto

09.07.2019 14:23, Dmitry Belyavsky пишет:
> Если у тебя с той стороны клиент, не соблюдающий стандарт, и ты поверишь
> его UKM,

  Так я ж вроде об этом и пишу: что "поверить" UKM можно только, если
этот UKM положено передавать в явном виде, как сейчас. А если его не
передавать, то и верить будет не чему — придётся вычислять самому. И тут
уж если клиент действовал не по стандарту, то ключи шифрования будут
отличаться у вас — и ничего не заработает.

> то у тебя всё заработает.

  Вот сейчас именно так и есть в OpenSSL.

> А не должно.
> 
> On Tue, Jul 9, 2019 at 2:08 PM <manowar@altlinux.org
> <mailto:manowar@altlinux.org>> wrote:
> 
>     Вторник, 9 июля 2019 г получено от Dmitry Belyavsky:
>     > Для защиты от чего-нибудь. Глпого прокси.
> 
>     Дык, если ты сам посчитаешь UKM и он окажется другим, то у тебя
>     просто KEK не сойдётся и всё. Насколько я понимаю.
> 
> 
>     > On Tue, Jul 9, 2019 at 1:00 PM <manowar@altlinux.org
>     <mailto:manowar@altlinux.org>> wrote:
>     >
>     > > Вторник, 9 июля 2019 г получено от Dmitry Belyavsky:
>     > > > Привет
>     > > >
>     > > > Это скорее всего живущая у меня с незапамятных времён ошибка.
>     > >
>     > > Это понятно. Но если бы ukm вообще не передавался, то и ошибки
>     бы не было.
>     > > Вот и вопрос, зачем в RFC так сделано.
>     > >
>     > >
>     > > > On Tue, Jul 9, 2019 at 4:05 AM Paul Wolneykien
>     <manowar@altlinux.org <mailto:manowar@altlinux.org>>
>     > > wrote:
>     > > >
>     > > > > 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 ---------
>     > > > > > От: <internet-drafts@ietf.org
>     <mailto:internet-drafts@ietf.org>>
>     > > > > > 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 <http://tools.ietf.org>.
>     > > > > >
>     > > > > > The IETF Secretariat
>     > > > > >
>     > > > > >
>     > > > > >
>     > > > >
>     > > > > _______________________________________________
>     > > > > oss-gost-crypto mailing list
>     > > > > oss-gost-crypto@lists.altlinux.org
>     <mailto:oss-gost-crypto@lists.altlinux.org>
>     > > > > https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
>     > > > >
>     > > >
>     > > >
>     > > > --
>     > > > SY, Dmitry Belyavsky
>     > > >
>     > > _______________________________________________
>     > > oss-gost-crypto mailing list
>     > > oss-gost-crypto@lists.altlinux.org
>     <mailto:oss-gost-crypto@lists.altlinux.org>
>     > > https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
>     > >
>     >
>     >
>     > --
>     > SY, Dmitry Belyavsky
>     >
>     _______________________________________________
>     oss-gost-crypto mailing list
>     oss-gost-crypto@lists.altlinux.org
>     <mailto:oss-gost-crypto@lists.altlinux.org>
>     https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
> 
> 
> 
> -- 
> SY, Dmitry Belyavsky
> 
> 
> _______________________________________________
> oss-gost-crypto mailing list
> oss-gost-crypto@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-07-09 12:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-25 22:10 ` [oss-gost-crypto] Fwd: New Version Notification for draft-dolmatov-magma-00.txt Dmitry Eremin-Solenikov
2019-07-09  1:04   ` Paul Wolneykien
2019-07-09  1:10     ` Paul Wolneykien
2019-07-09 10:00       ` manowar
2019-07-09 11:08           ` manowar
2019-07-09 12:03               ` Paul Wolneykien

Open-source aspects of GOST Cryptography

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/oss-gost-crypto/0 oss-gost-crypto/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 oss-gost-crypto oss-gost-crypto/ http://lore.altlinux.org/oss-gost-crypto \
		oss-gost-crypto@lists.altlinux.org oss-gost-crypto@lists.altlinux.ru oss-gost-crypto@lists.altlinux.com
	public-inbox-index oss-gost-crypto

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.oss-gost-crypto


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git