From nobody Sat Dec 2 19:46:57 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03A2126C22 for ; Sat, 2 Dec 2017 19:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFmT0l0znFiE for ; Sat, 2 Dec 2017 19:46:52 -0800 (PST) Received: from sonic315-18.consmr.mail.bf2.yahoo.com (sonic315.consmr.mail.bf2.yahoo.com [74.6.134.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFEB124D6C for ; Sat, 2 Dec 2017 19:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1512272810; bh=eKkE4FF6CZcWrFGh42WLOKfdulur8g9SlrvQOwKn6A8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=TaE6jJ8GPwWs2ER2YBGXHR35Eb3kSogz8jjXTu/Jomrnm+6VsbcfyK41b5nYSUhAvfHIj3LS99iAj7eGV8KUDUysS2sBZH+uKMacffNYJHpgZvqNamJLIGVM8vMDPVmvrS3bze8wmX2QLMtx3UU8YDOZToX6IO/c6cVAq7dBwHplTbyyZuWmwQ+LYvM8OqLumb3lnV3X9qG0XVpr9GY8O21m/9JKyEGItNZupHJ8nPuS1fekm/vRJpWHjMaVtZTyQEZ6HcJSJdQaZNB3gmdcIRbwf1phCaxLhOCjaVGqGdpAwvEe8ZYo664NV+CEmhlmzmZyNe3PeWOeqscmnElXAg== X-YMail-OSG: Ga8jmeYVM1l3MbxnelsTgL_X63kiqB3vJoYAann0xQg9LLEqfmZ2Uew_G.1pK4l j31gQoTasNKAXQq4uCbOs1TqWwShJ6iczNlauDkXxRvUwyMjcl9s.vQfRyOqpwo7SXLsvYryVI7S ovTAwqHqOTZnBS7ZhAidWCtmclansKycE2sjLqS7u4k4jPP4xjnFigMNDBs40yvQ6fMO33Lx.hc7 0HqjTrWM8Cw68fbRnj8RXllZLqZXVHw7UYdfSb.Ecgq_IDvlge2t3GmCpsgjxDyP751_Xh6etduY SvXYLioOA2M7zhORRkUncod_GmkLgnojQAdSQNh50hDu8iGJylmBf2N5IeKK5pUBxt9oO6cQhgUz h_SLDlt3PG9H.5ERWZDnxUeQuiTUkuaTmYxO1EvukiTLnBXVP2sljR5BBzeLob_rHEVmSjJfFNPt 9HUqBOa6nMZVE8H2N0B.uS.QkHsiG6pKqNQ5ixiZFC2YPkQDEK4s7_g1ySWEGp3.RaxXgfJve64J DyHZvcrmo1Xrx1EEj Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Sun, 3 Dec 2017 03:46:50 +0000 Received: from smtp101.sbc.mail.bf1.yahoo.com (EHLO Davids-iMac.local) ([98.139.228.106]) by smtp414.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 1716476646; Sun, 03 Dec 2017 03:46:49 +0000 (UTC) To: "Stanislav V. Smyshlyaev" , Richard Barnes Cc: "cfrg@irtf.org" References: From: David Jacobson Message-ID: <4fa7e777-22e2-264f-1119-8f593b6487ef@sbcglobal.net> Date: Sat, 2 Dec 2017 19:46:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD053119B569B3027A2891C2" Content-Language: en-US Archived-At: Subject: Re: [Cfrg] I like PKEX X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 03:46:55 -0000 This is a multi-part message in MIME format. --------------DD053119B569B3027A2891C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about to mention might be already solved. 1.  I'd like some advocates of PKEX/PAKE to give a brief explanation of what has to be added to browsers to make this work.  And, in particular, how can the end-user be sure that the thing asking for her account number and password is the genuine browser implementation of the client side of PKEX or PAKE, not some imposter? 2.  How do you bootstrap the security?    The connection can't be secure until the client presents some credentials.  But the client doesn't want to send credentials in the clear during the setup. And the client wants to be certain that the entity she is communicating with is genuine.  So it looks like we have to use the present protocols for creating an account.   So we haven't really gotten rid of having to trust a CA. 3.  And a similar problem arises around anonymous browsing. Suppose our end user wants to browse women's apparel and wants to look around and not identify herself unless she sees something she likes and wants to buy it.  There are many people who advocate using HTTPS for everything to make it hard for an attacker to inject a malicious web page.  But with PKEX/PAKE the client either has to fall back on present protocols or be vulnerable to injected attacks until she has decided to reveal her identity.    --David Jacobson On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote: > Though, unfortunately, I am not aware of any online banking systems or > messengers that use PAKEs for user authentication, I'd like to mention > (hope you consider it interesting) that there are some existing cloud > signature solutions (digital signature servers) in Russia that use one > of PAKEs to authenticate users to their private keys stored in a cloud > - in a way that is pretty similar to the one that has been mentioned > by Rich. > > > Best regards, > Stanislav > > > 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev >: > > In fact, PKEX (password-authenticated key exchange protocol by Dan > Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 > - for > Richard), as all secure PAKE protocols can help to upgrade most > cases of authentication, when some shared secret (password or, as > in Rich's example, an account number), to solutions which do not > require having a primary trust to someone you're authenticating to. > > I'd also like to see PAKEs in the messengers, as I commented > during the CFRG meeting yesterday. > > > 2017-11-16 15:21 GMT+08:00 Richard Barnes >: > > Sorry, what is PKEX? > > On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich > wrote: > > I think the PKEX stuff is very interesting.  It inverts > the trust model used on the Web. Suppose I want to do some > online banking with mybank.com . My > browser checks the server cert, and decided to trust it if > the CA verifies the identity. I then type my name and > password into the website. There is a risk if I end up at > the wrong website. > > With PKEX, I can use my name and password and the bank can > use something like my account number or other similar > info, and we exchange and get a shared secret. We then use > that secret to get an authenticated ECDSA key and then I > switch to TLS and get its benefits.  No third-party trust > is needed. > > I think this solves an interesting use-case and it would > be nice to have it in our toolbox. > > > _______________________________________________ > 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 > > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --------------DD053119B569B3027A2891C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about to mention might be already solved.

1.  I'd like some advocates of PKEX/PAKE to give a brief explanation of what has to be added to browsers to make this work.  And, in particular, how can the end-user be sure that the thing asking for her account number and password is the genuine browser implementation of the client side of PKEX or PAKE, not some imposter?

2.  How do you bootstrap the security?    The connection can't be secure until the client presents some credentials.  But the client doesn't want to send credentials in the clear during the setup.  And the client wants to be certain that the entity she is communicating with is genuine.  So it looks like we have to use the present protocols for creating an account.   So we haven't really gotten rid of having to trust a CA.

3.  And a similar problem arises around anonymous browsing.   Suppose our end user wants to browse women's apparel and wants to look around and not identify herself unless she sees something she likes and wants to buy it.  There are many people who advocate using HTTPS for everything to make it hard for an attacker to inject a malicious web page.  But with PKEX/PAKE the client either has to fall back on present protocols or be vulnerable to injected attacks until she has decided to reveal her identity.
 
   --David Jacobson




On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote:
Though, unfortunately, I am not aware of any online banking systems or messengers that use PAKEs for user authentication, I'd like to mention (hope you consider it interesting) that there are some existing cloud signature solutions (digital signature servers) in Russia that use one of PAKEs to authenticate users to their private keys stored in a cloud - in a way that is pretty similar to the one that has been mentioned by Rich.


Best regards,
Stanislav


2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com>:
In fact, PKEX (password-authenticated key exchange protocol by Dan Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 - for Richard), as all secure PAKE protocols can help to upgrade most cases of authentication, when some shared secret (password or, as in Rich's example, an account number), to solutions which do not require having a primary trust to someone you're authenticating to. 

I'd also like to see PAKEs in the messengers, as I commented during the CFRG meeting yesterday.


2017-11-16 15:21 GMT+08:00 Richard Barnes <rlb@ipv.sx>:

Sorry, what is PKEX?

On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <rsalz@akamai.com> wrote:

I think the PKEX stuff is very interesting.  It inverts the trust model used on the Web.   Suppose I want to do some online banking with mybank.com. My browser checks the server cert, and decided to trust it if the CA verifies the identity. I then type my name and password into the website. There is a risk if I end up at the wrong website.

 

With PKEX, I can use my name and password and the bank can use something like my account number or other similar info, and we exchange and get a shared secret. We then use that secret to get an authenticated ECDSA key and then I switch to TLS and get its benefits.  No third-party trust is needed.

 

I think this solves an interesting use-case and it would be nice to have it in our toolbox.

 


_______________________________________________
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





_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--------------DD053119B569B3027A2891C2-- From nobody Sun Dec 3 02:36:31 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D0D1241FC for ; Sun, 3 Dec 2017 02:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1xLtHYOBm8A for ; Sun, 3 Dec 2017 02:36:27 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF3A120713 for ; Sun, 3 Dec 2017 02:36:26 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id d4so18020434qtj.5 for ; Sun, 03 Dec 2017 02:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VrlALeXVmJ3gp4oN20tODBDCPM0IKCwtukPUjiPV3XU=; b=WVM6EuNy2XwKwR6ErQ9lMyXdHEfUj6iYXjB/WVtMOSHHdegM1iRaScpJD8agLwFsRR RWslGKSVlt8xKHw7OHW6IWJgocaga8/PGoeddhR75EtEPr/Usu732h0xsCHKI4arBoQ/ dNhZhU3fSLivXQHq+Dw4hhXhJcMPECy8pbuY6i7OjwyiZpX7kg7ZTsYEhQEyU8TIvE0w 2OLvUnep5UKQzWdjwHmCTHBOQ7mY3Rs1K9yOh/Pwow9b6q1zX0oi03Xm5H/nFBz7kiz8 R+tikd96d2SvTpC0I0W0m0cbrvjbsha3lNFA/UZ3q19xPwYjsQU13WS8Acvc0z3UdGrk KCiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VrlALeXVmJ3gp4oN20tODBDCPM0IKCwtukPUjiPV3XU=; b=Mbf3VGZ6NvTPRxmNz9BRDfEwWk3N8Z06ITQKDgEHw1XE65wxjGp/m2/l3fCb2XUKCa 0ab1xhiTd7DbX9L8jAqN4bq4IL0I4isePWsPFRpHOiu+KDUWp3i5vjJf0GmwfNq+4Br1 qykCk84E7ilyR2iE0rQakF00QiQd6Pmwxerqj6uGdlq+Tudb+os8SUTZ+USxm3FFmznD ccVQTY70L9Fci0FszbW5pVnTz8t8Q6VLNtho4WdMz0IkkZYzJhO5XqMbl7vWH+IDRA2F 6l3CEuaAc24prTpLrobYDbWh8OgjANkMQZDhtlLeGarHRAoOWIL8HSce9mXaVB7DjxGD kMIQ== X-Gm-Message-State: AKGB3mJolHrPppkxMwn/lf+UdVuPlRBtl71Dz+ygw/fSdADVruEg8Bst aZtMBUTTfYqoL3Dm9B+N04rZ6enoa0PCJo1OW7A= X-Google-Smtp-Source: AGs4zMYclK5TECt+O9b71oqn08RNSkDarI5lljrZIwraHppE4q64M+K29vdup7xXLceiOJ5ZHwRQJAI2N/VmItlKdjU= X-Received: by 10.237.62.5 with SMTP id l5mr12817022qtf.299.1512297386095; Sun, 03 Dec 2017 02:36:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.139 with HTTP; Sun, 3 Dec 2017 02:36:25 -0800 (PST) In-Reply-To: <4fa7e777-22e2-264f-1119-8f593b6487ef@sbcglobal.net> References: <4fa7e777-22e2-264f-1119-8f593b6487ef@sbcglobal.net> From: "Stanislav V. Smyshlyaev" Date: Sun, 3 Dec 2017 13:36:25 +0300 Message-ID: To: David Jacobson Cc: Richard Barnes , "cfrg@irtf.org" Content-Type: multipart/alternative; boundary="001a11417d2c7e37e6055f6d2cf8" Archived-At: Subject: Re: [Cfrg] I like PKEX X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 10:36:29 -0000 --001a11417d2c7e37e6055f6d2cf8 Content-Type: text/plain; charset="UTF-8" Dear David, PKEX/PAKEs cannot be seen as a silver bullet, that can solve any authentication problems. My view on the second and the third questions that you've raised is the following. First of all, the usage of PAKE always assumes that there is a certain password distributed among communicating parties - this type of protocols is absolutely meaningless otherwise. That provides an answer to your third question: PAKEs cannot provide any help for anonymous browsing. On the second question and the security bootstrapping issue - PAKEs can help in the following case: when some memorable secret is used for the initial secure communication session, during which long-term secret keys can be established and stored in the devices for all further authentication purposes. But you're completely right that PAKEs can't be used without any preceding actions (face-to-face communication, provision of some memorable PINs to users, negotiation to some "security questions" etc). Best regards, Stanislav Smyshlyaev, Ph.D., Head of Information Security Department, CryptoPro LLC 2017-12-03 6:46 GMT+03:00 David Jacobson : > I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about > to mention might be already solved. > > 1. I'd like some advocates of PKEX/PAKE to give a brief explanation of > what has to be added to browsers to make this work. And, in particular, > how can the end-user be sure that the thing asking for her account number > and password is the genuine browser implementation of the client side of > PKEX or PAKE, not some imposter? > > 2. How do you bootstrap the security? The connection can't be secure > until the client presents some credentials. But the client doesn't want to > send credentials in the clear during the setup. And the client wants to be > certain that the entity she is communicating with is genuine. So it looks > like we have to use the present protocols for creating an account. So we > haven't really gotten rid of having to trust a CA. > > 3. And a similar problem arises around anonymous browsing. Suppose our > end user wants to browse women's apparel and wants to look around and not > identify herself unless she sees something she likes and wants to buy it. > There are many people who advocate using HTTPS for everything to make it > hard for an attacker to inject a malicious web page. But with PKEX/PAKE > the client either has to fall back on present protocols or be vulnerable to > injected attacks until she has decided to reveal her identity. > > --David Jacobson > > > > > > On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote: > > Though, unfortunately, I am not aware of any online banking systems or > messengers that use PAKEs for user authentication, I'd like to mention > (hope you consider it interesting) that there are some existing cloud > signature solutions (digital signature servers) in Russia that use one of > PAKEs to authenticate users to their private keys stored in a cloud - in > a way that is pretty similar to the one that has been mentioned by Rich. > > > Best regards, > Stanislav > > > 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev : > >> In fact, PKEX (password-authenticated key exchange protocol by Dan >> Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 - for >> Richard), as all secure PAKE protocols can help to upgrade most cases of >> authentication, when some shared secret (password or, as in Rich's example, >> an account number), to solutions which do not require having a primary >> trust to someone you're authenticating to. >> >> I'd also like to see PAKEs in the messengers, as I commented during the >> CFRG meeting yesterday. >> >> >> 2017-11-16 15:21 GMT+08:00 Richard Barnes : >> >>> Sorry, what is PKEX? >>> >>> On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich wrote: >>> >>>> I think the PKEX stuff is very interesting. It inverts the trust model >>>> used on the Web. Suppose I want to do some online banking with >>>> mybank.com. My browser checks the server cert, and decided to trust it >>>> if the CA verifies the identity. I then type my name and password into the >>>> website. There is a risk if I end up at the wrong website. >>>> >>>> >>>> >>>> With PKEX, I can use my name and password and the bank can use >>>> something like my account number or other similar info, and we exchange and >>>> get a shared secret. We then use that secret to get an authenticated ECDSA >>>> key and then I switch to TLS and get its benefits. No third-party trust is >>>> needed. >>>> >>>> >>>> >>>> I think this solves an interesting use-case and it would be nice to >>>> have it in our toolbox. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > > _______________________________________________ > Cfrg mailing listCfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg > > > --001a11417d2c7e37e6055f6d2cf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear David,

PKEX/PAKEs ca= nnot be seen as a silver bullet, that can solve any authentication problems= .

My view on the second and the third questions th= at you've raised is the following.
First of all, the usage of= PAKE always assumes that there is a certain password distributed among com= municating parties - this type of protocols is absolutely meaningless other= wise. That provides an answer to your third question: PAKEs cannot provide = any help for anonymous browsing.

On the second que= stion and the security bootstrapping issue - PAKEs can help in the followin= g case: when some memorable secret is used for the initial secure communica= tion session, during which long-term secret keys can be established and sto= red in the devices for all further authentication purposes. But you're = completely right that PAKEs can't be used without any preceding actions= (face-to-face communication, provision of some memorable PINs to users, ne= gotiation to some "security questions" etc).

=

Best regards,
Stanislav Smyshlyaev, Ph.D.,
Head of Information Security Department,=C2=A0
CryptoPro = LLC

2017-12-03 6:46 GMT+03:00 David Jacobson <dmjacobson@sbcglobal.net>:
=20 =20 =20
I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about to mention might be already solved.

1.=C2=A0 I'd like some advocates of PKEX/PAKE to give a brief explanation of what has to be added to browsers to make this work.=C2=A0 And, in particular, how can the end-user be sure that the thing asking for her account number and password is the genuine browser implementation of the client side of PKEX or PAKE, not some imposter?

2.=C2=A0 How do you bootstrap the security?=C2=A0=C2=A0=C2=A0 The con= nection can't be secure until the client presents some credentials.=C2=A0 But the clie= nt doesn't want to send credentials in the clear during the setup.= =C2=A0 And the client wants to be certain that the entity she is communicating with is genuine.=C2=A0 So it looks like we have to use the present protocols for creating an account. =C2=A0 So we haven'= ;t really gotten rid of having to trust a CA.

3.=C2=A0 And a similar problem arises around anonymous browsing.=C2= =A0=C2=A0 Suppose our end user wants to browse women's apparel and wants to look around and not identify herself unless she sees something she likes and wants to buy it.=C2=A0 There are many people who advocate using HTTPS for everything to make it hard for an attacker to inject a malicious web page.=C2=A0 But with PKEX/PAKE the client eith= er has to fall back on present protocols or be vulnerable to injected attacks until she has decided to reveal her identity.
=C2=A0
=C2=A0=C2=A0 --David Jacobson





On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote:
Though, unfortunately, I am not aware of any online banking systems or messengers that use PAKEs for user authentication, I'd like to mention (hope yo= u consider it interesting) that there are some existing cloud signature solutions (digital signature servers) in Russia that use one of PAKEs to authenticate=C2=A0users to their private keys stored in a cloud - in a way that is pretty similar to the one that has been mentioned by Rich.


Best regards,
Stanislav


2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com>:
In fact, PKEX (password-authenticated key exchange protocol by Dan Harkins,=C2=A0https://tools.i= etf.org/html/draft-harkins-pkex-04 - for Richard), as all secure PAKE protocols can help to upgrade most cases of authentication, when some shared secret (password or, as in Rich's example, an account number), to solutions which do not require having a primary trust to someone you're authenticating to.=C2= =A0

I'd also like to see PAKEs in the messengers, as I commented during the CFRG meeting yesterday.


2017-11-16 15:21 GMT+08:00 Richard Barnes <= rlb@ipv.sx>:<= br>

Sorry, what is PKEX?

On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <rsalz@akamai.com><= /span> wrote:

I think the PKEX stuff is very interesting.=C2=A0 It inverts the trust model used on the Web.=C2=A0=C2= =A0 Suppose I want to do some online banking with mybank.com. My browser checks the server cert, and decided to trust it if the CA verifies the identity. I then type my name and password into the website. There is a risk if I end up at the wrong website.

=C2=A0

With PKEX, I can use my name and password and the bank can use something like my account number or other similar info, and we exchange and get a shared secret. We then use that secret to get an authenticated ECDSA key and then I switch to TLS and get its benefits.=C2=A0 No third-party trust is needed.

=C2=A0

I think this solves an interesting use-case and it would be nice to have it in our toolbox.

=C2=A0


__________________________________= _____________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/m= ailman/listinfo/cfrg



________________________________________= _______
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman= /listinfo/cfrg





_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
ht=
tps://www.irtf.org/mailman/listinfo/cfrg



--001a11417d2c7e37e6055f6d2cf8-- From nobody Sun Dec 3 23:26:37 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012B5126BF3 for ; Sun, 3 Dec 2017 23:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSFMHEnCwXAm for ; Sun, 3 Dec 2017 23:26:33 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 27C81126B7E for ; Sun, 3 Dec 2017 23:26:33 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 5183410224054; Sun, 3 Dec 2017 23:26:32 -0800 (PST) To: cfrg@irtf.org, David Jacobson References: <4fa7e777-22e2-264f-1119-8f593b6487ef@sbcglobal.net> From: Dan Harkins Message-ID: <29eab276-e60d-1620-54e7-014427673d9d@lounge.org> Date: Sun, 3 Dec 2017 23:26:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4fa7e777-22e2-264f-1119-8f593b6487ef@sbcglobal.net> Content-Type: multipart/alternative; boundary="------------E1C5F80D89388C1BBAEBF752" Content-Language: en-US Archived-At: Subject: Re: [Cfrg] I like PKEX X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 07:26:36 -0000 This is a multi-part message in MIME format. --------------E1C5F80D89388C1BBAEBF752 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit   Hi David, On 12/2/17 7:46 PM, David Jacobson wrote: > I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm > about to mention might be already solved. > > 1.  I'd like some advocates of PKEX/PAKE to give a brief explanation > of what has to be added to browsers to make this work.  And, in > particular, how can the end-user be sure that the thing asking for her > account number and password is the genuine browser implementation of > the client side of PKEX or PAKE, not some imposter?   The only way the PAKE can succeed is if both sides know the same password. The advantage an attacker gains against the PAKE is based on interaction and not computation so as long as the user limits the number of "oh I must've fat-fingered my password, let me try again" the probability that the other side is not genuine can be acceptably low-- it would be n/d where n is the number of "oh I must've fat-fingered..." attempts attempted before giving up and d is the size of the pool from which the password was drawn. > 2.  How do you bootstrap the security?    The connection can't be > secure until the client presents some credentials.  But the client > doesn't want to send credentials in the clear during the setup.  And > the client wants to be certain that the entity she is communicating > with is genuine.  So it looks like we have to use the present > protocols for creating an account.   So we haven't really gotten rid > of having to trust a CA.   Yes, this is a problem, we can't create security out of whole cloth. Depending on the site the password could be set up face-to-face (think of a bank) or maybe sent via SMS (think a social media sight). There is no need for a CA though because the password, once established, is parlayed into a trusted public key. Once PKEX is finished the password can be thrown away, or even exposed. It is of no use anymore. The public key is now used.   Why do PKEX if you're gonna bootstrap the whole thing face-to-face? Well, a password is a more natural credential than a public key. It would be possible to do a PGP web of trust type of interaction to exchange trusted public keys at the bank but that level of sophistication is beyond your random teller and your random bank customer. Giving an 8 character password (abcd-wxyz) would be easy for teller to provide and for the customer to understand how to use-- just enter it next time he or she points a browser to the bank's website. > 3.  And a similar problem arises around anonymous browsing.   Suppose > our end user wants to browse women's apparel and wants to look around > and not identify herself unless she sees something she likes and wants > to buy it.  There are many people who advocate using HTTPS for > everything to make it hard for an attacker to inject a malicious web > page.  But with PKEX/PAKE the client either has to fall back on > present protocols or be vulnerable to injected attacks until she has > decided to reveal her identity.   This isn't a solution to the problem of anonymous browsing but I would imagine that in the scenario you describe that if the sight was willing to support that sort of thing the HTTPS connection could be set up with server-side only authentication where the woman browsing authenticates the website with the public key she obtained earlier from her run of PKEX. Then she can anonymously browse to her heart's content until she finds something and then when she goes to purchase the selected item(s) will do another run of TLS this time with mutual authentication where she presents her public key, the one she provided during her run of PKEX, as part of client authentication.   regards,   Dan. >    --David Jacobson > > > > > On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote: >> Though, unfortunately, I am not aware of any online banking systems >> or messengers that use PAKEs for user authentication, I'd like to >> mention (hope you consider it interesting) that there are some >> existing cloud signature solutions (digital signature servers) in >> Russia that use one of PAKEs to authenticate users to their private >> keys stored in a cloud - in a way that is pretty similar to the one >> that has been mentioned by Rich. >> >> >> Best regards, >> Stanislav >> >> >> 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev > >: >> >> In fact, PKEX (password-authenticated key exchange protocol by >> Dan Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 >> - for >> Richard), as all secure PAKE protocols can help to upgrade most >> cases of authentication, when some shared secret (password or, as >> in Rich's example, an account number), to solutions which do not >> require having a primary trust to someone you're authenticating to. >> >> I'd also like to see PAKEs in the messengers, as I commented >> during the CFRG meeting yesterday. >> >> >> 2017-11-16 15:21 GMT+08:00 Richard Barnes > >: >> >> Sorry, what is PKEX? >> >> On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich > > wrote: >> >> I think the PKEX stuff is very interesting.  It inverts >> the trust model used on the Web.   Suppose I want to do >> some online banking with mybank.com . >> My browser checks the server cert, and decided to trust >> it if the CA verifies the identity. I then type my name >> and password into the website. There is a risk if I end >> up at the wrong website. >> >> With PKEX, I can use my name and password and the bank >> can use something like my account number or other similar >> info, and we exchange and get a shared secret. We then >> use that secret to get an authenticated ECDSA key and >> then I switch to TLS and get its benefits.  No >> third-party trust is needed. >> >> I think this solves an interesting use-case and it would >> be nice to have it in our toolbox. >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> >> _______________________________________________ >> 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 --------------E1C5F80D89388C1BBAEBF752 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
  Hi David,

On 12/2/17 7:46 PM, David Jacobson wrote:
I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about to mention might be already solved.

1.  I'd like some advocates of PKEX/PAKE to give a brief explanation of what has to be added to browsers to make this work.  And, in particular, how can the end-user be sure that the thing asking for her account number and password is the genuine browser implementation of the client side of PKEX or PAKE, not some imposter?

  The only way the PAKE can succeed is if both sides know the same password.
The advantage an attacker gains against the PAKE is based on interaction and not
computation so as long as the user limits the number of "oh I must've fat-fingered
my password, let me try again" the probability that the other side is not genuine
can be acceptably low-- it would be n/d where n is the number of "oh I must've
fat-fingered..." attempts attempted before giving up and d is the size of the pool
from which the password was drawn.

2.  How do you bootstrap the security?    The connection can't be secure until the client presents some credentials.  But the client doesn't want to send credentials in the clear during the setup.  And the client wants to be certain that the entity she is communicating with is genuine.  So it looks like we have to use the present protocols for creating an account.   So we haven't really gotten rid of having to trust a CA.

  Yes, this is a problem, we can't create security out of whole cloth. Depending
on the site the password could be set up face-to-face (think of a bank) or maybe
sent via SMS (think a social media sight). There is no need for a CA though because
the password, once established, is parlayed into a trusted public key. Once PKEX
is finished the password can be thrown away, or even exposed. It is of no use
anymore. The public key is now used.

  Why do PKEX if you're gonna bootstrap the whole thing face-to-face? Well, a password
is a more natural credential than a public key. It would be possible to do a PGP web
of trust type of interaction to exchange trusted public keys at the bank but that level
of sophistication is beyond your random teller and your random bank customer. Giving an
8 character password (abcd-wxyz) would be easy for teller to provide and for the
customer to understand how to use-- just enter it next time he or she points a browser
to the bank's website.

3.  And a similar problem arises around anonymous browsing.   Suppose our end user wants to browse women's apparel and wants to look around and not identify herself unless she sees something she likes and wants to buy it.  There are many people who advocate using HTTPS for everything to make it hard for an attacker to inject a malicious web page.  But with PKEX/PAKE the client either has to fall back on present protocols or be vulnerable to injected attacks until she has decided to reveal her identity.

  This isn't a solution to the problem of anonymous browsing but I would imagine
that in the scenario you describe that if the sight was willing to support that
sort of thing the HTTPS connection could be set up with server-side only
authentication where the woman browsing authenticates the website with the
public key she obtained earlier from her run of PKEX. Then she can anonymously
browse to her heart's content until she finds something and then when she goes
to purchase the selected item(s) will do another run of TLS this time with mutual
authentication where she presents her public key, the one she provided during
her run of PKEX, as part of client authentication.

  regards,

  Dan.
   --David Jacobson




On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote:
Though, unfortunately, I am not aware of any online banking systems or messengers that use PAKEs for user authentication, I'd like to mention (hope you consider it interesting) that there are some existing cloud signature solutions (digital signature servers) in Russia that use one of PAKEs to authenticate users to their private keys stored in a cloud - in a way that is pretty similar to the one that has been mentioned by Rich.


Best regards,
Stanislav


2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com>:
In fact, PKEX (password-authenticated key exchange protocol by Dan Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 - for Richard), as all secure PAKE protocols can help to upgrade most cases of authentication, when some shared secret (password or, as in Rich's example, an account number), to solutions which do not require having a primary trust to someone you're authenticating to. 

I'd also like to see PAKEs in the messengers, as I commented during the CFRG meeting yesterday.


2017-11-16 15:21 GMT+08:00 Richard Barnes <rlb@ipv.sx>:

Sorry, what is PKEX?

On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <rsalz@akamai.com> wrote:

I think the PKEX stuff is very interesting.  It inverts the trust model used on the Web.   Suppose I want to do some online banking with mybank.com. My browser checks the server cert, and decided to trust it if the CA verifies the identity. I then type my name and password into the website. There is a risk if I end up at the wrong website.

 

With PKEX, I can use my name and password and the bank can use something like my account number or other similar info, and we exchange and get a shared secret. We then use that secret to get an authenticated ECDSA key and then I switch to TLS and get its benefits.  No third-party trust is needed.

 

I think this solves an interesting use-case and it would be nice to have it in our toolbox.

 


_______________________________________________
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





_______________________________________________
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

--------------E1C5F80D89388C1BBAEBF752-- From nobody Fri Dec 8 01:03:00 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF8126DEE for ; Fri, 8 Dec 2017 01:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spy3-MPD5aBx for ; Fri, 8 Dec 2017 01:02:53 -0800 (PST) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEC2124319 for ; Fri, 8 Dec 2017 01:02:52 -0800 (PST) Received: from Morten ([62.44.135.202]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201712081002471840; Fri, 08 Dec 2017 10:02:47 +0100 From: "Erik Andersen" To: "Cfrg" Cc: "Carsten Strunge" Date: Fri, 8 Dec 2017 10:02:47 +0100 Message-ID: <000801d37003$5165df80$f4319e80$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01D3700B.B32C9170" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdNwAj7rtSh6exWUShSQuW95dPBnSg== Content-Language: en-gb Archived-At: Subject: [Cfrg] Use of the term "deprecated" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 09:02:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0009_01D3700B.B32C9170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the smart grid security standards the term deprecated is used for certain cryptographic algorithms, such as SHA-1, instead of disallowing them. NIST in SP 800-57, Part 1 Revision 4 has stopped using the term deprecated. What is the general feeling among list members on using the term deprecated on cryptographic algorithms? Erik ------=_NextPart_000_0009_01D3700B.B32C9170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the smart grid security standards the term = deprecated is used for certain cryptographic algorithms, such as SHA-1, = instead of disallowing them. NIST in SP 800-57, Part 1 Revision 4 has = stopped using the term deprecated.

 

What is the = general feeling among  list members on using the term deprecated on = cryptographic algorithms?

 

Erik

------=_NextPart_000_0009_01D3700B.B32C9170-- From nobody Fri Dec 8 07:31:38 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CDE1243F6 for ; Fri, 8 Dec 2017 07:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrsRuN4xZ8K0 for ; Fri, 8 Dec 2017 07:31:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255E6120721 for ; Fri, 8 Dec 2017 07:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6088; q=dns/txt; s=iport; t=1512747095; x=1513956695; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fpCkqBF2aztHvF42MPhkUQkFr9Vzlojh2p4Iv0GCS6Y=; b=Uyaks5EtHCnXnkwyvfrDKjX5PBpAMSwZc2wSJ5drByGga+Q97nRZMp+8 vK/5p5d+S1V48NfYKdmCvG2LBrhhwyHFOEo7lxZ9cqrL++hhWu89HRIMq 3KH+7/rBaWhOxZg+Gf8zz3GGFCTZFPBWZQC1rqbhMTZz0/sie/uHwSK15 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQD2rypa/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0JweOHI8AgX2RQYVLghUKJYUWAoUCPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUiAQEBAQMtTBACAQgOAwQBASgHMhQJCAEBBAENBQiJPGQQqiOKYwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFg1uCC4FWgWmDK4UtKIVCBaMIApUVk2qWLwIRGQG?= =?us-ascii?q?BOgEfOYFPbxU6gimCUgEbgWd4AYkggRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,378,1508803200"; d="scan'208,217";a="328249540" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 15:31:30 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vB8FVUEU008661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 15:31:30 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 09:31:29 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Fri, 8 Dec 2017 09:31:29 -0600 From: "Panos Kampanakis (pkampana)" To: Erik Andersen , Cfrg CC: Carsten Strunge Thread-Topic: [Cfrg] Use of the term "deprecated" Thread-Index: AdNwAj7rtSh6exWUShSQuW95dPBnSgANoRsA Date: Fri, 8 Dec 2017 15:31:29 +0000 Message-ID: <493e5bc356fc40268177e1c8d87c5bc4@XCH-ALN-010.cisco.com> References: <000801d37003$5165df80$f4319e80$@x500.eu> In-Reply-To: <000801d37003$5165df80$f4319e80$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.3] Content-Type: multipart/alternative; boundary="_000_493e5bc356fc40268177e1c8d87c5bc4XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cfrg] Use of the term "deprecated" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:31:37 -0000 --_000_493e5bc356fc40268177e1c8d87c5bc4XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Erik, For what it is worth, our "subjective" Cisco approach includes the term Leg= acy which is equivalent to Deprecated. The definition is "Legacy algorithms= provide a marginal but acceptable security level. They should be used only= when no better alternatives are available, such as when interoperating wit= h legacy equipment. It is recommended that these legacy algorithms be phase= d out and replaced with stronger algorithms." In the table https://www.cisc= o.com/c/en/us/about/security-center/next-generation-cryptography.html#2 you= will see we are flagging SHA1 as legacy, MD5 as avoid. Rgs, Panos From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Erik Andersen Sent: Friday, December 08, 2017 4:03 AM To: Cfrg Cc: Carsten Strunge Subject: [Cfrg] Use of the term "deprecated" In the smart grid security standards the term deprecated is used for certai= n cryptographic algorithms, such as SHA-1, instead of disallowing them. NIS= T in SP 800-57, Part 1 Revision 4 has stopped using the term deprecated. What is the general feeling among list members on using the term deprecate= d on cryptographic algorithms? Erik --_000_493e5bc356fc40268177e1c8d87c5bc4XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Erik,

 

For what it is worth, = our “subjective” Cisco approach includes the term Legacy which = is equivalent to Deprecated. The definition is “Le= gacy algorithms provide a marginal but acceptable security level. They should b= e used only when no better alternatives are available, such as when interop= erating with legacy equipment. It is recommended that these legacy algorith= ms be phased out and replaced with stronger algorithms.” In the ta= ble https://www.cisco.com/c/en/us/about/security-center/next-generation-cryptog= raphy.html#2 you will see we are flagging SHA1 as legacy, MD5 as avoid.

 

Rgs,=

Panos

 

 

From: Cfrg [mailto:cfrg-bounces@irtf.org] = On Behalf Of Erik Andersen
Sent: Friday, December 08, 2017 4:03 AM
To: Cfrg <cfrg@irtf.org>
Cc: Carsten Strunge <CAS@energinet.dk>
Subject: [Cfrg] Use of the term "deprecated"

 

In the smart grid security stan= dards the term deprecated is used for certain cryptographic algorithms, suc= h as SHA-1, instead of disallowing them. NIST in SP 800-57, Part 1 Revision= 4 has stopped using the term deprecated.

 

What is the general feeling amo= ng  list members on using the term deprecated on cryptographic algorit= hms?

 

Erik

--_000_493e5bc356fc40268177e1c8d87c5bc4XCHALN010ciscocom_-- From nobody Fri Dec 8 07:44:53 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B528126D74 for ; Fri, 8 Dec 2017 07:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J09QiVoULCX for ; Fri, 8 Dec 2017 07:44:50 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id C15CB126B6D for ; Fri, 8 Dec 2017 07:44:49 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id vB8FimFi021540 for ; Fri, 8 Dec 2017 10:44:48 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Cfrg Thread-Topic: [Cfrg] Use of the term "deprecated" Thread-Index: AdNwAj7rtSh6exWUShSQuW95dPBnSgANoRsAAACtk4A= Date: Fri, 8 Dec 2017 15:44:47 +0000 Message-ID: References: <000801d37003$5165df80$f4319e80$@x500.eu> <493e5bc356fc40268177e1c8d87c5bc4@XCH-ALN-010.cisco.com> In-Reply-To: <493e5bc356fc40268177e1c8d87c5bc4@XCH-ALN-010.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-originating-ip: [172.25.177.154] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3595574687_1470976812" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080216 Archived-At: Subject: Re: [Cfrg] Use of the term "deprecated" X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:44:52 -0000 --B_3595574687_1470976812 Content-type: multipart/alternative; boundary="B_3595574687_1455961071" --B_3595574687_1455961071 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The term =E2=80=9CLegacy=E2=80=9D does not carry as much strength as the term =E2=80=9CDeprec= ated=E2=80=9D. So I strongly (pun intended) suggest using the term =E2=80=9CDeprecated=E2=80= =9D to emphasize the fact that the algorithms in question should not be used i= f at all possible. =20 -- Regards, Uri Blumenthal =20 From: Cfrg on behalf of "Panos Kampanakis (pkampana= )" Date: Friday, December 08, 2017 at 10:32 To: Erik Andersen , CFRG Cc: Carsten Strunge Subject: Re: [Cfrg] Use of the term "deprecated" =20 Hi Erik, =20 For what it is worth, our =E2=80=9Csubjective=E2=80=9D Cisco approach includes the term= Legacy which is equivalent to Deprecated. The definition is =E2=80=9CLegacy algor= ithms provide a marginal but acceptable security level. They should be used = only when no better alternatives are available, such as when interoperating = with legacy equipment. It is recommended that these legacy algorithms be pha= sed out and replaced with stronger algorithms.=E2=80=9D In the table https://www.c= isco.com/c/en/us/about/security-center/next-generation-cryptography.html#2 y= ou will see we are flagging SHA1 as legacy, MD5 as avoid.=20 =20 Rgs, Panos =20 =20 From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Erik Andersen Sent: Friday, December 08, 2017 4:03 AM To: Cfrg Cc: Carsten Strunge Subject: [Cfrg] Use of the term "deprecated" =20 In the smart grid security standards the term deprecated is used for certai= n cryptographic algorithms, such as SHA-1, instead of disallowing them. NIST= in SP 800-57, Part 1 Revision 4 has stopped using the term deprecated. =20 What is the general feeling among list members on using the term deprecate= d on cryptographic algorithms? =20 Erik --B_3595574687_1455961071 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The term =E2=80=9CLegacy=E2=80=9D does n= ot carry as much strength as the term =E2=80=9CDeprecated=E2=80=9D. So I strongly (pun i= ntended) suggest using the term =E2=80=9CDeprecated=E2=80=9D to emphasize the fact that = the algorithms in question should not be used if at all possible.

 

--

Regards,=

Uri Blumenthal

<= o:p> 

From: Cfrg <cfrg-bounces@irtf.org> on behalf of &quo= t;Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Date: <= /b>Friday, December 08, 2017 at 10:32
To: Erik Andersen <era@x5= 00.eu>, CFRG <cfrg@irtf.org>
Cc: Carsten Strunge <CAS@= energinet.dk>
Subject: Re: [Cfrg] Use of the term "depreca= ted"

 

Hi Erik,

 

For what it is worth, our =E2=80=9Csubjective=E2=80=9D Cisco approach includes th= e term Legacy which is equivalent to Deprecated. The definition is =E2=80=9C= Legacy algorithms provide a marginal but acceptable security level. They sho= uld be used only when no better alternatives are available, such as when int= eroperating with legacy equipment. It is recommended that these legacy algor= ithms be phased out and replaced with stronger algorithms.=E2=80=9D In the table https://www.cisco.co= m/c/en/us/about/security-center/next-generation-cryptography.html#2 you = will see we are flagging SHA1 as legacy, MD5 as avoid.

&nb= sp;

Rgs,

Panos

 

 

From: Cfrg [mailto:cfrg-bounces@irtf.org] On = Behalf Of Erik Andersen
Sent: Friday, December 08, 2017 4:03 A= M
To: Cfrg <cfrg@irtf.org>
Cc: Carsten Strunge <= ;CAS@energinet.dk>
Subject: [Cfrg] Use of the term "deprec= ated"

 

In the smart grid security standards the term deprecated is used = for certain cryptographic algorithms, such as SHA-1, instead of disallowing = them. NIST in SP 800-57, Part 1 Revision 4 has stopped using the term deprec= ated.

 

What is the general feeling among  list member= s on using the term deprecated on cryptographic algorithms?

 

Erik

--B_3595574687_1455961071-- --B_3595574687_1470976812 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgR76eIukWM40rTAzP 981o2BhKrLpjibSQv/V7c5IR/aQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTcxMjA4MTU0NDQ3WjANBgkqhkiG9w0BAQEFAASCAQCanemHFh4HH+r2oy6M jG7oVpetvkcdR6i7/N2bitcB1+0K17MUONAEW0L/V8gNc0p52M1wX2N6EqJQgZlWtBNdodJ7 yee6JFBj2J5UsvoBwhGzpIwmE8OvfjAlC0mg7Nuw4aEH0ZMI6rFQWuR6XQ6bewVbVkRdQPFv UDa86c742oyfh0N6j32w3cX0/1iN18VBU2S1J899H6/fsyJzflboP1zpMifa15kEGcei/bSt eZUPGqMlOKDr2FQSOyAtSPN1iFNRibp6w/igc71YJ0D9xQuPUoTH8zQQw633GhqNM3ohYR2/ EG2N6PcK/opjzmLn+0sKaKnlMd6+cZfHAjxF --B_3595574687_1470976812-- From nobody Wed Dec 13 07:04:12 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A70124B0A; Wed, 13 Dec 2017 07:04:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151317744523.30150.12359945272860305230@ietfa.amsl.com> Date: Wed, 13 Dec 2017 07:04:05 -0800 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-11.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:04:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : XMSS: Extended Hash-Based Signatures Authors : Andreas Huelsing Denis Butin Stefan-Lukas Gazdag Joost Rijneveld Aziz Mohaisen Filename : draft-irtf-cfrg-xmss-hash-based-signatures-11.txt Pages : 71 Date : 2017-12-13 Abstract: This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system. It follows existing descriptions in scientific literature. The note specifies the WOTS+ one-time signature scheme, a single-tree (XMSS) and a multi-tree variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can withstand so far known attacks using quantum computers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-11 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xmss-hash-based-signatures-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-xmss-hash-based-signatures-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 14 08:33:27 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3AE12941C for ; Thu, 14 Dec 2017 08:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6TEgGpUvbvD for ; Thu, 14 Dec 2017 08:33:23 -0800 (PST) Received: from smtp2.science.ru.nl (smtp2.science.ru.nl [131.174.16.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979B612940F for ; Thu, 14 Dec 2017 08:33:23 -0800 (PST) Received: from localhost.localdomain (ip-145-116-134-6.wlan-int.ru.nl [145.116.134.6]) (authen=benoit) by smtp2.science.ru.nl (8.14.4/5.32) with ESMTP id vBEGXKHg027160 for ; Thu, 14 Dec 2017 17:33:21 +0100 To: cfrg@irtf.org From: =?UTF-8?Q?Beno=c3=aet_Viguier?= Message-ID: <222451df-8795-7621-9fd9-043ada216c1b@science.ru.nl> Date: Thu, 14 Dec 2017 17:33:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A2221851D81A60DB871E7EF7" Content-Language: en-US Archived-At: Subject: [Cfrg] KangarooTwelve draft has been updated to 01 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 16:33:26 -0000 This is a multi-part message in MIME format. --------------A2221851D81A60DB871E7EF7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear CFRG participants I updated the RFC draft for KangarooTwelve with respect to the remarks of David Wong, Quynh Dang and the participants of IETF meeting in Prague. You can find the new version of the draft here: https://tools.ietf.org/html/draft-viguier-kangarootwelve-01 KangarooTwelve provides an efficient and secure hashing primitive, which is able to exploit the parallelism of the implementation in a scalable way. It uses tree hashing over a round-reduced version of SHAKE128 as underlying primitive. The reference code is also at available at:https://github.com/KeccakTeam/KeccakCodePackage (Standalone/KangarooTwelve-reference/K12.py) I intend to present the draft in London at the next CFRG meeting. -- Kind regards, Benoît Viguier Software Engineer - PhD Student | Cryptography & Formal Methods Radboud University | Mercator 1, room 03.17, Toernooiveld 212 6525 EC Nijmegen, the Netherlands | www.viguier.nl --------------A2221851D81A60DB871E7EF7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Dear CFRG participants

I updated the RFC draft for KangarooTwelve with respect to the remarks of
David Wong, Quynh Dang and the participants of IETF meeting in Prague.
You can find the new version of the draft here:
https://tools.ietf.org/html/draft-viguier-kangarootwelve-01

KangarooTwelve provides an efficient and secure hashing primitive, which is
able to exploit the parallelism of the implementation in a scalable way. It
uses tree hashing over a round-reduced version of SHAKE128 as underlying
primitive.
The reference code is also at available at:
https://github.com/KeccakTeam/KeccakCodePackage
(Standalone/KangarooTwelve-reference/K12.py)

I intend to present the draft in London at the next CFRG meeting.

-- 
Kind regards,

Benoît Viguier
Software Engineer - PhD Student | Cryptography & Formal Methods
Radboud University | Mercator 1, room 03.17, Toernooiveld 212
6525 EC Nijmegen, the Netherlands | www.viguier.nl
--------------A2221851D81A60DB871E7EF7-- From nobody Mon Dec 18 06:34:53 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40B12D7E4 for ; Mon, 18 Dec 2017 06:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePfKS22PFRcy for ; Mon, 18 Dec 2017 06:34:49 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57038124B17 for ; Mon, 18 Dec 2017 06:34:49 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-75-5a37d20748af Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 86.E8.27591.702D73A5; Mon, 18 Dec 2017 15:34:47 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 18 Dec 2017 15:34:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PyquNSyLOhBryd1FiAIsdZqKZaW/juBgzcsWBr9w4XA=; b=NzQ8pTLL6ch59sGnOZfynTU7LP+494agG5GmQWP3JUO1d49JcRJqEXCR8dt91bZURd3joMo4fvDI6U58PmiL23VQghPPTWp9b3fFAvdRmR1mK84fENSK8py425oMfFv8QpK6vdyHBjNGIdbEgDA97h7MesUdagg1CWe/FAs5M2M= Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) by HE1PR0701MB2009.eurprd07.prod.outlook.com (10.167.189.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Mon, 18 Dec 2017 14:34:45 +0000 Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::e053:8a18:a6e0:70e4]) by HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::e053:8a18:a6e0:70e4%13]) with mapi id 15.20.0345.013; Mon, 18 Dec 2017 14:34:45 +0000 From: John Mattsson To: =?utf-8?B?QmVub8OudCBWaWd1aWVy?= , "cfrg@irtf.org" Thread-Topic: [Cfrg] KangarooTwelve draft has been updated to 01 Thread-Index: AQHTdPlW3DMfadTsAkmaUm+JZkn7mqNJQTgA Date: Mon, 18 Dec 2017 14:34:45 +0000 Message-ID: <0A72A5A6-DDEE-4265-9159-8F3D0821BD6B@ericsson.com> References: <222451df-8795-7621-9fd9-043ada216c1b@science.ru.nl> In-Reply-To: <222451df-8795-7621-9fd9-043ada216c1b@science.ru.nl> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2009; 6:NvmPF9h2gdFaC84MSIaCMu5n1iTzwg0Tp4VpzeMnnBBYhNitU8IYzctsmuEEZMrSuHdi1LEzEllNRPolNUjGAwbKjycneh9IZYacwtDaj3q8JxHh/VTisbhdtvf/W3eXfBRUkWC9LBtOZGj0SyAHG0YV9sPzyJMRc66WZeSTLWXa+8i5gHqoCyvInvOLFVtd8R/Ot5sFwhmpC7BaIRW1zJbbmXS80wP+8MeNW1NoC8Vb6ZXoC4BuraSK6cvxTxK1ZfakALKgOu0CSC9GM3NkjcgpPtobD00HLMLgQasD5lFh5jjukVbtJh7pFpCXPwc8NJ8Tb8JB6T1UWeGGYNYinUQVg0YTDcJkJDO9TC77tok=; 5:zjXvDu3JubJtsvmnAQ86gFgNJUcB0/7irWcALx7Uyd0yRw6gaN2BSXPaBBJXXiJP7kG3UVI1yM5usEi3CsUrf+jDlW3M5EBmyXkMfGh9dWlVCuOIKQ/FVSPebuu/262U1rLyVfvigYEMrzm7UIF2sHgyI+RLzhM0j54cahOgi5k=; 24:7GW8bpj7hnRNV8ZnYJ9NBVtpCWYYHo5s0hq7KmfVTAlD8Pi4q+JkM1rIE840GjzGZTSk4+yV+JDHdlWKEb4VBoNIXLkHJFYCGwMnLt0yWZc=; 7:RuMZdiZN6jPqGjzGQr+1W8Z9v4cSBYGtZzx5TytuDhcfjsCSZMR/27nTXh1rnuQ9qcL8GuNO1cxa10MwnG5+rLmxMETNJlgi+0pf1R+l2c58XFcXRQcqFvcyOjYtA1OJbLGDH0eDlcGkMMez9dOSeAGbJ62ZBWjEn4oppUr6of/4CcyF/iY5bHuyhxxz47nTYJp34JWOV5x4SosXmkMFSBzFrcoCP4CxEdL6flJd2bXsdkT6Bo0Gzk0OipbC4ALR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f7b809d7-a876-4934-8514-08d546247c04 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:HE1PR0701MB2009; x-ms-traffictypediagnostic: HE1PR0701MB2009: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011); SRVR:HE1PR0701MB2009; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2009; x-forefront-prvs: 0525BB0ADF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(366004)(189003)(199004)(9326002)(83716003)(25786009)(10710500007)(68736007)(2950100002)(2900100001)(76176011)(316002)(5660300001)(106356001)(110136005)(105586002)(53936002)(606006)(53386004)(6246003)(58126008)(97736004)(99286004)(83506002)(2501003)(5250100002)(229853002)(2906002)(6306002)(236005)(6436002)(102836003)(3846002)(33656002)(86362001)(8676002)(81166006)(561944003)(81156014)(966005)(478600001)(7736002)(36756003)(82746002)(15650500001)(1680700002)(2420400007)(3280700002)(53546011)(3660700001)(7110500001)(6486002)(6116002)(59450400001)(14454004)(6512007)(8936002)(6506007)(66066001)(54896002)(554374003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2009; H:HE1PR0701MB2011.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0A72A5A6DDEE426591598F3D0821BD6Bericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f7b809d7-a876-4934-8514-08d546247c04 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2017 14:34:45.4668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2009 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c45247S4HNpvniBnIRLcpoIGkQp/ZH+oQVR1Chq6lFX3tpR cxIxdEa6DF0Xp24pJVE50GRilhe8hFmWsiTKIlsWutTUSjfwQtvOAv/7ned53u973sNHkyIz L4BW5BYwylx5tpjvTdWd7IQIgSVWFjXaFh7XZ5TGaR39RDyRePPJID/RZks6Ssi896cz2Yoi Rhl54Jx3VstvDZHvqEDFE73fSDVquIoqkRcNOAbWTJNEJfKmRXgQwduvGoHLEOGXCAxdKS6D wlUk/Gm38rlUIwFLd2Yp7mMGgX1VQ7lG+DgKjN1qvot9sRxWlh+SLt6OD0Jv3zji9HgwlG2Q HEfD1PCKW6fwLnA0LLuvFjrz+pV7PK5GPFSbLO6MF06AzVU14WKEd4D9lcnNJPaH0r+PeNw+ GJq7x0iO/cA2venW/bAUNrvmPLNnoLy81qnTzsxOsHakcPFgsDRqkWsvwEMCqL89SnCGFDpq Fjz/Kxk+jLYKuNADBFVN6wLO2ANt412eEnnw+ueip8RpMNxVk9xAMwnzhlrPqUEwPaSlqlFE /ZYlOE6DyR9GNwuxD4zUfafqnWVJvBtan0VykRC4pbUKOJZAucHo4USo7fjI35ppQvRj5Mcy bGpOZnS0lFEq0lg2L1eayxS0I+db6jevRT1FtpmEAYRpJN4mDB+LlYl48iJWlTOAgCbFvsKU N05JmC5XlTDKvLPKwmyGHUCBNCX2F44kCWUinCkvYC4wTD6j/O8StFeAGnmZJeNVMWvz4ccW dIsD2gmHVae/n3z402rIkcLA0ISK0EPnBbzgRSrrS7CqbPZSqVnya59uytcxqEytOGXv6b+R uJFhtlwcFsa8m7mmCGuRyO0+xh5TEJ+5fGXpuq5TczxZE8ZaaprW56zFn0tspdSJjFXVyFLC 88731Au9XkyxWfK94aSSlf8DkQxGfUcDAAA= Archived-At: Subject: Re: [Cfrg] KangarooTwelve draft has been updated to 01 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:34:52 -0000 --_000_0A72A5A6DDEE426591598F3D0821BD6Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gcG9zaXRpdmUgdG8gc3RhbmRhcmRpemF0aW9uIG9mIHRoaXMgZHJhZnQuIEhp Z2ggc3BlZWQgYWxnb3JpdGhtcyBhcmUgYWx3YXlzIHdlbGNvbWUgYXMgbG9uZyBhcyB0aGV5IG9m ZmVyIHN1ZmZpY2llbnQgc2VjdXJpdHkgbWFyZ2lucywgYW5kIGFzIGZhciBhcyBJIGNhbiB0ZWxs LCB0aGlzIHByb3Bvc2FsIGRvZXMganVzdCB0aGF0Lg0KDQoNCkkgcmVhZCB0aHJvdWdoIHRoZSBk cmFmdCBhbmQgaGF2ZSBzb21lIGhpZ2gtbGV2ZWwgY29tbWVudHM6DQoNCi0gSSB0aGluayB0aGUg ZHJhZnQgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIHRoZSBzYW1lIG5vdGF0aW9uIGFzIE5JU1QuIFdo aWxlIEkga2luZCBvZiBsaWtlIHRoZSBNLEMgbm90YXRpb24gaW4gZHJhZnQtdmlndWllci1rYW5n YXJvb3R3ZWx2ZSBiZXR0ZXIgdGhhbiB0aGUgWCxTIG5vdGF0aW9uIGJ5IE5JU1QsIEkgdGhpbmsg aGF2aW5nIGEgY29tbW9uIG5vdGF0aW9uIGZvciBhbGwgc3RhbmRhcmRpemVkIGFsZ29yaXRobXMg aW4gdGhlIEtlY2NhYy1mYW1pbHkgYXZvaWRzIGEgbG90IG9mIG1pc3VuZGVyc3RhbmRpbmcuDQoN Cg0KLSDigJxUaGUgU0hBLTMgZnVuY3Rpb25zIHByb2Nlc3MgZGF0YSBpbiBhIHNlcmlhbCBtYW5u ZXIgYW5kIGFyZSB1bmFibGUgdG8gb3B0aW1hbGx5IGV4cGxvaXQgcGFyYWxsZWxpc20gYXZhaWxh YmxlIGluIG1vZGVybiBDUFUgYXJjaGl0ZWN0dXJlc+KAnQ0KDQpJIHRoaW5rIHRoZSBkcmFmdCBz aG91bGQgcmVmZXIgdG8gUGFyYWxsZWxIYXNoIFtOSVNUIFNQIDgwMC0xODVdIGFuZCBleHBsYWlu IHdoYXQgYmVuZWZpdHMgS2FuZ2Fyb29Ud2VsdmUgaGFzIGNvbXBhcmVkIHRvIFBhcmFsbGVsSGFz aDEyOC4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGRpc2N1c3MgdGhlIEtlY2NhayBm YW1pbHkgKFNIQS0zLCBTSEFLRSwgY1NIQUtFLCBQYXJhbGxlbEhhc2gsIEthbmdhcm9vVHdlbHdl KSB3aXRoIGEgZmV3IG1vcmUgc2VudGVuY2VzIChlLmcuIHBvaW50aW5nIG91dCB0aGF0IFNIQS0z IGlzIG5vdCBhIFhPRiB3aGlsZSB0aGUgb3RoZXJzIGFyZSwgY3VzdG9taXphdGlvbiwgcGFyYWxs ZWxpc20sIG51bWJlciBvZiByb3VuZHMsIGV0Yy4gKS4NCg0KDQotIOKAnGFpbXMgYXQgaGlnaGVy IHNwZWVkIHRoYW4gU0hBS0UgYW5kIFNIQS0zLuKAnQ0KDQpEb2VzIGl0IHN1Y2NlZWQ/IEkgdGhp bmsgc29tZSBudW1iZXJzIGxpa2UgdGhlIG9uZSBwcmVzZW50ZWQgaW4gaHR0cHM6Ly9rZWNjYWsu dGVhbS8yMDE3L2lzX3NoYTNfc2xvdy5odG1sIHdvdWxkIGJlIGdvb2QuDQoNCg0KLSAiSXQgbWFr ZXMgbm8gYXNzZXJ0aW9uIHRvIGl0cyBzZWN1cml0eSINCg0KSSB0aGluayB0aGlzIGRvY3VtZW50 IGF0IGxlYXN0IG5lZWRzIHRvIHRlbGwgdGhlIHJlYWRlciB0aGF0IEthbmdvcm9vVHdlbHZlIHBy b3ZpZGVzIGEgMTI4LWJpdCBzZWN1cml0eSBzdHJlbmd0aC4NCg0KSSB0aGluayB0aGUgZG9jdW1l bnQgYWxzbyBuZWVkIHRvIGdpdmUgcmVxdWlyZW1lbnRzIGZvciB0aGUgcGFyYW1ldGVyIG91dHB1 dEJ5dGVMZW4uIERvaW5nIHNvLCBpdCBtaWdodCBuZWVkIHRvIGRpc2N1c3MgcHJlaW1hZ2UgYW5k IGNvbGxpc2lvbiBhdHRhY2tzLg0KDQoNCi0gSWYgQ0ZSRyBkZWNpZGVzIHRvIHN0YW5kYXJkaXpl IHRoaXMgKHdoaWNoIEkgdGhpbmsgaXQgc2hvdWxkKSwgdGhlcmUgc2hvdWxkIGJlIGRpc2N1c3Np b24gb24gd2hldGhlciBNYXJzdXBpbGFtaUZvdXJ0ZWVuIHNob3VsZCBhbHNvIGJlIHN0YW5kYXJk aXplZCwgd2hldGhlciBDRlJHIGFncmVlcyB3aXRoIHRoZSBkZWNpc2lvbiB0byBmaXggdGhlIHBh cmFtZXRlciBCIChOSVNUIGxlYXZlcyBpdCBhcyBhIHVzZXItY2hvc2VuIHBhcmFtZXRlciksIGFu ZCB3aGV0aGVyIENGUkcgYWdyZWVzIHRoYXQgQj04MTkyIGlzIHRoZSBiZXN0IGNob2ljZS4NCg0K Q2hlZXJzLA0KSm9obg0KDQpGcm9tOiBDZnJnIDxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmc+IG9uIGJl aGFsZiBvZiBCZW5vw650IFZpZ3VpZXIgPGIudmlndWllckBzY2llbmNlLnJ1Lm5sPg0KRGF0ZTog VGh1cnNkYXksIDE0IERlY2VtYmVyIDIwMTcgYXQgMTc6MzMNClRvOiAiY2ZyZ0BpcnRmLm9yZyIg PGNmcmdAaXJ0Zi5vcmc+DQpTdWJqZWN0OiBbQ2ZyZ10gS2FuZ2Fyb29Ud2VsdmUgZHJhZnQgaGFz IGJlZW4gdXBkYXRlZCB0byAwMQ0KDQoNCkRlYXIgQ0ZSRyBwYXJ0aWNpcGFudHMNCg0KSSB1cGRh dGVkIHRoZSBSRkMgZHJhZnQgZm9yIEthbmdhcm9vVHdlbHZlIHdpdGggcmVzcGVjdCB0byB0aGUg cmVtYXJrcyBvZg0KDQpEYXZpZCBXb25nLCBRdXluaCBEYW5nIGFuZCB0aGUgcGFydGljaXBhbnRz IG9mIElFVEYgbWVldGluZyBpbiBQcmFndWUuDQoNCllvdSBjYW4gZmluZCB0aGUgbmV3IHZlcnNp b24gb2YgdGhlIGRyYWZ0IGhlcmU6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC12aWd1aWVyLWthbmdhcm9vdHdlbHZlLTAxDQoNCg0KDQpLYW5nYXJvb1R3ZWx2ZSBwcm92aWRl cyBhbiBlZmZpY2llbnQgYW5kIHNlY3VyZSBoYXNoaW5nIHByaW1pdGl2ZSwgd2hpY2ggaXMNCg0K YWJsZSB0byBleHBsb2l0IHRoZSBwYXJhbGxlbGlzbSBvZiB0aGUgaW1wbGVtZW50YXRpb24gaW4g YSBzY2FsYWJsZSB3YXkuIEl0DQoNCnVzZXMgdHJlZSBoYXNoaW5nIG92ZXIgYSByb3VuZC1yZWR1 Y2VkIHZlcnNpb24gb2YgU0hBS0UxMjggYXMgdW5kZXJseWluZw0KDQpwcmltaXRpdmUuDQoNClRo ZSByZWZlcmVuY2UgY29kZSBpcyBhbHNvIGF0IGF2YWlsYWJsZSBhdDo8aHR0cHM6Ly9naXRodWIu Y29tL0tlY2Nha1RlYW0vS2VjY2FrQ29kZVBhY2thZ2U+DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9L ZWNjYWtUZWFtL0tlY2Nha0NvZGVQYWNrYWdlDQoNCihTdGFuZGFsb25lL0thbmdhcm9vVHdlbHZl LXJlZmVyZW5jZS9LMTIucHkpDQoNCg0KDQpJIGludGVuZCB0byBwcmVzZW50IHRoZSBkcmFmdCBp biBMb25kb24gYXQgdGhlIG5leHQgQ0ZSRyBtZWV0aW5nLg0KDQotLQ0KDQpLaW5kIHJlZ2FyZHMs DQoNCg0KDQpCZW5vw650IFZpZ3VpZXINCg0KU29mdHdhcmUgRW5naW5lZXIgLSBQaEQgU3R1ZGVu dCB8IENyeXB0b2dyYXBoeSAmIEZvcm1hbCBNZXRob2RzDQoNClJhZGJvdWQgVW5pdmVyc2l0eSB8 IE1lcmNhdG9yIDEsIHJvb20gMDMuMTcsIFRvZXJub29pdmVsZCAyMTINCg0KNjUyNSBFQyBOaWpt ZWdlbiwgdGhlIE5ldGhlcmxhbmRzIHwgd3d3LnZpZ3VpZXIubmw8aHR0cDovL3d3dy52aWd1aWVy Lm5sPg0K --_000_0A72A5A6DDEE426591598F3D0821BD6Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIiLHNlcmlmO30NCnNwYW4uZmluYWwtcGF0aA0KCXttc28tc3R5bGUtbmFtZTpmaW5hbC1w YXRoO30NCnNwYW4uc2VwYXJhdG9yDQoJe21zby1zdHlsZS1uYW1lOnNlcGFyYXRvcjt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYW0gcG9zaXRpdmUgdG8gc3RhbmRhcmRpemF0 aW9uIG9mIHRoaXMgZHJhZnQuIEhpZ2ggc3BlZWQgYWxnb3JpdGhtcyBhcmUgYWx3YXlzIHdlbGNv bWUgYXMgbG9uZyBhcyB0aGV5IG9mZmVyIHN1ZmZpY2llbnQgc2VjdXJpdHkgbWFyZ2lucywgYW5k IGFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGlzIHByb3Bvc2FsIGRvZXMganVzdCB0aGF0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgcmVhZCB0aHJvdWdoIHRoZSBk cmFmdCBhbmQgaGF2ZSBzb21lIGhpZ2gtbGV2ZWwgY29tbWVudHM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0gSSB0aGluayB0 aGUgZHJhZnQgc2hvdWxkIGNvbnNpZGVyIHVzaW5nIHRoZSBzYW1lIG5vdGF0aW9uIGFzIE5JU1Qu IFdoaWxlIEkga2luZCBvZiBsaWtlIHRoZSBNLEMgbm90YXRpb24gaW4gZHJhZnQtdmlndWllci1r YW5nYXJvb3R3ZWx2ZSBiZXR0ZXIgdGhhbiB0aGUgWCxTIG5vdGF0aW9uIGJ5IE5JU1QsIEkgdGhp bmsgaGF2aW5nIGEgY29tbW9uDQogbm90YXRpb24gZm9yIGFsbCBzdGFuZGFyZGl6ZWQgYWxnb3Jp dGhtcyBpbiB0aGUgS2VjY2FjLWZhbWlseSBhdm9pZHMgYSBsb3Qgb2YgbWlzdW5kZXJzdGFuZGlu Zy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0g4oCcVGhlIFNI QS0zIGZ1bmN0aW9ucyBwcm9jZXNzIGRhdGEgaW4gYSBzZXJpYWwgbWFubmVyIGFuZCBhcmUgdW5h YmxlIHRvIG9wdGltYWxseSBleHBsb2l0IHBhcmFsbGVsaXNtIGF2YWlsYWJsZSBpbiBtb2Rlcm4g Q1BVIGFyY2hpdGVjdHVyZXPigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIHJlZmVy IHRvIFBhcmFsbGVsSGFzaCBbTklTVCBTUCA4MDAtMTg1XSBhbmQgZXhwbGFpbiB3aGF0IGJlbmVm aXRzIEthbmdhcm9vVHdlbHZlIGhhcyBjb21wYXJlZCB0byBQYXJhbGxlbEhhc2gxMjguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBkaXNjdXNzIHRoZSBLZWNjYWsgZmFtaWx5IChT SEEtMywgU0hBS0UsIGNTSEFLRSwgUGFyYWxsZWxIYXNoLCBLYW5nYXJvb1R3ZWx3ZSkgd2l0aCBh IGZldyBtb3JlIHNlbnRlbmNlcyAoZS5nLiBwb2ludGluZyBvdXQgdGhhdCBTSEEtMyBpcyBub3Qg YSBYT0Ygd2hpbGUgdGhlIG90aGVycyBhcmUsDQogY3VzdG9taXphdGlvbiwgcGFyYWxsZWxpc20s IG51bWJlciBvZiByb3VuZHMsIGV0Yy4gKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4tIOKAnGFpbXMgYXQgaGlnaGVyIHNwZWVkIHRoYW4gU0hBS0UgYW5kIFNIQS0z LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5Eb2VzIGl0IHN1Y2NlZWQ/IEkgdGhpbmsgc29tZSBudW1iZXJzIGxpa2UgdGhl IG9uZSBwcmVzZW50ZWQgaW4gaHR0cHM6Ly9rZWNjYWsudGVhbS8yMDE3L2lzX3NoYTNfc2xvdy5o dG1sIHdvdWxkIGJlIGdvb2QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+LSAmcXVvdDtJdCBtYWtlcyBubyBhc3NlcnRpb24gdG8gaXRzIHNlY3VyaXR5JnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkkgdGhpbmsgdGhpcyBkb2N1bWVudCBhdCBsZWFzdCBuZWVkcyB0byB0ZWxsIHRoZSByZWFk ZXIgdGhhdCBLYW5nb3Jvb1R3ZWx2ZSBwcm92aWRlcyBhIDEyOC1iaXQgc2VjdXJpdHkgc3RyZW5n dGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkkgdGhpbmsgdGhlIGRvY3VtZW50IGFsc28gbmVlZCB0byBnaXZlIHJlcXVpcmVt ZW50cyBmb3IgdGhlIHBhcmFtZXRlciBvdXRwdXRCeXRlTGVuLiBEb2luZyBzbywgaXQgbWlnaHQg bmVlZCB0byBkaXNjdXNzIHByZWltYWdlIGFuZCBjb2xsaXNpb24gYXR0YWNrcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tIElmIENGUkcgZGVjaWRlcyB0byBzdGFu ZGFyZGl6ZSB0aGlzICh3aGljaCBJIHRoaW5rIGl0IHNob3VsZCksIHRoZXJlIHNob3VsZCBiZSBk aXNjdXNzaW9uIG9uIHdoZXRoZXIgTWFyc3VwaWxhbWlGb3VydGVlbiBzaG91bGQgYWxzbyBiZSBz dGFuZGFyZGl6ZWQsIHdoZXRoZXIgQ0ZSRyBhZ3JlZXMgd2l0aCB0aGUgZGVjaXNpb24gdG8gZml4 DQogdGhlIHBhcmFtZXRlciBCIChOSVNUIGxlYXZlcyBpdCBhcyBhIHVzZXItY2hvc2VuIHBhcmFt ZXRlciksIGFuZCB3aGV0aGVyIENGUkcgYWdyZWVzIHRoYXQgQj04MTkyIGlzIHRoZSBiZXN0IGNo b2ljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Sm9objxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkNmcmcgJmx0O2NmcmctYm91bmNl c0BpcnRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJlbm/DrnQgVmlndWllciAmbHQ7Yi52aWd1aWVy QHNjaWVuY2UucnUubmwmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCAxNCBEZWNlbWJl ciAyMDE3IGF0IDE3OjMzPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtjZnJnQGlydGYub3JnJnF1b3Q7 ICZsdDtjZnJnQGlydGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bQ2ZyZ10gS2FuZ2Fy b29Ud2VsdmUgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZCB0byAwMTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cHJlPkRlYXIgQ0ZSRyBwYXJ0aWNpcGFudHM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5JIHVwZGF0ZWQgdGhlIFJGQyBkcmFmdCBmb3IgS2FuZ2Fyb29Ud2VsdmUgd2l0aCBy ZXNwZWN0IHRvIHRoZSByZW1hcmtzIG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+RGF2aWQgV29u ZywgUXV5bmggRGFuZyBhbmQgdGhlIHBhcnRpY2lwYW50cyBvZiBJRVRGIG1lZXRpbmcgaW4gUHJh Z3VlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPllvdSBjYW4gZmluZCB0aGUgbmV3IHZlcnNpb24g b2YgdGhlIGRyYWZ0IGhlcmU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZpZ3VpZXIta2FuZ2Fyb290d2VsdmUtMDEiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12aWd1aWVyLWthbmdhcm9vdHdlbHZlLTAx PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl Pkthbmdhcm9vVHdlbHZlIHByb3ZpZGVzIGFuIGVmZmljaWVudCBhbmQgc2VjdXJlIGhhc2hpbmcg cHJpbWl0aXZlLCB3aGljaCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFibGUgdG8gZXhwbG9p dCB0aGUgcGFyYWxsZWxpc20gb2YgdGhlIGltcGxlbWVudGF0aW9uIGluIGEgc2NhbGFibGUgd2F5 LiBJdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVzZXMgdHJlZSBoYXNoaW5nIG92ZXIgYSByb3Vu ZC1yZWR1Y2VkIHZlcnNpb24gb2YgU0hBS0UxMjggYXMgdW5kZXJseWluZzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnByaW1pdGl2ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgcmVmZXJlbmNl IGNvZGUgaXMgYWxzbyBhdCBhdmFpbGFibGUgYXQ6PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L0tlY2Nha1RlYW0vS2VjY2FrQ29kZVBhY2thZ2UiPjxvOnA+PC9vOnA+PC9hPjwvcHJlPg0KPHBy ZT48c3BhbiBjbGFzcz0iTXNvSHlwZXJsaW5rIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v S2VjY2FrVGVhbS9LZWNjYWtDb2RlUGFja2FnZSI+aHR0cHM6Ly9naXRodWIuY29tL0tlY2Nha1Rl YW0vS2VjY2FrQ29kZVBhY2thZ2U8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPihT dGFuZGFsb25lLzxzcGFuIGNsYXNzPSJmaW5hbC1wYXRoIj5LYW5nYXJvb1R3ZWx2ZS1yZWZlcmVu Y2U8L3NwYW4+PHNwYW4gY2xhc3M9InNlcGFyYXRvciI+L0sxMi5weSk8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBpbnRlbmQgdG8g cHJlc2VudCB0aGUgZHJhZnQgaW4gTG9uZG9uIGF0IHRoZSBuZXh0IENGUkcgbWVldGluZy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5LaW5kIHJlZ2Fy ZHMsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ QmVub8OudCBWaWd1aWVyPG86cD48L286cD48L3ByZT4NCjxwcmU+U29mdHdhcmUgRW5naW5lZXIg LSBQaEQgU3R1ZGVudCB8IENyeXB0b2dyYXBoeSAmYW1wOyBGb3JtYWwgTWV0aG9kczxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlJhZGJvdWQgVW5pdmVyc2l0eSB8IE1lcmNhdG9yIDEsIHJvb20gMDMu MTcsIFRvZXJub29pdmVsZCAyMTI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT42NTI1IEVDIE5pam1l Z2VuLCB0aGUgTmV0aGVybGFuZHMgfCA8YSBocmVmPSJodHRwOi8vd3d3LnZpZ3VpZXIubmwiPnd3 dy52aWd1aWVyLm5sPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_0A72A5A6DDEE426591598F3D0821BD6Bericssoncom_-- From nobody Mon Dec 18 16:53:21 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4BC126BF0; Mon, 18 Dec 2017 16:53:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kenny.paterson@rhul.ac.uk, cfrg@ietf.org, irtf-chair@irtf.org, cfrg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151364479965.7395.7915051151060919545.idtracker@ietfa.amsl.com> Date: Mon, 18 Dec 2017 16:53:19 -0800 Archived-At: Subject: [Cfrg] cfrg - New Meeting Session Request for IETF 101 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 00:53:20 -0000 A new meeting session request has just been submitted by Kenny Paterson, a Chair of the cfrg working group. --------------------------------------------------------- Working Group Name: Crypto Forum Area Name: IRTF Session Requester: Kenny Paterson Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: tls Second Priority: quic People who must be present: Alexey Melnikov Kenny Paterson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Dec 19 17:57:01 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86636124234; Tue, 19 Dec 2017 17:56:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kenny.paterson@rhul.ac.uk, cfrg@ietf.org, irtf-chair@irtf.org, cfrg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151373501952.2749.658683232600829287.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 17:56:59 -0800 Archived-At: Subject: [Cfrg] cfrg - Update to a Meeting Session Request for IETF 101 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 01:56:59 -0000 An update to a meeting session request has just been submitted by Kenny Paterson, a Chair of the cfrg working group. --------------------------------------------------------- Working Group Name: Crypto Forum Area Name: IRTF Session Requester: Kenny Paterson Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: tls Second Priority: quic People who must be present: Alexey Melnikov Kenny Paterson Resources Requested: Special Requests: If possible please could you schedule on Monday or Tuesday of the week. --------------------------------------------------------- From nobody Wed Dec 20 00:30:53 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB771270B4; Wed, 20 Dec 2017 00:30:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: alexey.melnikov@isode.com, cfrg@ietf.org, irtf-chair@irtf.org, cfrg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151375865153.2621.5046074239666514645.idtracker@ietfa.amsl.com> Date: Wed, 20 Dec 2017 00:30:51 -0800 Archived-At: Subject: [Cfrg] cfrg - Update to a Meeting Session Request for IETF 101 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 08:30:51 -0000 An update to a meeting session request has just been submitted by Alexey Melnikov, a Chair of the cfrg working group. --------------------------------------------------------- Working Group Name: Crypto Forum Area Name: IRTF Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: tls saag quic lamps uta jmap dispatch Second Priority: extra People who must be present: Alexey Melnikov Kenny Paterson Resources Requested: Special Requests: If possible please could you schedule on Monday or Tuesday of the week, as Wednesday-Friday is a conflict for one of editors. Please also avoid conflicts with Security Area BoFs and WG. --------------------------------------------------------- From nobody Thu Dec 21 02:49:55 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7C41241F5 for ; Wed, 20 Dec 2017 10:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Air4Ls9ZB8Yq for ; Wed, 20 Dec 2017 10:53:31 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30044.outbound.protection.outlook.com [40.107.3.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFFF126B6E for ; Wed, 20 Dec 2017 10:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+2Aors0AlCMGwqvUMu3ph67J5AS62zT9d3Wao/GNYIo=; b=d46vk3fqxNRMiIM7VgZmqAB/bWgJ/CzHBIHAp2W+UHUcs12dIWvKq1GyuGtCBEX3kN38w4fGsfkG7rQnau17yunF1H4z2lGTP2x4F5EEgH6x8v7pOQoF/KDAwArkaYeYWGvJeSnLlizHzdCOdKd4zzjUwz0DgCswoucllWkobzA= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Wed, 20 Dec 2017 18:53:25 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::6d3b:b5be:a706:14e2]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::6d3b:b5be:a706:14e2%13]) with mapi id 15.20.0323.018; Wed, 20 Dec 2017 18:53:24 +0000 From: "Paterson, Kenny" To: "Stanislav V. Smyshlyaev" CC: Ronald Tse , "cfrg@irtf.org" , Wai Kit Wong , "alexey.melnikov@isode.com" Thread-Topic: [Cfrg] Review request for SM4 block cipher draft: draft-ribose-cfrg-sm4-00 Thread-Index: AQHTLgUmp7FpkMBAJECCcRFM3ApYHaK1sL8AgJcreYCAAE9dmA== Date: Wed, 20 Dec 2017 18:53:24 +0000 Message-ID: References: <3606FBCE-CFBA-4B88-A169-73148BF11773@ribose.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [85.255.237.118] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 6:CrnYNBTu90V/m6SCfIYxptB7mzPi+xUcBUiMK95EOrqKOVLHZux14OiRFC3jKzmydiZ7XMD26ps5JAv63QhSzflqKrFrXpz+/aovtV8pPi/ia179QieP3Am1F+1g0GGCGvll1xlSTBsd/YYzhbJlebZBlKI52p7nUVytjc7XVqu/JDkN+UcLYyBjg9o8T0EL5vydX9Oil1PvO+NeIxDgSxuV332pHCRQwzD3IpBEzw1mG2fIG9gxadOCPare+rkSmIMVxmQ2cNzEltWJL4x2QB4MnGCC368HJ/WF2ZK43SKdRD2SF16FnxvbbQxpSqfddV6B84Pef3zVx+Q/tNRSb+JmDAYNRQlTotrtbYSitDY=; 5:vnLKX+0LKbbn+N5QtE3LNv4WaPZP+DyoK9R9TS37DlzjuNEmOUgjp26ckup4ctHiFGpKb1fkfcYFwLlJVNUV3+2kCvG7cpCHvCoJaW8xP3YPHaqSBJTkoeSt8/cb8ScS+wZhKkr6wbr8AaGXochZtvPm4YimUEq3KP4o1kUx1ck=; 24:aCvCsV1ncXESPMJ1ZeEs7hBRXh02+e552nKJXwrhX9LJPOFVfzS4wJ5rs/wODTiX7Ow5N3lXtu7HQ3+ipbJoUyK594RfW4UpxzwLvDW4f54=; 7:DUsHuI12JI2yuFck0bvp+7SjRos6tXfsFeOuhLAHPKneYdKzpucJ5S0hyxF9p0ltzbPbWJdQnGhRXzWfilB1pawmq+JRSKN0HrJwzZSIRcVJ7feT82Zn4JNIlMH1R2ad0imXi+KLu5PvgkwtedcVvUimbEXaSKPunxPRph/ONlGsAQoOnjUAr+2i8m/v0iPLE62JREVwmpL1yG2rlfywsBWtjfCQF8jBDVdSvXOCi+Gt1SNE9youMATVJF3MIv+K x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(39380400002)(396003)(189003)(377424004)(57704003)(51444003)(199004)(24454002)(53386004)(8936002)(4001150100001)(68736007)(76176011)(606006)(14454004)(59450400001)(3660700001)(2906002)(83716003)(66066001)(316002)(72206003)(236005)(36756003)(345774005)(413944005)(786003)(74482002)(102836004)(966005)(6512007)(82746002)(230783001)(99286004)(6306002)(478600001)(54906003)(86362001)(1411001)(2950100002)(53936002)(5250100002)(106356001)(1680700002)(6916009)(42882006)(54896002)(105586002)(7736002)(6116002)(229853002)(6486002)(6436002)(8676002)(81166006)(53546011)(3846002)(81156014)(97736004)(6246003)(4326008)(2900100001)(33656002)(39060400002)(6506007)(25786009)(5660300001)(3280700002)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: f19ee69d-e0df-406f-f77c-08d547daf2da x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603307)(7153060); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(156092457628694); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(93006095)(93001095)(6041268)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0527DFA348 received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D8F69AA24FD8412DB13A68051F5A598Brhulacuk_" MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: f19ee69d-e0df-406f-f77c-08d547daf2da X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 18:53:24.4422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906 Archived-At: X-Mailman-Approved-At: Thu, 21 Dec 2017 02:49:53 -0800 Subject: Re: [Cfrg] Review request for SM4 block cipher draft: draft-ribose-cfrg-sm4-00 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 18:53:37 -0000 --_000_D8F69AA24FD8412DB13A68051F5A598Brhulacuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBTdGFuaXNsYXYsDQoNCkxldCBtZSB0aGFuayB5b3UgZm9yIHRoaXMgdmVyeSBkZXRhaWxl ZCByZXZpZXcuIEkgdmVyeSBtdWNoIGFwcHJlY2lhdGUgdGhlIGFtb3VudCBvZiBpbnRlbGxlY3R1 YWwgZWZmb3J0IGFuZCB0aW1lIGl0IHdvdWxkIGhhdmUgdGFrZW4gdG8gYnJpbmcgYWxsIG9mIHRo ZSByZWxldmFudCBsaXRlcmF0dXJlIHRvZ2V0aGVyIGFuZCB0byBzdHVkeSB0aGUgZGlmZmVyZW50 IHNjaGVtZXMgYXQgdGhpcyBsZXZlbCBvZiBkZXRhaWwuDQoNCkJlc3Qgd2lzaGVzLA0KDQpLZW5u eQ0KDQpPbiAyMCBEZWMgMjAxNywgYXQgMTQ6MDksIFN0YW5pc2xhdiBWLiBTbXlzaGx5YWV2IDxz bXlzaHN2QGdtYWlsLmNvbTxtYWlsdG86c215c2hzdkBnbWFpbC5jb20+PiB3cm90ZToNCg0KRG9j dW1lbnQ6IGRyYWZ0LXJpYm9zZS1vcGVucGdwLW9zY2NhLTAxIChhbmQgZHJhZnQtcmlib3NlLW9w ZW5wZ3Atc2NhLTAwKQ0KUmV2aWV3ZXI6IFN0YW5pc2xhdiBTbXlzaGx5YWV2DQpSZXZpZXcgRGF0 ZTogMjAxNy0xMi0yMA0KU3VtbWFyeTogTWFqb3IgcmV2aXNpb24gbmVlZGVkDQoNClRoZSBJLUQg ZGVzY3JpYmVzIHRoZSB1c2FnZSBvZiBTTTIsIFNNMyBhbmQgU000IGFsZ29yaXRobXMsIGRldmVs b3BlZCBpbiBDaGluYSwgaW4gT3BlblBHUC4gU00yIGRlZmluZXMgZGlnaXRhbCBzaWduYXR1cmUs IGtleSBleGNoYW5nZSBhbmQgcHVibGljIGtleSBlbmNyeXB0aW9uIGFsZ29yaXRobXMsIFNNMyBk ZWZpbmVzIGEgaGFzaCBmdW5jdGlvbiBhbmQgU000IGRlZmluZXMgYSAxMjgtYml0IGJsb2NrIDEy OC1iaXQga2V5IGJsb2NrIGNpcGhlci4NCg0KSW4gdGhpcyByZXZpZXcgcHJlcGFyZWQgYXMgYSBt ZW1iZXIgb2YgQ3J5cHRvIFJldmlldyBQYW5lbCwgaGVuY2UgdGhlIGZvY3VzIGlzIG5vdCBvbiB0 ZWNobmljYWwgaXNzdWVzIHJlbGF0ZWQgdG8gT3BlblBHUCBpdHNlbGYsIHRoZSByZXZpZXcgaXMg YmVpbmcgZG9uZSBmcm9tIHRoZSBjcnlwdG9ncmFwaGljIHBlcnNwZWN0aXZlLiBOZXZlcnRoZWxl c3MsIGZ1bGwgY3J5cHRhbmFseXNpcyBvZiAzIGFsZ29yaXRobXMgZnJvbSBhIHNjcmF0Y2ggaXMg aW1wb3NzaWJsZSB0byBiZSBtYWRlIGFzIGEgcGFydCBvZiByZXZpZXcsIHNvIHRoZSBhbmFseXNp cyBpcyBjb25kdWN0ZWQgaGVhdmlseSB0YWtpbmcgaW50byBhY2NvdW50IGN1cnJlbnQgc3RhdGUg b2YgdGhlIGFuYWx5c2lzIG9mIHRoZSBwcm9wb3NlZCBtZWNoYW5pc21zLg0KDQpUaGUgY3VycmVu dCByZXZpZXcgaXMgY29uZHVjdGVkIGJhc2VkIG9uIHRoZSBJLUQgaXRzZWxmIGFuZCBhbHNvIEkt RHMgZHJhZnQtc2NhLWNmcmctc20zLTAwIGFuZCBkcmFmdC1yaWJvc2UtY2ZyZy1zbTQtMDgsIHBy b3ZpZGluZyBtYXRlcmlhbCBvbiBkZXNpZ24gcmF0aW9uYWxlIGFuZCBwdWJsaXNoZWQgc2VjdXJp dHkgYW5hbHlzaXMgb2YgU00zIGFuZCBTTTQuIEF0IHRoZSB0aW1lIG9mIHRoaXMgcmV2aWV3IHRo ZSBTTTIgSS1EIGRvZXMgbm90IGNvbnRhaW4gc2ltaWxhciBtYXRlcmlhbCwgdGh1cyBJIHRoaW5r IHRoYXQgYSBuZXcgcmV2aWV3IGxhdGVyIGlzIG5lY2Vzc2FyeSBhZnRlciBzdWNoIGEgbWF0ZXJp YWwgb24gU00yIGlzIGFkZGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIEktRCAodGhlIGF1dGhvciwg Um9uYWxkIFRzZSwgaGFzIHNhaWQgdGhhdCB0aGUgY29ycmVzcG9uZGluZyB3b3JrIGlzIGluIHBy b2dyZXNzKS4NCg0KDQpTTTINCg0KVGhlIHN1bW1hcnkgb2YgdGhlIGtub3duIHJlc3VsdHMgZm9y IFNNMiBpcyBub3QgcHJvdmlkZWQgaW4gdGhlIEktRCBmb3IgU00yLCBzbyBhIHNob3J0IHN1bW1h cnkgaXMgcHJvdmlkZWQgaGVyZSBpbiB0aGUgcmV2aWV3Lg0KDQpTTTIgWzE2XSBpcyBhIHNldCBv ZiB0aHJlZSBwdWJsaWMga2V5IGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBiYXNlZCBvbiBlbGxp cHRpYyBjdXJ2ZXM6IHNpZ25hdHVyZSBhbGdvcml0aG0sIGtleSBleGNoYW5nZSBwcm90b2NvbCwg YW5kIHB1YmxpYyBrZXkgZW5jcnlwdGlvbiBhbGdvcml0aG0uIFRoZXNlIGFsZ29yaXRobXMgYW5k IHJlY29tbWVuZGVkIHBhcmFtZXRlcnMgYXJlIHB1Ymxpc2hlZCBieSBDaGluZXNlIENvbW1lcmNp YWwgQ3J5cHRvZ3JhcGh5IEFkbWluaXN0cmF0aW9uIE9mZmljZSBmb3IgdGhlIHVzZSBvZiBlbGVj dHJvbmljIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2Ugc3lzdGVtLiBJbiBbMjVdLCB0aGUgY2xhc3Mg b2Ygc2lnbmF0dXJlIGFsZ29yaXRobXMgaXMgYW5hbHl6ZWQsIHdoaWNoIGluY2x1ZGVzIHRoZSBT TTIgc2lnbmF0dXJlIGFsZ29yaXRobS4gTW9yZSBleGFjdGx5LCB0aGUgZ2VuZXJhbGl6ZWQga2V5 IHN1YnN0aXR1dGlvbiBhdHRhY2tzIGFyZSBpbnZlc3RpZ2F0ZWQgd2hlcmUgdGhlIGJhc2UgZWxl bWVudCBpcyBjb25zaWRlcmVkIGFzIGEgcGFydCBvZiB0aGUgcHVibGljIGtleSBhbmQgY2FuIGJl IHN1YnN0aXR1dGVkLiBJdCBpcyBwcm92ZW4gdGhhdCB0aGUgQ2hpbmVzZSBzdGFuZGFyZCBTTTIg c2lnbmF0dXJlIHNjaGVtZSBpcyBleGlzdGVudGlhbGx5IHVuZm9yZ2VhYmxlIGFnYWluc3QgYWRh cHRpdmVseSBjaG9zZW4tbWVzc2FnZSBhdHRhY2tzIGluIHRoZSBnZW5lcmljIGdyb3VwIG1vZGVs IGlmIHRoZSB1bmRlcmx5aW5nIGhhc2ggZnVuY3Rpb24gaXMgdW5pZm9ybSBhbmQgY29sbGlzaW9u LXJlc2lzdGFudCBhbmQgdGhlIHVuZGVybHlpbmcgY29udmVyc2lvbiBmdW5jdGlvbiBpcyBhbG1v c3QtaW52ZXJ0aWJsZSwgYW5kIHRoZSBTTTIgZGlnaXRhbCBzaWduYXR1cmUgc2NoZW1lIGlzIHNl Y3VyZSBhZ2FpbnN0IHRoZSBnZW5lcmFsaXplZCBrZXkgc3Vic3RpdHV0aW9uIGF0dGFja3MgaWYg dGhlIHVuZGVybHlpbmcgaGFzaCBmdW5jdGlvbnMgYXJlIG1vZGVsZWQgYXMgbm9uLXByb2dyYW1t YWJsZSByYW5kb20gb3JhY2xlcyAoTlBST3MpLg0KDQpJbiBbMTFdLCB0aGUgcGFydGlhbGx5IGtu b3duIG5vbmNlcyBhdHRhY2sgYWdhaW5zdCBTTTIgYXJlIGRpc2N1c3NlZC4gSXQgaXMgc2hvd24g YnkgdGhlIGV4cGVyaW1lbnRzIHRoYXQgdGhlIHByaXZhdGUga2V5IGNhbiBiZSByZWNvdmVyZWQs IGdpdmVuIDEwMCBzaWduYXR1cmVzIHdpdGggMyBiaXRzIG9mIG5vbmNlcyBrbm93biBmb3IgMjU2 LWJpdCBTTTIuIEFsc28gYSBieXRlLWZhdWx0IGF0dGFjayBvbiBTTTIgaXMgZGV2ZWxvcGVkIHdo ZW4gYSBieXRlIG9mIHJhbmRvbSBmYXVsdCBpcyBpbmplY3RlZCBvbiB0aGUgc2VjcmV0IGtleSBk dXJpbmcgdGhlIHNpZ25pbmcgcHJvY2Vzcy4gSW4gWzNdLCBhIHByYWN0aWNhbCBsYXR0aWNlLWJh c2VkIGZhdWx0IGF0dGFjayBhZ2FpbnN0IFNNMiBzaWduYXR1cmUgYWxnb3JpdGhtIGluIGEgc21h cnQgY2FyZCBpcyBwcmVzZW50ZWQuIEF1dGhvcnMgb2YgWzNdIHN1Y2Nlc3NmdWxseSB1dGlsaXpl ZCB0aGUgbGFzZXIgZmF1bHQgYXR0YWNrIHRvIHNraXAgdGhlIGluc3RydWN0aW9ucyBvZiBub25j ZXMgYmVpbmcgd3JpdHRlbiBpbnRvIFJBTSwgc28gdGhhdCB0aGUgbm9uY2VzIGluIHNpZ25hdHVy ZXMgc2hhcmUgcGFydGlhbCBzYW1lIGJpdHMgZnJvbSBlYWNoIG90aGVyLiBOZXh0LCB0aGV5IGJ1 aWxkIHRoZSBtb2RlbCBvZiBsYXR0aWNlIGF0dGFjayBhbmQgcmVjb3ZlciB0aGUgcHJpdmF0ZSBr ZXkuIFRoZSBleHBlcmltZW50YWwgcmVzdWx0cyBzaG93IHRoYXQgb25seSAzIGZhdWx0eSBzaWdu YXR1cmVzIGFyZSBuZWVkZWQgdG8gbW91bnQgbGF0dGljZSBhdHRhY2sgc3VjY2Vzc2Z1bGx5IGlu IGFib3V0IDMyIMK1cy4gTW9yZW92ZXIsIHRoZXkgcHJvcG9zZWQgYSBuZXcgY291bnRlcm1lYXN1 cmUgZm9yIFNNMiBzaWduYXR1cmUgYWxnb3JpdGhtIHRvIHJlc2lzdCBsYXR0aWNlLWJhc2VkIGZh dWx0IGF0dGFjayBieSBkZXN0cm95aW5nIHRoZSBjb25kaXRpb24gb2YgbGF0dGljZSBhdHRhY2sg cmF0aGVyIHRoYW4gdGh3YXJ0aW5nIGZhdWx0IGF0dGFjay4gSXQgaXMgcHJvdmVuIHRoYXQgdGhl IGNvdW50ZXJtZWFzdXJlIGNhbiBndWFyYW50ZWUgdGhlIGFiaWxpdHkgdG8gcmVzaXN0IGxhdHRp Y2UgYXR0YWNrLCBldmVuIGlmIHNvbWUgaW5mb3JtYXRpb24gb2YgdGhlIG5vbmNlcyBpcyBsZWFr ZWQuIEFzIG5vdGVkIGluIFs3XSwgdGhlIFNNMiBzaWduYXR1cmUgYWxnb3JpdGhtIGFzIHdlbGwg YXMgdGhlIFJ1c3NpYW4gc3RhbmRhcmQgR09TVCBSIDM0LjEwLTIwMTIsIGFuZCB0aGUgRUNEU0Eg YWxnb3JpdGhtIGZpdHMgaW50byB0aGUgZ2VuZXJhbCBzY2hlbWUgb2YgdGhlIEVsR2FtYWwgc2ln bmF0dXJlIGFsZ29yaXRobSwgcHJvcG9zZWQgYmFjayBpbiAxOTk3IGluIHRoZSBjbGFzc2ljIG1v bm9ncmFwaCBbMTRdLiBJbiBbMjBdLCBhcHBhcmVudGx5IGNvbmNlcm5pbmcgdGhlIGVhcmxpZXIg dmVyc2lvbiBvZiB0aGUgU00yIGtleSBleGNoYW5nZSBwcm90b2NvbCwgaXQgaXMgc2hvd24gdGhh dCB0aGlzIHZlcnNpb24gaXMgdnVsbmVyYWJsZSB0byByZWFsaXN0aWMgYXR0YWNrcyBpbiB0aGUg Q2FuZXR0aS1LcmF3Y3p5ayBtb2RlbCwgaW4gd2hpY2ggYW4gYWR2ZXJzYXJ5IG9ubHkga25vd3Mg dGhlIHN0YXRlIG9mIHRoZSBzZXNzaW9uLiBTaW1wbGUgbW9kaWZpY2F0aW9ucyBvZiB0aGlzIHZl cnNpb24gYXJlIHByb3Bvc2VkLCB3aGljaCBlbGltaW5hdGUgdGhpcyBwcm9ibGVtLiBJbiBbMjFd LCB0aGUgc2VjdXJpdHkgb2YgdGhlIFNNMiBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgaW4gdGhlIHdp ZGVzcHJlYWQgQmVsbGFyZS1Sb2dhd2F5IG1vZGVsIGlzIHByb3ZlZCB1bmRlciB0aGUgYXNzdW1w dGlvbiB0aGF0IHRoZSBkaXNjcmV0ZSBsb2dhcml0aG0gcHJvYmxlbSBmb3IgZWxsaXB0aWMgY3Vy dmVzIGlzIGhhcmQuIEFsc28gaW4gdGhpcyBwYXBlciBhIHNpbXBsaWZpZWQgYnV0IG1vcmUgZWZm ZWN0aXZlIHZlcnNpb24gb2YgdGhpcyBwcm90b2NvbCBpcyBwcmVzZW50ZWQgdG9nZXRoZXIgd2l0 aCBhIHNpbWlsYXIgc2VjdXJpdHkgcHJvb2YuDQoNCkJhc2VkIG9uIHRoZSBwdWJsaXNoZWQgcmVz dWx0cywgSSBzZWUgbm8gcmVhc29ucyB0byBvYmplY3QgYWdhaW5zdCB1c2luZyB0aGUgU00yIGRp Z2l0YWwgc2lnbmF0dXJlIHNjaGVtZSBhbmQgdGhlIFNNMiBwdWJsaWMga2V5IGVuY3J5cHRpb24g Zm9yIHNlY3VyZSBlbGxpcHRpYyBjdXJ2ZXMuDQpOZXZlcnRoZWxlc3MsIEknZCBwcmVmZXIgdG8g Y29uZHVjdCBhbiBhZGRpdGlvbmFsIHJldmlldyBhZnRlciBhIHNlY3Rpb24gYWJvdXQgZGVzaWdu IHJhdGlvbmFsZSBhbmQgYSBzdW1tYXJ5IG9mIGNyeXB0YW5hbHl0aWMgcmVzdWx0cyBpcyBhZGRl ZCB0byB0aGUgU00yIEktRC4NCg0KDQpTTTMNCg0KVGhlIFNNMyBoYXNoIGZ1bmN0aW9uIFsxN10g aXMgY29uc3RydWN0ZWQgb24gdGhlIGNyeXB0b2dyYXBoaWMgcHJpbmNpcGxlcyBlbWJlZGRlZCBp biB0aGUgTUQ0IGhhc2ggZnVuY3Rpb24gZmFtaWx5LCBvciBtb3JlIHByZWNpc2VseSwgaW4gdGhl IFNIQS0yIGhhc2ggZnVuY3Rpb25zLiBJbiB0aGUgNiB5ZWFycyBzaW5jZSBwdWJsaWNhdGlvbiBv ZiB0aGUgU00zIGhhc2ggZnVuY3Rpb24sIHNvbWUgYXR0YWNrcyBvbiB0cnVuY2F0ZWQgdmVyc2lv bnMgaGF2ZSBiZWVuIGJ1aWx0LiBUaGVzZSBhcmUgYXR0YWNrcyBvZiBmaW5kaW5nIHByZWltYWdl LCBjb2xsaXNpb25zLCBwc2V1ZG8tY29sbGlzaW9ucyBhbmQgZnJlZS1zdGFydCBjb2xsaXNpb25z LCBhcyB3ZWxsIGFzIGF0dGFja3Mgb2YgY29uc3RydWN0aW5nIGJvb21lcmFuZy1kaXN0aW5ndWlz aGVycy4gSW4gWzE5XSwgdGhlIHByZWltYWdlIGF0dGFja3MgdHJhbnNmb3JtZWQgaW50byBhdHRh Y2tzIG9mIGNvbnN0cnVjdGluZyBwc2V1ZG8tY29sbGlzaW9ucyBmb3IgdmVyc2lvbnMgb2YgdGhl IFNNMyBoYXNoIGZ1bmN0aW9uLCB0cnVuY2F0ZWQgdG8gMjksIDMwLCAzMSBhbmQgMzIgc3RlcHMs IHdpdGggY29tcGxleGl0aWVzIDJeMTIyICwgMl4xMjUuMSAsIDJeMTIyIGFuZCAyXjEyNS4xICwg cmVzcGVjdGl2ZWx5LiBJbiBbMTNdLCByZWFsIGNvbGxpc2lvbnMgd2VyZSBmb3VuZCB3aXRoIHBy YWN0aWNhbCBjb21wbGV4aXR5IGZvciB0aGUgMjAgKG9mIDY0KSBzdGVwcyBTTTMgaGFzaCBmdW5j dGlvbiwgYW5kIHJlYWwgZnJlZS1zdGFydCBjb2xsaXNpb25zIHdlcmUgZm91bmQgd2l0aCBwcmFj dGljYWwgY29tcGxleGl0eSBmb3IgdGhlIDI0IHN0ZXBzIFNNMyBoYXNoIGZ1bmN0aW9uLg0KDQpC YXNlZCBvbiB0aGUgcHVibGlzaGVkIHJlc3VsdHMsIEkgc2VlIG5vIHJlYXNvbnMgdG8gb2JqZWN0 IGFnYWluc3QgdXNpbmcgdGhlIFNNMyBoYXNoIGZ1bmN0aW9uLg0KDQoNClNNNA0KDQpTTVM0IFs1 XSwgaXNzdWVkIGluIDIwMDYgYnkgQ2hpbmVzZSBnb3Zlcm5tZW50LCBzZXJ2ZXMgdGhlIFdBUEkg KFdMQU4gQXV0aGVudGljYXRpb24gYW5kIFByaXZhY3kgSW5mcmFzdHJ1Y3R1cmUpIGFzIHRoZSB1 bmRlcmxpbmcgYmxvY2sgY2lwaGVyIGZvciB0aGUgc2VjdXJpdHkgb2Ygd2lyZWxlc3MgTEFOcy4g SW4gMjAxMiwgU01TNCB3YXMgYW5ub3VuY2VkIGFzIHRoZSBDaGluZXNlIGNvbW1lcmNpYWwgYmxv Y2sgY2lwaGVyIHN0YW5kYXJkLCByZW5hbWVkIHRvIFNNNC4gU000IGlzIGEgMzItcm91bmQgYmxv Y2sgY2lwaGVyIHdpdGggdGhlIHNhbWUgYmxvY2sgbGVuZ3RoIGFuZCBrZXkgZXF1YWwgdG8gMTI4 IGJpdC4NClVubGlrZSBvdGhlciBvcGVuIENoaW5lc2UgY3J5cHRvZ3JhcGhpYyBzdGFuZGFyZHMg KFNNMiBhbmQgU00zKSwgdGhlIGJsb2NrIGNpcGhlciBTTTQgYXR0cmFjdGVkIG1vcmUgYXR0ZW50 aW9uIG9mIHRoZSBpbnRlcm5hdGlvbmFsIGNyeXB0b2dyYXBoaWMgY29tbXVuaXR5LiBTbyBpbiBb OV0gdGhlIGludGVncmFsIGF0dGFjayBpcyBwcm9wb3NlZCBmb3IgdGhlIDEzLXJvdW5kIHZlcnNp b24gb2YgdGhlIFNNNCBjaXBoZXIuIEluIFs4XSwgdGhlIHJlY3RhbmdsZSBhbmQgYm9vbWVyYW5n IGF0dGFja3Mgb24gMTgtcm91bmQgU000IGFuZCB0aGUgbGluZWFyIGFuZCBkaWZmZXJlbnRpYWwg YXR0YWNrcyBvbiAyMi1yb3VuZCBTTTQgaGF2ZSBiZWVuIHByZXNlbnRlZC4gVXNpbmcgdGhlIHRl Y2huaXF1ZSBvZiBtdWx0aXBsZSBsaW5lYXIgYXBwcm94aW1hdGlvbnMsIGluIFs2XSBhbiBhdHRh Y2sgd2FzIGRldmVsb3BlZCBmb3IgdGhlIDIyLSBhbmQgMjMtcm91bmQgdmVyc2lvbiBvZiBTTTQu IEluIFsyNF0sIHRoZSByZXN1bHRzIG9mIFs2XSBmb3IgdGhlIDIyLXJvdW5kIHZlcnNpb24gd2Vy ZSBpbXByb3ZlZC4gVGhlIGJlc3QgZGlmZmVyZW50aWFsIGF0dGFja3MgdG8gZGF0ZSBmb3IgdGhl IDIzLXJvdW5kIHZlcnNpb24gb2YgU000IHdlcmUgb2J0YWluZWQgaW4gWzE4XS4gRm9yIHRoZSBz YW1lIHZlcnNpb24gb2YgU000LCB0aGUgbXVsdGlkaW1lbnNpb25hbCBsaW5lYXIgYXR0YWNrIHdh cyBwcm9wb3NlZCBpbiBbNF0uIFRoZSBiZXN0IGxpbmVhciBhdHRhY2tzIHRvIGRhdGUgZm9yIHRo ZSAyMy0gYW5kIDI0LXJvdW5kIHZlcnNpb24gb2YgU000IGhhdmUgYmVlbiBkZXZlbG9wZWQgaW4g WzEwXSBhbmQgWzEyXSwgcmVzcGVjdGl2ZWx5LiBJbiBbMjNdIGl0IGlzIHNob3duIHRoYXQgdGhl IFNNNCBjaXBoZXIgaXMgcmVzaXN0YW50IHRvIGRpZmZlcmVudGlhbCBjcnlwdGFuYWx5c2lzIGlu IHRoZSByZWxhdGVkIGtleSBtb2RlbCBmb3IgdmVyc2lvbnMgc3RhcnRpbmcgYXQgMTkgcm91bmRz LiBJdCBpcyBhbHNvIHdvcnRoIG1lbnRpb25pbmcgaGVyZSB0aGUgcGFwZXIgWzIyXSwgaW4gd2hp Y2ggbG93ZXIgYm91bmRzIGFyZSBvYnRhaW5lZCBmb3IgdGhlIG51bWJlciBvZiDigJwgbGluZWFy bHkgYWN0aXZl4oCdIFMtYm94ZXMgZm9yIFNNNC1saWtlIGJsb2NrIGNpcGhlcnMuDQoNCkJhc2Vk IG9uIHRoZSBwdWJsaXNoZWQgcmVzdWx0cywgSSBzZWUgbm8gcmVhc29ucyB0byBvYmplY3QgYWdh aW5zdCB1c2luZyB0aGUgU000IGNpcGhlci4NCg0KDQpUaGUgZWxsaXB0aWMgY3VydmUgcGFyYW1l dGVycw0KDQpUaGVyZSBpcyBubyBzdWZmaWNpZW50IG1hdGVyaWFsIG9uIGEgcHJvdmlkZWQgZWxs aXB0aWMgY3VydmUsIHNvIHNvbWUgYW5hbHlzaXMgaXMgbWFkZSBpbiB0aGUgY3VycmVudCByZXZp ZXcuDQoNClRoZSBwcm92aWRlZCBzaG9ydCBXZWllcnN0cmFzcyBlcXVhdGlvbiBjb2VmZmljaWVu dHMgY29ycmVjdGx5IGRlZmluZSB0aGUgZWxsaXB0aWMgY3VydmUgKGl0IGhhcyBub24tbnVsbCBk aXNjcmltaW5hbnQpLiBUaGUgai1pbnZhcmlhbnQgb2YgdGhlIGN1cnZlIGlzIG5vdCBlcXVhbCB0 byAwIG9yIDE3MjguIFRoZSBvcmRlciBvZiB0aGUgcHJvdmlkZWQgY3VydmUgcG9pbnRzIGdyb3Vw IG0gZXF1YWxzIDExNTc5MjA4OTIxMDM1NjI0ODc1NjQyMDM0NTIxNDAyMDg5Mjc2NjA2MTYyMzcy NDk1Nzc0NDU2Nzg0MzgwOTM1NjI5MzQzOTA0NTkyMyBhbmQgaXMgcHJpbWUuICBUaGUgcHJvdmlk ZWQgYmFzZSBwb2ludCBiZWxvbmdzIHRvIHRoZSBjdXJ2ZSBhbmQgaGFzIG9yZGVyIHEgZXF1YWwg dG8gbS4gVGhlcmVmb3JlIGNvZmFjdG9yIGggb2YgdGhlIHNwZWNpZmllZCBzdWJncm91cCBlcXVh bHMgdG8gMS4gVGhlIG9yZGVyIG9mIHRoZSBzdWJncm91cCBpcyBiaWcgZW5vdWdoIChhYm91dCAy XjI1NikgdG8gbWFrZSBhdHRhY2tzIGJhc2Ugb24gUG9sbGFyZOKAmXMgcmhvIG1ldGhvZCBpbmVm ZmVjdGl2ZS4gU2luY2UgcSAhPSBwIGVmZmVjdGl2ZSBhZGRpdGl2ZSB0cmFuc2ZlcnMgYXJlIG5v dCBwb3NzaWJsZS4gTU9WLWF0dGFja3MgYXJlIGluZWZmZWN0aXZlIHNpbmNlIHRoZSBjdXJ2ZSBo YXMgaGlnaCBlbWJlZGRpbmcgZGVncmVlIChlcXVhbHMgcS0xKS4gVGhlIGFic29sdXRlIHZhbHVl IG9mIGNvbXBsZXggbXVsdGlwbGljYXRpb24gZGlzY3JpbWluYW50IGlzIGFib3V0IDJeMjU3IGFu ZCBmdWxseSBzYXRpc2ZpZXMgcmVxdWlyZW1lbnRzIG9mIHRoZSBTYWZlQ3VydmVzIChbMjddKS4g VGhlIGF0dGFjayBieSBQZXRpdCwgS29zdGVycyBhbmQgTWVzc2VuZyAoWzI4XSkgd2hpY2ggZW1w bG95cyBTZW1hZXYgc3VtbWF0aW9uIHBvbHlub21pYWxzIGlzIGFsc28gaW5lZmZlY3RpdmUgc2lu Y2UgYWxsIHNldHMgb2Ygc21hbGwgZmFjdG9yIG9mIHAtMSAobmFtZWx5IDIgYW5kIDQzKSBtZWV0 IGNyaXRlcmlvbiwgcHJvdmlkZWQgaW4gWzI5XS4NCg0KSXQgY2FuIHNob3duIHRoYXQgZ3JvdXAg b2YgcG9pbnRzIG9mIHRoZSBxdWFkcmF0aWMgdHdpc3Qgb2YgdGhlIGN1cnZlIGhhcyBvcmRlciBt 4oCZIGVxdWFsIHRvIDExNTc5MjA4OTIxMDM1NjI0ODc1NjQyMDM0NTIxNDAyMDg5Mjc2NjQzOTA4 NDI1ODg5MDYzODM0MDk5ODU3ODUxMDI4NTkzMDkzODA3Ny4gVGhlIGxhcmdlc3Qgc3ViZ3JvdXAg aGFzIHRoZSBvcmRlciBx4oCZID0gMzM2OTQyMjU5MTQ4MzU4MDE0MzI2NjE4Nzc2MjA2MDgxNjA0 MTY1NTIwMTAzIHdpdGggY29mYWN0b3IgaOKAmT0gMzQzNjU1NTg1MDkzNTA0NjY2NDQ3MDA1NzUy Mjg0MDU5LiBTaW5jZSBx4oCZIGlzIGFib3V0IDJeMTQ3IFBvbGxhcmTigJlzIHJobyBhbGdvcml0 aG0gaXMgbW9yZSBlZmZlY3RpdmUgaGVyZSB0aGFuIG9uIHRoZSBvcmlnaW5hbCBjdXJ2ZS4gU2lu Y2UgceKAmSBpcyBub3QgZXF1YWwgdG8gcCBhbmQgb3JkKHApIGluIFoqKHHigJkpIGVxdWFscyAo cSctMSkvMTEgdGhlcmUgZXhpc3QgbmVpdGhlciBlZmZlY3RpdmUgYWRkaXRpdmUgdHJhbnNmZXJz IG5vciBlZmZlY3RpdmUgbXVsdGlwbGljYXRpdmUgdHJhbnNmZXJzLiBJdCBpcyBpbXBvcnRhbnQg dG8gbm90ZSwgaG93ZXZlciwgdGhlIHByb3ZpZGVkIGN1cnZlIGNhbm5vdCBiZSByZXdyaXR0ZW4g aW4gTW9udGdvbWVyeSBmb3JtLg0KDQpUaGUgcHJvdmlkZWQgY3VydmUgc2F0aXNmaWVzIGFsbCBt b2Rlcm4gc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiBIb3dldmVyLCBzb21lIGNsYXJpZmljYXRpb25z IG9uIHRoZSBzZWxlY3Rpb24gb2YgdmFsdWVzIG9mIGIsIHgoUCksIHkoUCkgaGF2ZSB0byBiZSBw cm92aWRlZDogc29tZSBraW5kIG9mIE5VTVMtdHlwZSBhcmd1bWVudHMgYXJlIGRlc2lyYWJsZS4N Cg0KDQpHZW5lcmFsIGNvbW1lbnRzIGZvciB0aGUgSS1EDQoNClRoZXJlIGFyZSBhIGxvdCBvZiB3 b3JkcyBhYm91dCBPU0NDQS9TQ0EtY29tcGxpYW5jZS4gSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMg aXMgaW1wb3J0YW50IGZvciBhbiBJRVRGIGRvY3VtZW50IC0gbWF5YmUgaXQgd291bGQgYmUgYmV0 dGVyIG5vdCB0byBtZW50aW9uIHRoZXNlIHJlZ3VsYXRvcnkgaXNzdWVzLg0KDQpBIGxvdCBvZiBy ZWZlcmVuY2VzIGlzIGdpdmVuIHRvIE9TQ0NBL1NDQSBkb2N1bWVudHMgYW5kIENoaW5lc2Ugc3Rh bmRhcmRzIC0gbWF5YmUgaXQgd2lsbCBiZSBiZXR0ZXIgdG8gdXNlIHJlZmVyZW5jZXMgdG8gSUVU RiBJLURzL1JGQ3MgZm9yIFNNMiwgU00zLCBTTTQuDQoNClRocm91Z2hvdXQgdGhlIHRleHQgdGhl cmUgYXJlICJNVVNUIiBjb2Rld29yZHMgYWJvdXQgImEgY29tcGxpYW50IE9wZW5QR1AgaW1wbGVt ZW50YXRpb24iIC0gaXQgc2VlbXMgdG8gYmUgdG9vIHN0cmljdCB0byB1c2UgTVVTVCBjb2Rld29y ZCB3aGVuIGRpc2N1c3Npbmcgb3B0aW9uYWwgYWxnb3JpdGhtcy9wYXJhbWV0ZXJzIHRvIHVzZSB3 aXRoIHNvbWUgcHJvdG9jb2xzL2ltcGxlbWVudGF0aW9ucy4NCg0KVGhlcmUgYXJlIHNvbWUgcHJv YmxlbXMgd2l0aCBsaW5rcyB0byBvc2NjYS5nb3YuY248aHR0cDovL29zY2NhLmdvdi5jbj4gLSBt YXliZSB0aGUgc2l0ZSBoYXMgYmVlbiBkb3duIHJlY2VudCBkYXlzLCBidXQgSSBjb3VsZG4ndCBv cGVuIHRoZXNlIGxpbmtzLiBEbyB3ZSBuZWVkIHRoZW0gcHJvdmlkZWQgdGhhdCB3ZSBoYXZlIFJG Q3MgYW5kIG90aGVyIGxpbmtzPw0KDQoNClBhcnRpY3VsYXIgY29tbWVudHMNCg0KU2VjdGlvbiAx Og0KU000IGlzIGNhbGxlZCAia000Ii4NCkFib3V0IFNNMyAoYSBoYXNoKSBpbnN0ZWFkIG9mICJl bGVjdHJvbmljIGF1dGhlbnRpY2F0aW9uIiBhbmQgImRhdGEgdmFsaWRhdGlvbiIgaXQgd291bGQg YmV0dGVyIHNheSBzb21ldGhpbmcgbGlrZSAiaW50ZWdyaXR5Ii4NCkluICJzdXBwb3J0IHRoZSBT TTQgc3ltbWV0cmljIGVuY3J5cHRpb24gYWxnb3JpdGhtIGZvciBkYXRhIHByb3RlY3Rpb24gcHVy cG9zZXMiIEknZCBwcmVmZXIgdG8gc2F5IGFib3V0ICJjb25maWRlbnRpYWxpdHkiLCBub3QgInBy b3RlY3Rpb24iIChlc3BlY2lhbGx5IHNpbmNlIFNNNCBkb2VzIG5vdCBkZWZpbmUgYSBNQUMgbW9k ZSkuDQoiU00zIHdpdGggb3RoZXIgZGlnaXRhbCBzaWduaW5nIGFsZ29yaXRobXMsIHN1Y2ggYXMg UlNBLCBFQ0RTQSBhbmQgU00yIjogMSkgInNpZ25pbmciLT4ic2lnbmF0dXJlIjsgMikgRUMtUkRT QSBmcm9tICBJU08vSUVDIDE0ODg4LTMgaXMgYWxzbyBhcHByb3ByaWF0ZSBoZXJlLg0KDQpTZWN0 aW9uIDMsIGZpcnN0IHNlbnRlbmNlOiAidGhleSIgc2VlbXMgdG8gYmUgb21pdHRlZCBhZnRlciAi YW5kIi4NCg0KU2VjdGlvbiA0OiAiZWxsaXB0aWNhbCIgLT4gImVsbGlwdGljIi4NCg0KU2VjdGlv biA0LjE6IGRvIHdlIG5lZWQgdG8gc2F5IGFib3V0IHRoaXMgb3B0aW9uYWwgWkEgZmllbGQgZnJv bSBTTTIgc3RhbmRhcmQ/IEFuZCBwZXJzb25hbGx5IEkgZG9uJ3QgbGlrZSB0aGlzIGRvdWJsZSBo YXNoaW5nIChIKFpBfHwgSChtc2cpKSkuDQpJIGFtIG5vdCBzdXJlIHRoYXQgc2VjdGlvbiA0LjIg aXMgbmVlZGVkOiBpdCBpcyBzYWlkIHRoYXQgdGhpcyBhbGdvcml0aG0gaXMgbm90IHJlbGF0ZWQg dG8gT3BlblBHUCBhbmQgYWxzbyBoYXMgc2VjdXJpdHkgaXNzdWVzIC0gSSdkIHJlY29tbWVuZCB0 byByZW1vdmUgdGhpcyBwYXJ0IGZyb20gdGhlIGRvY3VtZW50IGF0IGFsbC4NCg0KU2VjdGlvbiA0 LjQuMjogSSdkIHJlY29tbWVuZCB0byBzYXkgdGhhdCB0aGUgY3VydmUgaXMgZGVmaW5lZCBvdmVy IGEgY2VydGFpbiBmaW5pdGUgZmllbGQgaW4gc2hvcnQgV2VpZXJzdHJhc3MgZm9ybS4NCg0KU2Vj dGlvbiA0LjQuMzogSSdkIHByZWZlciB0byBzZWUgYWxzbyB3b3JkcyBhYm91dCB0aGUgY29mYWN0 b3Igb2YgdGhlIGdyb3VwIGFuZCB0aGF0IGFsbCBudW1iZXJzIGFyZSBpbiBiaWctZW5kaWFuIGZv cm0uDQoNClNlY3Rpb24gNC41LjE6IEl0IHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseSB0aGF0 IGFsbCBudW1iZXJzIGFyZSBpbiBsaXR0bGUtZW5kaWFuIG9yIGJpZy1lbmRpYW4uDQoNClNlY3Rp b24gNS4NCkEgbWlzcHJpbnQ6ICJjcnlwdG9ncnBhaGljIi4NCkluc3RlYWQgb2YgImRpZ2l0YWwg c2lnbmF0dXJlcyBhbmQgdGhlaXIgdmVyaWZpY2F0aW9uIiBpdCB3b3VsZCBiZXR0ZXIgc2F5ICJk aWdpdGFsIHNpZ25hdHVyZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb24iLg0KV2hlbiB3ZSBz YXkgYWJvdXQgTUFDaW5nIG9yIFBSTkdzLCBzcGVjaWZpYyBjb25zdHJ1Y3Rpb25zIHNob3VsZCBi ZSBtZW50aW9uZWQsIGluIG15IG9waW5pb24uIE90aGVyd2lzZSwgSSdkIHByZWZlciBub3QgdG8g aGF2ZSB0aGVzZSBnZW5lcmFsIHdvcmRzIGFib3V0IFNNMyBhcHBsaWNhdGlvbnMgKHRoZXkgYXJl IHRoZSBzYW1lIGFzIGZvciBhbnkgaGFzaCBmdW5jdGlvbikuDQpUaGVyZSBpcyBhIHBhcmFtZXRl ciAibSIsIHdoaWNoIHNlZW1zIG5vdCB0byBiZSBkZWZpbmVkIGF0IHRoYXQgbW9tZW50Lg0KDQpT ZWN0aW9uIDY6IGl0IHNlZW1zIHRvIGJlIHVzZWZ1bCB0byBkZWZpbmUgd2hldGhlciB0aGUgUy1i b3ggaXMgZml4ZWQgb3IgdmFyaWFibGUuDQpUaGUgbm90ZSBpcyBtaXNzaW5nIHRoYXQgU000IGlz IGFuIHVuYmFsYW5jZWQgRmVpc3RlbCBuZXR3b3JrIOKAkyB0aGlzIHNlZW1zIG1vcmUgaW1wb3J0 YW50IHRoYW4gdGhlIG5vdGUgdGhhdCBpdCBpcyBkZXNpZ25lZCBmb3IgZW5jcnlwdGlvbi4NCg0K SW4gc2VjdGlvbiA3LjMgdGhlcmUgaXMgYSBtaXN0YWtlIGluIHRoZSBzZWNvbmQgcGFyYWdyYXBo OiB0aGlzIGlzIG5vdCBhICJzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbGdvcml0aG0iLg0KDQpJbiBz ZWN0aW9uIDkuMyAid2hvbGUgbnVtYmVyIiAtPiAiaW50ZWdlciIuICJIYSEiIGRvZXNuJ3QgbG9v ayBhIGdvb2QgdmFyaWFibGUgbmFtZS4gU2luY2UgbiBpcyBhbiBpbnRlZ2VyLCBjZWlsIGlzIG5v dCBuZWVkZWQuDQoNCkluIHNlY3Rpb24gMTQgdGhlIHNlY29uZCBwYXJhZ3JhcGggZG9lc24ndCBs b29rIGFjY3VyYXRlIGVub3VnaC4gRm9yIGluc3RhbmNlLCAiRUNETFAiIHNlZW1zIG1vcmUgYXBw cm9wcmlhdGUgdGhhbiAiRUNMUCIuIFJlZ2FyZGluZyB0aGUgZGlnaXRhbCBzaWduYXR1cmUsIGEg cmVmZXJlbmNlIHRvIHRoZSBoYXNoIGlzIGFsc28gbmVlZGVkIGhlcmUuIFJlZ2FyZGluZyB0aGUg a2V5IGV4Y2hhbmdlIHNjaGVtZSAtIG5vdCBvbmx5IGEgcmVmZXJlbmNlIHRvIGRpc2NyZXRlIGxv Z2FyaXRobSBwcm9ibGVtLCBidXQgYWxzbyB0byBDREgvRERIIGlzIGRlc2lyYWJsZS4NCiJyYW5k b21seSBnZW5lcmF0ZWQgd2l0aG91dCBmaXhlZCBjb3JyZWxhdGlvbiIgLSB0aGUgc2VudGVuY2Ug bG9va3MgYSBsaXR0bGUgc3RyYW5nZSBiZWNhdXNlIG9mICJmaXhlZCIuDQoNClNlY3Rpb24gMTU6 IE1heWJlIGl0IHdvdWxkIGJlIGJldHRlciB0byBzYXkgImhhcyBtYWRlIiBhZnRlciB0aGUgYXNz aWdubWVudHMgYXJlIG1hZGUuDQoNCg0KUmVmZXJlbmNlcw0KDQpbMV0gQmFpIEQuLCBZdSBILiwg V2FuZyBHLiwgV2FuZyBYLjogSW1wcm92ZWQgQm9vbWVyYW5nIEF0dGFja3Mgb24gU00zLiBJbjog Qm95ZCBDLixTaW1wc29uIEwuIChlZHMpIEluZm9ybWF0aW9uIFNlY3VyaXR5IGFuZCBQcml2YWN5 LiBBQ0lTUCAyMDEzLiBMZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZvbCA3OTU5 LCBwcC4gMjUx4oCTMjY2LiBTcHJpbmdlciwgQmVybGluLCBIZWlkZWxiZXJnICgyMDEzKS4NClsy XSBCYWkgRC4sIFl1IEguLCBXYW5nIEcuLCBXYW5nIFguOiBJbXByb3ZlZCBib29tZXJhbmcgYXR0 YWNrcyBvbiByb3VuZC1yZWR1Y2VkIFNNMyBhbmQga2V5ZWQgcGVybXV0YXRpb24gb2YgQkxBS0Ut MjU2LiBJRVQgSW5mb3JtYXRpb24gU2VjdXJpdHkgOSgzKTogcHAuIDE2N+KAkzE3OCAoMjAxNSku DQpbM10gQ2FvIFcuLCBGZW5nIEouLCBaaHUgUy4sIENoZW4gSC4sIFd1IFcuLCBIYW4gWC4sIFpo ZW5nIFguOiBQcmFjdGljYWwgTGF0dGljZS1CYXNlZCBGYXVsdCBBdHRhY2sgYW5kIENvdW50ZXJt ZWFzdXJlIG9uIFNNMiBTaWduYXR1cmUgQWxnb3JpdGhtLiBJbjogUWluZyBTLiwgT2thbW90byBF LiwgS2ltIEsuLCBMaXUgRC4gKGVkcykgSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIFNl Y3VyaXR5LiBJQ0lDUyAyMDE1LiBMZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZv bCA5NTQzLCBwcC4gNjLigJM3MC4gU3ByaW5nZXIsIENoYW0gKDIwMTUpLg0KWzRdIENobyBKLiwg TnliZXJnIEsuOiBJbXByb3ZlZCBMaW5lYXIgQ3J5cHRhbmFseXNpcyBvZiBTTVM0IEJsb2NrIENp cGhlci4gU3ltbWV0cmljIEtleSBFbmNyeXB0aW9uIFdvcmtzaG9wLCBwcC4gMeKAkzE0LiAoMjAx MSkuIGh0dHA6Ly9za2V3MjAxMS5tYXQuZHR1LmRrL3Byb2NlZWRpbmdzL0ltcHJvdmVkJTIwTGlu ZWFyJTIwQ3J5cHRhbmFseXNpcyUyMG9mJTIwU01TNCUyMEJsb2NrJTIwQ2lwaGVyLnBkZg0KWzVd IERpZmZpZSBXLiwgTGVkaW4gRy46IFNNUzQgRW5jcnlwdGlvbiBBbGdvcml0aG0gZm9yIFdpcmVs ZXNzIE5ldHdvcmtzLiBDcnlwdG9sb2d5IGVQcmludCBBcmNoaXZlIDIwMDgvMzI5LiBodHRwOi8v ZXByaW50LmlhY3Iub3JnLzIwMDgvMzI5LnBkZg0KWzZdIEV0cm9nIEouLCBSb2JzaGF3IE0uIEou IEIuOiBUaGUgQ3J5cHRhbmFseXNpcyBvZiBSZWR1Y2VkLVJvdW5kIFNNUzQuIEluOiBBdmFuemkg Ui4gTS4sIEtlbGloZXIgTC4sIFNpY2EgRi4gKGVkcykgU2VsZWN0ZWQgQXJlYXMgaW4gQ3J5cHRv Z3JhcGh5LiBTQUMgMjAwOC4gTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlLCB2b2wg NTM4MSwgcHAuIDUx4oCTNjUuIFNwcmluZ2VyLCBCZXJsaW4sIEhlaWRlbGJlcmcgKDIwMDkpLg0K WzddIEZlcnNjaCBNLiwgS2lsdHogRS4sIFBvZXR0ZXJpbmcgQi46IE9uIHRoZSBPbmUtUGVyLU1l c3NhZ2UgVW5mb3JnZWFiaWxpdHkgb2YgKEVDKURTQSBhbmQgSXRzIFZhcmlhbnRzLiBJbjogS2Fs YWkgWS4sIFJleXppbiBMLiAoZWRzKSBUaGVvcnkgb2YgQ3J5cHRvZ3JhcGh5LiBUQ0MgMjAxNy4g TGVjdHVyZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlLCB2b2wgMTA2NzgsIHBwLiA1MTnigJM1 MzQuIFNwcmluZ2VyLCBDaGFtICgyMDE3KS4NCls4XSBLaW0gVC4sIEtpbSBKLiwgSG9uZyBTLiwg U3VuZyBKLjogTGluZWFyIGFuZCBEaWZmZXJlbnRpYWwgQ3J5cHRhbmFseXNpcyBvZiBSZWR1Y2Vk IFNNUzQgQmxvY2sgQ2lwaGVyLiBJQUNSIENyeXB0b2xvZ3kgZVByaW50QXJjaGl2ZSAyMDA4LzI4 MSwgKDIwMDgpLiBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDA4LzI4MTEucGRmDQpbOV0gTGl1 IEYuLCBKaSBXLiwgSHUgTC4sIERpbmcgSi4sIEx2IFMuLCBQeXNoa2luIEEuLCBXZWlubWFubiBS Li1QLjogQW5hbHlzaXMgb2YgdGhlIFNNUzQgQmxvY2sgQ2lwaGVyLiBJbjogUGllcHJ6eWsgSi4s IEdob2Rvc2kgSC4sIERhd3NvbiBFLiAoZWRzKSBJbmZvcm1hdGlvbiBTZWN1cml0eSBhbmQgUHJp dmFjeS4gQUNJU1AgMjAwNy4gTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlLCB2b2wg NDU4NiwgcHAuIDE1OOKAkzE3MC4gU3ByaW5nZXIsIEJlcmxpbiwgSGVpZGVsYmVyZyAoMjAwNyku DQpbMTBdIExpdSBNLi1KLiwgQ2hlbiBKLi1aLjogSW1wcm92ZWQgTGluZWFyIEF0dGFja3Mgb24g dGhlIENoaW5lc2UgQmxvY2sgQ2lwaGVyIFN0YW5kYXJkLiBKLiBDb21wdXQuIFNjaS4gVGVjaG5v bC4gKDIwMTQpIDI5KDYpOiBwcC4gMTEyM+KAkzExMzMuICgyMDE0KS4NClsxMV0gTGl1IE0uLCBD aGVuIEouLCBMaSBILjogUGFydGlhbGx5IEtub3duIE5vbmNlcyBhbmQgRmF1bHQgSW5qZWN0aW9u IEF0dGFja3Mgb24gU00yIFNpZ25hdHVyZSBBbGdvcml0aG0uIEluOiBMaW4gRC4sIFh1IFMuLCBZ dW5nIE0uIChlZHMpIEluZm9ybWF0aW9uIFNlY3VyaXR5IGFuZCBDcnlwdG9sb2d5LiBJbnNjcnlw dCAyMDEzLiBMZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZvbCA4NTY3LCBwcC4g MzQz4oCTMzU4LiBTcHJpbmdlciwgQ2hhbSAoMjAxNCkuDQpbMTJdIExpdSBZLiwgTGlhbmcgSC4s IFdhbmcgVy4sIFdhbmcgTS46IE5ldyBMaW5lYXIgQ3J5cHRhbmFseXNpcyBvZiBDaGluZXNlIENv bW1lcmNpYWwgQmxvY2sgQ2lwaGVyIFN0YW5kYXJkIFNNNC4gU2VjdXJpdHkgYW5kIENvbW11bmlj YXRpb24gTmV0d29ya3MuIFZvbHVtZSAyMDE3LCBBcnRpY2xlIElEIDE0NjE1MjAsIDEwIHBhZ2Vz ICgyMDE3KS4gaHR0cDovL2Rvd25sb2Fkcy5oaW5kYXdpLmNvbS9qb3VybmFscy9zY24vMjAxNy8x NDYxNTIwLnBkZg0KWzEzXSBNZW5kZWwgRi4sIE5hZCBULiwgU2NobMKoIGFmZmVyIE0uOiBGaW5k aW5nIENvbGxpc2lvbnMgZm9yIFJvdW5kLVJlZHVjZWQgU00zLiBJbjogRGF3c29uIEUuIChlZHMp IFRvcGljcyBpbiBDcnlwdG9sb2d5IOKAlCBDVC1SU0EgMjAxMy4gQ1QtUlNBIDIwMTMuIExlY3R1 cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDc3NzksIHBwLiAxNzQtMTg4LiBTcHJp bmdlciwgQmVybGluLCBIZWlkZWxiZXJnICgyMDEzKS4NClsxNF0gTWVuZXplcyBBLiBKLiwgdmFu IE9vcnNjaG90IFAuIEMuLCBWYW5zdG9uZSBTLiBBLjogSGFuZGJvb2sgb2YgQXBwbGllZCBDcnlw dG9ncmFwaHkuIFRoZSBDUkMgUHJlc3Mgc2VyaWVzIG9uIGRpc2NyZXRlIG1hdGhlbWF0aWNzIGFu ZCBpdHMgYXBwbGljYXRpb25zLCBDUkMgUHJlc3MsIDIwMDAgTi5XLiBDb3Jwb3JhdGUgQmx2ZC4s IEJvY2EgUmF0b24sIEZMIDMzNDMxLTk4NjgsIFVTQSAoMTk5NykuDQpbMTVdIFNoZW4gWS4sIEJh aSBELiwgWXUgSC46IEltcHJvdmVkIGNyeXB0YW5hbHlzaXMgb2Ygc3RlcC1yZWR1Y2VkIFNNMy4g U2NpZW5jZSBDaGluYSBJbmZvcm1hdGlvbiBTY2llbmNlcywgNjEgKDIwMTcpOiBwcC4gMeKAkzIu DQpbMTZdIFNoZW4gUy4sIExlZSBYLjogU00yIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobS4g SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwgSW50ZXJuZXQtRHJhZnQgZHJhZnQtc2hl bi1zbTItZWNkc2EtMDIsIEZlYnJ1YXJ5IDE0LCAyMDE0LiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2hlbi1zbTItZWNkc2EtMDINClsxN10gU2hlbiBTLiwgTGVlIFguOiBTTTMg SGFzaCBmdW5jdGlvbi4gSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwgSW50ZXJuZXQt RHJhZnQgZHJhZnQtc2hlbi1zbTMtaGFzaC0wMSwgRmVicnVhcnkgMTQsIDIwMTQuIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGVuLXNtMy1oYXNoLTAxDQpbMThdIFN1IEIuLVou LCBXdSBXLi1MLiwgWmhhbmcgVy4tVC46IFNlY3VyaXR5IG9mIHRoZSBTTVM0IEJsb2NrIENpcGhl ciBBZ2FpbnN0IERpZmZlcmVudGlhbCBDcnlwdGFuYWx5c2lzLiBKLiBDb21wdXQuIFNjaS4gVGVj aG5vbC4gKDIwMTEpIDI2KDEpOiBwcC4gMTMw4oCTMTM4LiAoMjAxMSkuDQpbMTldIFdhbmcgRy4s IFNoZW4gWS46IFByZWltYWdlIGFuZCBwc2V1ZG8tY29sbGlzaW9uIGF0dGFja3Mgb24gc3RlcC1y ZWR1Y2VkIFNNMyBoYXNoIGZ1bmN0aW9uLiBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIExldHRlcnMs IDIwMTMsIDExMywgcHAuIDMwMeKAkzMwNiwgKDIwMTMpLg0KWzIwXSBYdSBKLiwgRmVuZyBELjog Q29tbWVudHMgb24gdGhlIFNNMiBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wuIEluOiBMaW4gRC4sIFRz dWRpayBHLiwgV2FuZyBYLiAoZWRzKSBDcnlwdG9sb2d5IGFuZCBOZXR3b3JrIFNlY3VyaXR5LiBD QU5TIDIwMTEuIExlY3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDcwOTIsIHBw LiAxNjDigJMxNzEuIFNwcmluZ2VyLCBCZXJsaW4sIEhlaWRlbGJlcmcgKDIwMTEpLg0KWzIxXSBZ YW5nIEEuLCBOYW0gSiwgS2ltIE0uLCBDaG9vIEsuLUsuIFIuOiBQcm92YWJseS1TZWN1cmUgKENo aW5lc2UgR292ZXJubWVudCkgU00yIGFuZCBTaW1wbGlmaWVkIFNNMiBLZXkgRXhjaGFuZ2UgUHJv dG9jb2xzLiBUaGUgU2NpZW50aWZpYyBXb3JsZCBKb3VybmFsLCBWb2x1bWUgMjAxNCwgQXJ0aWNs ZSBJRCA4MjU5ODQgKDIwMTQpLiBodHRwczovL3d3dy5oaW5kYXdpLmNvbS9qb3VybmFscy90c3dq LzIwMTQvODI1OTg0Lw0KWzIyXSBaaGFuZyBCLiwgSmluIEMuOiBQcmFjdGljYWwgc2VjdXJpdHkg YWdhaW5zdCBsaW5lYXIgY3J5cHRhbmFseXNpcyBmb3IgU01TNC1saWtlIGNpcGhlcnMgd2l0aCBT UCByb3VuZCBmdW5jdGlvbi4gU2NpLiBDaGluYSBJbmYuIFNjaS4gKDIwMTIpIDU1KDkpOiBwcC4g MjE2MeKAkzIxNzAuICgyMDEyKS4NClsyM10gWmhhbmcgSi4sIFd1IFcuLCBaaGVuZyBZLjogU2Vj dXJpdHkgb2YgU000IEFnYWluc3QgKFJlbGF0ZWQtS2V5KSBEaWZmZXJlbnRpYWwgQ3J5cHRhbmFs eXNpcy4gSW46IEJhbyBGLiwgQ2hlbiBMLiwgRGVuZyBSLiwgV2FuZyBHLiAoZWRzKSBJbmZvcm1h dGlvbiBTZWN1cml0eSBQcmFjdGljZSBhbmQgRXhwZXJpZW5jZS4gSVNQRUMgMjAxNi4gTGVjdHVy ZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlLCB2b2wgMTAwNjAsIHBwLiA2NeKAkzc4LiBTcHJp bmdlciwgQ2hhbSAoMjAxNikuDQpbMjRdIFpoYW5nIFcuLCBXdSBXLiwgRmVuZyBELiwgU3UgQi46 IFNvbWUgTmV3IE9ic2VydmF0aW9ucyBvbiB0aGUgU01TNCBCbG9jayBDaXBoZXIgaW4gdGhlIENo aW5lc2UgV0FQSSBTdGFuZGFyZC4gSW46IEJhbyBGLiwgTGkgSC4sIFdhbmcgRy4gKGVkcykgSW5m b3JtYXRpb24gU2VjdXJpdHkgUHJhY3RpY2UgYW5kIEV4cGVyaWVuY2UuIElTUEVDIDIwMDkuIExl Y3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDU0NTEsIHBwLiAzMjTigJMzMzUu IFNwcmluZ2VyLCBCZXJsaW4sIEhlaWRlbGJlcmcgKDIwMDkpLg0KWzI1XSBaaGFuZyBaLiwgWWFu ZyBLLiwgWmhhbmcgSi4sIENoZW4gQy46IFNlY3VyaXR5IG9mIHRoZSBTTTIgU2lnbmF0dXJlIFNj aGVtZSBBZ2FpbnN0IEdlbmVyYWxpemVkIEtleSBTdWJzdGl0dXRpb24gQXR0YWNrcy4gSW46IENo ZW4gTC4sIE1hdHN1byBTLiAoZWRzKSBTZWN1cml0eSBTdGFuZGFyZGlzYXRpb24gUmVzZWFyY2gu IExlY3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDk0OTcsIHBwLiAxNDDigJMx NTMuIFNwcmluZ2VyLCBDaGFtICgyMDE1KS4NClsyNl0gWm91IEouLCBXdSBXLiwgV3UgUy4sIFN1 IEIuLCBEb25nIEwuOiBQcmVpbWFnZSBBdHRhY2tzIG9uIFN0ZXAtUmVkdWNlZCBTTTMgSGFzaCBG dW5jdGlvbi4gSW46IEtpbSBILiAoZWRzKSBJbmZvcm1hdGlvbiBTZWN1cml0eSBhbmQgQ3J5cHRv bG9neSDigJQgSUNJU0MgMjAxMS4gSUNJU0MgMjAxMS4gTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRl ciBTY2llbmNlLCB2b2wgNzI1OSwgcHAuIDM3NS0zOTAuIFNwcmluZ2VyLCBCZXJsaW4sIEhlaWRl bGJlcmcgKDIwMTIpLg0KWzI3XSBodHRwczovL3NhZmVjdXJ2ZXMuY3IueXAudG8vZGlzYy5odG1s DQpbMjhdIFBldGl0IEMuLCBLb3N0ZXJzIE0uLCBNZXNzZW5nIEEuICgyMDE2KSBBbGdlYnJhaWMg QXBwcm9hY2hlcyBmb3IgdGhlIEVsbGlwdGljIEN1cnZlIERpc2NyZXRlIExvZ2FyaXRobSBQcm9i bGVtIG92ZXIgUHJpbWUgRmllbGRzLiBJbjogQ2hlbmcgQ00uLCBDaHVuZyBLTS4sIFBlcnNpYW5v IEcuLCBZYW5nIEJZLiAoZWRzKSBQdWJsaWMtS2V5IENyeXB0b2dyYXBoeSDigJMgUEtDIDIwMTYu IFBLQyAyMDE2LiBMZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZvbCA5NjE1LiBT cHJpbmdlciwgQmVybGluLCBIZWlkZWxiZXJnDQpbMjldIEUuIEFsZWtzZWV2LCBWLiBOaWtvbGFl diwgUy4gU215c2hseWFldi4gT24gdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgUnVzc2lhbiBz dGFuZGFyZGl6ZWQgZWxsaXB0aWMgY3VydmVzLiBDVENyeXB04oCZMTcgUHJlcHJvY2VlZGluZ3Mu DQo= --_000_D8F69AA24FD8412DB13A68051F5A598Brhulacuk_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkRlYXIgU3RhbmlzbGF2LDwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48 YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+TGV0IG1lIHRoYW5rIHlv dSBmb3IgdGhpcyB2ZXJ5IGRldGFpbGVkIHJldmlldy4gSSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZSB0 aGUgYW1vdW50IG9mIGludGVsbGVjdHVhbCBlZmZvcnQgYW5kIHRpbWUgaXQgd291bGQgaGF2ZSB0 YWtlbiB0byBicmluZyBhbGwgb2YgdGhlIHJlbGV2YW50IGxpdGVyYXR1cmUgdG9nZXRoZXIgYW5k IHRvIHN0dWR5IHRoZSBkaWZmZXJlbnQgc2NoZW1lcyBhdCB0aGlzIGxldmVsDQogb2YgZGV0YWls LiZuYnNwOzwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4N CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+QmVzdCB3aXNoZXMsPC9kaXY+DQo8ZGl2IGlk PSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2ln bmF0dXJlIj5LZW5ueTwvZGl2Pg0KPGRpdj48YnI+DQpPbiAyMCBEZWMgMjAxNywgYXQgMTQ6MDks IFN0YW5pc2xhdiBWLiBTbXlzaGx5YWV2ICZsdDs8YSBocmVmPSJtYWlsdG86c215c2hzdkBnbWFp bC5jb20iPnNteXNoc3ZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXY+RG9jdW1lbnQ6IGRyYWZ0LXJpYm9zZS1vcGVucGdw LW9zY2NhLTAxIChhbmQgZHJhZnQtcmlib3NlLW9wZW5wZ3Atc2NhLTAwKTwvZGl2Pg0KPGRpdj5S ZXZpZXdlcjogU3RhbmlzbGF2IFNteXNobHlhZXY8L2Rpdj4NCjxkaXY+UmV2aWV3IERhdGU6IDIw MTctMTItMjA8L2Rpdj4NCjxkaXY+U3VtbWFyeTogTWFqb3IgcmV2aXNpb24gbmVlZGVkPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgSS1EIGRlc2NyaWJlcyB0aGUgdXNhZ2Ugb2Yg U00yLCBTTTMgYW5kIFNNNCBhbGdvcml0aG1zLCBkZXZlbG9wZWQgaW4gQ2hpbmEsIGluIE9wZW5Q R1AuIFNNMiBkZWZpbmVzIGRpZ2l0YWwgc2lnbmF0dXJlLCBrZXkgZXhjaGFuZ2UgYW5kIHB1Ymxp YyBrZXkgZW5jcnlwdGlvbiBhbGdvcml0aG1zLCBTTTMgZGVmaW5lcyBhIGhhc2ggZnVuY3Rpb24g YW5kIFNNNCBkZWZpbmVzIGEgMTI4LWJpdCBibG9jayAxMjgtYml0IGtleSBibG9jaw0KIGNpcGhl ci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIHRoaXMgcmV2aWV3IHByZXBhcmVk IGFzIGEgbWVtYmVyIG9mIENyeXB0byBSZXZpZXcgUGFuZWwsIGhlbmNlIHRoZSBmb2N1cyBpcyBu b3Qgb24gdGVjaG5pY2FsIGlzc3VlcyByZWxhdGVkIHRvIE9wZW5QR1AgaXRzZWxmLCB0aGUgcmV2 aWV3IGlzIGJlaW5nIGRvbmUgZnJvbSB0aGUgY3J5cHRvZ3JhcGhpYyBwZXJzcGVjdGl2ZS4gTmV2 ZXJ0aGVsZXNzLCBmdWxsIGNyeXB0YW5hbHlzaXMgb2YgMyBhbGdvcml0aG1zIGZyb20gYSBzY3Jh dGNoDQogaXMgaW1wb3NzaWJsZSB0byBiZSBtYWRlIGFzIGEgcGFydCBvZiByZXZpZXcsIHNvIHRo ZSBhbmFseXNpcyBpcyBjb25kdWN0ZWQgaGVhdmlseSB0YWtpbmcgaW50byBhY2NvdW50IGN1cnJl bnQgc3RhdGUgb2YgdGhlIGFuYWx5c2lzIG9mIHRoZSBwcm9wb3NlZCBtZWNoYW5pc21zLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGN1cnJlbnQgcmV2aWV3IGlzIGNvbmR1Y3Rl ZCBiYXNlZCBvbiB0aGUgSS1EIGl0c2VsZiBhbmQgYWxzbyBJLURzIGRyYWZ0LXNjYS1jZnJnLXNt My0wMCBhbmQgZHJhZnQtcmlib3NlLWNmcmctc200LTA4LCBwcm92aWRpbmcgbWF0ZXJpYWwgb24g ZGVzaWduIHJhdGlvbmFsZSBhbmQgcHVibGlzaGVkIHNlY3VyaXR5IGFuYWx5c2lzIG9mIFNNMyBh bmQgU000LiBBdCB0aGUgdGltZSBvZiB0aGlzIHJldmlldyB0aGUgU00yIEktRCBkb2VzDQogbm90 IGNvbnRhaW4gc2ltaWxhciBtYXRlcmlhbCwgdGh1cyBJIHRoaW5rIHRoYXQgYSBuZXcgcmV2aWV3 IGxhdGVyIGlzIG5lY2Vzc2FyeSBhZnRlciBzdWNoIGEgbWF0ZXJpYWwgb24gU00yIGlzIGFkZGVk IHRvIHRoZSBjb3JyZXNwb25kaW5nIEktRCAodGhlIGF1dGhvciwgUm9uYWxkIFRzZSwgaGFzIHNh aWQgdGhhdCB0aGUgY29ycmVzcG9uZGluZyB3b3JrIGlzIGluIHByb2dyZXNzKS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxiPjxicj4NCjwvYj48L2Rpdj4NCjxkaXY+PGI+U00yPC9i PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHN1bW1hcnkgb2YgdGhlIGtub3du IHJlc3VsdHMgZm9yIFNNMiBpcyBub3QgcHJvdmlkZWQgaW4gdGhlIEktRCBmb3IgU00yLCBzbyBh IHNob3J0IHN1bW1hcnkgaXMgcHJvdmlkZWQgaGVyZSBpbiB0aGUgcmV2aWV3LjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+U00yIFsxNl0gaXMgYSBzZXQgb2YgdGhyZWUgcHVibGljIGtl eSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYmFzZWQgb24gZWxsaXB0aWMgY3VydmVzOiBzaWdu YXR1cmUgYWxnb3JpdGhtLCBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wsIGFuZCBwdWJsaWMga2V5IGVu Y3J5cHRpb24gYWxnb3JpdGhtLiBUaGVzZSBhbGdvcml0aG1zIGFuZCByZWNvbW1lbmRlZCBwYXJh bWV0ZXJzIGFyZSBwdWJsaXNoZWQgYnkgQ2hpbmVzZSBDb21tZXJjaWFsIENyeXB0b2dyYXBoeQ0K IEFkbWluaXN0cmF0aW9uIE9mZmljZSBmb3IgdGhlIHVzZSBvZiBlbGVjdHJvbmljIGF1dGhlbnRp Y2F0aW9uIHNlcnZpY2Ugc3lzdGVtLiBJbiBbMjVdLCB0aGUgY2xhc3Mgb2Ygc2lnbmF0dXJlIGFs Z29yaXRobXMgaXMgYW5hbHl6ZWQsIHdoaWNoIGluY2x1ZGVzIHRoZSBTTTIgc2lnbmF0dXJlIGFs Z29yaXRobS4gTW9yZSBleGFjdGx5LCB0aGUgZ2VuZXJhbGl6ZWQga2V5IHN1YnN0aXR1dGlvbiBh dHRhY2tzIGFyZSBpbnZlc3RpZ2F0ZWQgd2hlcmUNCiB0aGUgYmFzZSBlbGVtZW50IGlzIGNvbnNp ZGVyZWQgYXMgYSBwYXJ0IG9mIHRoZSBwdWJsaWMga2V5IGFuZCBjYW4gYmUgc3Vic3RpdHV0ZWQu IEl0IGlzIHByb3ZlbiB0aGF0IHRoZSBDaGluZXNlIHN0YW5kYXJkIFNNMiBzaWduYXR1cmUgc2No ZW1lIGlzIGV4aXN0ZW50aWFsbHkgdW5mb3JnZWFibGUgYWdhaW5zdCBhZGFwdGl2ZWx5IGNob3Nl bi1tZXNzYWdlIGF0dGFja3MgaW4gdGhlIGdlbmVyaWMgZ3JvdXAgbW9kZWwgaWYgdGhlIHVuZGVy bHlpbmcNCiBoYXNoIGZ1bmN0aW9uIGlzIHVuaWZvcm0gYW5kIGNvbGxpc2lvbi1yZXNpc3RhbnQg YW5kIHRoZSB1bmRlcmx5aW5nIGNvbnZlcnNpb24gZnVuY3Rpb24gaXMgYWxtb3N0LWludmVydGli bGUsIGFuZCB0aGUgU00yIGRpZ2l0YWwgc2lnbmF0dXJlIHNjaGVtZSBpcyBzZWN1cmUgYWdhaW5z dCB0aGUgZ2VuZXJhbGl6ZWQga2V5IHN1YnN0aXR1dGlvbiBhdHRhY2tzIGlmIHRoZSB1bmRlcmx5 aW5nIGhhc2ggZnVuY3Rpb25zIGFyZSBtb2RlbGVkIGFzIG5vbi1wcm9ncmFtbWFibGUNCiByYW5k b20gb3JhY2xlcyAoTlBST3MpLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SW4gWzExXSwgdGhlIHBhcnRpYWxseSBrbm93biBub25jZXMgYXR0YWNrIGFnYWluc3QgU00yIGFy ZSBkaXNjdXNzZWQuIEl0IGlzIHNob3duIGJ5IHRoZSBleHBlcmltZW50cyB0aGF0IHRoZSBwcml2 YXRlIGtleSBjYW4gYmUgcmVjb3ZlcmVkLCBnaXZlbiAxMDAgc2lnbmF0dXJlcyB3aXRoIDMgYml0 cyBvZiBub25jZXMga25vd24gZm9yIDI1Ni1iaXQgU00yLiBBbHNvIGEgYnl0ZS1mYXVsdCBhdHRh Y2sgb24gU00yIGlzIGRldmVsb3BlZCB3aGVuDQogYSBieXRlIG9mIHJhbmRvbSBmYXVsdCBpcyBp bmplY3RlZCBvbiB0aGUgc2VjcmV0IGtleSBkdXJpbmcgdGhlIHNpZ25pbmcgcHJvY2Vzcy4gSW4g WzNdLCBhIHByYWN0aWNhbCBsYXR0aWNlLWJhc2VkIGZhdWx0IGF0dGFjayBhZ2FpbnN0IFNNMiBz aWduYXR1cmUgYWxnb3JpdGhtIGluIGEgc21hcnQgY2FyZCBpcyBwcmVzZW50ZWQuIEF1dGhvcnMg b2YgWzNdIHN1Y2Nlc3NmdWxseSB1dGlsaXplZCB0aGUgbGFzZXIgZmF1bHQgYXR0YWNrIHRvIHNr aXANCiB0aGUgaW5zdHJ1Y3Rpb25zIG9mIG5vbmNlcyBiZWluZyB3cml0dGVuIGludG8gUkFNLCBz byB0aGF0IHRoZSBub25jZXMgaW4gc2lnbmF0dXJlcyBzaGFyZSBwYXJ0aWFsIHNhbWUgYml0cyBm cm9tIGVhY2ggb3RoZXIuIE5leHQsIHRoZXkgYnVpbGQgdGhlIG1vZGVsIG9mIGxhdHRpY2UgYXR0 YWNrIGFuZCByZWNvdmVyIHRoZSBwcml2YXRlIGtleS4gVGhlIGV4cGVyaW1lbnRhbCByZXN1bHRz IHNob3cgdGhhdCBvbmx5IDMgZmF1bHR5IHNpZ25hdHVyZXMNCiBhcmUgbmVlZGVkIHRvIG1vdW50 IGxhdHRpY2UgYXR0YWNrIHN1Y2Nlc3NmdWxseSBpbiBhYm91dCAzMiDCtXMuIE1vcmVvdmVyLCB0 aGV5IHByb3Bvc2VkIGEgbmV3IGNvdW50ZXJtZWFzdXJlIGZvciBTTTIgc2lnbmF0dXJlIGFsZ29y aXRobSB0byByZXNpc3QgbGF0dGljZS1iYXNlZCBmYXVsdCBhdHRhY2sgYnkgZGVzdHJveWluZyB0 aGUgY29uZGl0aW9uIG9mIGxhdHRpY2UgYXR0YWNrIHJhdGhlciB0aGFuIHRod2FydGluZyBmYXVs dCBhdHRhY2suDQogSXQgaXMgcHJvdmVuIHRoYXQgdGhlIGNvdW50ZXJtZWFzdXJlIGNhbiBndWFy YW50ZWUgdGhlIGFiaWxpdHkgdG8gcmVzaXN0IGxhdHRpY2UgYXR0YWNrLCBldmVuIGlmIHNvbWUg aW5mb3JtYXRpb24gb2YgdGhlIG5vbmNlcyBpcyBsZWFrZWQuIEFzIG5vdGVkIGluIFs3XSwgdGhl IFNNMiBzaWduYXR1cmUgYWxnb3JpdGhtIGFzIHdlbGwgYXMgdGhlIFJ1c3NpYW4gc3RhbmRhcmQg R09TVCBSIDM0LjEwLTIwMTIsIGFuZCB0aGUgRUNEU0EgYWxnb3JpdGhtDQogZml0cyBpbnRvIHRo ZSBnZW5lcmFsIHNjaGVtZSBvZiB0aGUgRWxHYW1hbCBzaWduYXR1cmUgYWxnb3JpdGhtLCBwcm9w b3NlZCBiYWNrIGluIDE5OTcgaW4gdGhlIGNsYXNzaWMgbW9ub2dyYXBoIFsxNF0uIEluIFsyMF0s IGFwcGFyZW50bHkgY29uY2VybmluZyB0aGUgZWFybGllciB2ZXJzaW9uIG9mIHRoZSBTTTIga2V5 IGV4Y2hhbmdlIHByb3RvY29sLCBpdCBpcyBzaG93biB0aGF0IHRoaXMgdmVyc2lvbiBpcyB2dWxu ZXJhYmxlIHRvIHJlYWxpc3RpYw0KIGF0dGFja3MgaW4gdGhlIENhbmV0dGktS3Jhd2N6eWsgbW9k ZWwsIGluIHdoaWNoIGFuIGFkdmVyc2FyeSBvbmx5IGtub3dzIHRoZSBzdGF0ZSBvZiB0aGUgc2Vz c2lvbi4gU2ltcGxlIG1vZGlmaWNhdGlvbnMgb2YgdGhpcyB2ZXJzaW9uIGFyZSBwcm9wb3NlZCwg d2hpY2ggZWxpbWluYXRlIHRoaXMgcHJvYmxlbS4gSW4gWzIxXSwgdGhlIHNlY3VyaXR5IG9mIHRo ZSBTTTIga2V5IGV4Y2hhbmdlIHByb3RvY29sIGluIHRoZSB3aWRlc3ByZWFkIEJlbGxhcmUtUm9n YXdheQ0KIG1vZGVsIGlzIHByb3ZlZCB1bmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBkaXNj cmV0ZSBsb2dhcml0aG0gcHJvYmxlbSBmb3IgZWxsaXB0aWMgY3VydmVzIGlzIGhhcmQuIEFsc28g aW4gdGhpcyBwYXBlciBhIHNpbXBsaWZpZWQgYnV0IG1vcmUgZWZmZWN0aXZlIHZlcnNpb24gb2Yg dGhpcyBwcm90b2NvbCBpcyBwcmVzZW50ZWQgdG9nZXRoZXIgd2l0aCBhIHNpbWlsYXIgc2VjdXJp dHkgcHJvb2YuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CYXNlZCBvbiB0aGUgcHVi bGlzaGVkIHJlc3VsdHMsIEkgc2VlIG5vIHJlYXNvbnMgdG8gb2JqZWN0IGFnYWluc3QgdXNpbmcg dGhlIFNNMiBkaWdpdGFsIHNpZ25hdHVyZSBzY2hlbWUgYW5kIHRoZSBTTTIgcHVibGljIGtleSBl bmNyeXB0aW9uIGZvciBzZWN1cmUgZWxsaXB0aWMgY3VydmVzLiZuYnNwOzwvZGl2Pg0KPGRpdj5O ZXZlcnRoZWxlc3MsIEknZCBwcmVmZXIgdG8gY29uZHVjdCBhbiBhZGRpdGlvbmFsIHJldmlldyBh ZnRlciBhIHNlY3Rpb24gYWJvdXQgZGVzaWduIHJhdGlvbmFsZSBhbmQgYSBzdW1tYXJ5IG9mIGNy eXB0YW5hbHl0aWMgcmVzdWx0cyBpcyBhZGRlZCB0byB0aGUgU00yIEktRC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48Yj5TTTM8L2I+PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgU00zIGhhc2ggZnVuY3Rpb24gWzE3XSBpcyBjb25z dHJ1Y3RlZCBvbiB0aGUgY3J5cHRvZ3JhcGhpYyBwcmluY2lwbGVzIGVtYmVkZGVkIGluIHRoZSBN RDQgaGFzaCBmdW5jdGlvbiBmYW1pbHksIG9yIG1vcmUgcHJlY2lzZWx5LCBpbiB0aGUgU0hBLTIg aGFzaCBmdW5jdGlvbnMuIEluIHRoZSA2IHllYXJzIHNpbmNlIHB1YmxpY2F0aW9uIG9mIHRoZSBT TTMgaGFzaCBmdW5jdGlvbiwgc29tZSBhdHRhY2tzIG9uIHRydW5jYXRlZCB2ZXJzaW9ucw0KIGhh dmUgYmVlbiBidWlsdC4gVGhlc2UgYXJlIGF0dGFja3Mgb2YgZmluZGluZyBwcmVpbWFnZSwgY29s bGlzaW9ucywgcHNldWRvLWNvbGxpc2lvbnMgYW5kIGZyZWUtc3RhcnQgY29sbGlzaW9ucywgYXMg d2VsbCBhcyBhdHRhY2tzIG9mIGNvbnN0cnVjdGluZyBib29tZXJhbmctZGlzdGluZ3Vpc2hlcnMu IEluIFsxOV0sIHRoZSBwcmVpbWFnZSBhdHRhY2tzIHRyYW5zZm9ybWVkIGludG8gYXR0YWNrcyBv ZiBjb25zdHJ1Y3RpbmcgcHNldWRvLWNvbGxpc2lvbnMNCiBmb3IgdmVyc2lvbnMgb2YgdGhlIFNN MyBoYXNoIGZ1bmN0aW9uLCB0cnVuY2F0ZWQgdG8gMjksIDMwLCAzMSBhbmQgMzIgc3RlcHMsIHdp dGggY29tcGxleGl0aWVzIDJeMTIyICwgMl4xMjUuMSAsIDJeMTIyIGFuZCAyXjEyNS4xICwgcmVz cGVjdGl2ZWx5LiBJbiBbMTNdLCByZWFsIGNvbGxpc2lvbnMgd2VyZSBmb3VuZCB3aXRoIHByYWN0 aWNhbCBjb21wbGV4aXR5IGZvciB0aGUgMjAgKG9mIDY0KSBzdGVwcyBTTTMgaGFzaCBmdW5jdGlv biwgYW5kDQogcmVhbCBmcmVlLXN0YXJ0IGNvbGxpc2lvbnMgd2VyZSBmb3VuZCB3aXRoIHByYWN0 aWNhbCBjb21wbGV4aXR5IGZvciB0aGUgMjQgc3RlcHMgU00zIGhhc2ggZnVuY3Rpb24uPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CYXNlZCBvbiB0aGUgcHVibGlzaGVkIHJlc3VsdHMs IEkgc2VlIG5vIHJlYXNvbnMgdG8gb2JqZWN0IGFnYWluc3QmbmJzcDt1c2luZyB0aGUgU00zIGhh c2ggZnVuY3Rpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGI+U000PC9iPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U01TNCBbNV0s IGlzc3VlZCBpbiAyMDA2IGJ5IENoaW5lc2UgZ292ZXJubWVudCwgc2VydmVzIHRoZSBXQVBJIChX TEFOIEF1dGhlbnRpY2F0aW9uIGFuZCBQcml2YWN5IEluZnJhc3RydWN0dXJlKSBhcyB0aGUgdW5k ZXJsaW5nIGJsb2NrIGNpcGhlciBmb3IgdGhlIHNlY3VyaXR5IG9mIHdpcmVsZXNzIExBTnMuIElu IDIwMTIsIFNNUzQgd2FzIGFubm91bmNlZCBhcyB0aGUgQ2hpbmVzZSBjb21tZXJjaWFsIGJsb2Nr IGNpcGhlciBzdGFuZGFyZCwNCiByZW5hbWVkIHRvIFNNNC4gU000IGlzIGEgMzItcm91bmQgYmxv Y2sgY2lwaGVyIHdpdGggdGhlIHNhbWUgYmxvY2sgbGVuZ3RoIGFuZCBrZXkgZXF1YWwgdG8gMTI4 IGJpdC4mbmJzcDs8L2Rpdj4NCjxkaXY+VW5saWtlIG90aGVyIG9wZW4gQ2hpbmVzZSBjcnlwdG9n cmFwaGljIHN0YW5kYXJkcyAoU00yIGFuZCBTTTMpLCB0aGUgYmxvY2sgY2lwaGVyIFNNNCBhdHRy YWN0ZWQgbW9yZSBhdHRlbnRpb24gb2YgdGhlIGludGVybmF0aW9uYWwgY3J5cHRvZ3JhcGhpYyBj b21tdW5pdHkuIFNvIGluIFs5XSB0aGUgaW50ZWdyYWwgYXR0YWNrIGlzIHByb3Bvc2VkIGZvciB0 aGUgMTMtcm91bmQgdmVyc2lvbiBvZiB0aGUgU000IGNpcGhlci4gSW4gWzhdLCB0aGUNCiByZWN0 YW5nbGUgYW5kIGJvb21lcmFuZyBhdHRhY2tzIG9uIDE4LXJvdW5kIFNNNCBhbmQgdGhlIGxpbmVh ciBhbmQgZGlmZmVyZW50aWFsIGF0dGFja3Mgb24gMjItcm91bmQgU000IGhhdmUgYmVlbiBwcmVz ZW50ZWQuIFVzaW5nIHRoZSB0ZWNobmlxdWUgb2YgbXVsdGlwbGUgbGluZWFyIGFwcHJveGltYXRp b25zLCBpbiBbNl0gYW4gYXR0YWNrIHdhcyBkZXZlbG9wZWQgZm9yIHRoZSAyMi0gYW5kIDIzLXJv dW5kIHZlcnNpb24gb2YgU000LiBJbiBbMjRdLA0KIHRoZSByZXN1bHRzIG9mIFs2XSBmb3IgdGhl IDIyLXJvdW5kIHZlcnNpb24gd2VyZSBpbXByb3ZlZC4gVGhlIGJlc3QgZGlmZmVyZW50aWFsIGF0 dGFja3MgdG8gZGF0ZSBmb3IgdGhlIDIzLXJvdW5kIHZlcnNpb24gb2YgU000IHdlcmUgb2J0YWlu ZWQgaW4gWzE4XS4gRm9yIHRoZSBzYW1lIHZlcnNpb24gb2YgU000LCB0aGUgbXVsdGlkaW1lbnNp b25hbCBsaW5lYXIgYXR0YWNrIHdhcyBwcm9wb3NlZCBpbiBbNF0uIFRoZSBiZXN0IGxpbmVhciBh dHRhY2tzDQogdG8gZGF0ZSBmb3IgdGhlIDIzLSBhbmQgMjQtcm91bmQgdmVyc2lvbiBvZiBTTTQg aGF2ZSBiZWVuIGRldmVsb3BlZCBpbiBbMTBdIGFuZCBbMTJdLCByZXNwZWN0aXZlbHkuIEluIFsy M10gaXQgaXMgc2hvd24gdGhhdCB0aGUgU000IGNpcGhlciBpcyByZXNpc3RhbnQgdG8gZGlmZmVy ZW50aWFsIGNyeXB0YW5hbHlzaXMgaW4gdGhlIHJlbGF0ZWQga2V5IG1vZGVsIGZvciB2ZXJzaW9u cyBzdGFydGluZyBhdCAxOSByb3VuZHMuIEl0IGlzIGFsc28gd29ydGgNCiBtZW50aW9uaW5nIGhl cmUgdGhlIHBhcGVyIFsyMl0sIGluIHdoaWNoIGxvd2VyIGJvdW5kcyBhcmUgb2J0YWluZWQgZm9y IHRoZSBudW1iZXIgb2Yg4oCcIGxpbmVhcmx5IGFjdGl2ZeKAnSBTLWJveGVzIGZvciBTTTQtbGlr ZSBibG9jayBjaXBoZXJzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmFzZWQgb24g dGhlIHB1Ymxpc2hlZCByZXN1bHRzLCBJIHNlZSBubyByZWFzb25zIHRvIG9iamVjdCBhZ2FpbnN0 Jm5ic3A7dXNpbmcgdGhlIFNNNCBjaXBoZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGI+VGhlIGVsbGlwdGljIGN1cnZlIHBhcmFtZXRlcnM8L2I+ PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGVyZSBpcyBubyBzdWZmaWNpZW50IG1h dGVyaWFsIG9uIGEgcHJvdmlkZWQgZWxsaXB0aWMgY3VydmUsIHNvIHNvbWUgYW5hbHlzaXMgaXMg bWFkZSBpbiB0aGUgY3VycmVudCByZXZpZXcuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGUgcHJvdmlkZWQgc2hvcnQgV2VpZXJzdHJhc3MgZXF1YXRpb24gY29lZmZpY2llbnRzIGNv cnJlY3RseSBkZWZpbmUgdGhlIGVsbGlwdGljIGN1cnZlIChpdCBoYXMgbm9uLW51bGwgZGlzY3Jp bWluYW50KS4gVGhlIGotaW52YXJpYW50IG9mIHRoZSBjdXJ2ZSBpcyBub3QgZXF1YWwgdG8gMCBv ciAxNzI4LiBUaGUgb3JkZXIgb2YgdGhlIHByb3ZpZGVkIGN1cnZlIHBvaW50cyBncm91cCBtIGVx dWFscyAxMTU3OTIwODkyMTAzNTYyNDg3NTY0MjAzNDUyMTQwMjA4OTI3NjYwNjE2MjM3MjQ5NTc3 NDQ1Njc4NDM4MDkzNTYyOTM0MzkwNDU5MjMNCiBhbmQgaXMgcHJpbWUuJm5ic3A7IFRoZSBwcm92 aWRlZCBiYXNlIHBvaW50IGJlbG9uZ3MgdG8gdGhlIGN1cnZlIGFuZCBoYXMgb3JkZXIgcSBlcXVh bCB0byBtLiBUaGVyZWZvcmUgY29mYWN0b3IgaCBvZiB0aGUgc3BlY2lmaWVkIHN1Ymdyb3VwIGVx dWFscyB0byAxLiBUaGUgb3JkZXIgb2YgdGhlIHN1Ymdyb3VwIGlzIGJpZyBlbm91Z2ggKGFib3V0 IDJeMjU2KSB0byBtYWtlIGF0dGFja3MgYmFzZSBvbiBQb2xsYXJk4oCZcyByaG8gbWV0aG9kIGlu ZWZmZWN0aXZlLg0KIFNpbmNlIHEgIT0gcCBlZmZlY3RpdmUgYWRkaXRpdmUgdHJhbnNmZXJzIGFy ZSBub3QgcG9zc2libGUuIE1PVi1hdHRhY2tzIGFyZSBpbmVmZmVjdGl2ZSBzaW5jZSB0aGUgY3Vy dmUgaGFzIGhpZ2ggZW1iZWRkaW5nIGRlZ3JlZSAoZXF1YWxzIHEtMSkuIFRoZSBhYnNvbHV0ZSB2 YWx1ZSBvZiBjb21wbGV4IG11bHRpcGxpY2F0aW9uIGRpc2NyaW1pbmFudCBpcyBhYm91dCAyXjI1 NyBhbmQgZnVsbHkgc2F0aXNmaWVzIHJlcXVpcmVtZW50cyBvZiB0aGUNCiBTYWZlQ3VydmVzIChb MjddKS4gVGhlIGF0dGFjayBieSBQZXRpdCwgS29zdGVycyBhbmQgTWVzc2VuZyAoWzI4XSkgd2hp Y2ggZW1wbG95cyBTZW1hZXYgc3VtbWF0aW9uIHBvbHlub21pYWxzIGlzIGFsc28gaW5lZmZlY3Rp dmUgc2luY2UgYWxsIHNldHMgb2Ygc21hbGwgZmFjdG9yIG9mIHAtMSAobmFtZWx5IDIgYW5kIDQz KSBtZWV0IGNyaXRlcmlvbiwgcHJvdmlkZWQgaW4gWzI5XS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pkl0IGNhbiBzaG93biB0aGF0IGdyb3VwIG9mIHBvaW50cyBvZiB0aGUgcXVhZHJh dGljIHR3aXN0IG9mIHRoZSBjdXJ2ZSBoYXMgb3JkZXIgbeKAmSBlcXVhbCB0byAxMTU3OTIwODky MTAzNTYyNDg3NTY0MjAzNDUyMTQwMjA4OTI3NjY0MzkwODQyNTg4OTA2MzgzNDA5OTg1Nzg1MTAy ODU5MzA5MzgwNzcuIFRoZSBsYXJnZXN0IHN1Ymdyb3VwIGhhcyB0aGUgb3JkZXIgceKAmSA9IDMz Njk0MjI1OTE0ODM1ODAxNDMyNjYxODc3NjIwNjA4MTYwNDE2NTUyMDEwMw0KIHdpdGggY29mYWN0 b3IgaOKAmT0gMzQzNjU1NTg1MDkzNTA0NjY2NDQ3MDA1NzUyMjg0MDU5LiBTaW5jZSBx4oCZIGlz IGFib3V0IDJeMTQ3IFBvbGxhcmTigJlzIHJobyBhbGdvcml0aG0gaXMgbW9yZSBlZmZlY3RpdmUg aGVyZSB0aGFuIG9uIHRoZSBvcmlnaW5hbCBjdXJ2ZS4gU2luY2UgceKAmSBpcyBub3QgZXF1YWwg dG8gcCBhbmQgb3JkKHApIGluIFoqKHHigJkpIGVxdWFscyAocSctMSkvMTEgdGhlcmUgZXhpc3Qg bmVpdGhlciBlZmZlY3RpdmUgYWRkaXRpdmUNCiB0cmFuc2ZlcnMgbm9yIGVmZmVjdGl2ZSBtdWx0 aXBsaWNhdGl2ZSB0cmFuc2ZlcnMuIEl0IGlzIGltcG9ydGFudCB0byBub3RlLCBob3dldmVyLCB0 aGUgcHJvdmlkZWQgY3VydmUgY2Fubm90IGJlIHJld3JpdHRlbiBpbiBNb250Z29tZXJ5IGZvcm0u PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcHJvdmlkZWQgY3VydmUgc2F0aXNm aWVzIGFsbCBtb2Rlcm4gc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiBIb3dldmVyLCBzb21lIGNsYXJp ZmljYXRpb25zIG9uIHRoZSBzZWxlY3Rpb24gb2YgdmFsdWVzIG9mIGIsIHgoUCksIHkoUCkgaGF2 ZSB0byBiZSBwcm92aWRlZDogc29tZSBraW5kIG9mIE5VTVMtdHlwZSBhcmd1bWVudHMgYXJlIGRl c2lyYWJsZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxiPjxicj4NCjwvYj48L2Rp dj4NCjxkaXY+PGI+R2VuZXJhbCBjb21tZW50cyBmb3IgdGhlIEktRDwvYj48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGFyZSBhIGxvdCBvZiB3b3JkcyBhYm91dCBPU0NDQS9T Q0EtY29tcGxpYW5jZS4gSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgaW1wb3J0YW50IGZvciBh biBJRVRGIGRvY3VtZW50IC0gbWF5YmUgaXQgd291bGQgYmUgYmV0dGVyIG5vdCB0byBtZW50aW9u IHRoZXNlIHJlZ3VsYXRvcnkgaXNzdWVzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ QSBsb3Qgb2YgcmVmZXJlbmNlcyBpcyBnaXZlbiB0byBPU0NDQS9TQ0EgZG9jdW1lbnRzIGFuZCBD aGluZXNlIHN0YW5kYXJkcyAtIG1heWJlIGl0IHdpbGwgYmUgYmV0dGVyIHRvIHVzZSByZWZlcmVu Y2VzIHRvIElFVEYgSS1Ecy9SRkNzIGZvciBTTTIsIFNNMywgU000LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhyb3VnaG91dCB0aGUgdGV4dCB0aGVyZSBhcmUgJnF1b3Q7TVVTVCZx dW90OyBjb2Rld29yZHMgYWJvdXQgJnF1b3Q7YSBjb21wbGlhbnQgT3BlblBHUCBpbXBsZW1lbnRh dGlvbiZxdW90OyAtIGl0IHNlZW1zIHRvIGJlIHRvbyBzdHJpY3QgdG8gdXNlIE1VU1QgY29kZXdv cmQgd2hlbiBkaXNjdXNzaW5nIG9wdGlvbmFsIGFsZ29yaXRobXMvcGFyYW1ldGVycyB0byB1c2Ug d2l0aCBzb21lIHByb3RvY29scy9pbXBsZW1lbnRhdGlvbnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGVyZSBhcmUgc29tZSBwcm9ibGVtcyB3aXRoIGxpbmtzIHRvIDxhIGhyZWY9 Imh0dHA6Ly9vc2NjYS5nb3YuY24iPm9zY2NhLmdvdi5jbjwvYT4gLSBtYXliZSB0aGUgc2l0ZSBo YXMgYmVlbiBkb3duIHJlY2VudCBkYXlzLCBidXQgSSBjb3VsZG4ndCBvcGVuIHRoZXNlIGxpbmtz LiBEbyB3ZSBuZWVkIHRoZW0gcHJvdmlkZWQgdGhhdCB3ZSBoYXZlIFJGQ3MgYW5kIG90aGVyIGxp bmtzPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi PlBhcnRpY3VsYXIgY29tbWVudHM8L2I+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5T ZWN0aW9uIDE6Jm5ic3A7PC9kaXY+DQo8ZGl2PlNNNCBpcyBjYWxsZWQgJnF1b3Q7a000JnF1b3Q7 LiZuYnNwOzwvZGl2Pg0KPGRpdj5BYm91dCBTTTMgKGEgaGFzaCkgaW5zdGVhZCBvZiAmcXVvdDtl bGVjdHJvbmljIGF1dGhlbnRpY2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDtkYXRhIHZhbGlkYXRpb24m cXVvdDsgaXQgd291bGQgYmV0dGVyIHNheSBzb21ldGhpbmcgbGlrZSAmcXVvdDtpbnRlZ3JpdHkm cXVvdDsuJm5ic3A7PC9kaXY+DQo8ZGl2PkluICZxdW90O3N1cHBvcnQgdGhlIFNNNCBzeW1tZXRy aWMgZW5jcnlwdGlvbiBhbGdvcml0aG0gZm9yIGRhdGEgcHJvdGVjdGlvbiBwdXJwb3NlcyZxdW90 OyBJJ2QgcHJlZmVyIHRvIHNheSBhYm91dCAmcXVvdDtjb25maWRlbnRpYWxpdHkmcXVvdDssIG5v dCAmcXVvdDtwcm90ZWN0aW9uJnF1b3Q7IChlc3BlY2lhbGx5IHNpbmNlIFNNNCBkb2VzIG5vdCBk ZWZpbmUgYSBNQUMgbW9kZSkuJm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2PiZxdW90O1NNMyB3aXRo IG90aGVyIGRpZ2l0YWwgc2lnbmluZyBhbGdvcml0aG1zLCBzdWNoIGFzIFJTQSwgRUNEU0EgYW5k IFNNMiZxdW90OzogMSkgJnF1b3Q7c2lnbmluZyZxdW90Oy0mZ3Q7JnF1b3Q7c2lnbmF0dXJlJnF1 b3Q7OyAyKSBFQy1SRFNBIGZyb20mbmJzcDsgSVNPL0lFQyAxNDg4OC0zIGlzIGFsc28gYXBwcm9w cmlhdGUgaGVyZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlY3Rpb24gMywgZmly c3Qgc2VudGVuY2U6ICZxdW90O3RoZXkmcXVvdDsgc2VlbXMgdG8gYmUgb21pdHRlZCBhZnRlciAm cXVvdDthbmQmcXVvdDsuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDQ6 ICZxdW90O2VsbGlwdGljYWwmcXVvdDsgLSZndDsgJnF1b3Q7ZWxsaXB0aWMmcXVvdDsuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDQuMTogZG8gd2UgbmVlZCB0byBzYXkg YWJvdXQgdGhpcyBvcHRpb25hbCBaQSBmaWVsZCBmcm9tIFNNMiBzdGFuZGFyZD8gQW5kIHBlcnNv bmFsbHkgSSBkb24ndCBsaWtlIHRoaXMgZG91YmxlIGhhc2hpbmcgKEgoWkF8fCBIKG1zZykpKS48 L2Rpdj4NCjxkaXY+SSBhbSBub3Qgc3VyZSB0aGF0IHNlY3Rpb24gNC4yIGlzIG5lZWRlZDogaXQg aXMgc2FpZCB0aGF0IHRoaXMgYWxnb3JpdGhtIGlzIG5vdCByZWxhdGVkIHRvIE9wZW5QR1AgYW5k IGFsc28gaGFzIHNlY3VyaXR5IGlzc3VlcyAtIEknZCByZWNvbW1lbmQgdG8gcmVtb3ZlIHRoaXMg cGFydCBmcm9tIHRoZSBkb2N1bWVudCBhdCBhbGwuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5TZWN0aW9uIDQuNC4yOiBJJ2QgcmVjb21tZW5kIHRvIHNheSB0aGF0IHRoZSBj dXJ2ZSBpcyBkZWZpbmVkIG92ZXIgYSBjZXJ0YWluIGZpbml0ZSBmaWVsZCBpbiBzaG9ydCBXZWll cnN0cmFzcyBmb3JtLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VjdGlvbiA0LjQu MzogSSdkIHByZWZlciB0byBzZWUgYWxzbyB3b3JkcyBhYm91dCB0aGUgY29mYWN0b3Igb2YgdGhl IGdyb3VwIGFuZCB0aGF0IGFsbCBudW1iZXJzIGFyZSBpbiBiaWctZW5kaWFuIGZvcm0uPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDQuNS4xOiBJdCBzaG91bGQgYmUgc3Rh dGVkIGV4cGxpY2l0bHkgdGhhdCBhbGwgbnVtYmVycyBhcmUgaW4gbGl0dGxlLWVuZGlhbiBvciBi aWctZW5kaWFuLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VjdGlvbiA1LjwvZGl2 Pg0KPGRpdj5BIG1pc3ByaW50OiAmcXVvdDtjcnlwdG9ncnBhaGljJnF1b3Q7LjwvZGl2Pg0KPGRp dj5JbnN0ZWFkIG9mICZxdW90O2RpZ2l0YWwgc2lnbmF0dXJlcyBhbmQgdGhlaXIgdmVyaWZpY2F0 aW9uJnF1b3Q7IGl0IHdvdWxkIGJldHRlciBzYXkgJnF1b3Q7ZGlnaXRhbCBzaWduYXR1cmUgZ2Vu ZXJhdGlvbiBhbmQgdmVyaWZpY2F0aW9uJnF1b3Q7LiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdj5X aGVuIHdlIHNheSBhYm91dCBNQUNpbmcgb3IgUFJOR3MsIHNwZWNpZmljIGNvbnN0cnVjdGlvbnMg c2hvdWxkIGJlIG1lbnRpb25lZCwgaW4gbXkgb3Bpbmlvbi4gT3RoZXJ3aXNlLCBJJ2QgcHJlZmVy IG5vdCB0byBoYXZlIHRoZXNlIGdlbmVyYWwgd29yZHMgYWJvdXQgU00zIGFwcGxpY2F0aW9ucyAo dGhleSBhcmUgdGhlIHNhbWUgYXMgZm9yIGFueSBoYXNoIGZ1bmN0aW9uKS48YnI+DQo8L2Rpdj4N CjxkaXY+VGhlcmUgaXMgYSBwYXJhbWV0ZXIgJnF1b3Q7bSZxdW90Oywgd2hpY2ggc2VlbXMgbm90 IHRvIGJlIGRlZmluZWQgYXQgdGhhdCBtb21lbnQuJm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDY6IGl0IHNlZW1zIHRvIGJlIHVzZWZ1bCB0byBkZWZp bmUgd2hldGhlciB0aGUgUy1ib3ggaXMgZml4ZWQgb3IgdmFyaWFibGUuPC9kaXY+DQo8ZGl2PlRo ZSBub3RlIGlzIG1pc3NpbmcgdGhhdCBTTTQgaXMgYW4gdW5iYWxhbmNlZCBGZWlzdGVsIG5ldHdv cmsg4oCTIHRoaXMgc2VlbXMgbW9yZSBpbXBvcnRhbnQgdGhhbiB0aGUgbm90ZSB0aGF0IGl0IGlz IGRlc2lnbmVkIGZvciBlbmNyeXB0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SW4gc2VjdGlvbiA3LjMgdGhlcmUgaXMgYSBtaXN0YWtlIGluIHRoZSBzZWNvbmQgcGFyYWdyYXBo OiB0aGlzIGlzIG5vdCBhICZxdW90O3N5bW1ldHJpYyBlbmNyeXB0aW9uIGFsZ29yaXRobSZxdW90 Oy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIHNlY3Rpb24gOS4zICZxdW90O3do b2xlIG51bWJlciZxdW90OyAtJmd0OyAmcXVvdDtpbnRlZ2VyJnF1b3Q7LiAmcXVvdDtIYSEmcXVv dDsgZG9lc24ndCBsb29rIGEgZ29vZCB2YXJpYWJsZSBuYW1lLiBTaW5jZSBuIGlzIGFuIGludGVn ZXIsIGNlaWwgaXMgbm90IG5lZWRlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pklu IHNlY3Rpb24gMTQgdGhlIHNlY29uZCBwYXJhZ3JhcGggZG9lc24ndCBsb29rIGFjY3VyYXRlIGVu b3VnaC4gRm9yIGluc3RhbmNlLCAmcXVvdDtFQ0RMUCZxdW90OyBzZWVtcyBtb3JlIGFwcHJvcHJp YXRlIHRoYW4gJnF1b3Q7RUNMUCZxdW90Oy4gUmVnYXJkaW5nIHRoZSBkaWdpdGFsIHNpZ25hdHVy ZSwgYSByZWZlcmVuY2UgdG8gdGhlIGhhc2ggaXMgYWxzbyBuZWVkZWQgaGVyZS4gUmVnYXJkaW5n IHRoZSBrZXkgZXhjaGFuZ2Ugc2NoZW1lIC0gbm90IG9ubHkgYSByZWZlcmVuY2UNCiB0byBkaXNj cmV0ZSBsb2dhcml0aG0gcHJvYmxlbSwgYnV0IGFsc28gdG8gQ0RIL0RESCBpcyBkZXNpcmFibGUu PC9kaXY+DQo8ZGl2PiZxdW90O3JhbmRvbWx5IGdlbmVyYXRlZCB3aXRob3V0IGZpeGVkIGNvcnJl bGF0aW9uJnF1b3Q7IC0gdGhlIHNlbnRlbmNlIGxvb2tzIGEgbGl0dGxlIHN0cmFuZ2UgYmVjYXVz ZSBvZiAmcXVvdDtmaXhlZCZxdW90Oy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNl Y3Rpb24gMTU6IE1heWJlIGl0IHdvdWxkIGJlIGJldHRlciB0byBzYXkgJnF1b3Q7aGFzIG1hZGUm cXVvdDsgYWZ0ZXIgdGhlIGFzc2lnbm1lbnRzIGFyZSBtYWRlLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxiPlJlZmVyZW5jZXM8L2I+PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bMV0gQmFpIEQuLCBZdSBILiwgV2FuZyBHLiwgV2FuZyBY LjogSW1wcm92ZWQgQm9vbWVyYW5nIEF0dGFja3Mgb24gU00zLiBJbjogQm95ZCBDLixTaW1wc29u IEwuIChlZHMpIEluZm9ybWF0aW9uIFNlY3VyaXR5IGFuZCBQcml2YWN5LiBBQ0lTUCAyMDEzLiBM ZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZvbCA3OTU5LCBwcC4gMjUx4oCTMjY2 LiBTcHJpbmdlciwgQmVybGluLCBIZWlkZWxiZXJnICgyMDEzKS48L2Rpdj4NCjxkaXY+WzJdIEJh aSBELiwgWXUgSC4sIFdhbmcgRy4sIFdhbmcgWC46IEltcHJvdmVkIGJvb21lcmFuZyBhdHRhY2tz IG9uIHJvdW5kLXJlZHVjZWQgU00zIGFuZCBrZXllZCBwZXJtdXRhdGlvbiBvZiBCTEFLRS0yNTYu IElFVCBJbmZvcm1hdGlvbiBTZWN1cml0eSA5KDMpOiBwcC4gMTY34oCTMTc4ICgyMDE1KS48L2Rp dj4NCjxkaXY+WzNdIENhbyBXLiwgRmVuZyBKLiwgWmh1IFMuLCBDaGVuIEguLCBXdSBXLiwgSGFu IFguLCBaaGVuZyBYLjogUHJhY3RpY2FsIExhdHRpY2UtQmFzZWQgRmF1bHQgQXR0YWNrIGFuZCBD b3VudGVybWVhc3VyZSBvbiBTTTIgU2lnbmF0dXJlIEFsZ29yaXRobS4gSW46IFFpbmcgUy4sIE9r YW1vdG8gRS4sIEtpbSBLLiwgTGl1IEQuIChlZHMpIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0 aW9ucyBTZWN1cml0eS4gSUNJQ1MgMjAxNS4gTGVjdHVyZQ0KIE5vdGVzIGluIENvbXB1dGVyIFNj aWVuY2UsIHZvbCA5NTQzLCBwcC4gNjLigJM3MC4gU3ByaW5nZXIsIENoYW0gKDIwMTUpLjwvZGl2 Pg0KPGRpdj5bNF0gQ2hvIEouLCBOeWJlcmcgSy46IEltcHJvdmVkIExpbmVhciBDcnlwdGFuYWx5 c2lzIG9mIFNNUzQgQmxvY2sgQ2lwaGVyLiBTeW1tZXRyaWMgS2V5IEVuY3J5cHRpb24gV29ya3No b3AsIHBwLiAx4oCTMTQuICgyMDExKS4NCjxhIGhyZWY9Imh0dHA6Ly9za2V3MjAxMS5tYXQuZHR1 LmRrL3Byb2NlZWRpbmdzL0ltcHJvdmVkJTIwTGluZWFyJTIwQ3J5cHRhbmFseXNpcyUyMG9mJTIw U01TNCUyMEJsb2NrJTIwQ2lwaGVyLnBkZiI+DQpodHRwOi8vc2tldzIwMTEubWF0LmR0dS5kay9w cm9jZWVkaW5ncy9JbXByb3ZlZCUyMExpbmVhciUyMENyeXB0YW5hbHlzaXMlMjBvZiUyMFNNUzQl MjBCbG9jayUyMENpcGhlci5wZGY8L2E+PC9kaXY+DQo8ZGl2Pls1XSBEaWZmaWUgVy4sIExlZGlu IEcuOiBTTVM0IEVuY3J5cHRpb24gQWxnb3JpdGhtIGZvciBXaXJlbGVzcyBOZXR3b3Jrcy4gQ3J5 cHRvbG9neSBlUHJpbnQgQXJjaGl2ZSAyMDA4LzMyOS4NCjxhIGhyZWY9Imh0dHA6Ly9lcHJpbnQu aWFjci5vcmcvMjAwOC8zMjkucGRmIj5odHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMDgvMzI5LnBk ZjwvYT48L2Rpdj4NCjxkaXY+WzZdIEV0cm9nIEouLCBSb2JzaGF3IE0uIEouIEIuOiBUaGUgQ3J5 cHRhbmFseXNpcyBvZiBSZWR1Y2VkLVJvdW5kIFNNUzQuIEluOiBBdmFuemkgUi4gTS4sIEtlbGlo ZXIgTC4sIFNpY2EgRi4gKGVkcykgU2VsZWN0ZWQgQXJlYXMgaW4gQ3J5cHRvZ3JhcGh5LiBTQUMg MjAwOC4gTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlLCB2b2wgNTM4MSwgcHAuIDUx 4oCTNjUuIFNwcmluZ2VyLCBCZXJsaW4sIEhlaWRlbGJlcmcgKDIwMDkpLjwvZGl2Pg0KPGRpdj5b N10gRmVyc2NoIE0uLCBLaWx0eiBFLiwgUG9ldHRlcmluZyBCLjogT24gdGhlIE9uZS1QZXItTWVz c2FnZSBVbmZvcmdlYWJpbGl0eSBvZiAoRUMpRFNBIGFuZCBJdHMgVmFyaWFudHMuIEluOiBLYWxh aSBZLiwgUmV5emluIEwuIChlZHMpIFRoZW9yeSBvZiBDcnlwdG9ncmFwaHkuIFRDQyAyMDE3LiBM ZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZvbCAxMDY3OCwgcHAuIDUxOeKAkzUz NC4gU3ByaW5nZXIsIENoYW0gKDIwMTcpLjwvZGl2Pg0KPGRpdj5bOF0gS2ltIFQuLCBLaW0gSi4s IEhvbmcgUy4sIFN1bmcgSi46IExpbmVhciBhbmQgRGlmZmVyZW50aWFsIENyeXB0YW5hbHlzaXMg b2YgUmVkdWNlZCBTTVM0IEJsb2NrIENpcGhlci4gSUFDUiBDcnlwdG9sb2d5IGVQcmludEFyY2hp dmUgMjAwOC8yODEsICgyMDA4KS4NCjxhIGhyZWY9Imh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIw MDgvMjgxMS5wZGYiPmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMDgvMjgxMS5wZGY8L2E+PC9k aXY+DQo8ZGl2Pls5XSBMaXUgRi4sIEppIFcuLCBIdSBMLiwgRGluZyBKLiwgTHYgUy4sIFB5c2hr aW4gQS4sIFdlaW5tYW5uIFIuLVAuOiBBbmFseXNpcyBvZiB0aGUgU01TNCBCbG9jayBDaXBoZXIu IEluOiBQaWVwcnp5ayBKLiwgR2hvZG9zaSBILiwgRGF3c29uIEUuIChlZHMpIEluZm9ybWF0aW9u IFNlY3VyaXR5IGFuZCBQcml2YWN5LiBBQ0lTUCAyMDA3LiBMZWN0dXJlIE5vdGVzIGluIENvbXB1 dGVyIFNjaWVuY2UsIHZvbCA0NTg2LCBwcC4gMTU44oCTMTcwLg0KIFNwcmluZ2VyLCBCZXJsaW4s IEhlaWRlbGJlcmcgKDIwMDcpLjwvZGl2Pg0KPGRpdj5bMTBdIExpdSBNLi1KLiwgQ2hlbiBKLi1a LjogSW1wcm92ZWQgTGluZWFyIEF0dGFja3Mgb24gdGhlIENoaW5lc2UgQmxvY2sgQ2lwaGVyIFN0 YW5kYXJkLiBKLiBDb21wdXQuIFNjaS4gVGVjaG5vbC4gKDIwMTQpIDI5KDYpOiBwcC4gMTEyM+KA kzExMzMuICgyMDE0KS48L2Rpdj4NCjxkaXY+WzExXSBMaXUgTS4sIENoZW4gSi4sIExpIEguOiBQ YXJ0aWFsbHkgS25vd24gTm9uY2VzIGFuZCBGYXVsdCBJbmplY3Rpb24gQXR0YWNrcyBvbiBTTTIg U2lnbmF0dXJlIEFsZ29yaXRobS4gSW46IExpbiBELiwgWHUgUy4sIFl1bmcgTS4gKGVkcykgSW5m b3JtYXRpb24gU2VjdXJpdHkgYW5kIENyeXB0b2xvZ3kuIEluc2NyeXB0IDIwMTMuIExlY3R1cmUg Tm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDg1NjcsIHBwLiAzNDPigJMzNTguIFNwcmlu Z2VyLA0KIENoYW0gKDIwMTQpLjwvZGl2Pg0KPGRpdj5bMTJdIExpdSBZLiwgTGlhbmcgSC4sIFdh bmcgVy4sIFdhbmcgTS46IE5ldyBMaW5lYXIgQ3J5cHRhbmFseXNpcyBvZiBDaGluZXNlIENvbW1l cmNpYWwgQmxvY2sgQ2lwaGVyIFN0YW5kYXJkIFNNNC4gU2VjdXJpdHkgYW5kIENvbW11bmljYXRp b24gTmV0d29ya3MuIFZvbHVtZSAyMDE3LCBBcnRpY2xlIElEIDE0NjE1MjAsIDEwIHBhZ2VzICgy MDE3KS4NCjxhIGhyZWY9Imh0dHA6Ly9kb3dubG9hZHMuaGluZGF3aS5jb20vam91cm5hbHMvc2Nu LzIwMTcvMTQ2MTUyMC5wZGYiPmh0dHA6Ly9kb3dubG9hZHMuaGluZGF3aS5jb20vam91cm5hbHMv c2NuLzIwMTcvMTQ2MTUyMC5wZGY8L2E+PC9kaXY+DQo8ZGl2PlsxM10gTWVuZGVsIEYuLCBOYWQg VC4sIFNjaGzCqCBhZmZlciBNLjogRmluZGluZyBDb2xsaXNpb25zIGZvciBSb3VuZC1SZWR1Y2Vk IFNNMy4gSW46IERhd3NvbiBFLiAoZWRzKSBUb3BpY3MgaW4gQ3J5cHRvbG9neSDigJQgQ1QtUlNB IDIwMTMuIENULVJTQSAyMDEzLiBMZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2UsIHZv bCA3Nzc5LCBwcC4gMTc0LTE4OC4gU3ByaW5nZXIsIEJlcmxpbiwgSGVpZGVsYmVyZyAoMjAxMyku PC9kaXY+DQo8ZGl2PlsxNF0gTWVuZXplcyBBLiBKLiwgdmFuIE9vcnNjaG90IFAuIEMuLCBWYW5z dG9uZSBTLiBBLjogSGFuZGJvb2sgb2YgQXBwbGllZCBDcnlwdG9ncmFwaHkuIFRoZSBDUkMgUHJl c3Mgc2VyaWVzIG9uIGRpc2NyZXRlIG1hdGhlbWF0aWNzIGFuZCBpdHMgYXBwbGljYXRpb25zLCBD UkMgUHJlc3MsIDIwMDAgTi5XLiBDb3Jwb3JhdGUgQmx2ZC4sIEJvY2EgUmF0b24sIEZMIDMzNDMx LTk4NjgsIFVTQSAoMTk5NykuPC9kaXY+DQo8ZGl2PlsxNV0gU2hlbiBZLiwgQmFpIEQuLCBZdSBI LjogSW1wcm92ZWQgY3J5cHRhbmFseXNpcyBvZiBzdGVwLXJlZHVjZWQgU00zLiBTY2llbmNlIENo aW5hIEluZm9ybWF0aW9uIFNjaWVuY2VzLCA2MSAoMjAxNyk6IHBwLiAx4oCTMi4mbmJzcDs8L2Rp dj4NCjxkaXY+WzE2XSBTaGVuIFMuLCBMZWUgWC46IFNNMiBEaWdpdGFsIFNpZ25hdHVyZSBBbGdv cml0aG0uIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UsIEludGVybmV0LURyYWZ0IGRy YWZ0LXNoZW4tc20yLWVjZHNhLTAyLCBGZWJydWFyeSAxNCwgMjAxNC4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGVuLXNtMi1lY2RzYS0wMiI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoZW4tc20yLWVjZHNhLTAyPC9hPjwvZGl2Pg0KPGRp dj5bMTddIFNoZW4gUy4sIExlZSBYLjogU00zIEhhc2ggZnVuY3Rpb24uIEludGVybmV0IEVuZ2lu ZWVyaW5nIFRhc2sgRm9yY2UsIEludGVybmV0LURyYWZ0IGRyYWZ0LXNoZW4tc20zLWhhc2gtMDEs IEZlYnJ1YXJ5IDE0LCAyMDE0Lg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNoZW4tc20zLWhhc2gtMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zaGVuLXNtMy1oYXNoLTAxPC9hPjwvZGl2Pg0KPGRpdj5bMThdIFN1IEIuLVouLCBXdSBXLi1M LiwgWmhhbmcgVy4tVC46IFNlY3VyaXR5IG9mIHRoZSBTTVM0IEJsb2NrIENpcGhlciBBZ2FpbnN0 IERpZmZlcmVudGlhbCBDcnlwdGFuYWx5c2lzLiBKLiBDb21wdXQuIFNjaS4gVGVjaG5vbC4gKDIw MTEpIDI2KDEpOiBwcC4gMTMw4oCTMTM4LiAoMjAxMSkuPC9kaXY+DQo8ZGl2PlsxOV0gV2FuZyBH LiwgU2hlbiBZLjogUHJlaW1hZ2UgYW5kIHBzZXVkby1jb2xsaXNpb24gYXR0YWNrcyBvbiBzdGVw LXJlZHVjZWQgU00zIGhhc2ggZnVuY3Rpb24uIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgTGV0dGVy cywgMjAxMywgMTEzLCBwcC4gMzAx4oCTMzA2LCAoMjAxMykuPC9kaXY+DQo8ZGl2PlsyMF0gWHUg Si4sIEZlbmcgRC46IENvbW1lbnRzIG9uIHRoZSBTTTIgS2V5IEV4Y2hhbmdlIFByb3RvY29sLiBJ bjogTGluIEQuLCBUc3VkaWsgRy4sIFdhbmcgWC4gKGVkcykgQ3J5cHRvbG9neSBhbmQgTmV0d29y ayBTZWN1cml0eS4gQ0FOUyAyMDExLiBMZWN0dXJlIE5vdGVzIGluIENvbXB1dGVyIFNjaWVuY2Us IHZvbCA3MDkyLCBwcC4gMTYw4oCTMTcxLiBTcHJpbmdlciwgQmVybGluLCBIZWlkZWxiZXJnICgy MDExKS48L2Rpdj4NCjxkaXY+WzIxXSBZYW5nIEEuLCBOYW0gSiwgS2ltIE0uLCBDaG9vIEsuLUsu IFIuOiBQcm92YWJseS1TZWN1cmUgKENoaW5lc2UgR292ZXJubWVudCkgU00yIGFuZCBTaW1wbGlm aWVkIFNNMiBLZXkgRXhjaGFuZ2UgUHJvdG9jb2xzLiBUaGUgU2NpZW50aWZpYyBXb3JsZCBKb3Vy bmFsLCBWb2x1bWUgMjAxNCwgQXJ0aWNsZSBJRCA4MjU5ODQgKDIwMTQpLg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaGluZGF3aS5jb20vam91cm5hbHMvdHN3ai8yMDE0LzgyNTk4NC8iPmh0dHBzOi8v d3d3LmhpbmRhd2kuY29tL2pvdXJuYWxzL3Rzd2ovMjAxNC84MjU5ODQvPC9hPjwvZGl2Pg0KPGRp dj5bMjJdIFpoYW5nIEIuLCBKaW4gQy46IFByYWN0aWNhbCBzZWN1cml0eSBhZ2FpbnN0IGxpbmVh ciBjcnlwdGFuYWx5c2lzIGZvciBTTVM0LWxpa2UgY2lwaGVycyB3aXRoIFNQIHJvdW5kIGZ1bmN0 aW9uLiBTY2kuIENoaW5hIEluZi4gU2NpLiAoMjAxMikgNTUoOSk6IHBwLiAyMTYx4oCTMjE3MC4g KDIwMTIpLjwvZGl2Pg0KPGRpdj5bMjNdIFpoYW5nIEouLCBXdSBXLiwgWmhlbmcgWS46IFNlY3Vy aXR5IG9mIFNNNCBBZ2FpbnN0IChSZWxhdGVkLUtleSkgRGlmZmVyZW50aWFsIENyeXB0YW5hbHlz aXMuIEluOiBCYW8gRi4sIENoZW4gTC4sIERlbmcgUi4sIFdhbmcgRy4gKGVkcykgSW5mb3JtYXRp b24gU2VjdXJpdHkgUHJhY3RpY2UgYW5kIEV4cGVyaWVuY2UuIElTUEVDIDIwMTYuIExlY3R1cmUg Tm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDEwMDYwLCBwcC4gNjXigJM3OC4NCiBTcHJp bmdlciwgQ2hhbSAoMjAxNikuPC9kaXY+DQo8ZGl2PlsyNF0gWmhhbmcgVy4sIFd1IFcuLCBGZW5n IEQuLCBTdSBCLjogU29tZSBOZXcgT2JzZXJ2YXRpb25zIG9uIHRoZSBTTVM0IEJsb2NrIENpcGhl ciBpbiB0aGUgQ2hpbmVzZSBXQVBJIFN0YW5kYXJkLiBJbjogQmFvIEYuLCBMaSBILiwgV2FuZyBH LiAoZWRzKSBJbmZvcm1hdGlvbiBTZWN1cml0eSBQcmFjdGljZSBhbmQgRXhwZXJpZW5jZS4gSVNQ RUMgMjAwOS4gTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRlciBTY2llbmNlLCB2b2wgNTQ1MSwgcHAu DQogMzI04oCTMzM1LiBTcHJpbmdlciwgQmVybGluLCBIZWlkZWxiZXJnICgyMDA5KS48L2Rpdj4N CjxkaXY+WzI1XSBaaGFuZyBaLiwgWWFuZyBLLiwgWmhhbmcgSi4sIENoZW4gQy46IFNlY3VyaXR5 IG9mIHRoZSBTTTIgU2lnbmF0dXJlIFNjaGVtZSBBZ2FpbnN0IEdlbmVyYWxpemVkIEtleSBTdWJz dGl0dXRpb24gQXR0YWNrcy4gSW46IENoZW4gTC4sIE1hdHN1byBTLiAoZWRzKSBTZWN1cml0eSBT dGFuZGFyZGlzYXRpb24gUmVzZWFyY2guIExlY3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5j ZSwgdm9sIDk0OTcsIHBwLiAxNDDigJMxNTMuIFNwcmluZ2VyLA0KIENoYW0gKDIwMTUpLjwvZGl2 Pg0KPGRpdj5bMjZdIFpvdSBKLiwgV3UgVy4sIFd1IFMuLCBTdSBCLiwgRG9uZyBMLjogUHJlaW1h Z2UgQXR0YWNrcyBvbiBTdGVwLVJlZHVjZWQgU00zIEhhc2ggRnVuY3Rpb24uIEluOiBLaW0gSC4g KGVkcykgSW5mb3JtYXRpb24gU2VjdXJpdHkgYW5kIENyeXB0b2xvZ3kg4oCUIElDSVNDIDIwMTEu IElDSVNDIDIwMTEuIExlY3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDcyNTks IHBwLiAzNzUtMzkwLiBTcHJpbmdlciwgQmVybGluLCBIZWlkZWxiZXJnDQogKDIwMTIpLjwvZGl2 Pg0KPGRpdj5bMjddIDxhIGhyZWY9Imh0dHBzOi8vc2FmZWN1cnZlcy5jci55cC50by9kaXNjLmh0 bWwiPmh0dHBzOi8vc2FmZWN1cnZlcy5jci55cC50by9kaXNjLmh0bWw8L2E+PC9kaXY+DQo8ZGl2 PlsyOF0gUGV0aXQgQy4sIEtvc3RlcnMgTS4sIE1lc3NlbmcgQS4gKDIwMTYpIEFsZ2VicmFpYyBB cHByb2FjaGVzIGZvciB0aGUgRWxsaXB0aWMgQ3VydmUgRGlzY3JldGUgTG9nYXJpdGhtIFByb2Js ZW0gb3ZlciBQcmltZSBGaWVsZHMuIEluOiBDaGVuZyBDTS4sIENodW5nIEtNLiwgUGVyc2lhbm8g Ry4sIFlhbmcgQlkuIChlZHMpIFB1YmxpYy1LZXkgQ3J5cHRvZ3JhcGh5IOKAkyBQS0MgMjAxNi4g UEtDIDIwMTYuIExlY3R1cmUgTm90ZXMgaW4NCiBDb21wdXRlciBTY2llbmNlLCB2b2wgOTYxNS4g U3ByaW5nZXIsIEJlcmxpbiwgSGVpZGVsYmVyZzwvZGl2Pg0KPGRpdj5bMjldIEUuIEFsZWtzZWV2 LCBWLiBOaWtvbGFldiwgUy4gU215c2hseWFldi4gT24gdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMg b2YgUnVzc2lhbiBzdGFuZGFyZGl6ZWQgZWxsaXB0aWMgY3VydmVzLiBDVENyeXB04oCZMTcgUHJl cHJvY2VlZGluZ3MuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D8F69AA24FD8412DB13A68051F5A598Brhulacuk_-- From nobody Thu Dec 21 02:50:15 2017 Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B429129C6F for ; Wed, 20 Dec 2017 06:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L9kNuI-kV8R for ; Wed, 20 Dec 2017 06:09:23 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182B0126CD6 for ; Wed, 20 Dec 2017 06:09:23 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id d202so2254166qkc.9 for ; Wed, 20 Dec 2017 06:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=agidvsv0xn3Wavn7WG4k4TzXlcJ16KAm5xpA4cVJTi0=; b=sWl3AqSbnN3lOdSA8P4Tty3CveGAjXP8P6lkhb3gJ9A9EyMDBv3QscAhJXLKZgixJA zUPzhr555xdHjTnRZAWxIFZZ+xCEyhaWJX0jppd0kjJqCd2BS8C/hbODja1rAvOOG+aT ai3Fx5CBlQQ0Hyespf10MBLZ19v47utY/G1ohFvEHU2c/ejMmfCdfdSBXUszrBvgsnZs zJc4WFXT0i5/lOug1v+8lhXw70bQZRK8ptticy0fEmZq5a6busIUJLLIhXfXCRTo8S/5 SPZM0CeOEVJoRELtQCcDlDeG4hGkfIchWzWyRn0E0mZc6uKAE2k1WCPVJ3ZBGZuFNfgl 8wUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=agidvsv0xn3Wavn7WG4k4TzXlcJ16KAm5xpA4cVJTi0=; b=S0G4KkJUxK4eFAzo+rqg8WVvQW2HDRMt5TkUjHsw/xlDDCfslV/Qa+ETMk0RK46Pzr OlR/Xeqq0r02vrzLfx/J0Rv4g3+FGbr3qLAivGveA+2/sNKky0kykPM9IppwVD8WGCfR OaE7i7r9KteZbPiWNAZd0dtVltQdv1TNRHhYdeL4laijBugAyQcrFcheYtFYpXwMN5oR uK5B0iOe11HsSYwl1l+9taVdYuxnVppgsKtiId+Pcaw1U8Oa3vpi1b8Dd0qnxCQbkvZ1 amxChKDnfnCrOuwBm8IQGs7jo1b8DpoAXcSqmfVXzXBUR6mODqLqU5UleiGKO5dQ+29J 7+ow== X-Gm-Message-State: AKGB3mK4eqFKpcqI+iOwXiS+/FVIqLX0hL2fc/Li1dH9rUb1swKXAhIs i8gztjBBl44tzt9H6at5XhVsj1slWbQvBzFyXpc= X-Google-Smtp-Source: ACJfBosLfnEj0o49mrTF4Eo5Jp/2a17ZzPKRNz1OjQevzGq9dbkHgWRyRB6wdlNKhUcWqA8np9rdax6sZJu96DXtpqc= X-Received: by 10.55.80.8 with SMTP id e8mr9901443qkb.126.1513778961454; Wed, 20 Dec 2017 06:09:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.139 with HTTP; Wed, 20 Dec 2017 06:09:21 -0800 (PST) In-Reply-To: <3606FBCE-CFBA-4B88-A169-73148BF11773@ribose.com> References: <3606FBCE-CFBA-4B88-A169-73148BF11773@ribose.com> From: "Stanislav V. Smyshlyaev" Date: Wed, 20 Dec 2017 17:09:21 +0300 Message-ID: To: Ronald Tse , "cfrg@irtf.org" Cc: "Paterson, Kenny" , Wai Kit Wong , alexey.melnikov@isode.com Content-Type: multipart/alternative; boundary="001a114a7166441b6c0560c62179" Archived-At: X-Mailman-Approved-At: Thu, 21 Dec 2017 02:50:12 -0800 Subject: Re: [Cfrg] Review request for SM4 block cipher draft: draft-ribose-cfrg-sm4-00 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 14:09:27 -0000 --001a114a7166441b6c0560c62179 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Document: draft-ribose-openpgp-oscca-01 (and draft-ribose-openpgp-sca-00) Reviewer: Stanislav Smyshlyaev Review Date: 2017-12-20 Summary: Major revision needed The I-D describes the usage of SM2, SM3 and SM4 algorithms, developed in China, in OpenPGP. SM2 defines digital signature, key exchange and public key encryption algorithms, SM3 defines a hash function and SM4 defines a 128-bit block 128-bit key block cipher. In this review prepared as a member of Crypto Review Panel, hence the focus is not on technical issues related to OpenPGP itself, the review is being done from the cryptographic perspective. Nevertheless, full cryptanalysis of 3 algorithms from a scratch is impossible to be made as a part of review, so the analysis is conducted heavily taking into account current state of the analysis of the proposed mechanisms. The current review is conducted based on the I-D itself and also I-Ds draft-sca-cfrg-sm3-00 and draft-ribose-cfrg-sm4-08, providing material on design rationale and published security analysis of SM3 and SM4. At the time of this review the SM2 I-D does not contain similar material, thus I think that a new review later is necessary after such a material on SM2 is added to the corresponding I-D (the author, Ronald Tse, has said that the corresponding work is in progress). *SM2* The summary of the known results for SM2 is not provided in the I-D for SM2, so a short summary is provided here in the review. SM2 [16] is a set of three public key cryptographic algorithms based on elliptic curves: signature algorithm, key exchange protocol, and public key encryption algorithm. These algorithms and recommended parameters are published by Chinese Commercial Cryptography Administration Office for the use of electronic authentication service system. In [25], the class of signature algorithms is analyzed, which includes the SM2 signature algorithm. More exactly, the generalized key substitution attacks are investigated where the base element is considered as a part of the public key and can be substituted. It is proven that the Chinese standard SM2 signature scheme is existentially unforgeable against adaptively chosen-message attacks in the generic group model if the underlying hash function is uniform and collision-resistant and the underlying conversion function is almost-invertible, and the SM2 digital signature scheme is secure against the generalized key substitution attacks if the underlying hash functions are modeled as non-programmable random oracles (NPROs). In [11], the partially known nonces attack against SM2 are discussed. It is shown by the experiments that the private key can be recovered, given 100 signatures with 3 bits of nonces known for 256-bit SM2. Also a byte-fault attack on SM2 is developed when a byte of random fault is injected on the secret key during the signing process. In [3], a practical lattice-based fault attack against SM2 signature algorithm in a smart card is presented. Authors of [3] successfully utilized the laser fault attack to skip the instructions of nonces being written into RAM, so that the nonces in signatures share partial same bits from each other. Next, they build the model of lattice attack and recover the private key. The experimental results show that only 3 faulty signatures are needed to mount lattice attack successfully in about 32 =C2=B5s. Moreover, they proposed a new countermeasure for SM2 signature algorithm to resist lattice-based fault attack by destroying the condition of lattice attack rather than thwarting fault attack. It is proven that the countermeasure can guarantee the ability to resist lattice attack, even if some information of the nonces is leaked. As noted in [7], the SM2 signature algorithm as well as the Russian standard GOST R 34.10-2012, and the ECDSA algorithm fits into the general scheme of the ElGamal signature algorithm, proposed back in 1997 in the classic monograph [14]. In [20], apparently concerning the earlier version of the SM2 key exchange protocol, it is shown that this version is vulnerable to realistic attacks in the Canetti-Krawczyk model, in which an adversary only knows the state of the session. Simple modifications of this version are proposed, which eliminate this problem. In [21], the security of the SM2 key exchange protocol in the widespread Bellare-Rogaway model is proved under the assumption that the discrete logarithm problem for elliptic curves is hard. Also in this paper a simplified but more effective version of this protocol is presented together with a similar security proof. Based on the published results, I see no reasons to object against using the SM2 digital signature scheme and the SM2 public key encryption for secure elliptic curves. Nevertheless, I'd prefer to conduct an additional review after a section about design rationale and a summary of cryptanalytic results is added to the SM2 I-D. *SM3* The SM3 hash function [17] is constructed on the cryptographic principles embedded in the MD4 hash function family, or more precisely, in the SHA-2 hash functions. In the 6 years since publication of the SM3 hash function, some attacks on truncated versions have been built. These are attacks of finding preimage, collisions, pseudo-collisions and free-start collisions, as well as attacks of constructing boomerang-distinguishers. In [19], the preimage attacks transformed into attacks of constructing pseudo-collisions for versions of the SM3 hash function, truncated to 29, 30, 31 and 32 steps, with complexities 2^122 , 2^125.1 , 2^122 and 2^125.1 , respectively. In [13], real collisions were found with practical complexity for the 20 (of 64) steps SM3 hash function, and real free-start collisions were found with practical complexity for the 24 steps SM3 hash function. Based on the published results, I see no reasons to object against using the SM3 hash function. *SM4* SMS4 [5], issued in 2006 by Chinese government, serves the WAPI (WLAN Authentication and Privacy Infrastructure) as the underling block cipher for the security of wireless LANs. In 2012, SMS4 was announced as the Chinese commercial block cipher standard, renamed to SM4. SM4 is a 32-round block cipher with the same block length and key equal to 128 bit. Unlike other open Chinese cryptographic standards (SM2 and SM3), the block cipher SM4 attracted more attention of the international cryptographic community. So in [9] the integral attack is proposed for the 13-round version of the SM4 cipher. In [8], the rectangle and boomerang attacks on 18-round SM4 and the linear and differential attacks on 22-round SM4 have been presented. Using the technique of multiple linear approximations, in [6] an attack was developed for the 22- and 23-round version of SM4. In [24], the results of [6] for the 22-round version were improved. The best differential attacks to date for the 23-round version of SM4 were obtained in [18]. For the same version of SM4, the multidimensional linear attack was proposed in [4]. The best linear attacks to date for the 23- and 24-round version of SM4 have been developed in [10] and [12], respectively. In [23] it is shown that the SM4 cipher is resistant to differential cryptanalysis in the related key model for versions starting at 19 rounds. It is also worth mentioning here the paper [22], in which lower bounds are obtained for the number of =E2=80=9C linearly active=E2=80=9D S-boxes for S= M4-like block ciphers. Based on the published results, I see no reasons to object against using the SM4 cipher. *The elliptic curve parameters* There is no sufficient material on a provided elliptic curve, so some analysis is made in the current review. The provided short Weierstrass equation coefficients correctly define the elliptic curve (it has non-null discriminant). The j-invariant of the curve is not equal to 0 or 1728. The order of the provided curve points group m equals 115792089210356248756420345214020892766061623724957744567843809356293439045= 923 and is prime. The provided base point belongs to the curve and has order q equal to m. Therefore cofactor h of the specified subgroup equals to 1. The order of the subgroup is big enough (about 2^256) to make attacks base on Pollard=E2=80=99s rho method ineffective. Since q !=3D p effective additive= transfers are not possible. MOV-attacks are ineffective since the curve has high embedding degree (equals q-1). The absolute value of complex multiplication discriminant is about 2^257 and fully satisfies requirements of the SafeCurves ([27]). The attack by Petit, Kosters and Messeng ([28]) which employs Semaev summation polynomials is also ineffective since all sets of small factor of p-1 (namely 2 and 43) meet criterion, provided in [29]. It can shown that group of points of the quadratic twist of the curve has order m=E2=80=99 equal to 115792089210356248756420345214020892766439084258890638340998578510285930938= 077. The largest subgroup has the order q=E2=80=99 =3D 336942259148358014326618776206081604165520103 with cofactor h=E2=80=99=3D 343655585093504666447005752284059. Since q=E2=80=99 is about 2^147 Pollard= =E2=80=99s rho algorithm is more effective here than on the original curve. Since q=E2=80= =99 is not equal to p and ord(p) in Z*(q=E2=80=99) equals (q'-1)/11 there exist ne= ither effective additive transfers nor effective multiplicative transfers. It is important to note, however, the provided curve cannot be rewritten in Montgomery form. The provided curve satisfies all modern security requirements. However, some clarifications on the selection of values of b, x(P), y(P) have to be provided: some kind of NUMS-type arguments are desirable. *General comments for the I-D* There are a lot of words about OSCCA/SCA-compliance. I am not sure that this is important for an IETF document - maybe it would be better not to mention these regulatory issues. A lot of references is given to OSCCA/SCA documents and Chinese standards - maybe it will be better to use references to IETF I-Ds/RFCs for SM2, SM3, SM4. Throughout the text there are "MUST" codewords about "a compliant OpenPGP implementation" - it seems to be too strict to use MUST codeword when discussing optional algorithms/parameters to use with some protocols/implementations. There are some problems with links to oscca.gov.cn - maybe the site has been down recent days, but I couldn't open these links. Do we need them provided that we have RFCs and other links? *Particular comments* Section 1: SM4 is called "kM4". About SM3 (a hash) instead of "electronic authentication" and "data validation" it would better say something like "integrity". In "support the SM4 symmetric encryption algorithm for data protection purposes" I'd prefer to say about "confidentiality", not "protection" (especially since SM4 does not define a MAC mode). "SM3 with other digital signing algorithms, such as RSA, ECDSA and SM2": 1) "signing"->"signature"; 2) EC-RDSA from ISO/IEC 14888-3 is also appropriate here. Section 3, first sentence: "they" seems to be omitted after "and". Section 4: "elliptical" -> "elliptic". Section 4.1: do we need to say about this optional ZA field from SM2 standard? And personally I don't like this double hashing (H(ZA|| H(msg))). I am not sure that section 4.2 is needed: it is said that this algorithm is not related to OpenPGP and also has security issues - I'd recommend to remove this part from the document at all. Section 4.4.2: I'd recommend to say that the curve is defined over a certain finite field in short Weierstrass form. Section 4.4.3: I'd prefer to see also words about the cofactor of the group and that all numbers are in big-endian form. Section 4.5.1: It should be stated explicitly that all numbers are in little-endian or big-endian. Section 5. A misprint: "cryptogrpahic". Instead of "digital signatures and their verification" it would better say "digital signature generation and verification". When we say about MACing or PRNGs, specific constructions should be mentioned, in my opinion. Otherwise, I'd prefer not to have these general words about SM3 applications (they are the same as for any hash function). There is a parameter "m", which seems not to be defined at that moment. Section 6: it seems to be useful to define whether the S-box is fixed or variable. The note is missing that SM4 is an unbalanced Feistel network =E2=80=93 thi= s seems more important than the note that it is designed for encryption. In section 7.3 there is a mistake in the second paragraph: this is not a "symmetric encryption algorithm". In section 9.3 "whole number" -> "integer". "Ha!" doesn't look a good variable name. Since n is an integer, ceil is not needed. In section 14 the second paragraph doesn't look accurate enough. For instance, "ECDLP" seems more appropriate than "ECLP". Regarding the digital signature, a reference to the hash is also needed here. Regarding the key exchange scheme - not only a reference to discrete logarithm problem, but also to CDH/DDH is desirable. "randomly generated without fixed correlation" - the sentence looks a little strange because of "fixed". Section 15: Maybe it would be better to say "has made" after the assignments are made. *References* [1] Bai D., Yu H., Wang G., Wang X.: Improved Boomerang Attacks on SM3. In: Boyd C.,Simpson L. (eds) Information Security and Privacy. ACISP 2013. Lecture Notes in Computer Science, vol 7959, pp. 251=E2=80=93266. Springer,= Berlin, Heidelberg (2013). [2] Bai D., Yu H., Wang G., Wang X.: Improved boomerang attacks on round-reduced SM3 and keyed permutation of BLAKE-256. IET Information Security 9(3): pp. 167=E2=80=93178 (2015). [3] Cao W., Feng J., Zhu S., Chen H., Wu W., Han X., Zheng X.: Practical Lattice-Based Fault Attack and Countermeasure on SM2 Signature Algorithm. In: Qing S., Okamoto E., Kim K., Liu D. (eds) Information and Communications Security. ICICS 2015. Lecture Notes in Computer Science, vol 9543, pp. 62=E2=80=9370. Springer, Cham (2015). [4] Cho J., Nyberg K.: Improved Linear Cryptanalysis of SMS4 Block Cipher. Symmetric Key Encryption Workshop, pp. 1=E2=80=9314. (2011). http://skew2011.mat.dtu.dk/proceedings/Improved%20Linear%20Cryptanalysis%20= of%20SMS4%20Block%20Cipher.pdf [5] Diffie W., Ledin G.: SMS4 Encryption Algorithm for Wireless Networks. Cryptology ePrint Archive 2008/329. http://eprint.iacr.org/2008/329.pdf [6] Etrog J., Robshaw M. J. B.: The Cryptanalysis of Reduced-Round SMS4. In: Avanzi R. M., Keliher L., Sica F. (eds) Selected Areas in Cryptography. SAC 2008. Lecture Notes in Computer Science, vol 5381, pp. 51=E2=80=9365. S= pringer, Berlin, Heidelberg (2009). [7] Fersch M., Kiltz E., Poettering B.: On the One-Per-Message Unforgeability of (EC)DSA and Its Variants. In: Kalai Y., Reyzin L. (eds) Theory of Cryptography. TCC 2017. Lecture Notes in Computer Science, vol 10678, pp. 519=E2=80=93534. Springer, Cham (2017). [8] Kim T., Kim J., Hong S., Sung J.: Linear and Differential Cryptanalysis of Reduced SMS4 Block Cipher. IACR Cryptology ePrintArchive 2008/281, (2008). https://eprint.iacr.org/2008/2811.pdf [9] Liu F., Ji W., Hu L., Ding J., Lv S., Pyshkin A., Weinmann R.-P.: Analysis of the SMS4 Block Cipher. In: Pieprzyk J., Ghodosi H., Dawson E. (eds) Information Security and Privacy. ACISP 2007. Lecture Notes in Computer Science, vol 4586, pp. 158=E2=80=93170. Springer, Berlin, Heidelbe= rg (2007). [10] Liu M.-J., Chen J.-Z.: Improved Linear Attacks on the Chinese Block Cipher Standard. J. Comput. Sci. Technol. (2014) 29(6): pp. 1123=E2=80=9311= 33. (2014). [11] Liu M., Chen J., Li H.: Partially Known Nonces and Fault Injection Attacks on SM2 Signature Algorithm. In: Lin D., Xu S., Yung M. (eds) Information Security and Cryptology. Inscrypt 2013. Lecture Notes in Computer Science, vol 8567, pp. 343=E2=80=93358. Springer, Cham (2014). [12] Liu Y., Liang H., Wang W., Wang M.: New Linear Cryptanalysis of Chinese Commercial Block Cipher Standard SM4. Security and Communication Networks. Volume 2017, Article ID 1461520, 10 pages (2017). http://downloads.hindawi.com/journals/scn/2017/1461520.pdf [13] Mendel F., Nad T., Schl=C2=A8 affer M.: Finding Collisions for Round-Reduced SM3. In: Dawson E. (eds) Topics in Cryptology =E2=80=94 CT-RS= A 2013. CT-RSA 2013. Lecture Notes in Computer Science, vol 7779, pp. 174-188. Springer, Berlin, Heidelberg (2013). [14] Menezes A. J., van Oorschot P. C., Vanstone S. A.: Handbook of Applied Cryptography. The CRC Press series on discrete mathematics and its applications, CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL 33431-9868, USA (1997). [15] Shen Y., Bai D., Yu H.: Improved cryptanalysis of step-reduced SM3. Science China Information Sciences, 61 (2017): pp. 1=E2=80=932. [16] Shen S., Lee X.: SM2 Digital Signature Algorithm. Internet Engineering Task Force, Internet-Draft draft-shen-sm2-ecdsa-02, February 14, 2014. https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 [17] Shen S., Lee X.: SM3 Hash function. Internet Engineering Task Force, Internet-Draft draft-shen-sm3-hash-01, February 14, 2014. https://tools.ietf.org/html/draft-shen-sm3-hash-01 [18] Su B.-Z., Wu W.-L., Zhang W.-T.: Security of the SMS4 Block Cipher Against Differential Cryptanalysis. J. Comput. Sci. Technol. (2011) 26(1): pp. 130=E2=80=93138. (2011). [19] Wang G., Shen Y.: Preimage and pseudo-collision attacks on step-reduced SM3 hash function. Information Processing Letters, 2013, 113, pp. 301=E2=80=93306, (2013). [20] Xu J., Feng D.: Comments on the SM2 Key Exchange Protocol. In: Lin D., Tsudik G., Wang X. (eds) Cryptology and Network Security. CANS 2011. Lecture Notes in Computer Science, vol 7092, pp. 160=E2=80=93171. Springer,= Berlin, Heidelberg (2011). [21] Yang A., Nam J, Kim M., Choo K.-K. R.: Provably-Secure (Chinese Government) SM2 and Simplified SM2 Key Exchange Protocols. The Scientific World Journal, Volume 2014, Article ID 825984 (2014). https://www.hindawi.com/journals/tswj/2014/825984/ [22] Zhang B., Jin C.: Practical security against linear cryptanalysis for SMS4-like ciphers with SP round function. Sci. China Inf. Sci. (2012) 55(9): pp. 2161=E2=80=932170. (2012). [23] Zhang J., Wu W., Zheng Y.: Security of SM4 Against (Related-Key) Differential Cryptanalysis. In: Bao F., Chen L., Deng R., Wang G. (eds) Information Security Practice and Experience. ISPEC 2016. Lecture Notes in Computer Science, vol 10060, pp. 65=E2=80=9378. Springer, Cham (2016). [24] Zhang W., Wu W., Feng D., Su B.: Some New Observations on the SMS4 Block Cipher in the Chinese WAPI Standard. In: Bao F., Li H., Wang G. (eds) Information Security Practice and Experience. ISPEC 2009. Lecture Notes in Computer Science, vol 5451, pp. 324=E2=80=93335. Springer, Berlin, Heidelbe= rg (2009). [25] Zhang Z., Yang K., Zhang J., Chen C.: Security of the SM2 Signature Scheme Against Generalized Key Substitution Attacks. In: Chen L., Matsuo S. (eds) Security Standardisation Research. Lecture Notes in Computer Science, vol 9497, pp. 140=E2=80=93153. Springer, Cham (2015). [26] Zou J., Wu W., Wu S., Su B., Dong L.: Preimage Attacks on Step-Reduced SM3 Hash Function. In: Kim H. (eds) Information Security and Cryptology =E2= =80=94 ICISC 2011. ICISC 2011. Lecture Notes in Computer Science, vol 7259, pp. 375-390. Springer, Berlin, Heidelberg (2012). [27] https://safecurves.cr.yp.to/disc.html [28] Petit C., Kosters M., Messeng A. (2016) Algebraic Approaches for the Elliptic Curve Discrete Logarithm Problem over Prime Fields. In: Cheng CM., Chung KM., Persiano G., Yang BY. (eds) Public-Key Cryptography =E2=80=93 PK= C 2016. PKC 2016. Lecture Notes in Computer Science, vol 9615. Springer, Berlin, Heidelberg [29] E. Alekseev, V. Nikolaev, S. Smyshlyaev. On the security properties of Russian standardized elliptic curves. CTCrypt=E2=80=9917 Preproceedings. --001a114a7166441b6c0560c62179 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-ribose-ope= npgp-oscca-01 (and draft-ribose-openpgp-sca-00)
Reviewer: Stanisl= av Smyshlyaev
Review Date: 2017-12-20
Summary: Major re= vision needed

The I-D describes the usage of SM2, = SM3 and SM4 algorithms, developed in China, in OpenPGP. SM2 defines digital= signature, key exchange and public key encryption algorithms, SM3 defines = a hash function and SM4 defines a 128-bit block 128-bit key block cipher.

In this review prepared as a member of Crypto Revie= w Panel, hence the focus is not on technical issues related to OpenPGP itse= lf, the review is being done from the cryptographic perspective. Neverthele= ss, full cryptanalysis of 3 algorithms from a scratch is impossible to be m= ade as a part of review, so the analysis is conducted heavily taking into a= ccount current state of the analysis of the proposed mechanisms.
=
The current review is conducted based on the I-D itself and = also I-Ds draft-sca-cfrg-sm3-00 and draft-ribose-cfrg-sm4-08, providing mat= erial on design rationale and published security analysis of SM3 and SM4. A= t the time of this review the SM2 I-D does not contain similar material, th= us I think that a new review later is necessary after such a material on SM= 2 is added to the corresponding I-D (the author, Ronald Tse, has said that = the corresponding work is in progress).


SM2

The summary of the known re= sults for SM2 is not provided in the I-D for SM2, so a short summary is pro= vided here in the review.

SM2 [16] is a set of thr= ee public key cryptographic algorithms based on elliptic curves: signature = algorithm, key exchange protocol, and public key encryption algorithm. Thes= e algorithms and recommended parameters are published by Chinese Commercial= Cryptography Administration Office for the use of electronic authenticatio= n service system. In [25], the class of signature algorithms is analyzed, w= hich includes the SM2 signature algorithm. More exactly, the generalized ke= y substitution attacks are investigated where the base element is considere= d as a part of the public key and can be substituted. It is proven that the= Chinese standard SM2 signature scheme is existentially unforgeable against= adaptively chosen-message attacks in the generic group model if the underl= ying hash function is uniform and collision-resistant and the underlying co= nversion function is almost-invertible, and the SM2 digital signature schem= e is secure against the generalized key substitution attacks if the underly= ing hash functions are modeled as non-programmable random oracles (NPROs).= =C2=A0

In [11], the partially known nonces attack = against SM2 are discussed. It is shown by the experiments that the private = key can be recovered, given 100 signatures with 3 bits of nonces known for = 256-bit SM2. Also a byte-fault attack on SM2 is developed when a byte of ra= ndom fault is injected on the secret key during the signing process. In [3]= , a practical lattice-based fault attack against SM2 signature algorithm in= a smart card is presented. Authors of [3] successfully utilized the laser = fault attack to skip the instructions of nonces being written into RAM, so = that the nonces in signatures share partial same bits from each other. Next= , they build the model of lattice attack and recover the private key. The e= xperimental results show that only 3 faulty signatures are needed to mount = lattice attack successfully in about 32 =C2=B5s. Moreover, they proposed a = new countermeasure for SM2 signature algorithm to resist lattice-based faul= t attack by destroying the condition of lattice attack rather than thwartin= g fault attack. It is proven that the countermeasure can guarantee the abil= ity to resist lattice attack, even if some information of the nonces is lea= ked. As noted in [7], the SM2 signature algorithm as well as the Russian st= andard GOST R 34.10-2012, and the ECDSA algorithm fits into the general sch= eme of the ElGamal signature algorithm, proposed back in 1997 in the classi= c monograph [14]. In [20], apparently concerning the earlier version of the= SM2 key exchange protocol, it is shown that this version is vulnerable to = realistic attacks in the Canetti-Krawczyk model, in which an adversary only= knows the state of the session. Simple modifications of this version are p= roposed, which eliminate this problem. In [21], the security of the SM2 key= exchange protocol in the widespread Bellare-Rogaway model is proved under = the assumption that the discrete logarithm problem for elliptic curves is h= ard. Also in this paper a simplified but more effective version of this pro= tocol is presented together with a similar security proof.

Based on the published results, I see no reasons to object against= using the SM2 digital signature scheme and the SM2 public key encryption f= or secure elliptic curves.=C2=A0
Nevertheless, I'd prefer to = conduct an additional review after a section about design rationale and a s= ummary of cryptanalytic results is added to the SM2 I-D.


SM3

The SM3 hash func= tion [17] is constructed on the cryptographic principles embedded in the MD= 4 hash function family, or more precisely, in the SHA-2 hash functions. In = the 6 years since publication of the SM3 hash function, some attacks on tru= ncated versions have been built. These are attacks of finding preimage, col= lisions, pseudo-collisions and free-start collisions, as well as attacks of= constructing boomerang-distinguishers. In [19], the preimage attacks trans= formed into attacks of constructing pseudo-collisions for versions of the S= M3 hash function, truncated to 29, 30, 31 and 32 steps, with complexities 2= ^122 , 2^125.1 , 2^122 and 2^125.1 , respectively. In [13], real collisions= were found with practical complexity for the 20 (of 64) steps SM3 hash fun= ction, and real free-start collisions were found with practical complexity = for the 24 steps SM3 hash function.

Based on the p= ublished results, I see no reasons to object against=C2=A0using the SM3 has= h function.


SM4
SMS4 [5], issued in 2006 by Chinese government, serves the WAP= I (WLAN Authentication and Privacy Infrastructure) as the underling block c= ipher for the security of wireless LANs. In 2012, SMS4 was announced as the= Chinese commercial block cipher standard, renamed to SM4. SM4 is a 32-roun= d block cipher with the same block length and key equal to 128 bit.=C2=A0
Unlike other open Chinese cryptographic standards (SM2 and SM3), t= he block cipher SM4 attracted more attention of the international cryptogra= phic community. So in [9] the integral attack is proposed for the 13-round = version of the SM4 cipher. In [8], the rectangle and boomerang attacks on 1= 8-round SM4 and the linear and differential attacks on 22-round SM4 have be= en presented. Using the technique of multiple linear approximations, in [6]= an attack was developed for the 22- and 23-round version of SM4. In [24], = the results of [6] for the 22-round version were improved. The best differe= ntial attacks to date for the 23-round version of SM4 were obtained in [18]= . For the same version of SM4, the multidimensional linear attack was propo= sed in [4]. The best linear attacks to date for the 23- and 24-round versio= n of SM4 have been developed in [10] and [12], respectively. In [23] it is = shown that the SM4 cipher is resistant to differential cryptanalysis in the= related key model for versions starting at 19 rounds. It is also worth men= tioning here the paper [22], in which lower bounds are obtained for the num= ber of =E2=80=9C linearly active=E2=80=9D S-boxes for SM4-like block cipher= s.

Based on the published results, I see no reason= s to object against=C2=A0using the SM4 cipher.

The elliptic curve parameters

T= here is no sufficient material on a provided elliptic curve, so some analys= is is made in the current review.

The provided sho= rt Weierstrass equation coefficients correctly define the elliptic curve (i= t has non-null discriminant). The j-invariant of the curve is not equal to = 0 or 1728. The order of the provided curve points group m equals 1157920892= 10356248756420345214020892766061623724957744567843809356293439045923 and is= prime.=C2=A0 The provided base point belongs to the curve and has order q = equal to m. Therefore cofactor h of the specified subgroup equals to 1. The= order of the subgroup is big enough (about 2^256) to make attacks base on = Pollard=E2=80=99s rho method ineffective. Since q !=3D p effective additive= transfers are not possible. MOV-attacks are ineffective since the curve ha= s high embedding degree (equals q-1). The absolute value of complex multipl= ication discriminant is about 2^257 and fully satisfies requirements of the= SafeCurves ([27]). The attack by Petit, Kosters and Messeng ([28]) which e= mploys Semaev summation polynomials is also ineffective since all sets of s= mall factor of p-1 (namely 2 and 43) meet criterion, provided in [29].

It can shown that group of points of the quadratic twi= st of the curve has order m=E2=80=99 equal to 11579208921035624875642034521= 4020892766439084258890638340998578510285930938077. The largest subgroup has= the order q=E2=80=99 =3D 336942259148358014326618776206081604165520103 wit= h cofactor h=E2=80=99=3D 343655585093504666447005752284059. Since q=E2=80= =99 is about 2^147 Pollard=E2=80=99s rho algorithm is more effective here t= han on the original curve. Since q=E2=80=99 is not equal to p and ord(p) in= Z*(q=E2=80=99) equals (q'-1)/11 there exist neither effective additive= transfers nor effective multiplicative transfers. It is important to note,= however, the provided curve cannot be rewritten in Montgomery form.
<= div>
The provided curve satisfies all modern security require= ments. However, some clarifications on the selection of values of b, x(P), = y(P) have to be provided: some kind of NUMS-type arguments are desirable.


General comments for the I= -D

There are a lot of words about OSCCA/SCA-co= mpliance. I am not sure that this is important for an IETF document - maybe= it would be better not to mention these regulatory issues.

<= /div>
A lot of references is given to OSCCA/SCA documents and Chinese s= tandards - maybe it will be better to use references to IETF I-Ds/RFCs for = SM2, SM3, SM4.

Throughout the text there are "= ;MUST" codewords about "a compliant OpenPGP implementation" = - it seems to be too strict to use MUST codeword when discussing optional a= lgorithms/parameters to use with some protocols/implementations.
=
There are some problems with links to oscca.gov.cn - maybe the site has been down recent days, but = I couldn't open these links. Do we need them provided that we have RFCs= and other links?


Particular com= ments

Section 1:=C2=A0
SM4 is called= "kM4".=C2=A0
About SM3 (a hash) instead of "elect= ronic authentication" and "data validation" it would better = say something like "integrity".=C2=A0
In "support = the SM4 symmetric encryption algorithm for data protection purposes" I= 'd prefer to say about "confidentiality", not "protectio= n" (especially since SM4 does not define a MAC mode).=C2=A0
<= div>"SM3 with other digital signing algorithms, such as RSA, ECDSA and= SM2": 1) "signing"->"signature"; 2) EC-RDSA fr= om=C2=A0 ISO/IEC 14888-3 is also appropriate here.

Section 3, first sentence: "they" seems to be omitted after &quo= t;and".

Section 4: "elliptical" -&g= t; "elliptic".

Section 4.1: do we need t= o say about this optional ZA field from SM2 standard? And personally I don&= #39;t like this double hashing (H(ZA|| H(msg))).
I am not sure th= at section 4.2 is needed: it is said that this algorithm is not related to = OpenPGP and also has security issues - I'd recommend to remove this par= t from the document at all.

Section 4.4.2: I&#= 39;d recommend to say that the curve is defined over a certain finite field= in short Weierstrass form.

Section 4.4.3: I'd= prefer to see also words about the cofactor of the group and that all numb= ers are in big-endian form.

Section 4.5.1: It shou= ld be stated explicitly that all numbers are in little-endian or big-endian= .

Section 5.
A misprint: "cryptogrp= ahic".
Instead of "digital signatures and their verific= ation" it would better say "digital signature generation and veri= fication".=C2=A0
When we say about MACing or PRNGs, spec= ific constructions should be mentioned, in my opinion. Otherwise, I'd p= refer not to have these general words about SM3 applications (they are the = same as for any hash function).
There is a parameter "m&= quot;, which seems not to be defined at that moment.=C2=A0
Section 6: it seems to be useful to define whether the S-box i= s fixed or variable.
The note is missing that SM4 is an unbalance= d Feistel network =E2=80=93 this seems more important than the note that it= is designed for encryption.

In section 7.3 there = is a mistake in the second paragraph: this is not a "symmetric encrypt= ion algorithm".

In section 9.3 "whole nu= mber" -> "integer". "Ha!" doesn't look a go= od variable name. Since n is an integer, ceil is not needed.

=
In section 14 the second paragraph doesn't look accurate eno= ugh. For instance, "ECDLP" seems more appropriate than "ECLP= ". Regarding the digital signature, a reference to the hash is also ne= eded here. Regarding the key exchange scheme - not only a reference to disc= rete logarithm problem, but also to CDH/DDH is desirable.
"r= andomly generated without fixed correlation" - the sentence looks a li= ttle strange because of "fixed".

Section= 15: Maybe it would be better to say "has made" after the assignm= ents are made.


References

[1] Bai D., Yu H., Wang G., Wang X.: Improved Boomer= ang Attacks on SM3. In: Boyd C.,Simpson L. (eds) Information Security and P= rivacy. ACISP 2013. Lecture Notes in Computer Science, vol 7959, pp. 251=E2= =80=93266. Springer, Berlin, Heidelberg (2013).
[2] Bai D., Yu H.= , Wang G., Wang X.: Improved boomerang attacks on round-reduced SM3 and key= ed permutation of BLAKE-256. IET Information Security 9(3): pp. 167=E2=80= =93178 (2015).
[3] Cao W., Feng J., Zhu S., Chen H., Wu W., Han X= ., Zheng X.: Practical Lattice-Based Fault Attack and Countermeasure on SM2= Signature Algorithm. In: Qing S., Okamoto E., Kim K., Liu D. (eds) Informa= tion and Communications Security. ICICS 2015. Lecture Notes in Computer Sci= ence, vol 9543, pp. 62=E2=80=9370. Springer, Cham (2015).
[4] Cho= J., Nyberg K.: Improved Linear Cryptanalysis of SMS4 Block Cipher. Symmetr= ic Key Encryption Workshop, pp. 1=E2=80=9314. (2011). http://skew2011.mat.dtu.dk/proceedings/Improved%20Lin= ear%20Cryptanalysis%20of%20SMS4%20Block%20Cipher.pdf
[5] Diff= ie W., Ledin G.: SMS4 Encryption Algorithm for Wireless Networks. Cryptolog= y ePrint Archive 2008/329. = http://eprint.iacr.org/2008/329.pdf
[6] Etrog J., Robshaw M. = J. B.: The Cryptanalysis of Reduced-Round SMS4. In: Avanzi R. M., Keliher L= ., Sica F. (eds) Selected Areas in Cryptography. SAC 2008. Lecture Notes in= Computer Science, vol 5381, pp. 51=E2=80=9365. Springer, Berlin, Heidelber= g (2009).
[7] Fersch M., Kiltz E., Poettering B.: On the One-Per-= Message Unforgeability of (EC)DSA and Its Variants. In: Kalai Y., Reyzin L.= (eds) Theory of Cryptography. TCC 2017. Lecture Notes in Computer Science,= vol 10678, pp. 519=E2=80=93534. Springer, Cham (2017).
[8] Kim T= ., Kim J., Hong S., Sung J.: Linear and Differential Cryptanalysis of Reduc= ed SMS4 Block Cipher. IACR Cryptology ePrintArchive 2008/281, (2008). https://eprint.iacr.org/2008/2= 811.pdf
[9] Liu F., Ji W., Hu L., Ding J., Lv S., Pyshkin A.,= Weinmann R.-P.: Analysis of the SMS4 Block Cipher. In: Pieprzyk J., Ghodos= i H., Dawson E. (eds) Information Security and Privacy. ACISP 2007. Lecture= Notes in Computer Science, vol 4586, pp. 158=E2=80=93170. Springer, Berlin= , Heidelberg (2007).
[10] Liu M.-J., Chen J.-Z.: Improved Linear = Attacks on the Chinese Block Cipher Standard. J. Comput. Sci. Technol. (201= 4) 29(6): pp. 1123=E2=80=931133. (2014).
[11] Liu M., Chen J., Li= H.: Partially Known Nonces and Fault Injection Attacks on SM2 Signature Al= gorithm. In: Lin D., Xu S., Yung M. (eds) Information Security and Cryptolo= gy. Inscrypt 2013. Lecture Notes in Computer Science, vol 8567, pp. 343=E2= =80=93358. Springer, Cham (2014).
[12] Liu Y., Liang H., Wang W.,= Wang M.: New Linear Cryptanalysis of Chinese Commercial Block Cipher Stand= ard SM4. Security and Communication Networks. Volume 2017, Article ID 14615= 20, 10 pages (2017). http://downloads.hindawi.com/journals/scn/2017/1461520.pdf=
[13] Mendel F., Nad T., Schl=C2=A8 affer M.: Finding Collisi= ons for Round-Reduced SM3. In: Dawson E. (eds) Topics in Cryptology =E2=80= =94 CT-RSA 2013. CT-RSA 2013. Lecture Notes in Computer Science, vol 7779, = pp. 174-188. Springer, Berlin, Heidelberg (2013).
[14] Menezes A.= J., van Oorschot P. C., Vanstone S. A.: Handbook of Applied Cryptography. = The CRC Press series on discrete mathematics and its applications, CRC Pres= s, 2000 N.W. Corporate Blvd., Boca Raton, FL 33431-9868, USA (1997).
<= div>[15] Shen Y., Bai D., Yu H.: Improved cryptanalysis of step-reduced SM3= . Science China Information Sciences, 61 (2017): pp. 1=E2=80=932.=C2=A0
[16] Shen S., Lee X.: SM2 Digital Signature Algorithm. Internet Engi= neering Task Force, Internet-Draft draft-shen-sm2-ecdsa-02, February 14, 20= 14. https:/= /tools.ietf.org/html/draft-shen-sm2-ecdsa-02
[17] Shen S., Le= e X.: SM3 Hash function. Internet Engineering Task Force, Internet-Draft dr= aft-shen-sm3-hash-01, February 14, 2014. https://tools.ietf.org/html/draft-shen-sm3-has= h-01
[18] Su B.-Z., Wu W.-L., Zhang W.-T.: Security of the SM= S4 Block Cipher Against Differential Cryptanalysis. J. Comput. Sci. Technol= . (2011) 26(1): pp. 130=E2=80=93138. (2011).
[19] Wang G., Shen Y= .: Preimage and pseudo-collision attacks on step-reduced SM3 hash function.= Information Processing Letters, 2013, 113, pp. 301=E2=80=93306, (2013).
[20] Xu J., Feng D.: Comments on the SM2 Key Exchange Protocol. In:= Lin D., Tsudik G., Wang X. (eds) Cryptology and Network Security. CANS 201= 1. Lecture Notes in Computer Science, vol 7092, pp. 160=E2=80=93171. Spring= er, Berlin, Heidelberg (2011).
[21] Yang A., Nam J, Kim M., Choo = K.-K. R.: Provably-Secure (Chinese Government) SM2 and Simplified SM2 Key E= xchange Protocols. The Scientific World Journal, Volume 2014, Article ID 82= 5984 (2014). https://www.hindawi.com/journals/tswj/2014/825984/
[22] Zhan= g B., Jin C.: Practical security against linear cryptanalysis for SMS4-like= ciphers with SP round function. Sci. China Inf. Sci. (2012) 55(9): pp. 216= 1=E2=80=932170. (2012).
[23] Zhang J., Wu W., Zheng Y.: Security = of SM4 Against (Related-Key) Differential Cryptanalysis. In: Bao F., Chen L= ., Deng R., Wang G. (eds) Information Security Practice and Experience. ISP= EC 2016. Lecture Notes in Computer Science, vol 10060, pp. 65=E2=80=9378. S= pringer, Cham (2016).
[24] Zhang W., Wu W., Feng D., Su B.: Some = New Observations on the SMS4 Block Cipher in the Chinese WAPI Standard. In:= Bao F., Li H., Wang G. (eds) Information Security Practice and Experience.= ISPEC 2009. Lecture Notes in Computer Science, vol 5451, pp. 324=E2=80=933= 35. Springer, Berlin, Heidelberg (2009).
[25] Zhang Z., Yang K., = Zhang J., Chen C.: Security of the SM2 Signature Scheme Against Generalized= Key Substitution Attacks. In: Chen L., Matsuo S. (eds) Security Standardis= ation Research. Lecture Notes in Computer Science, vol 9497, pp. 140=E2=80= =93153. Springer, Cham (2015).
[26] Zou J., Wu W., Wu S., Su B., = Dong L.: Preimage Attacks on Step-Reduced SM3 Hash Function. In: Kim H. (ed= s) Information Security and Cryptology =E2=80=94 ICISC 2011. ICISC 2011. Le= cture Notes in Computer Science, vol 7259, pp. 375-390. Springer, Berlin, H= eidelberg (2012).
[28] Petit C., = Kosters M., Messeng A. (2016) Algebraic Approaches for the Elliptic Curve D= iscrete Logarithm Problem over Prime Fields. In: Cheng CM., Chung KM., Pers= iano G., Yang BY. (eds) Public-Key Cryptography =E2=80=93 PKC 2016. PKC 201= 6. Lecture Notes in Computer Science, vol 9615. Springer, Berlin, Heidelber= g
[29] E. Alekseev, V. Nikolaev, S. Smyshlyaev. On the security p= roperties of Russian standardized elliptic curves. CTCrypt=E2=80=9917 Prepr= oceedings.
--001a114a7166441b6c0560c62179-- From nobody Fri Dec 29 11:31:25 2017 Return-Path: X-Original-To: cfrg@ietf.org Delivered-To: cfrg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6C71200FC; Fri, 29 Dec 2017 11:31:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cfrg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151457587878.7038.16769485425252567248@ietfa.amsl.com> Date: Fri, 29 Dec 2017 11:31:18 -0800 Archived-At: Subject: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-09.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 19:31:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Crypto Forum RG of the IRTF. Title : Re-keying Mechanisms for Symmetric Keys Author : Stanislav Smyshlyaev Filename : draft-irtf-cfrg-re-keying-09.txt Pages : 53 Date : 2017-12-29 Abstract: A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called "key lifetime". This specification describes a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms based on hash functions and on block ciphers, that can be used with modes of operations such as CTR, GCM, CBC, CFB and OMAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-09 https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/