From nobody Sat Jul 1 11:34:46 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D110F1274D0 for ; Sat, 1 Jul 2017 11:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.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 BMVzglzdavgB for ; Sat, 1 Jul 2017 11:34:43 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 AF7C1120454 for ; Sat, 1 Jul 2017 11:34:43 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id v197so20440866ybv.3 for ; Sat, 01 Jul 2017 11:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zH06pwSP8/OO4g9/4clKtWmd6u8rEvdd1msK4aY9oUU=; b=AyhZMHtY6ooKC/6mAGwtsLBjfkaBkFCe6SnEL7amN8+g7ZjAxfqLDT4oCJkY/SjHNk S7B4LBHDCCfin7epMf6p6/rYiqIqGC3iIpqMip/Ul+B8qROnDq2Y1/3HSh7JRyv8Qlue hiyPO4rFauylv7t9TIDzlQevwLS7TsyusvpSdk2InnygCLo+fyB6GQYStxBBfQF+PCDD VN9JisXYl6vsCFESIXALnpcs0OQp5j6f4AwyVTIptHlQYzxudgpVNR5N3K3+t01i2UoU FTcVsibEyHO9FA9ujxJBLO0cnf7JsRsEeALZu29V1gGh5yCKGjfzim2/L3E5IIvAl8iS HGzA== 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=zH06pwSP8/OO4g9/4clKtWmd6u8rEvdd1msK4aY9oUU=; b=A+eDhm8tM8QlNtbGZxGtQhwN536STYZ65qrLJOXLw7sS1LLy7LaPlmeG8NSLI2nSVi ahbzWjw9SyBdXNgnOF2gv0/oTkoohy0jR/ySVKfBWlMkP8axYAJnkkd9B6XGbX/mrdjI U54RNYCeD9yUQ/HvKcVajxDpgj7e/dqvHxJFXpoBY+JGvEds3u/nFbqdbUchAt5GQgI5 4sxk5urp/Drozs+oJjSbaRRWSASJ6Qm+VSMK/NSPDqx55rUUXmR3p8vEPWqDZbCoGH9G fC2AX1rF0xv2Hjeob4L8h70qzokWUz0oQgb3y6/R2QA4RTbmWnVxt8Z+fOo5xNY1Hc08 lj/g== X-Gm-Message-State: AKS2vOypcbYTJmMgBpfWy2nTvJ+SkwojlKcoBTiggT0AejJNnhqFw13Z mm0nhDabo0IYKwDXbIpTFA6ZP9kcj02B X-Received: by 10.37.183.6 with SMTP id t6mr20971559ybj.221.1498934082774; Sat, 01 Jul 2017 11:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.179.2 with HTTP; Sat, 1 Jul 2017 11:34:42 -0700 (PDT) In-Reply-To: References: From: Bjoern Tackmann Date: Sat, 1 Jul 2017 20:34:42 +0200 Message-ID: To: "Paterson, Kenny" Cc: "crypto-panel@irtf.org" , "alexey.melnikov@isode.com" Content-Type: multipart/alternative; boundary="089e08221adc8bfd6f055345c9b6" Archived-At: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 18:34:46 -0000 --089e08221adc8bfd6f055345c9b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please find my review below. It's a nice piece of work and overall in quite good shape. After looking at the other reviews: I do not quite understand Tibor's comment on the bit-length vs. byte-length, given that the draft states that the scheme takes "arbitrary-length plaintext & additional data byte-strings" -- and for me the term "byte-strings" means that the byte-length of the strings is an integer. However, since this lead to confusion, it may make sense to state this more explicitly. Best, Bj=C3=B6rn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Summary: Almost ready Major issues: none Minor issues: I found the description of the encryption method comprehensible but a bit too informal. Maybe a pseudo-code description may be easier to understand? In that description, I stumbled particularly over the =E2=80=9C_length bloc= k_=E2=80=9D - why the underscores? Also, I think it would make sense to clarify that the 32-bit counter value will overflow (and that this is intended). One aspect that read a bit arbitrary to me was the domain separation for AES by setting the first bit of the last byte to 1/0, and in particular that seemed a bit wasteful since it is evaluated only once with the bit set to 0. Wouldn't it be simpler (and possibly even with better security, but at the cost of limiting the length to 2^32 - 1 blocks) to not fiddle with the bits but just use the first counter-block to compute the tag? Note that this would certainly require re-doing some part of the security analysis, and the gains seem moderate, so I=E2=80=99m fine with this comment being di= scarded. (Just wanted to make sure it is discarded consciously.) On Thu, Jun 15, 2017 at 4:38 PM, Paterson, Kenny wrote: > Dear CFRG panel members, > > Any volunteers from the panel to perform a review of: > > https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-04 > > > I'd like to move it towards last call, and having a couple of reviews fro= m > you fine people would help give us the confidence to do so. > > The draft might be best read in conjunction with the technical paper: > > https://eprint.iacr.org/2017/168 > > > though of course it needs to stand alone as an RFC. > > Let me know. > > Cheers, > > Kenny > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --089e08221adc8bfd6f055345c9b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please find my review below. It's a nice piece of work= and overall in quite good shape.

After looking at the o= ther reviews: I do not quite understand Tibor's comment on the bit-leng= th vs. byte-length, given that the draft states that the scheme takes "= ;arbitrary-length plaintext & additi= onal data byte-strings" -- and for me the term "byte-strings"= ; means that the byte-length of the strings is an integer. However,=C2=A0si= nce this lead to confusion, it may make sense to state this more explicitly= .

Best,
Bj=C3=B6rn


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Summa= ry: Almost ready

Major issues: none

=
Minor issues:

I found the description o= f the encryption method comprehensible but a bit too informal. Maybe a pseu= do-code description may be easier to understand?

I= n that description, I stumbled particularly over the =E2=80=9C_length block= _=E2=80=9D - why the underscores? Also, I think it would make sense to clar= ify that the 32-bit counter value will overflow (and that this is intended)= .

One aspect that read a bit arbitrary to me was t= he domain separation for AES by setting the first bit of the last byte to 1= /0, and in particular that seemed a bit wasteful since it is evaluated only= once with the bit set to 0. Wouldn't it be simpler (and possibly even = with better security, but at the cost of limiting the length to 2^32 - 1 bl= ocks) to not fiddle with the bits but just use the first counter-block to c= ompute the tag? Note that this would certainly require re-doing some part o= f the security analysis, and the gains seem moderate, so I=E2=80=99m fine w= ith this comment being discarded. (Just wanted to make sure it is discarded= consciously.)

<= br>
On Thu, Jun 15, 2017 at 4:38 PM, Paterson, Ke= nny <Kenny.Paterson@rhul.ac.uk> wrote:
Dear CFRG panel members,

Any volunteers from the panel to perform a review of:

https://tools.ietf.org/html/draft-irtf-cfr= g-gcmsiv-04


I'd like to move it towards last call, and having a couple of reviews f= rom
you fine people would help give us the confidence to do so.

The draft might be best read in conjunction with the technical paper:

https://eprint.iacr.org/2017/168


though of course it needs to stand alone as an RFC.

Let me know.

Cheers,

Kenny

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/crypto-= panel

--089e08221adc8bfd6f055345c9b6-- From nobody Sun Jul 2 05:38:02 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F84E12EA74 for ; Sun, 2 Jul 2017 05:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, 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=uni-paderborn.de 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 fKviMbQvCXmK for ; Sun, 2 Jul 2017 05:37:58 -0700 (PDT) Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (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 10BB912EB4B for ; Sun, 2 Jul 2017 05:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=uni-paderborn.de; s=20170601; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:To:References:Subject; bh=EHhvjCKmcyF3Q/N65csIZLaeribW/bvPjuoYdZfhMmQ=; b=PONz5JFlSqoe+9QSjZ7Vjuzghek78tUdJ/xKPiaP83EUSp3N4rZyjlw77absbWgnKcYGaJhlhv6DZtBiqM3ucX48vvfPCajjmZsybCZiD60/2PBON48QmmiDr8nhpyQKgFvRyJJdqzAsxmXXGpxT9g5dE6pstm4NloIHw1l8ATE=; References: To: crypto-panel@irtf.org From: Tibor Jager Message-ID: Date: Sun, 2 Jul 2017 14:37:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IMT-Spam-Score: 0.0 () X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.7.2.123016, AntiVirus-Engine: 5.38.0, AntiVirus-Data: 2017.6.19.5380004 X-IMT-Authenticated-Sender: uid=tjager,ou=People,o=upb,c=de Archived-At: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 12:38:00 -0000 Hi all, On 01/07/2017 20:34, Bjoern Tackmann wrote: > Please find my review below. It's a nice piece of work and overall in > quite good shape. > > After looking at the other reviews: I do not quite understand Tibor's > comment on the bit-length vs. byte-length, given that the draft states > that the scheme takes "arbitrary-length plaintext & additional data > byte-strings" -- and for me the term "byte-strings" means that the > byte-length of the strings is an integer. Indeed, this is one of the sections that suggests that it is implicitly assumed that "valid" plaintexts and AD have always a byte-length which is an integer. What I found *potentially* confusing is: - Then it would also be somewhat more intuitive/consistent to include the byte-length of plaintext and AD in the length block. The current draft includes the bit-length. (This is of course technically fine and essentially just a different notation, but *could* be confusing.) - Also the example in Section 8 mentions the bit-length. - It would also make sense to let the encryption algorithm abort, if the lengths of plaintexts and AD are not a multiple of 8 bits (and one could ignore this check in applications where this is guaranteed by the environment - but this is of course something that only the application developer can decide). I do not see this as a big issue either, I just wanted to suggest to mention this assumption about the plaintext length more clearly - even if it seems quite standard to assume plaintexts/ADs are always given as sequences of bytes, and will most likely hold for most application anyway. Cheers, Tibor From nobody Tue Jul 4 05:27:57 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2771315E9 for ; Tue, 4 Jul 2017 05:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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=ieee-org.20150623.gappssmtp.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 58NKdikJ_rSr for ; Tue, 4 Jul 2017 05:27:54 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 442651315E3 for ; Tue, 4 Jul 2017 05:27:54 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v193so16037123ywg.2 for ; Tue, 04 Jul 2017 05:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BDpNFNBTlRrm54o+p8982a21ZYFdjSgS86HjjE7J1Hk=; b=Ep/CzCKtZgQ31DMl878NPktnuaM4kscSwtKMzmk1URH2HM1Lh7jM0W37lmIMh90XGa biuPG09KBeGFoStrQDrR/QqbnJIOjQGhZTORB4lAmIEgEQp1/beMRNJodI5f34Gfh+IQ Ot+qSmUB915Fb0QkU+Gpe7kn/WuXlsqsekuEoK8N5GEgj6Rk94EWSTqHrHS+q3NcUmrH 4ITm/FK4/UsgOSnHDBKf6tt+ZLiCLERY6+qalgWWh3b0DknuvsHzgOvgyVS+PG/9Z5oZ GDXypxcShY3AnHJCcMF2iBYAAE8Ki033B9UlZs0tSYM1qsFQs0/QrgL31N96A9WsFK1M heuA== 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=BDpNFNBTlRrm54o+p8982a21ZYFdjSgS86HjjE7J1Hk=; b=tfkFTY6IvOKmRbjxB86pNXo5kEVgvVskwIgfBNIzJqsqj/9T+XhYRvvidYTJXOZrxs F45wg/ERl1vx3G3PmiQcglBSau7jIdkhNtGYiECjGjITzgN3dpGtedO1khykba+fpyyU JNb5m1X8s/LDU4xAiq0jNxbsi8mApheNvJwKgHkD2Be1JJmaT47Q4KtvxgNYncvIur+d 4W2vKP6IwLgmpN7Yfgwa5G/25S9Quvou5E4kg829+FpuAZF8dqzzRfmmu7APe6GMXet3 m46bz4GaLCZpURpb4L3TeDk4ZeexehNU/IzyxoQ8Yomi24qLwJMUsuR5jZ94S13mvLt4 nJgA== X-Gm-Message-State: AKS2vOxb+TYXKzTg+WUQRS3sfK+XSUCU/DpcMFT2qLXAmYzbqrQZuv+Z +Q52feOEc6aHA5tER92z81RZtVucltVt X-Received: by 10.129.73.78 with SMTP id w75mr30097161ywa.244.1499171273507; Tue, 04 Jul 2017 05:27:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.179.2 with HTTP; Tue, 4 Jul 2017 05:27:52 -0700 (PDT) In-Reply-To: References: From: Bjoern Tackmann Date: Tue, 4 Jul 2017 14:27:52 +0200 Message-ID: To: Tibor Jager Cc: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="001a114da484374a7e05537d03c1" Archived-At: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 12:27:56 -0000 --001a114da484374a7e05537d03c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager wrote: > > On 01/07/2017 20:34, Bjoern Tackmann wrote: > > Please find my review below. It's a nice piece of work and overall in > > quite good shape. > > > > After looking at the other reviews: I do not quite understand Tibor's > > comment on the bit-length vs. byte-length, given that the draft states > > that the scheme takes "arbitrary-length plaintext & additional data > > byte-strings" -- and for me the term "byte-strings" means that the > > byte-length of the strings is an integer. > > Indeed, this is one of the sections that suggests that it is implicitly > assumed that "valid" plaintexts and AD have always a byte-length which > is an integer. > > What I found *potentially* confusing is: > > - Then it would also be somewhat more intuitive/consistent to include > the byte-length of plaintext and AD in the length block. The current > draft includes the bit-length. (This is of course technically fine and > essentially just a different notation, but *could* be confusing.) > > - Also the example in Section 8 mentions the bit-length. > I fully agree that it would be less ambiguous to do these computations in terms of byte-length. I do not see any advantage of having the scheme operate internally in terms of bit-length, when only byte-length strings are allowed. > - It would also make sense to let the encryption algorithm abort, if the > lengths of plaintexts and AD are not a multiple of 8 bits (and one could > ignore this check in applications where this is guaranteed by the > environment - but this is of course something that only the application > developer can decide). > Agreed. Best, Bj=C3=B6rn --001a114da484374a7e05537d03c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager &l= t;tibor.jager@upb.d= e> wrote:
=
On 01/07/2017 20:34, Bjoern Tackmann wrote:
> Please find my review below. It's a nice piece of work and overall= in
> quite good shape.
>
> After looking at the other reviews: I do not quite understand Tibor= 9;s
> comment on the bit-length vs. byte-length, given that the draft states=
> that the scheme takes "arbitrary-length plaintext & additiona= l data
> byte-strings" -- and for me the term "byte-strings" mea= ns that the
> byte-length of the strings is an integer.

Indeed, this is one of the sections that suggests that it is implici= tly
assumed that "valid" plaintexts and AD have always a byte-length = which
is an integer.

What I found *potentially* confusing is:

- Then it would also be somewhat more intuitive/consistent to include
the byte-length of plaintext and AD in the length block. The current
draft includes the bit-length. (This is of course technically fine and
essentially just a different notation, but *could* be confusing.)

- Also the example in Section 8 mentions the bit-length.

I fully agree that it would be less ambiguous to do these= computations in terms of byte-length. I do not see any advantage of having= the scheme operate internally in terms of bit-length, when only byte-lengt= h strings are allowed.

=C2=A0
- It would also make sense to let the encryption algorithm abort, if the lengths of plaintexts and AD are not a multiple of 8 bits (and one could ignore this check in applications where this is guaranteed by the
environment - but this is of course something that only the application
developer can decide).

Agreed.


Best,
Bj=C3=B6rn=C2=A0


--001a114da484374a7e05537d03c1-- From nobody Tue Jul 4 06:53:56 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B5132093 for ; Tue, 4 Jul 2017 06:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] 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 N0lM26Zx73bv for ; Tue, 4 Jul 2017 06:53:51 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0070.outbound.protection.outlook.com [104.47.1.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91071320B4 for ; Tue, 4 Jul 2017 06:53:50 -0700 (PDT) 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=OcxRCbgQoLvc+aaKIEs+7Oz/+H7Gtt6wBo90t0yPTUo=; b=mf4SpPuMh39ir5VPju8BY8F0ukQkmtjUESCfX5th42hA8OcyN5UBnQY7nV10P0wl3N5ZHuo5JA7V75UbhaK2gm6gDgcOyCrPgaf/ZGPparQvFR7Htb2V7d4gMlXPC8CsbutUHOsvr7ULpt0/How5tXP+aVxN2BLb2bYcGHLqoos= 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_128_CBC_SHA256_P256) id 15.1.1220.11; Tue, 4 Jul 2017 13:53:48 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Tue, 4 Jul 2017 13:53:47 +0000 From: "Paterson, Kenny" To: Bjoern Tackmann , Tibor Jager CC: "crypto-panel@irtf.org" Thread-Topic: [Crypto-panel] Review of AES-GCM-SIV Thread-Index: AQHS5eUMXPqksT4BkEOlrKXEsk18RKI/ZZ4AgAEupACAAyHcAIAAKM+A Date: Tue, 4 Jul 2017 13:53:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: ieee.org; dkim=none (message not signed) header.d=none;ieee.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:aDBf1V1E79hwh/ZRRGiXeBvdkaesIylbcUGj3v9/mzxo/wsAOL3R8n5fquQhcZ2ZXgZkO9sc0s5mbmYjc5NdnIfdOwmWTKRP/Ay/+TUUMTzpM3wGTMia4+VmzxdL64pU7fDXEoxcpF7GfFEluElQzNIGdk5GQGVryOc1VNQPtoztL6+UkGTJAnZYJIp3f9DIaa0BpxdMa/KoDWD01DfvUavFw2BB9+e3hn72NvFql4qE4UqQmXBmxw9QmKDhuJAQ7+MnyloSZrFa3j4nIG6n+ngFwMwmA9CvN5xgSXQQqYtLBQoqqQp4QzdAqbjIRUDdEQOC3eS3V+br0Cu/FS3Z0ki/XlrPCtzYRsuLwL2o9CSV6R4QNHDnMIT73kI3tjeoW+pcdK3PRy4BSwpII8qCiWDHUg1VdpB9g8WRFf4MvFQK4kngdCxrJR1Km3ACaJGUTpVqBnrkOkIlZlHnZfBLmqX/1NnzYycTGvabTWK+Bk4mrvDSkDSN8KaNcTOX/0wYRphKg0qCwJmTOWSeHjAfhPi7FvAf2yJTRsSyz2l0ic1CVpAfzait7VmysLVpMvrOV2WGQV68vSkeJXk/ov22NGliqX6A28jmQmOnlafAMPXlIBAKR2gMOjafBkho+byQCtXVePARv0ImFDiwOXzfZy1LP/uED4YyWnVrJhfJE/GXGlKYucM5GejoIS5a0RoxAFT9lZgfFkNJRVbR12VLfuVz1gnDe5u1J7GvSDsOzaXmVZK8Iah1diffFIP5Hr+amxJvR86uJW/meEIaMl2TgNDytRy55ztNIxKM74aYsww= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(39850400002)(377454003)(24454002)(53754006)(6246003)(99286003)(93886004)(230783001)(50986999)(66066001)(54356999)(42882006)(2950100002)(76176999)(36756003)(7736002)(38730400002)(305945005)(6512007)(81166006)(8936002)(2906002)(8676002)(74482002)(53936002)(4326008)(3660700001)(3280700002)(6116002)(2900100001)(3846002)(102836003)(6436002)(25786009)(14454004)(189998001)(478600001)(53546010)(72206003)(229853002)(6486002)(6506006)(5660300001)(86362001)(5250100002)(4001350100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 44e32f9b-b036-4e66-8b28-08d4c2e41827 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(48057245064654)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0358535363 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 13:53:47.8409 (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: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 13:53:54 -0000 VGhhbmtzIGV2ZXJ5b25lIGZvciB0aGlzIGhlbHBmdWwgZGlzY3Vzc2lvbi4NCg0KSWYgeW91IHdh bnQgdG8gdXBkYXRlIHlvdXIgcmV2aWV3cyBpbiB0aGUgbGlnaHQgb2YgaXQsIHBsZWFzZSBnbyBh aGVhZCBhbmQNCnJlc2VuZCB5b3VyIHJldmlld3MgaGVyZS4gSSdsbCB0aGVuIGNvbGxhdGUgdGhl IHRocmVlIHJldmlld3Mgd2UgaGF2ZSB0bw0KdGhlIENGUkcgbGlzdC4NCg0KQ2hlZXJzDQoNCktl bm55IA0KDQpPbiAwNC8wNy8yMDE3IDEzOjI3LCAiQ3J5cHRvLXBhbmVsIG9uIGJlaGFsZiBvZiBC am9lcm4gVGFja21hbm4iDQo8Y3J5cHRvLXBhbmVsLWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVoYWxm IG9mIGJqb2Vybi50YWNrbWFubkBpZWVlLm9yZz4NCndyb3RlOg0KDQo+SGkgYWxsLA0KPg0KPk9u IFN1biwgSnVsIDIsIDIwMTcgYXQgMjozNyBQTSwgVGlib3IgSmFnZXINCj48dGlib3IuamFnZXJA dXBiLmRlPiB3cm90ZToNCj4NCj4NCj5PbiAwMS8wNy8yMDE3IDIwOjM0LCBCam9lcm4gVGFja21h bm4gd3JvdGU6DQo+PiBQbGVhc2UgZmluZCBteSByZXZpZXcgYmVsb3cuIEl0J3MgYSBuaWNlIHBp ZWNlIG9mIHdvcmsgYW5kIG92ZXJhbGwgaW4NCj4+IHF1aXRlIGdvb2Qgc2hhcGUuDQo+Pg0KPj4g QWZ0ZXIgbG9va2luZyBhdCB0aGUgb3RoZXIgcmV2aWV3czogSSBkbyBub3QgcXVpdGUgdW5kZXJz dGFuZCBUaWJvcidzDQo+PiBjb21tZW50IG9uIHRoZSBiaXQtbGVuZ3RoIHZzLiBieXRlLWxlbmd0 aCwgZ2l2ZW4gdGhhdCB0aGUgZHJhZnQgc3RhdGVzDQo+PiB0aGF0IHRoZSBzY2hlbWUgdGFrZXMg ImFyYml0cmFyeS1sZW5ndGggcGxhaW50ZXh0ICYgYWRkaXRpb25hbCBkYXRhDQo+PiBieXRlLXN0 cmluZ3MiIC0tIGFuZCBmb3IgbWUgdGhlIHRlcm0gImJ5dGUtc3RyaW5ncyIgbWVhbnMgdGhhdCB0 aGUNCj4+IGJ5dGUtbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIGlzIGFuIGludGVnZXIuDQo+DQo+SW5k ZWVkLCB0aGlzIGlzIG9uZSBvZiB0aGUgc2VjdGlvbnMgdGhhdCBzdWdnZXN0cyB0aGF0IGl0IGlz IGltcGxpY2l0bHkNCj5hc3N1bWVkIHRoYXQgInZhbGlkIiBwbGFpbnRleHRzIGFuZCBBRCBoYXZl IGFsd2F5cyBhIGJ5dGUtbGVuZ3RoIHdoaWNoDQo+aXMgYW4gaW50ZWdlci4NCj4NCj5XaGF0IEkg Zm91bmQgKnBvdGVudGlhbGx5KiBjb25mdXNpbmcgaXM6DQo+DQo+LSBUaGVuIGl0IHdvdWxkIGFs c28gYmUgc29tZXdoYXQgbW9yZSBpbnR1aXRpdmUvY29uc2lzdGVudCB0byBpbmNsdWRlDQo+dGhl IGJ5dGUtbGVuZ3RoIG9mIHBsYWludGV4dCBhbmQgQUQgaW4gdGhlIGxlbmd0aCBibG9jay4gVGhl IGN1cnJlbnQNCj5kcmFmdCBpbmNsdWRlcyB0aGUgYml0LWxlbmd0aC4gKFRoaXMgaXMgb2YgY291 cnNlIHRlY2huaWNhbGx5IGZpbmUgYW5kDQo+ZXNzZW50aWFsbHkganVzdCBhIGRpZmZlcmVudCBu b3RhdGlvbiwgYnV0ICpjb3VsZCogYmUgY29uZnVzaW5nLikNCj4NCj4tIEFsc28gdGhlIGV4YW1w bGUgaW4gU2VjdGlvbiA4IG1lbnRpb25zIHRoZSBiaXQtbGVuZ3RoLg0KPg0KPg0KPg0KPg0KPkkg ZnVsbHkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBsZXNzIGFtYmlndW91cyB0byBkbyB0aGVzZSBj b21wdXRhdGlvbnMgaW4NCj50ZXJtcyBvZiBieXRlLWxlbmd0aC4gSSBkbyBub3Qgc2VlIGFueSBh ZHZhbnRhZ2Ugb2YgaGF2aW5nIHRoZSBzY2hlbWUNCj5vcGVyYXRlIGludGVybmFsbHkgaW4gdGVy bXMgb2YgYml0LWxlbmd0aCwgd2hlbiBvbmx5IGJ5dGUtbGVuZ3RoIHN0cmluZ3MNCj5hcmUgYWxs b3dlZC4NCj4NCj4NCj4gDQo+DQo+LSBJdCB3b3VsZCBhbHNvIG1ha2Ugc2Vuc2UgdG8gbGV0IHRo ZSBlbmNyeXB0aW9uIGFsZ29yaXRobSBhYm9ydCwgaWYgdGhlDQo+bGVuZ3RocyBvZiBwbGFpbnRl eHRzIGFuZCBBRCBhcmUgbm90IGEgbXVsdGlwbGUgb2YgOCBiaXRzIChhbmQgb25lIGNvdWxkDQo+ aWdub3JlIHRoaXMgY2hlY2sgaW4gYXBwbGljYXRpb25zIHdoZXJlIHRoaXMgaXMgZ3VhcmFudGVl ZCBieSB0aGUNCj5lbnZpcm9ubWVudCAtIGJ1dCB0aGlzIGlzIG9mIGNvdXJzZSBzb21ldGhpbmcg dGhhdCBvbmx5IHRoZSBhcHBsaWNhdGlvbg0KPmRldmVsb3BlciBjYW4gZGVjaWRlKS4NCj4NCj4N Cj4NCj4NCj5BZ3JlZWQuDQo+DQo+DQo+DQo+DQo+QmVzdCwNCj5CasO2cm4gDQo+DQo+DQo+DQo+ DQo+DQo+DQoNCg== From nobody Tue Jul 4 08:01:48 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7F12706D for ; Tue, 4 Jul 2017 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.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 rdPdpFxAEobP for ; Tue, 4 Jul 2017 08:01:42 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 ACB79131628 for ; Tue, 4 Jul 2017 08:01:39 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l21so74568218ywb.1 for ; Tue, 04 Jul 2017 08:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SXGLFvatJA+1Kh3DIedi7canx+vBIUB2vC8bSgBUhmE=; b=RdTIIeFaeE7F0Mck7C5GKm/Hj7EugQRgmwNdZKfD7V5BeYVKyjaSK0PCzfpiXtOL6p xEDkNv+x/NrKgt+8sG1HglYa1oLou+jCk4EsA1CfdObs1DQqVHRpQ4hOaR4wo4n4KKm/ FH3YTwysOc83HznlXCtf368Fjl+JoGkS1VUzIuQ+7jzKSraeAtIPMRhjR/c25vJ9t5FC Y72RcpPrhNrZMaIZ//YPc50KhVMdqaANO6b6ehaa3tBVvln7rTZcOl+MTXoz/puB9wEK V49Df1ZiJ4/jlTCLmSlFJFA7OHletzX31XVg4kGb0aGcAAuRWXgcF3aYzPS8wUxNVs1M eeug== 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=SXGLFvatJA+1Kh3DIedi7canx+vBIUB2vC8bSgBUhmE=; b=BAEba5CaaD+Uofg0m60z4WFNlplZnkp7cojUNVEVDSJqYxpccZFI0e5zrG87XWgq4C aTMU9AsEQOjG83nJKdHViY/fgLUEAUgKeiVumbIoCPLbheBjiiKSRgzaPsat9U6VyYZw AWvlNhsuX4rnuR47iR4V15o44liA9M1J6XBP0t+vCY8wiuOjggpxjKiGQloYhigJakqc K1uEahHwPAkz1mge8YQAWWuPQ39jCP2xmkpYFVCRYOnEAbwxqDQeeUXmaarif0HPJ+0f 2BAwxLqik65O9CdrOqzW+iILB9zPZ5v7UWb4C/QgPFef+U/0X2XdZQLfm4Lf61JiBxNR tCyA== X-Gm-Message-State: AKS2vOwCuljYL4glOcaFklb0cr8G8RPuHowD+KApIaNe99Vvi4Oj1bb0 kECltcSQ/ljxoddyL1SI5thtPhxTqvV/ X-Received: by 10.129.73.78 with SMTP id w75mr30658526ywa.244.1499180498665; Tue, 04 Jul 2017 08:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.179.2 with HTTP; Tue, 4 Jul 2017 08:01:38 -0700 (PDT) In-Reply-To: References: From: Bjoern Tackmann Date: Tue, 4 Jul 2017 17:01:38 +0200 Message-ID: To: "Paterson, Kenny" Cc: "crypto-panel@irtf.org" Content-Type: multipart/alternative; boundary="001a114da48414090105537f2936" Archived-At: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 15:01:44 -0000 --001a114da48414090105537f2936 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Kenny, and please find my updated report below. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Summary: Almost ready Major issues: none Minor issues: I found the description of the encryption method comprehensible but a bit too informal. Maybe a pseudo-code description may be easier to understand? In that description, I stumbled particularly over the =E2=80=9C_length bloc= k_=E2=80=9D - why the underscores? Also, I think it would make sense to explicitly clarify that the 32-bit counter value for the CTR part is explicitly allowed to overflow. One aspect that read a bit arbitrary to me was the domain separation for AES by setting the first bit of the last byte to 1/0, and in particular that seemed a bit wasteful since it is evaluated only once with the bit set to 0. Wouldn't it be simpler (and possibly even with better security, but at the cost of limiting the length to 2^32 - 1 blocks) to not fiddle with the bits but just use the first counter-block to compute the tag? Note that this would certainly require re-doing some part of the security analysis, and the gains seem moderate, so I=E2=80=99m fine with this comment being di= scarded. (Just wanted to make sure it is discarded consciously.) After discussion with the other reviewers: The draft is ambiguous with respect to byte-strings vs. bit-strings. My interpretation, stemming from the beginning of Section 4 explicitly mentioning byte-strings, is that all strings must be properly byte-aligned. But given that, using bytelen(additional_length) * 8 and bytelen(plaintext) * 8, i.e. bit-length, is confusing. If the draft is supposed to deal with byte-aligned strings only (which appears practically sensible), then this should be made clear in the document, and byte-length should be used in the encryption. Otherwise, the algorithms have to be specified more clearly for the case of bit-strings that are not byte-aligned. In either case, the draft should be clarified in this respect. On Tue, Jul 4, 2017 at 3:53 PM, Paterson, Kenny wrote: > Thanks everyone for this helpful discussion. > > If you want to update your reviews in the light of it, please go ahead an= d > resend your reviews here. I'll then collate the three reviews we have to > the CFRG list. > > Cheers > > Kenny > > On 04/07/2017 13:27, "Crypto-panel on behalf of Bjoern Tackmann" > > wrote: > > >Hi all, > > > >On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager > > wrote: > > > > > >On 01/07/2017 20:34, Bjoern Tackmann wrote: > >> Please find my review below. It's a nice piece of work and overall in > >> quite good shape. > >> > >> After looking at the other reviews: I do not quite understand Tibor's > >> comment on the bit-length vs. byte-length, given that the draft states > >> that the scheme takes "arbitrary-length plaintext & additional data > >> byte-strings" -- and for me the term "byte-strings" means that the > >> byte-length of the strings is an integer. > > > >Indeed, this is one of the sections that suggests that it is implicitly > >assumed that "valid" plaintexts and AD have always a byte-length which > >is an integer. > > > >What I found *potentially* confusing is: > > > >- Then it would also be somewhat more intuitive/consistent to include > >the byte-length of plaintext and AD in the length block. The current > >draft includes the bit-length. (This is of course technically fine and > >essentially just a different notation, but *could* be confusing.) > > > >- Also the example in Section 8 mentions the bit-length. > > > > > > > > > >I fully agree that it would be less ambiguous to do these computations i= n > >terms of byte-length. I do not see any advantage of having the scheme > >operate internally in terms of bit-length, when only byte-length strings > >are allowed. > > > > > > > > > >- It would also make sense to let the encryption algorithm abort, if the > >lengths of plaintexts and AD are not a multiple of 8 bits (and one could > >ignore this check in applications where this is guaranteed by the > >environment - but this is of course something that only the application > >developer can decide). > > > > > > > > > >Agreed. > > > > > > > > > >Best, > >Bj=C3=B6rn > > > > > > > > > > > > > > --001a114da48414090105537f2936 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Kenny, and please find my updated report below.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Summary: Almost ready

Major issues: none

Minor issues:
<= br>
I found the description of the encryption method comprehensib= le but a bit too informal. Maybe a pseudo-code description may be easier to= understand?

In that description, I stumbled parti= cularly over the =E2=80=9C_length block_=E2=80=9D - why the underscores? Al= so, I think it would make sense to explicitly clarify that the 32-bit count= er value for the CTR part is explicitly allowed to overflow.

=
One aspect that read a bit arbitrary to me was the domain separa= tion for AES by setting the first bit of the last byte to 1/0, and in parti= cular that seemed a bit wasteful since it is evaluated only once with the b= it set to 0. Wouldn't it be simpler (and possibly even with better secu= rity, but at the cost of limiting the length to 2^32 - 1 blocks) to not fid= dle with the bits but just use the first counter-block to compute the tag? = Note that this would certainly require re-doing some part of the security a= nalysis, and the gains seem moderate, so I=E2=80=99m fine with this comment= being discarded. (Just wanted to make sure it is discarded consciously.)

After discussion with the other reviewers: The draf= t is ambiguous with respect to byte-strings vs. bit-strings. My interpretat= ion, stemming from the beginning of Section 4 explicitly mentioning byte-st= rings, is that all strings must be properly byte-aligned. But given that, u= sing bytelen(additional_length) * 8 and bytelen(plaintext) * 8, i.e. bit-le= ngth, is confusing. If the draft is supposed to deal with byte-aligned stri= ngs only (which appears practically sensible), then this should be made cle= ar in the document, and byte-length should be used in the encryption. Other= wise, the algorithms have to be specified more clearly for the case of bit-= strings that are not byte-aligned. In either case, the draft should be clar= ified in this respect.


On Tue, Jul 4, 2017 at 3:53 PM, Pater= son, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
Thanks everyone for this helpful discussion.
If you want to update your reviews in the light of it, please go ahead and<= br> resend your reviews here. I'll then collate the three reviews we have t= o
the CFRG list.

Cheers

Kenny

On 04/07/2017 13:27, "Crypto-panel on behalf of Bjoern Tackmann"<= br> <crypto-panel-bounces@i= rtf.org on behalf of bjoern= .tackmann@ieee.org>
wrote:

>Hi all,
>
>On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager
><tibor.jager@upb.de> wr= ote:
>
>
>On 01/07/2017 20:34, Bjoern Tackmann wrote:
>> Please find my review below. It's a nice piece of work and ove= rall in
>> quite good shape.
>>
>> After looking at the other reviews: I do not quite understand Tibo= r's
>> comment on the bit-length vs. byte-length, given that the draft st= ates
>> that the scheme takes "arbitrary-length plaintext & addit= ional data
>> byte-strings" -- and for me the term "byte-strings"= means that the
>> byte-length of the strings is an integer.
>
>Indeed, this is one of the sections that suggests that it is implicitly=
>assumed that "valid" plaintexts and AD have always a byte-len= gth which
>is an integer.
>
>What I found *potentially* confusing is:
>
>- Then it would also be somewhat more intuitive/consistent to include >the byte-length of plaintext and AD in the length block. The current >draft includes the bit-length. (This is of course technically fine and<= br> >essentially just a different notation, but *could* be confusing.)
>
>- Also the example in Section 8 mentions the bit-length.
>
>
>
>
>I fully agree that it would be less ambiguous to do these computations = in
>terms of byte-length. I do not see any advantage of having the scheme >operate internally in terms of bit-length, when only byte-length string= s
>are allowed.
>
>
>
>
>- It would also make sense to let the encryption algorithm abort, if th= e
>lengths of plaintexts and AD are not a multiple of 8 bits (and one coul= d
>ignore this check in applications where this is guaranteed by the
>environment - but this is of course something that only the application=
>developer can decide).
>
>
>
>
>Agreed.
>
>
>
>
>Best,
>Bj=C3=B6rn
>
>
>
>
>
>


--001a114da48414090105537f2936-- From nobody Wed Jul 5 00:22:10 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624AF131830 for ; Wed, 5 Jul 2017 00:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uni-paderborn.de 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 DGpV1iJmQ9XZ for ; Wed, 5 Jul 2017 00:22:05 -0700 (PDT) Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (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 D5C5E13183B for ; Wed, 5 Jul 2017 00:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=uni-paderborn.de; s=20170601; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=vzErzMixNEzHCkxDB4+x6XXarMGC5Fx2uX7WFnUV1FU=; b=MgajK82G4WJDvtIhfwa06GDP3UiIDXbRRaL6aaBFzVJ0/5K/nA3xIOeZCCE1spWLdiabSTkZtdPKhIlCo5RIhDNWJZoaBo4aRSWYsiswpCrZjTrsfu4ELL+/PQ0UoGGHHUCHYWYMTlsrtUUyUasU8l8dsnbFhU0oC/w4uRsJhPM=; To: crypto-panel@irtf.org References: From: Tibor Jager Message-ID: Date: Wed, 5 Jul 2017 09:21:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IMT-Spam-Score: 0.0 () X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.7.5.71516, AntiVirus-Engine: 5.38.0, AntiVirus-Data: 2017.7.5.5380000 X-IMT-Authenticated-Sender: uid=tjager,ou=People,o=upb,c=de Archived-At: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 07:22:08 -0000 Hi all, Please find my updated review below: ================================================================================ Summary: almost ready ======================================== Major concerns: ======================================== none ======================================== Minor comments and recommendations: ======================================== The draft is somewhat unclear whether plaintexts and additional data (AD) are always assumed to be given as *byte*-strings, or whether it is also possible to encrypt arbitrary-length *bit*-strings whose length is not a multiple of 8. On the one hand, at the beginning of Section 4 it is clearly stated that the encryption algorithm takes "arbitrary-length plaintext & additional data *byte*-strings". On the other hand, then it would also be somewhat more intuitive/consistent to include the *byte*-length of plaintext and AD in the length block. The current draft includes the bit-length. (This is of course technically fine and essentially just a different notation, but *could* be misleading for developers.) Also the example in Section 8 mentions the bit-length of plaintext/AD. Hence, I want to suggest to mention this assumption about the plaintext length more clearly - even if it seems quite standard and will most likely hold for most application anyway. In the worst case, if a developer misunderstands this and allows the encryption with arbitrary bit-length plaintext and AD, then this may enable to break the integrity of ciphertexts (at least in theory), if the bytelen() function is implemented in the natural way. Let C = Enc(k,m,d,n) be a ciphertext, encrypting plaintext m with key k, nonce n, and additional data d. Suppose that |d| = 7 bits, and that bytelen() is implemented such that bytelen(d) = 1 (which seems natural, even tough bytelen(d) = 7/8 would actually be correct). Note that the encryption algorithm pads d with zeroes to a multiple of 16 bytes before it is processed by POLYVAL, such that in particular it holds that C = Enc(k,m,d,n) = Enc(k,m,d||0,n) and the decryption algorithm accepts both d and d||0 as "valid" additional data for C. Of course this attack is rather theoretical, but it can easily be avoided by either including the precise *bit*-length of plaintext and AD into the length block, or by letting the encryption algorithm abort, if the lengths of plaintexts or AD are not a multiple of 8 bits (and one could ignore this check in applications where this is guaranteed by the environment - but this is of course something that only the application developer can decide). ======================================== Nitpicking: ======================================== Section 1 "Introduction", 1st paragraph: I suggest to replace "...that is easier for practitioners to use correctly." with "that is easier to use correctly." In Section 4, first paragraph, the text suggests that plaintexts and additional data of arbitrary length can be encrypted. However, the description of the decryption procedure in Section 5 rejects ciphertexts of size larger than 2^36+16 bytes, and Section 6 gives upper bounds on the plaintext and AD sizes P_MAX and A_MAX. In Section 4, last paragraph, the result of encryption is the "resulting ciphertext ... followed by the tag". Thus, in this notation, the tag is not part of the "ciphertext", but it is separate and sent along with the ciphertext. However, at the beginning of Section 5, decryption algorithm receives as input key, nonce, AD, and a ciphertext, and the ciphertext is split into the encrypted plaintext and the tag, thus the "ciphertext" contains the tag here. One could unify this, by always considering the tag as part of the ciphertext. Section 8, very very nitpicking: One could mention here that the plaintext are the bit strings corresponding to the *ASCII encoding* of "Hello world" and "example". Section 8, 5th paragraph, again very nitpicking: Some developers may have difficulties in understanding immediately which numbers are given in hexadecimal notation, and which in decimal notation. For clarity, one could write here something like: "example": 7 characters = 56 bits = 0x38 bits "Hello world": 11 characters = 88 bits = 0x58 bits Section 9, 7th paragraph: "Suzuki et al. [multibirthday]", the reference lists Kazuhiro as first author, so it seems this should be Kazuhiro et al. I did not check the test vectors. Regarding Scott's comment on the verbal description of the encryption and decryption algorithms: I had the same impression, some pseudocode may be helpful to clarify what is happening here. Apart from the above minor comments, I think that this is an excellent RFC, which is very clear, precise, easy to understand, and well-readable. The large number of test vectors will certainly be considered very helpful to many implementers. I think it is very useful to have a nonce misuse-resistant encryption scheme defined in an RFC, in particular if it is as competitive with weaker solutions regarding implementational difficulty and computational efficiency as this one. ================================================================================ Cheers, Tibor On 04/07/2017 15:53, Paterson, Kenny wrote: > Thanks everyone for this helpful discussion. > > If you want to update your reviews in the light of it, please go ahead and > resend your reviews here. I'll then collate the three reviews we have to > the CFRG list. > > Cheers > > Kenny > > On 04/07/2017 13:27, "Crypto-panel on behalf of Bjoern Tackmann" > > wrote: > >> Hi all, >> >> On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager >> wrote: >> >> >> On 01/07/2017 20:34, Bjoern Tackmann wrote: >>> Please find my review below. It's a nice piece of work and overall in >>> quite good shape. >>> >>> After looking at the other reviews: I do not quite understand Tibor's >>> comment on the bit-length vs. byte-length, given that the draft states >>> that the scheme takes "arbitrary-length plaintext & additional data >>> byte-strings" -- and for me the term "byte-strings" means that the >>> byte-length of the strings is an integer. >> >> Indeed, this is one of the sections that suggests that it is implicitly >> assumed that "valid" plaintexts and AD have always a byte-length which >> is an integer. >> >> What I found *potentially* confusing is: >> >> - Then it would also be somewhat more intuitive/consistent to include >> the byte-length of plaintext and AD in the length block. The current >> draft includes the bit-length. (This is of course technically fine and >> essentially just a different notation, but *could* be confusing.) >> >> - Also the example in Section 8 mentions the bit-length. >> >> >> >> >> I fully agree that it would be less ambiguous to do these computations in >> terms of byte-length. I do not see any advantage of having the scheme >> operate internally in terms of bit-length, when only byte-length strings >> are allowed. >> >> >> >> >> - It would also make sense to let the encryption algorithm abort, if the >> lengths of plaintexts and AD are not a multiple of 8 bits (and one could >> ignore this check in applications where this is guaranteed by the >> environment - but this is of course something that only the application >> developer can decide). >> >> >> >> >> Agreed. >> >> >> >> >> Best, >> Björn >> >> >> >> >> >> > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > From nobody Wed Jul 5 00:35:19 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7671B131AA2 for ; Wed, 5 Jul 2017 00:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] 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 WlsJI3BvAnt3 for ; Wed, 5 Jul 2017 00:35:11 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0055.outbound.protection.outlook.com [104.47.1.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EEE131A9F for ; Wed, 5 Jul 2017 00:35:09 -0700 (PDT) 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=3MR8pjCtK9f8ltQ5vheX4qaYvcyjZnDYsDyjX+EZysc=; b=Qs3bHM6R2aBQeT138uF+46nobdIp8DttRCsNYm4qbP8Mx4HhSAG/pzVbf4H+9lOFxjgMzlKW7JavCt0dxElbkWKbwVIiV3Gk9Sg1E7FBlYH2azytZ9ZvZHEUUsejh2RAm56vRGH5k1l/jbaofXTAHHFkL+RCuhWLQlMXt9YMrVg= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1908.eurprd03.prod.outlook.com (10.168.3.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Wed, 5 Jul 2017 07:35:07 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Wed, 5 Jul 2017 07:35:06 +0000 From: "Paterson, Kenny" To: Tibor Jager , "crypto-panel@irtf.org" Thread-Topic: [Crypto-panel] Review of AES-GCM-SIV Thread-Index: AQHS5eUMXPqksT4BkEOlrKXEsk18RKI/ZZ4AgAEupACAAyHcAIAAKM+AgAEUEICAABRfAA== Date: Wed, 5 Jul 2017 07:35:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: upb.de; dkim=none (message not signed) header.d=none;upb.de; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:fraiF14exptgFvP0QH4yw1AyAVCpdp2NVRsyzM6XYy0hR5wWIBhopBZNVHFp8c15e6JSxZVcCp1gu5XqQICeqgCnikHiYoCgiek2TwTQC+opcXYUaMvB1fhu6haDQ9Hw/JpNqaXY6jzvSAaVj9eUWrn6LGTApkU5qVd33P2kQd8Eoy6nV4/foxumCXOKGAJ4baGjGM21JXr3ZAjs4WQuFkxKwgHc5hQYcqbgm3a0nPflBzUPpO8ddNghkkWE/mXZx6PNm743HVopLyukURiIK4jokecGxTL3SbcuV0sXwepqwXP2yp6Ii2ytR0K80t6hJzH5orb4eZQ1gCren55mv8WoEtceXWbGsODxk38dq2AGAMbNIc8q+ThMhbPxDEjl5A/t7oSpyWPtVdIH99+TAPts6GJUHwoXInzHqfb1esVRPB+IEiOIVh0Ya7poyq+CHNnIHNzH3RhckoUNY2lLaB3JWLI5xt1SKBXNGh+PPjexxhtw15jwIG1w2PqFjWItm2xBZnCB3ZDDrhbm0HM0IMpwofDGpmwj4fJYxI+OU8bsC6JPFeaOftqO1+FVaFQawSPYqcARYbI9SV3wLjjv2mS9c5vNO6Kctmwf3AKhxpJ3Ud/qfhWHHE5B10XC1+gE0Q2KuiG8QeoyyCmFyItYtVsE4Jb6TdFbNheKj1UGES3Si38pxjAyRkmTuMtu9b0CXO/wCgYMtilrvaRCuS96Mw7Fhwizpv42H/4yLHEGt8XzHhQdbJGCp2BRFCJAJeKRJLXUmZMAELiQ/cKlgaqJK0yZomUluhE2YwNOlzIosaA= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(53754006)(377454003)(24454002)(38730400002)(6246003)(6506006)(5250100002)(189998001)(966005)(2501003)(66066001)(53546010)(86362001)(14454004)(53936002)(6512007)(6436002)(102836003)(6116002)(99286003)(3846002)(6306002)(83506001)(25786009)(2900100001)(5660300001)(3660700001)(81166006)(8676002)(3280700002)(8936002)(74482002)(2906002)(36756003)(4001350100001)(478600001)(230783001)(305945005)(6486002)(93886004)(50986999)(72206003)(7736002)(76176999)(42882006)(2950100002)(54356999)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 6d322349-3a90-4477-d124-08d4c3785ba3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1908; x-ms-traffictypediagnostic: AM4PR0301MB1908: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(236129657087228)(788757137089)(48057245064654)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1908; x-forefront-prvs: 0359162B6D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5B6555FAF8C3164C81DBB518D4719D55@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 07:35:06.6411 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908 Archived-At: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 07:35:17 -0000 VGhhbmtzIFRpYm9yLCBtdWNoIGFwcHJlY2lhdGVkLg0KDQpPbiAwNS8wNy8yMDE3IDA4OjIxLCAi Q3J5cHRvLXBhbmVsIG9uIGJlaGFsZiBvZiBUaWJvciBKYWdlciINCjxjcnlwdG8tcGFuZWwtYm91 bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YgdGlib3IuamFnZXJAdXBiLmRlPiB3cm90ZToNCg0K PkhpIGFsbCwNCj4NCj5QbGVhc2UgZmluZCBteSB1cGRhdGVkIHJldmlldyBiZWxvdzoNCj4NCj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPj09PT09PQ0KPg0KPlN1bW1hcnk6IGFsbW9zdCByZWFkeQ0KPg0K Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj5NYWpvciBjb25jZXJu czoNCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+DQo+bm9uZQ0K Pg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj5NaW5vciBjb21t ZW50cyBhbmQgcmVjb21tZW5kYXRpb25zOg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4NCj4NCj5UaGUgZHJhZnQgaXMgc29tZXdoYXQgdW5jbGVhciB3aGV0aGVy IHBsYWludGV4dHMgYW5kIGFkZGl0aW9uYWwgZGF0YQ0KPihBRCkgYXJlIGFsd2F5cyBhc3N1bWVk IHRvIGJlIGdpdmVuIGFzICpieXRlKi1zdHJpbmdzLCBvciB3aGV0aGVyIGl0IGlzDQo+YWxzbyBw b3NzaWJsZSB0byBlbmNyeXB0IGFyYml0cmFyeS1sZW5ndGggKmJpdCotc3RyaW5ncyB3aG9zZSBs ZW5ndGggaXMNCj5ub3QgYSBtdWx0aXBsZSBvZiA4Lg0KPg0KPg0KPk9uIHRoZSBvbmUgaGFuZCwg YXQgdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDQgaXQgaXMgY2xlYXJseSBzdGF0ZWQgdGhhdA0K PnRoZSBlbmNyeXB0aW9uIGFsZ29yaXRobSB0YWtlcyAiYXJiaXRyYXJ5LWxlbmd0aCBwbGFpbnRl eHQgJiBhZGRpdGlvbmFsDQo+ZGF0YSAqYnl0ZSotc3RyaW5ncyIuDQo+DQo+T24gdGhlIG90aGVy IGhhbmQsIHRoZW4gaXQgd291bGQgYWxzbyBiZSBzb21ld2hhdCBtb3JlDQo+aW50dWl0aXZlL2Nv bnNpc3RlbnQgdG8gaW5jbHVkZQ0KPnRoZSAqYnl0ZSotbGVuZ3RoIG9mIHBsYWludGV4dCBhbmQg QUQgaW4gdGhlIGxlbmd0aCBibG9jay4gVGhlIGN1cnJlbnQNCj5kcmFmdCBpbmNsdWRlcyB0aGUg Yml0LWxlbmd0aC4gKFRoaXMgaXMgb2YgY291cnNlIHRlY2huaWNhbGx5IGZpbmUgYW5kDQo+ZXNz ZW50aWFsbHkganVzdCBhIGRpZmZlcmVudCBub3RhdGlvbiwgYnV0ICpjb3VsZCogYmUgbWlzbGVh ZGluZyBmb3INCj5kZXZlbG9wZXJzLikgQWxzbyB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDggbWVu dGlvbnMgdGhlIGJpdC1sZW5ndGggb2YNCj5wbGFpbnRleHQvQUQuDQo+DQo+SGVuY2UsIEkgd2Fu dCB0byBzdWdnZXN0IHRvIG1lbnRpb24gdGhpcyBhc3N1bXB0aW9uIGFib3V0IHRoZSBwbGFpbnRl eHQNCj5sZW5ndGggbW9yZSBjbGVhcmx5IC0gZXZlbiBpZiBpdCBzZWVtcyBxdWl0ZSBzdGFuZGFy ZCBhbmQgd2lsbCBtb3N0DQo+bGlrZWx5IGhvbGQgZm9yIG1vc3QgYXBwbGljYXRpb24gYW55d2F5 Lg0KPg0KPkluIHRoZSB3b3JzdCBjYXNlLCBpZiBhIGRldmVsb3BlciBtaXN1bmRlcnN0YW5kcyB0 aGlzIGFuZCBhbGxvd3MgdGhlDQo+ZW5jcnlwdGlvbiB3aXRoIGFyYml0cmFyeSBiaXQtbGVuZ3Ro IHBsYWludGV4dCBhbmQgQUQsIHRoZW4gdGhpcyBtYXkNCj5lbmFibGUgdG8gYnJlYWsgdGhlIGlu dGVncml0eSBvZiBjaXBoZXJ0ZXh0cyAoYXQgbGVhc3QgaW4gdGhlb3J5KSwgaWYNCj50aGUgYnl0 ZWxlbigpIGZ1bmN0aW9uIGlzIGltcGxlbWVudGVkIGluIHRoZSBuYXR1cmFsIHdheS4NCj4NCj5M ZXQgQyA9IEVuYyhrLG0sZCxuKSBiZSBhIGNpcGhlcnRleHQsIGVuY3J5cHRpbmcgcGxhaW50ZXh0 IG0gd2l0aCBrZXkgaywNCj5ub25jZSBuLCBhbmQgYWRkaXRpb25hbCBkYXRhIGQuIFN1cHBvc2Ug dGhhdCB8ZHwgPSA3IGJpdHMsIGFuZCB0aGF0DQo+Ynl0ZWxlbigpIGlzIGltcGxlbWVudGVkIHN1 Y2ggdGhhdCBieXRlbGVuKGQpID0gMSAod2hpY2ggc2VlbXMgbmF0dXJhbCwNCj5ldmVuIHRvdWdo IGJ5dGVsZW4oZCkgPSA3Lzggd291bGQgYWN0dWFsbHkgYmUgY29ycmVjdCkuIE5vdGUgdGhhdCB0 aGUNCj5lbmNyeXB0aW9uIGFsZ29yaXRobSBwYWRzIGQgd2l0aCB6ZXJvZXMgdG8gYSBtdWx0aXBs ZSBvZiAxNiBieXRlcyBiZWZvcmUNCj5pdCBpcyBwcm9jZXNzZWQgYnkgUE9MWVZBTCwgc3VjaCB0 aGF0IGluIHBhcnRpY3VsYXIgaXQgaG9sZHMgdGhhdA0KPg0KPiAgQyA9IEVuYyhrLG0sZCxuKSA9 IEVuYyhrLG0sZHx8MCxuKQ0KPg0KPmFuZCB0aGUgZGVjcnlwdGlvbiBhbGdvcml0aG0gYWNjZXB0 cyBib3RoIGQgYW5kIGR8fDAgYXMgInZhbGlkIg0KPmFkZGl0aW9uYWwgZGF0YSBmb3IgQy4NCj4N Cj5PZiBjb3Vyc2UgdGhpcyBhdHRhY2sgaXMgcmF0aGVyIHRoZW9yZXRpY2FsLCBidXQgaXQgY2Fu IGVhc2lseSBiZQ0KPmF2b2lkZWQgYnkgZWl0aGVyIGluY2x1ZGluZyB0aGUgcHJlY2lzZSAqYml0 Ki1sZW5ndGggb2YgcGxhaW50ZXh0IGFuZCBBRA0KPmludG8gdGhlIGxlbmd0aCBibG9jaywgb3Ig YnkgbGV0dGluZyB0aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gYWJvcnQsIGlmDQo+dGhlIGxlbmd0 aHMgb2YgcGxhaW50ZXh0cyBvciBBRCBhcmUgbm90IGEgbXVsdGlwbGUgb2YgOCBiaXRzIChhbmQg b25lDQo+Y291bGQgaWdub3JlIHRoaXMgY2hlY2sgaW4gYXBwbGljYXRpb25zIHdoZXJlIHRoaXMg aXMgZ3VhcmFudGVlZCBieSB0aGUNCj5lbnZpcm9ubWVudCAtIGJ1dCB0aGlzIGlzIG9mIGNvdXJz ZSBzb21ldGhpbmcgdGhhdCBvbmx5IHRoZSBhcHBsaWNhdGlvbg0KPmRldmVsb3BlciBjYW4gZGVj aWRlKS4NCj4NCj4NCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ Tml0cGlja2luZzoNCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ DQo+U2VjdGlvbiAxICJJbnRyb2R1Y3Rpb24iLCAxc3QgcGFyYWdyYXBoOiBJIHN1Z2dlc3QgdG8g cmVwbGFjZQ0KPiAgIi4uLnRoYXQgaXMgZWFzaWVyIGZvciBwcmFjdGl0aW9uZXJzIHRvIHVzZSBj b3JyZWN0bHkuIg0KPndpdGgNCj4gICJ0aGF0IGlzIGVhc2llciB0byB1c2UgY29ycmVjdGx5LiIN Cj4NCj4NCj5JbiBTZWN0aW9uIDQsIGZpcnN0IHBhcmFncmFwaCwgdGhlIHRleHQgc3VnZ2VzdHMg dGhhdCBwbGFpbnRleHRzIGFuZA0KPmFkZGl0aW9uYWwgZGF0YSBvZiBhcmJpdHJhcnkgbGVuZ3Ro IGNhbiBiZSBlbmNyeXB0ZWQuIEhvd2V2ZXIsIHRoZQ0KPmRlc2NyaXB0aW9uIG9mIHRoZSBkZWNy eXB0aW9uIHByb2NlZHVyZSBpbiBTZWN0aW9uIDUgcmVqZWN0cyBjaXBoZXJ0ZXh0cw0KPm9mIHNp emUgbGFyZ2VyIHRoYW4gMl4zNisxNiBieXRlcywgYW5kIFNlY3Rpb24gNiBnaXZlcyB1cHBlciBi b3VuZHMgb24NCj50aGUgcGxhaW50ZXh0IGFuZCBBRCBzaXplcyBQX01BWCBhbmQgQV9NQVguDQo+ DQo+DQo+SW4gU2VjdGlvbiA0LCBsYXN0IHBhcmFncmFwaCwgdGhlIHJlc3VsdCBvZiBlbmNyeXB0 aW9uIGlzIHRoZSAicmVzdWx0aW5nDQo+Y2lwaGVydGV4dCAuLi4gZm9sbG93ZWQgYnkgdGhlIHRh ZyIuIFRodXMsIGluIHRoaXMgbm90YXRpb24sIHRoZSB0YWcgaXMNCj5ub3QgcGFydCBvZiB0aGUg ImNpcGhlcnRleHQiLCBidXQgaXQgaXMgc2VwYXJhdGUgYW5kIHNlbnQgYWxvbmcgd2l0aCB0aGUN Cj5jaXBoZXJ0ZXh0Lg0KPkhvd2V2ZXIsIGF0IHRoZSBiZWdpbm5pbmcgb2YgU2VjdGlvbiA1LCBk ZWNyeXB0aW9uIGFsZ29yaXRobSByZWNlaXZlcyBhcw0KPmlucHV0IGtleSwgbm9uY2UsIEFELCBh bmQgYSBjaXBoZXJ0ZXh0LCBhbmQgdGhlIGNpcGhlcnRleHQgaXMgc3BsaXQgaW50bw0KPnRoZSBl bmNyeXB0ZWQgcGxhaW50ZXh0IGFuZCB0aGUgdGFnLCB0aHVzIHRoZSAiY2lwaGVydGV4dCIgY29u dGFpbnMgdGhlDQo+dGFnIGhlcmUuIE9uZSBjb3VsZCB1bmlmeSB0aGlzLCBieSBhbHdheXMgY29u c2lkZXJpbmcgdGhlIHRhZyBhcyBwYXJ0IG9mDQo+dGhlIGNpcGhlcnRleHQuDQo+DQo+DQo+U2Vj dGlvbiA4LCB2ZXJ5IHZlcnkgbml0cGlja2luZzogT25lIGNvdWxkIG1lbnRpb24gaGVyZSB0aGF0 IHRoZQ0KPnBsYWludGV4dCBhcmUgdGhlIGJpdCBzdHJpbmdzIGNvcnJlc3BvbmRpbmcgdG8gdGhl ICpBU0NJSSBlbmNvZGluZyogb2YNCj4iSGVsbG8gd29ybGQiIGFuZCAiZXhhbXBsZSIuDQo+DQo+ DQo+U2VjdGlvbiA4LCA1dGggcGFyYWdyYXBoLCBhZ2FpbiB2ZXJ5IG5pdHBpY2tpbmc6IFNvbWUg ZGV2ZWxvcGVycyBtYXkNCj5oYXZlIGRpZmZpY3VsdGllcyBpbiB1bmRlcnN0YW5kaW5nIGltbWVk aWF0ZWx5IHdoaWNoIG51bWJlcnMgYXJlIGdpdmVuDQo+aW4gaGV4YWRlY2ltYWwgbm90YXRpb24s IGFuZCB3aGljaCBpbiBkZWNpbWFsIG5vdGF0aW9uLiBGb3IgY2xhcml0eSwgb25lDQo+Y291bGQg d3JpdGUgaGVyZSBzb21ldGhpbmcgbGlrZToNCj4iZXhhbXBsZSI6IDcgY2hhcmFjdGVycyA9IDU2 IGJpdHMgPSAweDM4IGJpdHMNCj4iSGVsbG8gd29ybGQiOiAxMSBjaGFyYWN0ZXJzID0gODggYml0 cyA9IDB4NTggYml0cw0KPg0KPg0KPlNlY3Rpb24gOSwgN3RoIHBhcmFncmFwaDogIlN1enVraSBl dCBhbC4gW211bHRpYmlydGhkYXldIiwgdGhlIHJlZmVyZW5jZQ0KPmxpc3RzIEthenVoaXJvIGFz IGZpcnN0IGF1dGhvciwgc28gaXQgc2VlbXMgdGhpcyBzaG91bGQgYmUgS2F6dWhpcm8gZXQgYWwu DQo+DQo+DQo+SSBkaWQgbm90IGNoZWNrIHRoZSB0ZXN0IHZlY3RvcnMuDQo+DQo+DQo+UmVnYXJk aW5nIFNjb3R0J3MgY29tbWVudCBvbiB0aGUgdmVyYmFsIGRlc2NyaXB0aW9uIG9mIHRoZSBlbmNy eXB0aW9uDQo+YW5kIGRlY3J5cHRpb24gYWxnb3JpdGhtczogSSBoYWQgdGhlIHNhbWUgaW1wcmVz c2lvbiwgc29tZSBwc2V1ZG9jb2RlDQo+bWF5IGJlIGhlbHBmdWwgdG8gY2xhcmlmeSB3aGF0IGlz IGhhcHBlbmluZyBoZXJlLg0KPg0KPg0KPkFwYXJ0IGZyb20gdGhlIGFib3ZlIG1pbm9yIGNvbW1l bnRzLCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhbiBleGNlbGxlbnQNCj5SRkMsIHdoaWNoIGlzIHZl cnkgY2xlYXIsIHByZWNpc2UsIGVhc3kgdG8gdW5kZXJzdGFuZCwgYW5kDQo+d2VsbC1yZWFkYWJs ZS4gVGhlIGxhcmdlIG51bWJlciBvZiB0ZXN0IHZlY3RvcnMgd2lsbCBjZXJ0YWlubHkgYmUNCj5j b25zaWRlcmVkIHZlcnkgaGVscGZ1bCB0byBtYW55IGltcGxlbWVudGVycy4gSSB0aGluayBpdCBp cyB2ZXJ5IHVzZWZ1bA0KPnRvIGhhdmUgYSBub25jZSBtaXN1c2UtcmVzaXN0YW50IGVuY3J5cHRp b24gc2NoZW1lIGRlZmluZWQgaW4gYW4gUkZDLCBpbg0KPnBhcnRpY3VsYXIgaWYgaXQgaXMgYXMg Y29tcGV0aXRpdmUgd2l0aCB3ZWFrZXIgc29sdXRpb25zIHJlZ2FyZGluZw0KPmltcGxlbWVudGF0 aW9uYWwgZGlmZmljdWx0eSBhbmQgY29tcHV0YXRpb25hbCBlZmZpY2llbmN5IGFzIHRoaXMgb25l Lg0KPg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+PT09PT09DQo+DQo+DQo+Q2hlZXJzLA0KPlRpYm9y DQo+DQo+DQo+DQo+T24gMDQvMDcvMjAxNyAxNTo1MywgUGF0ZXJzb24sIEtlbm55IHdyb3RlOg0K Pj4gVGhhbmtzIGV2ZXJ5b25lIGZvciB0aGlzIGhlbHBmdWwgZGlzY3Vzc2lvbi4NCj4+IA0KPj4g SWYgeW91IHdhbnQgdG8gdXBkYXRlIHlvdXIgcmV2aWV3cyBpbiB0aGUgbGlnaHQgb2YgaXQsIHBs ZWFzZSBnbyBhaGVhZA0KPj5hbmQNCj4+IHJlc2VuZCB5b3VyIHJldmlld3MgaGVyZS4gSSdsbCB0 aGVuIGNvbGxhdGUgdGhlIHRocmVlIHJldmlld3Mgd2UgaGF2ZSB0bw0KPj4gdGhlIENGUkcgbGlz dC4NCj4+IA0KPj4gQ2hlZXJzDQo+PiANCj4+IEtlbm55IA0KPj4gDQo+PiBPbiAwNC8wNy8yMDE3 IDEzOjI3LCAiQ3J5cHRvLXBhbmVsIG9uIGJlaGFsZiBvZiBCam9lcm4gVGFja21hbm4iDQo+PiA8 Y3J5cHRvLXBhbmVsLWJvdW5jZXNAaXJ0Zi5vcmcgb24gYmVoYWxmIG9mIGJqb2Vybi50YWNrbWFu bkBpZWVlLm9yZz4NCj4+IHdyb3RlOg0KPj4gDQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4gT24gU3Vu LCBKdWwgMiwgMjAxNyBhdCAyOjM3IFBNLCBUaWJvciBKYWdlcg0KPj4+IDx0aWJvci5qYWdlckB1 cGIuZGU+IHdyb3RlOg0KPj4+DQo+Pj4NCj4+PiBPbiAwMS8wNy8yMDE3IDIwOjM0LCBCam9lcm4g VGFja21hbm4gd3JvdGU6DQo+Pj4+IFBsZWFzZSBmaW5kIG15IHJldmlldyBiZWxvdy4gSXQncyBh IG5pY2UgcGllY2Ugb2Ygd29yayBhbmQgb3ZlcmFsbCBpbg0KPj4+PiBxdWl0ZSBnb29kIHNoYXBl Lg0KPj4+Pg0KPj4+PiBBZnRlciBsb29raW5nIGF0IHRoZSBvdGhlciByZXZpZXdzOiBJIGRvIG5v dCBxdWl0ZSB1bmRlcnN0YW5kIFRpYm9yJ3MNCj4+Pj4gY29tbWVudCBvbiB0aGUgYml0LWxlbmd0 aCB2cy4gYnl0ZS1sZW5ndGgsIGdpdmVuIHRoYXQgdGhlIGRyYWZ0IHN0YXRlcw0KPj4+PiB0aGF0 IHRoZSBzY2hlbWUgdGFrZXMgImFyYml0cmFyeS1sZW5ndGggcGxhaW50ZXh0ICYgYWRkaXRpb25h bCBkYXRhDQo+Pj4+IGJ5dGUtc3RyaW5ncyIgLS0gYW5kIGZvciBtZSB0aGUgdGVybSAiYnl0ZS1z dHJpbmdzIiBtZWFucyB0aGF0IHRoZQ0KPj4+PiBieXRlLWxlbmd0aCBvZiB0aGUgc3RyaW5ncyBp cyBhbiBpbnRlZ2VyLg0KPj4+DQo+Pj4gSW5kZWVkLCB0aGlzIGlzIG9uZSBvZiB0aGUgc2VjdGlv bnMgdGhhdCBzdWdnZXN0cyB0aGF0IGl0IGlzIGltcGxpY2l0bHkNCj4+PiBhc3N1bWVkIHRoYXQg InZhbGlkIiBwbGFpbnRleHRzIGFuZCBBRCBoYXZlIGFsd2F5cyBhIGJ5dGUtbGVuZ3RoIHdoaWNo DQo+Pj4gaXMgYW4gaW50ZWdlci4NCj4+Pg0KPj4+IFdoYXQgSSBmb3VuZCAqcG90ZW50aWFsbHkq IGNvbmZ1c2luZyBpczoNCj4+Pg0KPj4+IC0gVGhlbiBpdCB3b3VsZCBhbHNvIGJlIHNvbWV3aGF0 IG1vcmUgaW50dWl0aXZlL2NvbnNpc3RlbnQgdG8gaW5jbHVkZQ0KPj4+IHRoZSBieXRlLWxlbmd0 aCBvZiBwbGFpbnRleHQgYW5kIEFEIGluIHRoZSBsZW5ndGggYmxvY2suIFRoZSBjdXJyZW50DQo+ Pj4gZHJhZnQgaW5jbHVkZXMgdGhlIGJpdC1sZW5ndGguIChUaGlzIGlzIG9mIGNvdXJzZSB0ZWNo bmljYWxseSBmaW5lIGFuZA0KPj4+IGVzc2VudGlhbGx5IGp1c3QgYSBkaWZmZXJlbnQgbm90YXRp b24sIGJ1dCAqY291bGQqIGJlIGNvbmZ1c2luZy4pDQo+Pj4NCj4+PiAtIEFsc28gdGhlIGV4YW1w bGUgaW4gU2VjdGlvbiA4IG1lbnRpb25zIHRoZSBiaXQtbGVuZ3RoLg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+DQo+Pj4gSSBmdWxseSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGJlIGxlc3MgYW1iaWd1b3VzIHRv IGRvIHRoZXNlIGNvbXB1dGF0aW9ucw0KPj4+aW4NCj4+PiB0ZXJtcyBvZiBieXRlLWxlbmd0aC4g SSBkbyBub3Qgc2VlIGFueSBhZHZhbnRhZ2Ugb2YgaGF2aW5nIHRoZSBzY2hlbWUNCj4+PiBvcGVy YXRlIGludGVybmFsbHkgaW4gdGVybXMgb2YgYml0LWxlbmd0aCwgd2hlbiBvbmx5IGJ5dGUtbGVu Z3RoDQo+Pj5zdHJpbmdzDQo+Pj4gYXJlIGFsbG93ZWQuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+ PiAtIEl0IHdvdWxkIGFsc28gbWFrZSBzZW5zZSB0byBsZXQgdGhlIGVuY3J5cHRpb24gYWxnb3Jp dGhtIGFib3J0LCBpZg0KPj4+dGhlDQo+Pj4gbGVuZ3RocyBvZiBwbGFpbnRleHRzIGFuZCBBRCBh cmUgbm90IGEgbXVsdGlwbGUgb2YgOCBiaXRzIChhbmQgb25lDQo+Pj5jb3VsZA0KPj4+IGlnbm9y ZSB0aGlzIGNoZWNrIGluIGFwcGxpY2F0aW9ucyB3aGVyZSB0aGlzIGlzIGd1YXJhbnRlZWQgYnkg dGhlDQo+Pj4gZW52aXJvbm1lbnQgLSBidXQgdGhpcyBpcyBvZiBjb3Vyc2Ugc29tZXRoaW5nIHRo YXQgb25seSB0aGUgYXBwbGljYXRpb24NCj4+PiBkZXZlbG9wZXIgY2FuIGRlY2lkZSkuDQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4NCj4+PiBBZ3JlZWQuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBCZXN0 LA0KPj4+IEJqw7ZybiANCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+IA0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IENyeXB0by1w YW5lbCBtYWlsaW5nIGxpc3QNCj4+IENyeXB0by1wYW5lbEBpcnRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jcnlwdG8tcGFuZWwNCj4+IA0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Q3J5cHRvLXBhbmVs IG1haWxpbmcgbGlzdA0KPkNyeXB0by1wYW5lbEBpcnRmLm9yZw0KPmh0dHBzOi8vd3d3LmlydGYu b3JnL21haWxtYW4vbGlzdGluZm8vY3J5cHRvLXBhbmVsDQoNCg== From nobody Wed Jul 5 00:36:43 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95066131A98 for ; Wed, 5 Jul 2017 00:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] 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 lOBxxD_XjPPY for ; Wed, 5 Jul 2017 00:36:38 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20071.outbound.protection.outlook.com [40.107.2.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003B7131A86 for ; Wed, 5 Jul 2017 00:36:37 -0700 (PDT) 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=2oEI1civ4QojApz7RuF29x2scgnl8DFWA1YksS18Oco=; b=oHgu8309MAgR7ZhR0mZb2ktsDX/f0WXBO83NB/z8C4ayeHALSsXV3vmfM6PJMrWpsiYNSoilxOzVxs16cmKKBgo+PLo5HqBoLm3a+zMfsams+vN9/2kckK14THgFNprokaXpkUp7i27iTDHWgYuEhmza1F2yREg/h4zGO/Q5qwQ= 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_128_CBC_SHA256_P256) id 15.1.1220.11; Wed, 5 Jul 2017 07:36:35 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1220.018; Wed, 5 Jul 2017 07:36:34 +0000 From: "Paterson, Kenny" To: Bjoern Tackmann CC: "crypto-panel@irtf.org" Thread-Topic: [Crypto-panel] Review of AES-GCM-SIV Thread-Index: AQHS5eUMXPqksT4BkEOlrKXEsk18RKI/ZZ4AgAEupACAAyHcAIAAKM+AgAACKACAASZaAA== Date: Wed, 5 Jul 2017 07:36:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: ieee.org; dkim=none (message not signed) header.d=none;ieee.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [134.219.227.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:baDVsy7fl32pbsvgHrlZCOs38FiW+IdEY7BVcoXbHanGjvK9/v9YqoKxLrYfjSaWj52qh9zCcNL4NSwTl9hJzSrKzefM3R6ycqwWDheEhbHbG2mAnlLLqnLdxGPuaz0jaWnrWVNhiMzNiK32OXS4UwyHkVERlysKjpZ7A9EfCUuJgWfucItxOXfRz+rRM5ulvsc6BE7qIeDBSZArsuyB32L23FMj87PDiOcHM72LeFQZtzynTuTWrm+8jH4drK44nsjnQnGRO38yu1EHTAoe/yCjdU9+g12UI/l0egoiOiURXkClsO/NWoqEAJsn4ONlBnBHzPk/zmiKCO3O+GBAqybYwjAglWU1YqhyppeF+GSnuGmjf2C9TrrDR8OvYpPUJFT1q1tsZSRBz86CQhSU1Yrg/ZtYDqIi3pTvcJig/nojYVdfpLwds+5+Pvek3cOvmO82KHgzxNXOIkh5AzGg9gZ5uWHpmx61sFLbIl3WIXBjOC1G2kafzyxnlrRTz0HuBhZrgKMLc1c0FZRYyxryIqirQ/U8wN8d7n3UvcO7AuR0mQqQGbTsWoB42zV12FoQjAUspyC4aF1L5NsA1U0+41Z7qhFBxK92LAU4IBO/y9FxqchE2dLb8ui7YLByiOSvPmfpXDcUMBeee5dFsbHNm3nslSSgEn7anye1RkrdkAvJ9RJ1cakrTmNdhUtPAaY95+4TMyY2eyHPWZzSQAPVSg1iWwSKy7gl9VbIb1kYrfmtqxBsRBCZm1cRAue4HiBpdtffp/z+j7MTIdzypFKnZrduRAnC4YgbLL6ZQJjTjaw= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39850400002)(39400400002)(39410400002)(39840400002)(24454002)(377454003)(53754006)(229853002)(25786009)(72206003)(6436002)(189998001)(478600001)(14454004)(53546010)(6116002)(3660700001)(4326008)(2900100001)(3280700002)(102836003)(3846002)(4001350100001)(86362001)(5660300001)(5250100002)(6486002)(83506001)(6506006)(76176999)(6916009)(42882006)(54356999)(2950100002)(99286003)(2906002)(6246003)(230783001)(66066001)(93886004)(50986999)(8936002)(81166006)(53936002)(110136004)(8676002)(74482002)(38730400002)(305945005)(7736002)(36756003)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 9acd09f0-6fd1-442a-6ade-08d4c3789040 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1906; x-ms-traffictypediagnostic: AM4PR0301MB1906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(278428928389397)(236129657087228)(192374486261705)(48057245064654)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201702281529075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1906; x-forefront-prvs: 0359162B6D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <634DA0EA7586CD43AA5DC6CEB89FCC7E@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 07:36:34.8308 (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: Subject: Re: [Crypto-panel] Review of AES-GCM-SIV X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 07:36:40 -0000 VGhhbmtzIEJqb2VybiBmb3IgdGhpcyByZXZpc2lvbi4NCg0KT24gMDQvMDcvMjAxNyAxNjowMSwg IkJqb2VybiBUYWNrbWFubiIgPGJqb2Vybi50YWNrbWFubkBpZWVlLm9yZz4gd3JvdGU6DQoNCj5U aGFua3MsIEtlbm55LCBhbmQgcGxlYXNlIGZpbmQgbXkgdXBkYXRlZCByZXBvcnQgYmVsb3cuDQo+ DQo+DQo+PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPlN1bW1hcnk6IEFsbW9zdCByZWFkeQ0K Pg0KPg0KPk1ham9yIGlzc3Vlczogbm9uZQ0KPg0KPg0KPk1pbm9yIGlzc3VlczoNCj4NCj4NCj5J IGZvdW5kIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgZW5jcnlwdGlvbiBtZXRob2QgY29tcHJlaGVu c2libGUgYnV0IGEgYml0DQo+dG9vIGluZm9ybWFsLiBNYXliZSBhIHBzZXVkby1jb2RlIGRlc2Ny aXB0aW9uIG1heSBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZD8NCj4NCj4NCj5JbiB0aGF0IGRlc2Ny aXB0aW9uLCBJIHN0dW1ibGVkIHBhcnRpY3VsYXJseSBvdmVyIHRoZSDigJxfbGVuZ3RoIGJsb2Nr X+KAnSAtDQo+d2h5IHRoZSB1bmRlcnNjb3Jlcz8gQWxzbywgSSB0aGluayBpdCB3b3VsZCBtYWtl IHNlbnNlIHRvIGV4cGxpY2l0bHkNCj5jbGFyaWZ5IHRoYXQgdGhlIDMyLWJpdCBjb3VudGVyIHZh bHVlIGZvciB0aGUgQ1RSIHBhcnQgaXMgZXhwbGljaXRseQ0KPmFsbG93ZWQgdG8gb3ZlcmZsb3cu DQo+DQo+DQo+T25lIGFzcGVjdCB0aGF0IHJlYWQgYSBiaXQgYXJiaXRyYXJ5IHRvIG1lIHdhcyB0 aGUgZG9tYWluIHNlcGFyYXRpb24gZm9yDQo+QUVTIGJ5IHNldHRpbmcgdGhlIGZpcnN0IGJpdCBv ZiB0aGUgbGFzdCBieXRlIHRvIDEvMCwgYW5kIGluIHBhcnRpY3VsYXINCj50aGF0IHNlZW1lZCBh IGJpdCB3YXN0ZWZ1bCBzaW5jZSBpdCBpcyBldmFsdWF0ZWQgb25seSBvbmNlIHdpdGggdGhlIGJp dA0KPnNldCB0byAwLiBXb3VsZG4ndCBpdCBiZSBzaW1wbGVyIChhbmQNCj4gcG9zc2libHkgZXZl biB3aXRoIGJldHRlciBzZWN1cml0eSwgYnV0IGF0IHRoZSBjb3N0IG9mIGxpbWl0aW5nIHRoZQ0K Pmxlbmd0aCB0byAyXjMyIC0gMSBibG9ja3MpIHRvIG5vdCBmaWRkbGUgd2l0aCB0aGUgYml0cyBi dXQganVzdCB1c2UgdGhlDQo+Zmlyc3QgY291bnRlci1ibG9jayB0byBjb21wdXRlIHRoZSB0YWc/ IE5vdGUgdGhhdCB0aGlzIHdvdWxkIGNlcnRhaW5seQ0KPnJlcXVpcmUgcmUtZG9pbmcgc29tZSBw YXJ0IG9mIHRoZSBzZWN1cml0eSBhbmFseXNpcywNCj4gYW5kIHRoZSBnYWlucyBzZWVtIG1vZGVy YXRlLCBzbyBJ4oCZbSBmaW5lIHdpdGggdGhpcyBjb21tZW50IGJlaW5nDQo+ZGlzY2FyZGVkLiAo SnVzdCB3YW50ZWQgdG8gbWFrZSBzdXJlIGl0IGlzIGRpc2NhcmRlZCBjb25zY2lvdXNseS4pDQo+ DQo+DQo+QWZ0ZXIgZGlzY3Vzc2lvbiB3aXRoIHRoZSBvdGhlciByZXZpZXdlcnM6IFRoZSBkcmFm dCBpcyBhbWJpZ3VvdXMgd2l0aA0KPnJlc3BlY3QgdG8gYnl0ZS1zdHJpbmdzIHZzLiBiaXQtc3Ry aW5ncy4gTXkgaW50ZXJwcmV0YXRpb24sIHN0ZW1taW5nIGZyb20NCj50aGUgYmVnaW5uaW5nIG9m IFNlY3Rpb24gNCBleHBsaWNpdGx5IG1lbnRpb25pbmcgYnl0ZS1zdHJpbmdzLCBpcyB0aGF0DQo+ YWxsIHN0cmluZ3MgbXVzdCBiZSBwcm9wZXJseSBieXRlLWFsaWduZWQuDQo+IEJ1dCBnaXZlbiB0 aGF0LCB1c2luZyBieXRlbGVuKGFkZGl0aW9uYWxfbGVuZ3RoKSAqIDggYW5kDQo+Ynl0ZWxlbihw bGFpbnRleHQpICogOCwgaS5lLiBiaXQtbGVuZ3RoLCBpcyBjb25mdXNpbmcuIElmIHRoZSBkcmFm dCBpcw0KPnN1cHBvc2VkIHRvIGRlYWwgd2l0aCBieXRlLWFsaWduZWQgc3RyaW5ncyBvbmx5ICh3 aGljaCBhcHBlYXJzDQo+cHJhY3RpY2FsbHkgc2Vuc2libGUpLCB0aGVuIHRoaXMgc2hvdWxkIGJl IG1hZGUgY2xlYXIgaW4gdGhlIGRvY3VtZW50LA0KPiBhbmQgYnl0ZS1sZW5ndGggc2hvdWxkIGJl IHVzZWQgaW4gdGhlIGVuY3J5cHRpb24uIE90aGVyd2lzZSwgdGhlDQo+YWxnb3JpdGhtcyBoYXZl IHRvIGJlIHNwZWNpZmllZCBtb3JlIGNsZWFybHkgZm9yIHRoZSBjYXNlIG9mIGJpdC1zdHJpbmdz DQo+dGhhdCBhcmUgbm90IGJ5dGUtYWxpZ25lZC4gSW4gZWl0aGVyIGNhc2UsIHRoZSBkcmFmdCBz aG91bGQgYmUgY2xhcmlmaWVkDQo+aW4gdGhpcyByZXNwZWN0Lg0KPg0KPg0KPg0KPg0KPg0KPk9u IFR1ZSwgSnVsIDQsIDIwMTcgYXQgMzo1MyBQTSwgUGF0ZXJzb24sIEtlbm55DQo+PEtlbm55LlBh dGVyc29uQHJodWwuYWMudWs+IHdyb3RlOg0KPg0KPlRoYW5rcyBldmVyeW9uZSBmb3IgdGhpcyBo ZWxwZnVsIGRpc2N1c3Npb24uDQo+DQo+SWYgeW91IHdhbnQgdG8gdXBkYXRlIHlvdXIgcmV2aWV3 cyBpbiB0aGUgbGlnaHQgb2YgaXQsIHBsZWFzZSBnbyBhaGVhZCBhbmQNCj5yZXNlbmQgeW91ciBy ZXZpZXdzIGhlcmUuIEknbGwgdGhlbiBjb2xsYXRlIHRoZSB0aHJlZSByZXZpZXdzIHdlIGhhdmUg dG8NCj50aGUgQ0ZSRyBsaXN0Lg0KPg0KPkNoZWVycw0KPg0KPktlbm55DQo+DQo+T24gMDQvMDcv MjAxNyAxMzoyNywgIkNyeXB0by1wYW5lbCBvbiBiZWhhbGYgb2YgQmpvZXJuIFRhY2ttYW5uIg0K PjxjcnlwdG8tcGFuZWwtYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YNCj5iam9lcm4udGFj a21hbm5AaWVlZS5vcmc+DQo+d3JvdGU6DQo+DQo+PkhpIGFsbCwNCj4+DQo+Pk9uIFN1biwgSnVs IDIsIDIwMTcgYXQgMjozNyBQTSwgVGlib3IgSmFnZXINCj4+PHRpYm9yLmphZ2VyQHVwYi5kZT4g d3JvdGU6DQo+Pg0KPj4NCj4+T24gMDEvMDcvMjAxNyAyMDozNCwgQmpvZXJuIFRhY2ttYW5uIHdy b3RlOg0KPj4+IFBsZWFzZSBmaW5kIG15IHJldmlldyBiZWxvdy4gSXQncyBhIG5pY2UgcGllY2Ug b2Ygd29yayBhbmQgb3ZlcmFsbCBpbg0KPj4+IHF1aXRlIGdvb2Qgc2hhcGUuDQo+Pj4NCj4+PiBB ZnRlciBsb29raW5nIGF0IHRoZSBvdGhlciByZXZpZXdzOiBJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0 YW5kIFRpYm9yJ3MNCj4+PiBjb21tZW50IG9uIHRoZSBiaXQtbGVuZ3RoIHZzLiBieXRlLWxlbmd0 aCwgZ2l2ZW4gdGhhdCB0aGUgZHJhZnQgc3RhdGVzDQo+Pj4gdGhhdCB0aGUgc2NoZW1lIHRha2Vz ICJhcmJpdHJhcnktbGVuZ3RoIHBsYWludGV4dCAmIGFkZGl0aW9uYWwgZGF0YQ0KPj4+IGJ5dGUt c3RyaW5ncyIgLS0gYW5kIGZvciBtZSB0aGUgdGVybSAiYnl0ZS1zdHJpbmdzIiBtZWFucyB0aGF0 IHRoZQ0KPj4+IGJ5dGUtbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIGlzIGFuIGludGVnZXIuDQo+Pg0K Pj5JbmRlZWQsIHRoaXMgaXMgb25lIG9mIHRoZSBzZWN0aW9ucyB0aGF0IHN1Z2dlc3RzIHRoYXQg aXQgaXMgaW1wbGljaXRseQ0KPj5hc3N1bWVkIHRoYXQgInZhbGlkIiBwbGFpbnRleHRzIGFuZCBB RCBoYXZlIGFsd2F5cyBhIGJ5dGUtbGVuZ3RoIHdoaWNoDQo+PmlzIGFuIGludGVnZXIuDQo+Pg0K Pj5XaGF0IEkgZm91bmQgKnBvdGVudGlhbGx5KiBjb25mdXNpbmcgaXM6DQo+Pg0KPj4tIFRoZW4g aXQgd291bGQgYWxzbyBiZSBzb21ld2hhdCBtb3JlIGludHVpdGl2ZS9jb25zaXN0ZW50IHRvIGlu Y2x1ZGUNCj4+dGhlIGJ5dGUtbGVuZ3RoIG9mIHBsYWludGV4dCBhbmQgQUQgaW4gdGhlIGxlbmd0 aCBibG9jay4gVGhlIGN1cnJlbnQNCj4+ZHJhZnQgaW5jbHVkZXMgdGhlIGJpdC1sZW5ndGguIChU aGlzIGlzIG9mIGNvdXJzZSB0ZWNobmljYWxseSBmaW5lIGFuZA0KPj5lc3NlbnRpYWxseSBqdXN0 IGEgZGlmZmVyZW50IG5vdGF0aW9uLCBidXQgKmNvdWxkKiBiZSBjb25mdXNpbmcuKQ0KPj4NCj4+ LSBBbHNvIHRoZSBleGFtcGxlIGluIFNlY3Rpb24gOCBtZW50aW9ucyB0aGUgYml0LWxlbmd0aC4N Cj4+DQo+Pg0KPj4NCj4+DQo+PkkgZnVsbHkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBsZXNzIGFt YmlndW91cyB0byBkbyB0aGVzZSBjb21wdXRhdGlvbnMgaW4NCj4+dGVybXMgb2YgYnl0ZS1sZW5n dGguIEkgZG8gbm90IHNlZSBhbnkgYWR2YW50YWdlIG9mIGhhdmluZyB0aGUgc2NoZW1lDQo+Pm9w ZXJhdGUgaW50ZXJuYWxseSBpbiB0ZXJtcyBvZiBiaXQtbGVuZ3RoLCB3aGVuIG9ubHkgYnl0ZS1s ZW5ndGggc3RyaW5ncw0KPj5hcmUgYWxsb3dlZC4NCj4+DQo+Pg0KPj4NCj4+DQo+Pi0gSXQgd291 bGQgYWxzbyBtYWtlIHNlbnNlIHRvIGxldCB0aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gYWJvcnQs IGlmIHRoZQ0KPj5sZW5ndGhzIG9mIHBsYWludGV4dHMgYW5kIEFEIGFyZSBub3QgYSBtdWx0aXBs ZSBvZiA4IGJpdHMgKGFuZCBvbmUgY291bGQNCj4+aWdub3JlIHRoaXMgY2hlY2sgaW4gYXBwbGlj YXRpb25zIHdoZXJlIHRoaXMgaXMgZ3VhcmFudGVlZCBieSB0aGUNCj4+ZW52aXJvbm1lbnQgLSBi dXQgdGhpcyBpcyBvZiBjb3Vyc2Ugc29tZXRoaW5nIHRoYXQgb25seSB0aGUgYXBwbGljYXRpb24N Cj4+ZGV2ZWxvcGVyIGNhbiBkZWNpZGUpLg0KPj4NCj4+DQo+Pg0KPj4NCj4+QWdyZWVkLg0KPj4N Cj4+DQo+Pg0KPj4NCj4+QmVzdCwNCj4+QmrDtnJuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQoNCg==