From nobody Thu Nov 17 19:45:16 2022 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EEAC14F740 for ; Thu, 17 Nov 2022 19:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H32zHwYV63Nc for ; Thu, 17 Nov 2022 19:45:11 -0800 (PST) Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A865C14F72B for ; Thu, 17 Nov 2022 19:45:11 -0800 (PST) Received: by mail-qv1-f43.google.com with SMTP id s18so1007610qvo.9 for ; Thu, 17 Nov 2022 19:45:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FLiCVKYEmWxT7M7lYdPHqHPtC9Gvxx7FtU9Ce4oDOyU=; b=6vhpPvHzhaoeGocYMWjpaXC1eB5z7G1LmzXPFEDXgtX3pZ9pfz4gm/WHRpIYew6QSv Ws5jHZAfXYYNfhPt/JOQV68pJxRw2rjbobj66F0SockzFH104VHEv70smTWOJ6E3Axy7 4XutOw8RDgtY94mcEANc3uWmRbe8ejdZgzqG0V0wNBOBGNSgqAHqPC1DoYU55swCYkks g1lPTSnRaqHXqRW9CdTf06euTK4w9eLirNo3pjruutQsqOqAuBqftLkSQUlwK5Q1RGIJ v1ryOpK9XAc0+7sDvdf44/aLDljIObA8sOpOiZ0SJ27hLBFYG17E5bD6b8R2mG6Yu5Lh oqEw== X-Gm-Message-State: ANoB5plRuTZBbgNHfJA4oK1Y1HruCzhkDabp6GIOR+hxrdYTqnyOTeOQ ZABRf6xx4WR+dwqb+HKy9sBJsCGfqu4= X-Google-Smtp-Source: AA0mqf7ZmY+dl61AfqR6dP3NV2ZzlpCenv5TOTmviV5uKytKwYADQg8n5Ut/ZdTLSOU4wAnVZnqtZQ== X-Received: by 2002:a0c:e30e:0:b0:4b1:9f75:561c with SMTP id s14-20020a0ce30e000000b004b19f75561cmr5258124qvl.120.1668743109929; Thu, 17 Nov 2022 19:45:09 -0800 (PST) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com. [209.85.160.178]) by smtp.gmail.com with ESMTPSA id c12-20020ac8054c000000b003995f6513b9sm1350384qth.95.2022.11.17.19.45.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Nov 2022 19:45:09 -0800 (PST) Received: by mail-qt1-f178.google.com with SMTP id l2so2436117qtq.11 for ; Thu, 17 Nov 2022 19:45:09 -0800 (PST) X-Received: by 2002:ac8:5ed5:0:b0:3a4:f479:e147 with SMTP id s21-20020ac85ed5000000b003a4f479e147mr5225278qtx.243.1668743109365; Thu, 17 Nov 2022 19:45:09 -0800 (PST) MIME-Version: 1.0 References: <9901f3c9-7944-e8a0-d2e5-a0aced7cbc3b@mtg.de> <9d49e51a-e59f-657d-5630-a8b6c34fddc9@mtg.de> In-Reply-To: <9d49e51a-e59f-657d-5630-a8b6c34fddc9@mtg.de> From: Andrey Jivsov Date: Thu, 17 Nov 2022 19:44:57 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Falko Strenzke Cc: openpgp@ietf.org Content-Type: multipart/related; boundary="00000000000041f76705edb688d5" Archived-At: Subject: Re: [openpgp] Review of crypto-refresh 07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2022 03:45:15 -0000 --00000000000041f76705edb688d5 Content-Type: multipart/alternative; boundary="00000000000041f76605edb688d4" --00000000000041f76605edb688d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wouldn't prohibit key generation. Instead, I would fix the method, with the understanding that we are unlikely to see these curves used in practice. I should have mentioned that such handling of "overflow" is currently one of two FIPS-approved methods to generate a key, and that's the one that OpenSSL uses. I think most SW uses it, and I believe gnupg is in this category too. See FIPS 186-4 sec. B.4.2 Key Pair Generation by Testing Candidates. It is natural to overlay on top of it a condition for when we overflow into the next byte with a private scalar, and reject this candidate. If software passes an input random buffer that already satisfies the property of not having the top bit set, by providing ceil(log2(p)) bits of input entropy, then there is no code to add in this case. So, this is simple and efficient change at the byte level, that generalizes to all curves. On Thu, Nov 17, 2022 at 4:57 AM Falko Strenzke wrote: > Hi Andrey, > > I tend to recommend not to specify the tweaks you propose or any other > tweak to handle curves with this property, even though this would not be > per se a security problem. The problems that I see are: > > - enhanced complexity for implementations > - need for test vectors for this special case > - possibly increased difficulty for OpenPGP-based products to pass > security validations > > Further, I want to argue that the curves that are affected by this error > are mostly irrelevant to OpenPGP: > > - The curves that I listed are the only ones with this property that I am > aware of. Koblitz curves are generally hardly ever used, and the random > 160-bit curves can only be used for lightweight authentication. > - Probably new curves with this property could be created, if they follow > the "prime =3D sparse linear combination of powers of two" paradigm, as t= he > SECP curves do. But it seems no one has done this for a long time, and I > would not expect anyone will do this in the future. > > On this background it suffices in my opinion to require implementations t= o > gracefully reject these curves. However, that pertains only to key > generation, since, as far as I can see, the stored private key is the onl= y > scalar that is affected. So it could be specified that > > 1. an implementation MUST NOT create keys for curves where the base point > order is represented in one more octet than p. > 2. an implementation SHOULD perform all other operations with such curves= . > > The second point means that if an implementation ignores the first point > using one of the methods you propose or it receives a private from > elsewhere, it will still be interoperable with other implementations that > only need to perform the public operation with that curve. > > Regarding the second point it could still be discussed if performing > private operations should also be forbidden. > > Does that make sense? > > - Falko > Am 17.11.22 um 01:55 schrieb Andrey Jivsov: > > ## 9.2. ECC Curves for OpenPGP >> >> > The "Field Size (fsize)" column represents the field size of the group >> in number of octets, rounded up, such that [...] or scalars [...] for th= e >> curve can be represented in that many octets. >> >> The assumption that a scalar, i.e. a group element, always fits into an >> array long enough to hold a field element, is not correct: according to >> Hasse's theorem for Weierstra=C3=9F GF( p ) curves, we find for the base= point >> order N >> >> N =E2=89=A4 p + 2 =E2=88=9Ap + 1 >> >> Thus, depending on the curve, scalars such as the private key can be one >> bit longer than the field size, and thus also need one more octet. >> secp160k1, secp160r1, secp160r2, and secp224k1 are examples of a domain >> parameter sets where the representation of N needs one more octet than p= . >> I do not think that there is a need (or desire) to correct the OpenPGP >> specification in this point. I would not expect that the need arises to >> support any new elliptic curves, and the ones listed above most likely a= re >> not desired to be supported at all. >> But I think a note should be given in the quoted section (or another >> appropriate place) regarding this restriction, as an OpenPGP implementat= ion >> may behave undefined when attempting to use it with any of the curves >> listed above (in an extension implementation of any kind). Implementatio= ns >> should be prepared to reject curves with this property for security reas= ons. >> > > The probability to hit this condition is at most 2^-80 for these new > curves. > > When this condition is known to occur, the key's security strength is onl= y > 40 bits. In general, we don't need to special-case odd key values, as the= y > are expected to be within the key space. > > However, in this case there will need to be special processing due to the > overflow into the next 64-bit word (or a byte at least). This may result = in > a side channel information, either due to time needed to process this new > condition, new code path, or even the key size on disk. > > For these reasons I think the best fix for this is to treat the overflow > of private value over log2(p) bits as an error. If detected, the key shou= ld > be regenerated. > > This error is an unfortunate side effect of supporting new ECC curves. > However, the error handling can be hidden inside the key generation routi= ne > with e.g. a maximum loop count over key generation fixed at 2. > Specifically, if we detect this condition, generate again, and if this > fails, return a key generation error to the higher level. > > > -- > > *MTG AG* > Dr. Falko Strenzke > Executive System Architect > > Phone: +49 6151 8000 24 > E-Mail: falko.strenzke@mtg.de > Web: mtg.de > > > *MTG Exhibitions 2022 =E2=80=93 Let=C2=B4s meet again!* > ------------------------------ > > > MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany > Commercial register: HRB 8901 > Register Court: Amtsgericht Darmstadt > Management Board: J=C3=BCrgen Ruf (CEO), Tamer Kemer=C3=B6z > Chairman of the Supervisory Board: Dr. Thomas Milde > > This email may contain confidential and/or privileged information. If you > are not the correct recipient or have received this email in error, > please inform the sender immediately and delete this email. Unauthorised > copying or distribution of this email is not permitted. > > Data protection information: Privacy policy > > --00000000000041f76605edb688d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wouldn't prohibit key generation. Instead, I wo= uld fix the method, with the understanding that we are unlikely to see thes= e curves used in practice.

I should have ment= ioned that such handling of "overflow" is currently one of two FI= PS-approved methods to generate a key, and that's the one that OpenSSL = uses. I think most SW uses it, and I believe gnupg is in this category too.=

See FIPS 186-4 sec. B.4.2 Key Pair Generatio= n by Testing Candidates. It is natural to overlay on top of it a condition = for when we overflow into the next byte with a private scalar, and reject t= his candidate.

If software passes an input ra= ndom buffer that already satisfies the property of not having the top bit s= et, by providing ceil(log2(p)) bits of input entropy, then there is no code= to add in this case. So, this is simple and efficient change at the byte l= evel, that generalizes to all curves.


On Thu, = Nov 17, 2022 at 4:57 AM Falko Strenzke <falko.strenzke@mtg.de> wrote:
=20 =20 =20

Hi Andrey,

I tend to recommend not to specify the tweaks you propose or any other tweak to handle curves with this property, even though this would not be per se a security problem. The problems that I see are:

- enhanced complexity for implementations
- need for test vectors for this special case
- possibly increased difficulty for OpenPGP-based products to pass security validations

Further, I want to argue that the curves that are affected by this error are mostly irrelevant to OpenPGP:

- The curves that I listed are the only ones with this property that I am aware of. Koblitz curves are generally hardly ever used, and the random 160-bit curves can only be used for lightweight authentication.
- Probably new curves with this property could be created, if they follow the "prime =3D sparse linear combination of powers of two= " paradigm, as the SECP curves do. But it seems no one has done this for a long time, and I would not expect anyone will do this in the future.

On this background it suffices in my opinion to require implementations to gracefully reject these curves. However, that pertains only to key generation, since, as far as I can see, the stored private key is the only scalar that is affected. So it could be specified that

1. an implementation MUST NOT create keys for curves where the base point order is represented in one more octet than p.
2. an implementation SHOULD perform all other operations with such curves.

The second point means that if an implementation ignores the first point using one of the methods you propose or it receives a private from elsewhere, it will still be interoperable with other implementations that only need to perform the public operation with that curve.

Regarding the second point it could still be discussed if performing private operations should also be forbidden.

Does that make sense?

- Falko

Am 17.11.22 um 01:55 schrieb Andrey Jivsov:
## 9.2. ECC Curves for OpenPGP
> The "Field Size (fsize)" column represents the f= ield size of the group in number of octets, rounded up, such that [...] or scalars [...] for the curve can be represented in that many octets.

The assumption that a scalar, i.e. a group element, always fits into an array long enough to hold a field element, is not correct: according to Hasse's theorem for Weierstra=C3= =9F GF( p ) curves, we find for the base point order N

=C2=A0 N =E2=89=A4 p + 2 =E2=88=9Ap + 1
=C2=A0
Thus, depending on the curve, scalars such as the private key can be one bit longer than the field size, and thus also need one more octet. secp160k1, secp160r1, secp160r2, and secp224k1 are examples of a domain parameter sets where the representation of N needs one more octet than p.
I do not think that there is a need (or desire) to correct the OpenPGP specification in this point. I would not expect that the need arises to support any new elliptic curves, and the ones listed above most likely are not desired to be supported at all.
But I think a note should be given in the quoted section (or another appropriate place) regarding this restriction, as an OpenPGP implementation may behave undefined when attempting to use it with any of the curves listed above (in an extension implementation of any kind). Implementations should be prepared to reject curves with this property for security reasons.

The probability to hit this condition is at most 2^-80 for these new curves.

When this condition is known to occur, the key's security strength is only 40 bits. In general, we don't need to special-case odd key values, as the= y are expected to be within the key space.

However, in this case there will need to be special processing due to the overflow into the next 64-bit word (or a byte at least). This may result in a side channel information, either due to time needed to process this new condition, new code path, or even the key size on disk.

For these reasons I think the best fix for this is to treat the overflow of private value over log2(p) bits as an error. If detected, the key should be regenerated.

This error is an unfortunate side effect=C2=A0 of supporting new ECC curves. However, the error handling can be hidden inside the key generation routine with e.g. a maximum loop count over key generation fixed at 2. Specifically, if we detect this condition, generate again, and if this fails, return a key generation error to the higher level.


--00000000000041f76605edb688d4-- --00000000000041f76705edb688d5 Content-Type: image/png; name="XmLRX00g0iPODZWI.png" Content-Disposition: inline; filename="XmLRX00g0iPODZWI.png" Content-Transfer-Encoding: base64 Content-ID: <18488c91ee17afac5051> X-Attachment-Id: 18488c91ee17afac5051 iVBORw0KGgoAAAANSUhEUgAAAIMAAACMCAMAAABoFeqBAAAC/VBMVEX///8dHRsAT58Acr0Acr4A c8AAcLomJiT29vZYWFcAcbz6/P79/f0Aj9P1+fzs7OsAlNYAb7lCQkEqKigAkdS4uLcAUaP8/v/w 9vsAdMILdbt3d3Xk5OSVw+LOzs4MWqcBUqbH3+8ApeUBm9wAjdEEcbkAbrcAl9kAldcAi9AAgccP eL0Ic7oAarUAZrEJXqsLXKqDg4J5eXg5OTcjIyEfHx36+vrp8/nl7/fz8/Pg4OAAoeAAnt4AmdrT 09IAh8w4jsgbfr8CZK8HYKxjY2L7+/vs9fru7u7m5uZVns8Ais4AhcsAhMkfgMEHVaQ3NzXN4/G7 2OzY2NdhptNOm87Ly8oohcMkg8IVe78IV6ZSUlA8PDo1NTQzMzEtLSshIR/9///y+Pzm8fnT5vPJ 4PCu0enR0dBBk8rDw8MEYq2mpqb4+PjX6fTQ5fKy1OqGut1srNZFlcvIyMgAf8VJgbuFhYRycnHh 7ve/2+231+vp6emmy+Wdx+QAo+J9tdt5s9laodEsiMS/v74Aa7ezs7Ikaa+enp2Xl5aMjIptbWxe Xl1NTUtKSklHR0Xc6/XJ2uuSweGKvd4AnN0AjtM8kMgyjMcAe8PBwcACdr62trYzcrKpqamPj416 enk/Pz3q+P3k9vzY8PqB1fMDr+4Aq+sAqOinzeegyeVwuuGBt9za2tmaudlgrNgvn9dyrtZvrdbU 1NNJms52ocxVl8pik8Surq4GYa4aYqoBUKGTk5KAgH9WVlQvLy0iIiD3+v3e7fbw8PDD3e6n1+5S wOqUy+gSrui60OWZxeKvyOEgqeGMtdiLr9RmqNR+ps/GxsW8vLsGZLKjo6J0dHPO7vuy4/aN2fXX 5PC33fBRxvCP0e7t7ew/t+cJqOR9v+Mtr+MhreNltt8fpt8Uot4Sl9bU1NRunMkAeMjE6Pbg6vTg 6fPb5vKa1u9exu6s1uxmxuxuw+mkwt8Rntzc3NtTp9d+qtIVkc8djMoLfMBUib8+ercac7cicrUu cLETZbENXqqqxR9rAAAI2ElEQVR42uzV3UtTYRzA8d9RsGRubXDYLCLX2dzLgflyIVa6FkpFnnUR RRd544gICy9iQ/AivFhedBHCRiIGOTcVwU1IVw66EdPwhUBQU1Hzjei9iF7pInrOc7RzBrv08dw8 n3/gfHl+P34HKIqiKIqiKIqiKIqiKIrKQNMZiXSCquYWx3u4lc9vQDWmaCzGcbcruM0PoJb5WDcq qAy5Q5Y5UMfsOE6wuO16e8IHqojGthMcLGsdBTWYFrtxgkPPap1sH6jB9Kznf0JNeB1UgBq4kMUu JQhOtd6BQ9uoZ61Oj+Dlx0ANvuVK9Apaa41H4L0/y0ENkQ23nhUTvDzvHwNVLFl2Erz8qgZUEFn6 6mC1uMH/qBf2Vld0eW1tcmPTgRLCib7RhaarOsB0E8mOlt9T74CwuvntA23Xo0dYVW7iy0DKiJhb JoCsaA+Hz7O4Ctq0RXzbYc7CjAVkI2ZX5ITweh4oJHECjhg+BuTUfZTPs/VHAyi0FqSydhingZzO V9vn2eqscSbSnqHfmCU3BOqAmK7JCrd4G8PoD+GJg9Jrs6KhIx/IwA34POM/hPANlAZJN8izCEm3 UeD9/H1d2iwUDWaSs4AvFrSN4nn2t7X9ugAKDcNG+R36gaCuLb3TgxPa29svadKGYZRH4QOSRrfC Ak7ILjTkNJtAlh8wp6RJDLfCbjp94gCkW0gIAmo4mG2w2XLOHQWZb/CvGZ3qVGB3E+7k1t4rPQtp znzqi8fjF08VGlw2w6HrAwPNveUgaZ1OJl8818FuerCPQZ6OQAZ5TedtLlcw6HK5iv5M5QMhI7UM dgMyumYTv19UVFVVNTNEKuIII7kLGZVfDkoJ9U+qZ74DGScZSSOIbpbmIo3yjupuBcWE+vrq6uLi lvdAxPGHDPYYRPuvlDFMWe1h2KEZCuJXQAklJSWEzlLeP3bMJaaJIAzAfzO727I0bUpjsEWqHNpL axQrWHowbVIoHGpLKbQ8q4BAAGklovIIryhvCCQQJAJHCRx8JZqAqPGiiW89elbPxptREzsz27IV MXupJ79Ld2abzNeZ//9npjQmJwqoQxpuZCQ5xAyIwsGDR+5Cihh2TVaNUQUopA49IofDOBSOYIXK o58gFRSo1QXF/g23ug3nSM+BKuyw+jHWC4TTJYfJJGCFU5WvIBWMeq3W6tXqauswAIxbrWRhHnqt 3mOFQHj+Nj4Lp06degqpoEsmsAQAabIdXPlAsH2/Hzc49O0RpILcPBll3x4O0PvzCFXA21RKuDft PZ5wcGm1Yfycp9Vqx+MOyi9Xjx6trKw89OMppIpiV8LB39kyhZ+tS+WvN5Q795pXF65evfDCBqnj GHVIzs1k9ttsKkglWdQhuUb9nf8OlH/toLA3GQyG2/YCEKG2G2KQvmQed/T1rV0uAjGqx+ca98ff N+YINJ6Q6qAYmfCS0mlNyx2m6ZrfOXpxqhZ31qaNqpNHi3hYnU7HOW5AAlvkvMeoKQVKQIcEPmdL dPA/kO0gd+Eu+6Rc1JfRIj7wlvCMMTjk1LDG7EygrHl4VofMl4EyjzQs5fOsNAf3tEzMNq4ZnUQh QZ1IYh2h4NlLRe1zFj7UAIQ+PeKCA2vdwsSrFhhntkCDNIdN8ur4VNrkNpl77FCuJUNPpWWEydsp RWLWg7y+ETADPBsBzGU9r18XHUPrK9g7EmOyGAhtGWS4ewrIb5pOcpgsV4C6VU4K+z4QaES6wGk6 tAWVkNNHM2OcAxHnnOxLaQ41diD01ODWCt1gkxxGADMmw3SBwKVotAMIDU62GX92GBnsQqHzwqzD bgrfyzBXaGOCNFZOfvQrAYqJg6uQ3ITCeXk11CFhXE4m4hjsotTCDOLPW6zGB5np6TRAqVQvZCqV IOZAlxDmda4RvLBbQgrIXW0AbiuZ7CxD7I3CUF7eRErDvdbr12kM3Nb+2SF9EKGzeJtxsI6G2fPO UHOkHgjPGK7/5rxjvqxDdBR5I4uTZ1XjqA8LzWocE+P0Wftg5Yo6Wf3Nu+Xl5azjuxwyH6lUl0s4 NqDCi2Pmh4ZYHWIZZsgHmDnWZIoVEIbhXqogzvDDhMTqB3xaeB9vDuMfup0wrLv4GgTc76rkgipx SA46s96I9C9JLrZzJhMbGuwvc3Ksg9TOqI7TDAXuBDkNiqaDwKL2eJxpNxmgS0tXIxe39tWIStQW XYEmcu7dw8FnYXiGN0fIAKWciZ/34YwJcjwpi72O0KwNYOaWhrOUgkDB7aaTlKaNQiDYW8eWx65v tAHm67FaWYKL+fh1NW2EtVr5bof6SH9/mQdxg2fwZZXjnDP02nqNdxCtdLoEpwd5JpoJUvG3jlfH S+MbgPyL5Mk6+tpgaN0jL9qbeTRHHJgyIBQtIH09iMgx8g4VSMGw2NKJd6mTY3RN3gMcqMMPXj9Z lT3yAhrNKJgpdoAS1uIDEbYKVCHpGl+QIZfL/TRuaoVS0UlksmC3Ay4Ep4GgcrDmSwC+HYfB3xxO LDCSHGiNekfLNgnEiXxYIg5bgGkN0zoqUBoIdAPQGs2a20luLuynHXdYywzAk4EBX3xvQRIdvPi3 F+CUHSZLkKUU/iuo6VS0uUfqaKSCQK9OF41vTUxIhf84QMYcwMx4UDAdoIPV3QJCN0KBdMkOsoyV 0c1xbbygq700Uasm4gljzV2iSdtg4UJ034xo6D7Rx/PzJ0jRRuxNHJpO3tNAThrneX4WpK6FmAcK AOWYqCNM61eGmk54GcN5+uqLZvr1nP4JHYrRND+pb49akOccjph1hIbO1p/ICXBMhQ2koF7NEytM 2knnRKJjS6hW0x+EQDvPIGRxmhCjnxWytIJBnEWDGHMvvaiUIIbXh2IdoVKQhNK/ObUtFPNwbVeP YJZF48A7UrgpJ1S5gVLU79RrOJO5uSOxn5eFjBqT2dENlP1zntg3jOaSHJCOfWk0N8bylWJR2RrJ ze1qjSm5WxZbWloWDfkQp6j0WfbauUxxwerN7vMBJH3jRgP851d7cCAAAAAAIMjfepArAAAAgKMA MItH1YFWLGQAAAAASUVORK5CYII= --00000000000041f76705edb688d5--