Hi Stanislav,
I can provide an expertise on using PAKEs in IKEv2 for all =
candidates.
Regards,
Valery Smyslov.
From:=
Stanislav =
V. Smyshlyaev [mailto:smyshsv@gmail.com]
Sent: Thursday, =
August 01, 2019 10:10 AM
To: CFRG
Cc: =
cfrg-chairs@ietf.org; Christopher Wood; kivinen@iki.fi; Valery Smyslov; =
Salz, Rich
Subject: Call for independent experts (TLS, IPsec, =
IoT, privacy) for Stage 4 of the PAKE selection =
process
Dear =
CFRG,
According to the plan of the PAKE selection process, the =
chairs have selected a number of PAKE-related topics that require =
independent reviews from experts deeply involved in several particular =
areas of IETF work: TLS and IPsec protocols, constrained environments =
and privacy.
The chairs would like to announce the call for =
reviewers, who will be asked to prepare their reviews regarding one or =
more of the following topics about the nominated PAKEs:
- Convenience =
for usage within/together with TLS 1.3 Handshake.
- Convenience for =
usage within/together with IKEv2.
- Convenience for usage in M2M/IoT =
protocols (i.e., with corresponding constrains on hardware).
- =
Privacy considerations (e.g., recommendations to prevent user =
enumeration).
The experts who would like to volunteer to do such =
a review are kindly asked to choose:
1) which topics from the =
provided list will be considered by them;
2) whether they could =
prepare their reviews for
- all four balanced PAKEs,
- all =
four augmented PAKEs or
- all eight candidate PAKEs.
We ask =
each of the expert to prepare reviews for all PAKEs (or at least all =
balanced/all augmented ones) to be sure that each of the PAKEs will be =
studied from the same points of view.
The call for reviewers =
will last until the 15th of August.
Deadline for the reviews is =
15th of September.
The reviews will later be provided to Crypto =
Review Panel experts, who will prepare their overall reviews during =
Stage 5.
Best regards,
Stanislav Smyshlyaev,
CFRG Secretary
= Dear CFRG,
According to the plan of the PAKE selection process, the = chairs have selected a number of PAKE-related topics that require independe= nt reviews from experts deeply involved in several particular areas of IETF= work: TLS and IPsec protocols, constrained environments and privacy.=C2=A0=
The chairs would like to announce the call for reviewers, who will = be asked to prepare their reviews regarding one or more of the following to= pics about the nominated PAKEs:
- Convenience for usage within/together = with TLS 1.3 Handshake.
- Convenience for usage within/together with IKE= v2.
- Convenience for usage in M2M/IoT protocols (i.e., with correspondi= ng constrains on=C2=A0hardware).
- Privacy considerations (e.g., recomme= ndations to prevent user enumeration).
The experts who would like to= volunteer to do such a review are kindly asked to choose:
1) which topi= cs from the provided list will be considered by them;
2) whether they co= uld prepare their reviews for=C2=A0
- all four balanced PAKEs,
- all = four augmented PAKEs or
- all eight candidate PAKEs.
We ask each = of the expert to prepare reviews for all PAKEs (or at least all balanced/al= l augmented ones) to be sure that each of the PAKEs will be studied from th= e same points of view.
The call for reviewers will last until the= 15th of August.
Deadline for the reviews is 15th of September.
<= br>The reviews will later be provided to Crypto Review Panel experts, who w= ill prepare their overall reviews during Stage 5.Best r= egards,Stanislav Smyshlyaev,CFRG Secretary
Dear CFRG members,
=I would like to follow up on the short talk I gav= e several days ago. That talk was itself a follow-up to a previous e-mail [= 0] which presented a strange structure I found in pi, a component (S-box) w= hich is shared by both Streebog (RFC 6986) and Kuznyechik (RFC 7801).At the time of writing this previous e-mail, I did not know that t= he designers of these algorithms were still claiming that they had generate= d their S-box randomly. However, they do! Here are links to relevant ISO do= cuments that were leaked:- https://cdn.virgilsecurity.com= /assets/docs/memo-on-kuznyechik-s-box.pdfAs we can see in the first one,= the designers of pi did claim that they obtained this component by generat= ing many random S-boxes and then choosing the best according to some (fair = and usual) criteria. In fact, as we can see in the second, they insisted th= at they used this method even *after* the publication of my latest results = [1].That is hardly possible. Let us see why.
<= /div>There are 2^{L+1}-1 bitstrings of length at most L. Thus, the tot= al number of permutations with an implementation fitting in at most L bits = in a given language (e.g. in C) is upper bounded by 2^{L+1}. The shortest i= mplementation of pi in C we are aware of was found by ceilingcat [2] who im= proved a previous implementation by Xavier Bonnetain. That implementation i= s 139 ASCII characters long, i.e. 973 bits long. Thus, there are fewer than= 2^{974} permutations with an implementation this simple. As there are 256!= =3D 2^{1684} permutations operating on 8 bits, we easily conclude that the= probability that a random permutation has a C implementation at most 973 b= its long is smaller than 2^{974-1684} =3D 2^{-710}, which is beyond negligi= ble. If we look at languages more compact than C (see [2]) then we can dedu= ce even lower probabilities. In other words, the set of the permutations as= simple as pi for a very broad definition of simplicity is extremely small,= and thus the probability that we fall into it by chance is negligible. Mor= e detailed explanations are available at [3].= In light of this argument, only two possibilities are left:1= . the designers of pi really used a random process to generate their S-box,= they were just lucky enough to find one of the very (very very very) few p= ermutations with a short implementation, or2. they used a TK= log deliberately but decided to hide it, the TKlog being the structure I id= entified in [1].The probability that the first one is true c= an be upper bounded using the discussion above: it is at most 2^{-710}. For= comparison, there are about 10^80 =3D 2^266 atoms in the universe. The onl= y reasonable conclusion is then that we are in the second case: the use of = the TKlog is a deliberate choice by its designers. Note that this reasoning= is based purely on the simplicity of the TKlog structure. It does not take= into account its very peculiar interactions with the finite field, nor doe= s it consider the fact that=C2=A0 the finite field used to define it is the= same as the one used in the linear layer of Streebog. It is also unlikely = that the differential and linear properties of pi can be encountered in a f= easibly large set of random S-boxes [4].Becau= se of these observations, I insist that the designers of these algorithms h= ave provided cryptanalysts with misleading information. There cannot be any= good reason for this, which is why I think these algorithms cannot be trus= ted, and thus that RFC 6986 and 7801 should be deprecated.Cheers,/L=C3=A9o
<= /div>PS: Remember that the golfed implementations listed in [2] are on= ly intended to be small. They are *not* intended to be secure! Their runnin= g time in CPU cycles is directly proportionnal to the discrete logarithm of= their input, meaning that they are the opposite of constant time. An imple= mentation using them would be trivially vulnerable to some side channel att= acks.
[2] <= span class=3D"gmail-m_1835156983088108477Object" id=3D"gmail-m_183515698308= 8108477OBJ_PREFIX_DWT417_com_zimbra_url">https://codegolf.stackexchange.com/que= stions/186498/proving-that-a-russian-cryptographic-standard-is-too-structur= ed
Dear=C2=A0Le= o, dear CFRG members,Many thanks for = your efforts in analysis of Russian GOST crypto algorithms.=C2=A0I am not a cryptographer myself, but one of the implementors o= f Russian cryptography.On Mon, Aug 5, 2019 at 6:35 PM Leo Perrin <leo.perrin@inria.fr<= /a>> wrote:<= div>Dear CFRG members,I = would like to follow up on the short talk I gave several days ago. That tal= k was itself a follow-up to a previous e-mail [0] which presented a strange= structure I found in pi, a component (S-box) which is shared by both Stree= bog (RFC 6986) and Kuznyechik (RFC 7801).At the time of writ= ing this previous e-mail, I did not know that the designers of these algori= thms were still claiming that they had generated their S-box randomly. Howe= ver, they do! Here are links to relevant ISO documents that were leaked:As we can see in the = first one, the designers of pi did claim that they obtained this component = by generating many random S-boxes and then choosing the best according to s= ome (fair and usual) criteria. In fact, as we can see in the second, they i= nsisted that they used this method even *after* the publication of my lates= t results [1].That is hardly possible. Let us see why.=There are 2^{L+1}-1 bitstrings of length at most L. Thu= s, the total number of permutations with an implementation fitting in at mo= st L bits in a given language (e.g. in C) is upper bounded by 2^{L+1}. The = shortest implementation of pi in C we are aware of was found by ceilingcat = [2] who improved a previous implementation by Xavier Bonnetain. That implem= entation is 139 ASCII characters long, i.e. 973 bits long. Thus, there are = fewer than 2^{974} permutations with an implementation this simple. As ther= e are 256! =3D 2^{1684} permutations operating on 8 bits, we easily conclud= e that the probability that a random permutation has a C implementation at = most 973 bits long is smaller than 2^{974-1684} =3D 2^{-710}, which is beyo= nd negligible. If we look at languages more compact than C (see [2]) then w= e can deduce even lower probabilities. In other words, the set of the permu= tations as simple as pi for a very broad definition of simplicity is extrem= ely small, and thus the probability that we fall into it by chance is negli= gible. More detailed explanations are available at [3].
<= /div>In light of this argument, only two possibilities are left:1.. the designers of pi really used a random process to generate t= heir S-box, they were just lucky enough to find one of the very (very very = very) few permutations with a short implementation, or2. the= y used a TKlog deliberately but decided to hide it, the TKlog being the str= ucture I identified in [1].The probability that the first on= e is true can be upper bounded using the discussion above: it is at most 2^= {-710}. For comparison, there are about 10^80 =3D 2^266 atoms in the univer= se. The only reasonable conclusion is then that we are in the second case: = the use of the TKlog is a deliberate choice by its designers. Note that thi= s reasoning is based purely on the simplicity of the TKlog structure. It do= es not take into account its very peculiar interactions with the finite fie= ld, nor does it consider the fact that=C2=A0 the finite field used to defin= e it is the same as the one used in the linear layer of Streebog. It is als= o unlikely that the differential and linear properties of pi can be encount= ered in a feasibly large set of random S-boxes [4].Because of these observations, I insist that the designers of these a= lgorithms have provided cryptanalysts with misleading information. There ca= nnot be any good reason for this, which is why I think these algorithms can= not be trusted, and thus that RFC 6986 and 7801 should be deprecated.Cheers,/L=C3=A9oPS: Remember that the golfed implementations listed in= [2] are only intended to be small. They are *not* intended to be secure! T= heir running time in CPU cycles is directly proportionnal to the discrete l= ogarithm of their input, meaning that they are the opposite of constant tim= e. An implementation using them would be trivially vulnerable to some side = channel attacks.You say that you have arguments that the designers may have said controve= rsial declarations about some details of the construction in the ISO, but t= his doesn=E2=80=99t seem to correspond to attack.=C2=A0 __________= _____________________________________Could you please clarify how does the existence of a compact code for= generation of the S-box imply a possibility of attack?
Currently, I= don't see even a performance optimization as a consequence of the comp= act representation of the S-box.
The most widespread open-source implem= entation (https://github.com/gost-engine/engine/tree/openssl_1_= 1_0)=C2=A0of Streebog and Kuznyechik does not use the Pi tra= nsformations as a separate step =E2=80=94 they use a combined process.
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
Hiya,
On 06/08/2019 14:14, Stanislav V. Smyshlyaev wrote:
> Stephen, GOST R 34.11-94 is built using a completely different
> construction, so (Leo will correct me, if I am mistaken) the discovere= d
> properties are not related to GOST R 34.11-94. I=E2=80=99d also like t= o clarify
> that this GOST R 34.11-94 is an old hash function, which has been
> deprecated for about 7 years in Russia.
So that sounds like an erratum may be worthwhile
for each of 8624 and 7901? I guess the code points
defined for DNSSEC are really for the old algorithms
and ought not point to the RFCs for the new ones?
Those'd be valid errata I reckon, as it was a bit
of a mistake (though entirely understandable) to
refer to the new RFCs when the code points are for
the old algorithms. Those errata would just say
that the normative references to the new RFC were
wrong and should've been to the old RFC. And that
hasn't really got anything to do with the meat of
Leo's findings - it's just that his work flagged
up the erroneous references.
As to whether to deprecate the algorithms due to
Leo's findings, I agree that the existence of
deployments that'd be affected needs to be taken
into account in terms of the timing of when that
might reasonably be done. And the fact that the
algorithms in question are national standards is
also a relevant point, though of course deprecating
the RFCs has no formal effect on such national
standards.
Personally though, I think discovery of undeclared
and unexplained structure such as this in a crypto
algorithm ought be taken as a negative, even if there
is no known attack at present, so I'd be for moving
to deprecate when that is practical, in this case,
as I would in any other similar case.
Cheers,
S.
Dear Stephen,= >> So that sounds like an erratum may be worthwhile for each of 8624 = and 7901? I guess the code points defined for DNSSEC are really for the old= algorithms and ought not point to the RFCs for the new ones?=C2=A0>> And that hasn't really got anything to do with the meat of = Leo's findings - it's just that his work flagged up the erroneous r= eferences. Personally, I agree that it would be good to do the up= dates here. But, as for DNSSEC, I hope that the authors of RFC 5933 (or, ma= ybe, Dmitry Belyavsky) can comment better.=D0=B2=D1=82, 6 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 16:33, Stephen F= arrell <s= tephen.farrell@cs.tcd.ie>:
Hiya,
On 06/08/2019 14:14, Stanislav V. Smyshlyaev wrote:
> Stephen, GOST R 34.11-94 is built using a completely different
> construction, so (Leo will correct me, if I am mistaken) the discovere= d
> properties are not related to GOST R 34.11-94. I=E2=80=99d also like t= o clarify
> that this GOST R 34.11-94 is an old hash function, which has been
> deprecated for about 7 years in Russia.
So that sounds like an erratum may be worthwhile
for each of 8624 and 7901? I guess the code points
defined for DNSSEC are really for the old algorithms
and ought not point to the RFCs for the new ones?
Those'd be valid errata I reckon, as it was a bit
of a mistake (though entirely understandable) to
refer to the new RFCs when the code points are for
the old algorithms. Those errata would just say
that the normative references to the new RFC were
wrong and should've been to the old RFC. And that
hasn't really got anything to do with the meat of
Leo's findings - it's just that his work flagged
up the erroneous references.
As to whether to deprecate the algorithms due to
Leo's findings, I agree that the existence of
deployments that'd be affected needs to be taken
into account in terms of the timing of when that
might reasonably be done. And the fact that the
algorithms in question are national standards is
also a relevant point, though of course deprecating
the RFCs has no formal effect on such national
standards.
Personally though, I think discovery of undeclared
and unexplained structure such as this in a crypto
algorithm ought be taken as a negative, even if there
is no known attack at present, so I'd be for moving
to deprecate when that is practical, in this case,
as I would in any other similar case.
Cheers,
S.
Hiya,
On 06/08/2019 15:09, Dmitry Belyavsky wrote:
> Dear Stephen,
>
> RFC 7091 seems to be a translation of the corresponding GOST standard.=
>
> RFC 8624 contains a reference to RFC5933, where the GOST algorithms fo= r
> DNSSec were introduced.
> The reference is correct, the reference to the superseding algorithms = is
> correct too.
I'm not getting it. Why does 8624 need a normative
reference to 6986 and an informative reference to
5933 when the code points refer to the algorithms
defined in 5933?
S.
>
> So it seems that no errata required here.
>
>
> On Tue, Aug 6, 2019 at 4:56 PM Stanislav V. Smyshlyaev <smyshsv@gmail.com>
> wrote:
>
>> Dear Stephen,
>>
>>>> So that sounds like an erratum may be worthwhile for each = of 8624 and
>> 7901? I guess the code points defined for DNSSEC are really for th= e old
>> algorithms and ought not point to the RFCs for the new ones?
>>>> And that hasn't really got anything to do with the mea= t of Leo's
>> findings - it's just that his work flagged up the erroneous re= ferences.
>> Personally, I agree that it would be good to do the updates here. = But, as
>> for DNSSEC, I hope that the authors of RFC 5933 (or, maybe, Dmitry=
>> Belyavsky) can comment better.
>>
>>
>>
>> =D0=B2=D1=82, 6 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 16:33, Ste= phen Farrell <stephen.farrell@cs.tcd.ie>:
>>
>>>
>>> Hiya,
>>>
>>> On 06/08/2019 14:14, Stanislav V. Smyshlyaev wrote:
>>>> Stephen, GOST R 34.11-94 is built using a completely diffe= rent
>>>> construction, so (Leo will correct me, if I am mistaken) t= he discovered
>>>> properties are not related to GOST R 34.11-94. I=E2=80=99d= also like to clarify
>>>> that this GOST R 34.11-94 is an old hash function, which h= as been
>>>> deprecated for about 7 years in Russia.
>>>
>>> So that sounds like an erratum may be worthwhile
>>> for each of 8624 and 7901? I guess the code points
>>> defined for DNSSEC are really for the old algorithms
>>> and ought not point to the RFCs for the new ones?
>>> Those'd be valid errata I reckon, as it was a bit
>>> of a mistake (though entirely understandable) to
>>> refer to the new RFCs when the code points are for
>>> the old algorithms. Those errata would just say
>>> that the normative references to the new RFC were
>>> wrong and should've been to the old RFC. And that
>>> hasn't really got anything to do with the meat of
>>> Leo's findings - it's just that his work flagged
>>> up the erroneous references.
>>>
>>> As to whether to deprecate the algorithms due to
>>> Leo's findings, I agree that the existence of
>>> deployments that'd be affected needs to be taken
>>> into account in terms of the timing of when that
>>> might reasonably be done. And the fact that the
>>> algorithms in question are national standards is
>>> also a relevant point, though of course deprecating
>>> the RFCs has no formal effect on such national
>>> standards.
>>>
>>> Personally though, I think discovery of undeclared
>>> and unexplained structure such as this in a crypto
>>> algorithm ought be taken as a negative, even if there
>>> is no known attack at present, so I'd be for moving
>>> to deprecate when that is practical, in this case,
>>> as I would in any other similar case.
>>>
>>> Cheers,
>>> S.
>>>
>>
>
Sorry, I must be confusing something...
On 06/08/2019 15:20, Dmitry Belyavsky wrote:
> In fact, the reference to 5933 is normative (in part of=C2=A0 DNSSec).=
I'm looking at 8624 now and the reference
to 6986 is in section 7.1 "normative references" [1]
whereas the reference to 5933 is in 7.2 which
are the informative references. [2]
An errata that just said to swap those would make
sense and seems to match what you say below.
Cheers,
S.
[1] https://tools.ietf.org/html/rfc8624#section-7.1
[2] https://tools.ietf.org/html/rfc8624#section-7.2
>
> Then we have reference to the superseding algorithms which personally = I
> tend to treat as informative.
> It explains why the GOST algorithms have the status MUST NOT for
> signing/delegation.
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
Hi all,=C2=A0Obviously not as a pra= ctical suggestion, but just to clarify my understanding of the issue at han= d, would creating a new S-box lookup table from a verifiably random source = completely ameliorate Leo's concerns?If the S-box was create= d with no pattern in mind, as stated, then any other randomly generated loo= kup table should be equally sound, and would be immensely unlikely to have = this curious structure.Say we used a distributed randomness beac= on to seed a permutation of the S-box, such that anyone can verify for them= selves that the S-box was generated randomly, would everyone be satisfied t= hat the new version was at least as secure as the old?=C2=A0
=Regards,JonathanOn Tue, 6 Aug 20= 19 at 15:24, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
Sorry, I must be confusing something...
On 06/08/2019 15:20, Dmitry Belyavsky wrote:
> In fact, the reference to 5933 is normative (in part of=C2=A0 DNSSec).=
I'm looking at 8624 now and the reference
to 6986 is in section 7.1 "normative references" [1]
whereas the reference to 5933 is in 7.2 which
are the informative references. [2]
An errata that just said to swap those would make
sense and seems to match what you say below.
Cheers,
S.
[1] https://tools.ietf.org/html/rfc8624#section-7.1
[2] https://tools.ietf.org/html/rfc8624#section-7.2
>
> Then we have reference to the superseding algorithms which personally = I
> tend to treat as informative.
> It explains why the GOST algorithms have the status MUST NOT for
> signing/delegation.
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
De= : "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
=C3=80: "Leo Perrin" <leo.perrin@inria.fr>, "Stephen Farrell" <stephen.fa= rrell@cs.tcd.ie>
Cc: "cfrg" <cfrg@irtf.org>, "Dmitry Bel= yavsky" <beldmit@gmail.com>
Envoy=C3=A9: Mardi 6 Ao=C3=BBt = 2019 15:14:43
Objet: Re: [Cfrg] On the (non-)randomness of the S-= box of Streebog and Kuznyechik
<= div dir=3D"ltr">Dear Stephen and Leo,
>> Does the structure yo= u've discovered also exist in GOST R 34.11-94?
Stephen, GOST R 34.11-94 = is built using a completely different construction, so (Leo will correct me= , if I am mistaken) the discovered properties are not related to GOST R 34.= 11-94. I=E2=80=99d also like to clarify that this GOST R 34.11-94 is an old= hash function, which has been deprecated for about 7 years in Russia.
<= br>>> In general I would support CFRG deprecating any algorithms for = which there is significant doubt. I have not myself verified that the struc= ture Leo has found is real=E2=80=A6
First of all, I=E2=80=99d like to ex= press my sincere appreciation to Leo for his deep study of Streebog/Kuznyec= hik S-Box properties. I am not a designer of those algorithms, but my compa= ny (software development: digital signature servers, VPN solutions etc.) us= es them in those software products which are intended for usage with govern= mental applications inside Russia (they must be used for such applications)= . Hence, I am definitely interested in having as much research of those alg= orithms as possible: they are obviously worth being studied.
Leo=E2=80= =99s results about structures of those S-Boxes are very interesting and imp= ortant for understanding the properties of the algorithms themselves and fo= r optimization of their implementations (which is interesting for all softw= are developers implementing them). I sincerely wish that Leo continues your= research =E2=80=93 Leo, please continue this study, you=E2=80=99re doing a= great work.
Leo has discovered a very interesting property of the S-Bo= xes, a very curious structure of representing them, but there is a certain = contrast between high level of the Leo=E2=80=99s scientific part of work an= d the lack of ground (so far, at least) for conclusions and accusations abo= ut possible vulnerabilities in the algorithms. At the CFRG session in Montr= eal there was a discussion on this issue, it is important to continue the r= esearch when some new properties are found in any crypto, but we can=E2=80= =99t =E2=80=9Cdeprecate=E2=80=9D something deployed (at least, there are ma= ny cases when they are used in Russian part of Internet) =E2=80=9Cjust in c= ase=E2=80=9D, just because there are some new properties found (without any= results of how they could lead to a vulnerability or to a backdoor, despit= e the fact that Leo has obviously been working on finding such for at least= one year).
If Leo had a result like Ferguson and Shumow in 2007 (https://rum= p2007.cr.yp.to/15-shumow.pdf, when they showed that the knowledge of ce= rtain parameter =E2=80=93 discrete logarithm in that case =E2=80=93 allows = to mount an attack on predicting Dual EC DRBG outputs with low complexity),= then, of course, it would be definitely a reason for significant doubts in= those algorithms (and, particularly, for an I-D about the found attacks) = =E2=80=93 in international and national organizations and technical committ= ees. But, as Leo stresses himself, he does not have any (even preliminary) = results of this kind.
During the discussion at the CFRG session Leo= claimed that he stressed in his papers explicitly, that he hasn=E2=80=99t = found any methods for mounting the attacks or conditional results like =E2= =80=9Cif the designers know a certain parameter X, then they can mount the = following attack=E2=80=9D.
Leo, many thanks for that clarification of y= ours; you=E2=80=99ve been absolutely honest, I=E2=80=99ve found this in you= r papers:- =E2=80=9CKuznyechik seems to be in the second situ= ation [although the S-Box and linear layer are defined over similar structu= res, a small function was added with the explicit purpose of breaking this = similarity (case of the AES and the affine permutation used in its S-Box]= =E2=80=9D- =E2=80=9COpen Problem 1. Is there a way to lev= erage the partition-preserving property of \uD835\uDF0B to mount an attack = against Streebog?=E2=80=9C
Once more, Leo, your research = is extremely interesting =E2=80=93 I personally ask you to continue. But it= will be correct to underline that currently it=E2=80=99s only an ongoing r= esearch, without any reasons for statements about backdoors/vulnerabilities= .Best regards,
Stanislav
Dear Leo, dear CFRG members,Many thanks for your efforts in analysis of Russian GOST crypto alg= orithms.I am not a cryptographer myself, but o= ne of the implementors of Russian cryptography.On Mon, Aug 5, 2019 at 6= :35 PM Leo Perrin <leo.perrin@inria.fr> wrote:Dear CFRG members,I would like to follow up on the short talk I gave several days = ago. That talk was itself a follow-up to a previous e-mail [0] which presen= ted a strange structure I found in pi, a component (S-box) which is shared = by both Streebog (RFC 6986) and Kuznyechik (RFC 7801).At the= time of writing this previous e-mail, I did not know that the designers of= these algorithms were still claiming that they had generated their S-box r= andomly. However, they do! Here are links to relevant ISO documents that we= re leaked:-https://cdn.virgilsecurity.= com/assets/docs/memo-on-kuznyechik-s-box.pdfAs we can= see in the first one, the designers of pi did claim that they obtained thi= s component by generating many random S-boxes and then choosing the best ac= cording to some (fair and usual) criteria. In fact, as we can see in the se= cond, they insisted that they used this method even *after* the publication= of my latest results [1].That is hardly possible. Let us se= e why.There are 2^{L+1}-1 bitstrings of length at most L. Th= us, the total number of permutations with an implementation fitting in at m= ost L bits in a given language (e.g. in C) is upper bounded by 2^{L+1}. The= shortest implementation of pi in C we are aware of was found by ceilingcat= [2] who improved a previous implementation by Xavier Bonnetain. That imple= mentation is 139 ASCII characters long, i.e. 973 bits long. Thus, there are= fewer than 2^{974} permutations with an implementation this simple. As the= re are 256! =3D 2^{1684} permutations operating on 8 bits, we easily conclu= de that the probability that a random permutation has a C implementation at= most 973 bits long is smaller than 2^{974-1684} =3D 2^{-710}, which is bey= ond negligible. If we look at languages more compact than C (see [2]) then = we can deduce even lower probabilities. In other words, the set of the perm= utations as simple as pi for a very broad definition of simplicity is extre= mely small, and thus the probability that we fall into it by chance is negl= igible. More detailed explanations are available at [3].= In light of this argument, only two possibilities are left:1= .. the designers of pi really used a random process to generate their S-box= , they were just lucky enough to find one of the very (very very very) few = permutations with a short implementation, or2. they used a T= Klog deliberately but decided to hide it, the TKlog being the structure I i= dentified in [1].The probability that the first one is true = can be upper bounded using the discussion above: it is at most 2^{-710}. Fo= r comparison, there are about 10^80 =3D 2^266 atoms in the universe. The on= ly reasonable conclusion is then that we are in the second case: the use of= the TKlog is a deliberate choice by its designers. Note that this reasonin= g is based purely on the simplicity of the TKlog structure. It does not tak= e into account its very peculiar interactions with the finite field, nor do= es it consider the fact that the finite field used to define it is th= e same as the one used in the linear layer of Streebog. It is also unlikely= that the differential and linear properties of pi can be encountered in a = feasibly large set of random S-boxes [4].Because of thes= e observations, I insist that the designers of these algorithms have provid= ed cryptanalysts with misleading information. There cannot be any good reas= on for this, which is why I think these algorithms cannot be trusted, and t= hus that RFC 6986 and 7801 should be deprecated.Cheers,<= br>/L=C3=A9oPS: Remember that the golfed impl= ementations listed in [2] are only intended to be small. They are *not* int= ended to be secure! Their running time in CPU cycles is directly proportion= nal to the discrete logarithm of their input, meaning that they are the opp= osite of constant time. An implementation using them would be trivially vul= nerable to some side channel attacks.You say that you have arguments that the designers may have sai= d controversial declarations about some details of the construction in the = ISO, but this doesn=E2=80=99t seem to correspond to attack.
=Could you please clarify how does the existence of a compact code for = generation of the S-box imply a possibility of attack?
Currently, I = don't see even a performance optimization as a consequence of the compact r= epresentation of the S-box.
The most widespread open-source implementat= ion (https://github.com/gost-engine/engine/tree/openssl_1_1_0)
=_____________________________________________= __
=[0] https://mailarchive.ietf.org/arch/msg/cfrg/4= PmssKzCBsxTmLCieDgqD7Nynwg?fbclid=3DIwAR3JIGXt1_6aFwNOjDb-p7oC3ezHRuEEreznt= -atyY7Clah2QZU_uU7FKS8[2] <= span class=3D"gmail-m_-3515335629100444058gmail-m_1835156983088108477Object= " id=3D"gmail-m_-3515335629100444058gmail-m_1835156983088108477OBJ_PREFIX_D= WT518_com_zimbra_url">https://cod= egolf.stackexchange.com/questions/186498/proving-that-a-russian-cryptograph= ic-standard-is-too-structured[4] https://eprint.iacr.org/2019/528
<= /span>
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--SY, Dmitry Belyavsky_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
Bj=C3=B6r= n,
Its worth reading https://datatracker.ietf= .org/doc/draft-sullivan-tls-opaque=C2=A0 which Nick presented at 104: <= a href=3D"https://datatracker.ietf.org/meeting/104/materials/slides-104-tls= -slides-ietf104-tls-opaque-00" rel=3D"noreferrer" target=3D"_blank">https:/= /datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-t= ls-opaque-00. It covers both OPAQUE in the TLS handshake, and OPAQUE vi= a Exported Authenticators htt= ps://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ at= some point after TLS handshake has taken place. Its currently OPAQUE speci= fic, but the EA model could probably be applied to other PAKEs. And finally= , https://datatracker.ietf= .org/doc/draft-ietf-httpbis-http2-secondary-certs/ covers how to use EA= with HTTP2.
Owen
-----Original Message-----
From: Cfrg <c= frg-bounces@irtf.org> On Behalf Of Bj=C3=B6rn Haase
Sent: 23 July 2019 08:43
To: Benjamin Kaduk <k= aduk@mit.edu>; Watson Ladd <watsonbladd@gmail.com>
Cc: CFRG <cfrg@irtf.o= rg>; hugokra= w@gmail.com
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration in= to TLS // slides.
Dear Ben,
>To build on that, a big motivation for wanting auth at the HTTP layer <= br> >is that most generic web servers aren't going to know *at TLS hands= hake
>time* whether a given client is going to need to authenticate for the <= br> >HTTP requests that will subsequently be conveyed over that connection.<= br>
I fully agree. When saying this, I think that we might better be careful no= t to mix-up two aspects:
1) The human at the client side mostly wants to be sure that the server sid= e contents are authentic, from the very beginning.
2) The server side requires authentication often only when operations with = privileges are requested.
What we have here is something similar to what I'd be calling "re-= authentication use-case" for password checks in a connection that is a= lready established.
Moreover I see differences regarding the use-cases A=C2=A0 "End-custom= er-managed web servers (IoT)" and=C2=A0 B "Conventional Web-Shop = use-cases (Web-PKI)". The main additional benefit of PAKE for use-case= A is that the server-authentication (1.) above) is provided also without t= he need of Web-PKI integration of the server.
I think that one might best try to realize the maximum possible re-use for = authentication mechanisms in both use-cases A/B. Again this might be a reas= on for "outsourcing" all of the user-handling related stuff outsi= de of the main TLS body. Also for use case "B" it might be worth = to consider pulling out the password handling out from the main html applic= ation. Maybe one could use the same mechanisms of a "user authenticati= on" module that we would be using for PAKE? For doing so again some ki= nd of channel-linked tunnel mechanism through TLS might be helpful/necessar= y.
Yours,
Bj=C3=B6rn.
P.S.: I have moved this discussion back to the main list. Sorry for startin= g this discussion with the "not yet publication-ready" slides.
Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards
Dr. Bj=C3=B6rn Haase
Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen
Endress+| Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221 bjoern.haase@endress.com |=C2=A0 www.conducta.endress.com
Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Pers=C3=B6nlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfred Jagiella
=C2=A0
Gem=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu inform= ieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hau= ser-website) nach.
=C2=A0
Disclaimer:
The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential, proprietary, and/or privi= leged material. Any review, retransmission, dissemination or other use of, = or taking of any action in reliance upon, this information by persons or en= tities other than the intended recipient is prohibited. If you receive this= in error, please contact the sender and delete the material from any compu= ter. This e-mail does not constitute a contract offer, a contract amendment= , or an acceptance of a contract offer unless explicitly and conspicuously = designated or stated as such.
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
Hi all,=C2=A0
=I'm happy to volunteer to do some reviews for PAKEs if you a= re still looking for people.=C2=A0Specifically I&= #39;m happy to look at the TLS integration of the augmented PAKEs.=C2=A0Regards,Jonathan_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg