From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 23 Jan 2025 08:56:26 -0800 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tb0VF-0000yJ-1w for bitcoindev@gnusha.org; Thu, 23 Jan 2025 08:56:26 -0800 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-29f9dcd1235sf754843fac.3 for ; Thu, 23 Jan 2025 08:56:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1737651379; cv=pass; d=google.com; s=arc-20240605; b=CAMzZPUeld7Rw3OKZjIOBxCpI3sCO3jTgjaA8kkqwwDQdVrH4Fs9MtvJ7rz9AURBE0 5s2tXoAsLncgeVaaQkmtwXlKrGsUaROPxNTluOrPyAXeOyEg31xzAhBkJKc/N1K4iHki pdXDBRuofk+B4vrCReSu7VmSPhClFU2gYIIULn5+eADbe22yiJ33Er0sIDNlvjVJpQjJ LoSVhDBUwBTpBVudXiEchvbTqx7hUing2Dia034m9IDMREgCyQfy6h86cjI7r0pkxpM+ pu3fa/Bw3euND16712s8mDiD6gG8sYuXvMT5mjgrhqHjEDV4kmXMzvFD2AO4Nb6WLnQY COPw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:sender:dkim-signature; bh=V84GiYixYFo1UQI29xkZSOKgv8X0/Y3aSqDwqOBtN7A=; fh=xhbugxYcjBiAu97jPwMR6zPtE2yqRMM+O/aiOBitdzY=; b=J2er4sVDeQNWSqKR/XM5iY2mMb7gSYfhW7QAQRRL9vP+JwWqVx2NtiIkhXU7ONO5ph Dsb44jpfv5rFGRnZKd30H5s16lpIblTPPhgvIW8jkHMU8I0ZqAea6XSix5So6IDw/Oqq sZ247C3Wafxu1VxFA244gCNr7E3SmMDrQheYqdDyGsL8c6a+bIdcxQvdjmg94h92mrI3 1h4WljU2/xgOzXd0ZC9ZxZmJ5TIbZFhMHAqr5rIEHYpVAmwCHaP/KZJyzGZFCl04r9i9 Y70EWmU0oGfaTcdlqNBv8JbPeRae2vp/ahfGyS1AVvH/q0aG4XWBn2o3tGW7yRt9b0lX y4Vg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=kjBeZj0J; spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1737651379; x=1738256179; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=V84GiYixYFo1UQI29xkZSOKgv8X0/Y3aSqDwqOBtN7A=; b=jf0WFTnOOyOeBfZbbSzdxzh9ZR/5eFx3tI6z8ZBr571fSHZub/U7ZF9M5ywuL2I9XX yvnSxAzUzLfdvq3MHtF6QC8FRKecAXciopdIH/1xHzyiwZhsaVJVGCmcDaK7dGQ8Wc3F cFneal0tR4kI1k/dA3uCpD87pvlUchO3x3nIqfzKBREpgPoBiAFlXleFD/yjT4H7/kdD eMI4jMnwZDoFhFRuw2mBbAVeGusEoIA053YwRUOwRQ/7CcuXLieQ9zscWWUQOjiVjtmN xoeA3UTrX4/eIedoceWlh/5cIg3vvM/zPI+eWSOdJnqqjefpwZYJWl1xd1fLUPHtIeXC 4LZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737651379; x=1738256179; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=V84GiYixYFo1UQI29xkZSOKgv8X0/Y3aSqDwqOBtN7A=; b=MOSvNS44nP0Zmx1PYS3RB49KYMVO3XKrv/uf3FOJ3aVXHLSCMboy8yhIHaIGfVLhPc w9To0Cvi6qzNpkAyBBtkyuWPS1LxqOH/lkXiuJbZ3WE1zaqAUVv9AyxouubWD7o944ZB M9A2HIYDFdn57khVfJQ9d7I2JhPkZpOFSLjWPmEwDEuygY2UnMYbVGOdLWbstD+st784 8lx19xnwV5LiXZDwR8sMfDlU2RlBNCN/IvAE/2xvGRijrZq+A4TcX0H0V4Y6NmvbJ3nB evl8iir4lF2w3WgF7gliY4FEckXTqLTooVHScqycO5i5msB9zDevmykfI/Wc3e56lAea +K3w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWbBQOcjGUsbL/j+TAp40FxJbI/s8PMOhnyrf4ookCci+nVf7l7KmXd84n2cfEHkspsjkYYpzGGcl8X@gnusha.org X-Gm-Message-State: AOJu0YzI/ZdbYe5/BBkXXEo6hL6UBIAFKRzrQ/xbPpilsKFfN2Dp8FLv t8+xrrQa2MI7JNlNZPydgcrjSatDzLZm3IzfOtak5RpeTdg9oEz7 X-Google-Smtp-Source: AGHT+IFSgW7RE8ykgjURrlkyy6qN7gRV9M3ZBpdbYxTbJd6U6kjkvT3TS+rctIVcTqlPWv0qps9dQQ== X-Received: by 2002:a05:6870:4f81:b0:296:e10f:af14 with SMTP id 586e51a60fabf-2b1c0b5d5d5mr13991643fac.39.1737651378865; Thu, 23 Jan 2025 08:56:18 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6870:ce02:b0:2a0:39b:9275 with SMTP id 586e51a60fabf-2b273395ed1ls446510fac.2.-pod-prod-02-us; Thu, 23 Jan 2025 08:56:14 -0800 (PST) X-Received: by 2002:a05:6808:4d0f:b0:3ec:b672:da89 with SMTP id 5614622812f47-3f19fc55c5fmr11907962b6e.14.1737651374815; Thu, 23 Jan 2025 08:56:14 -0800 (PST) Received: by 2002:a05:6808:1982:b0:3eb:6ba8:8c6b with SMTP id 5614622812f47-3f1e4e874bemsb6e; Thu, 23 Jan 2025 08:25:52 -0800 (PST) X-Received: by 2002:a05:6870:2dcb:b0:288:563b:e48d with SMTP id 586e51a60fabf-2b1c08b0e99mr16384253fac.10.1737649549653; Thu, 23 Jan 2025 08:25:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1737649549; cv=none; d=google.com; s=arc-20240605; b=UqG9uyRaEfGox4pYAZ6NLswPId3BEIhcXvNarC7z2le6dWGJNrnaL8h9EubVtvKDFL 7xwcp9AFs/lrMwTukAlZb+0k7F8etuNVmdFcLEvCWby5qS4eELAna/2r/7uT8ApPYoN8 qv4Ftp4+y+dJCr62rrgiCrLubx5LiGAXpexh4nNFZh/jqwfDO4hGp78Nv72CvkiJn1ti w8DFZGepeAEwqk4j6R4TMi9pjELkKgqCBD/NQuerOvZ6SWIXdBdO+IJbzzKZD83Tty7/ p19pTf6uS2AGVWm5TMn2l7B91c/9StxRLd5+2/BvPxW+1E4EeJd63TA7nXFgcI1qggCT ncYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:dkim-signature; bh=FytyV63Y4+uidSjGwaqtiXAk+MefwirtjM3FKAuv+6E=; fh=5HyPAjoX9Qu8lrKcSbvwAEk6+YgBxPNZL8TnxYb/Mm4=; b=fG7n1p8m6TP0AC1RbvJIUPDHzerWGqG4vgaYG2ONXY46UQfsZ92C6P84HpQk/DNc2t TjbsSDK1uUVYhQQjq2SVzX4fxhv2rULkRZ1cOSXu7M1Uu8OGF6+dMOfzht+SxAUi9zS6 U3p3skph96W/aaWHYM4twsja2vTx/wm4FJmSIlIQmqoVZDLziiTfFc3p8vECmCWqio+6 8HKFcY1+FQrMcdwRbKCBATfougZjqCEIJFK65QCYqYRU3FDB7VET/jfIAzg0J6QjcAC2 clC5oL0TeAZKTgwmJG3u/rBAFmf8uNdTY9VgDnFOizF2r9DMYsltTiEI1VsWODIeHxvW n8Ag==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=kjBeZj0J; spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com. [202.12.124.151]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-2b28f4a3dacsi11155fac.5.2025.01.23.08.25.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2025 08:25:49 -0800 (PST) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) client-ip=202.12.124.151; Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id C75291140152; Thu, 23 Jan 2025 11:25:48 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Thu, 23 Jan 2025 11:25:48 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgvddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughr peffhffvvefukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefrvghtvghrucfvoh guugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvghrnhep geeiueffffffjeeuieduueefleekuedvtdduvedtvedufeejleetjeehvdehtdfgnecuff homhgrihhnpehkrhhufidrihhopdhgihhthhhusgdrtghomhdpghhoohhglhgvrdgtohhm pdgsihhttghoihhnthgrlhhkrdhorhhgpdgrrhgthhhivhgvrdhishdpthhrvgiiohhrrd hiohdpphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdrohhrghdpnhgspg hrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsghithgtohhi nhguvghvsehgohhoghhlvghgrhhouhhpshdrtghomhdprhgtphhtthhopehnohhthhhinh hgmhhutghhseifohhosghlihhnghdrohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 23 Jan 2025 11:25:47 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 55B879FC46; Thu, 23 Jan 2025 16:25:46 +0000 (UTC) Date: Thu, 23 Jan 2025 16:25:46 +0000 From: Peter Todd To: Yuval Kogman Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4eHEatFitjb6mP2G" Content-Disposition: inline In-Reply-To: X-Original-Sender: pete@petertodd.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=kjBeZj0J; spf=pass (google.com: domain of pete@petertodd.org designates 202.12.124.151 as permitted sender) smtp.mailfrom=pete@petertodd.org Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) --4eHEatFitjb6mP2G Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 21, 2024 at 03:16:09PM +0100, Yuval Kogman wrote: I've been reviewing Wasabi and other coinjoin implementations lately and I believe that your focus on lite clients with regard to Wasabi is incorrect. Let's go through the issues: # Sybil Attacks In General Let's get this out of the way first. As AdamISZ correctly noted in his Jan 7th reply=C2=B9 to you, sybil attacks in general are impossible to entirely prevent in any coinjoin protocol where participation is done anonymously. It is always possible for an adversary to simply flood the mechanism with coinjoin requests to the point where they are the only counterparty. What we can do is make sybil attacks costly. In general, Wasabi's current usage with user-settable centralized coordinators does that pretty well: typical coinjoin rounds on the most popular coordinator, https://coinjoin.kruw.io, are transactions close to the standard size limits, with hundreds of inputs and outputs, mixing millions of USD dollars worth of BTC per round. A trivial sybil flood attacker would have to spend a lot of money and hold a lot of coins to simulate that. # Attacks via Failed Rounds Secondly, there's a potential class of attacks via failed rounds; attacks via failed rounds are potentially cheap/free attacks, as no transaction fees are actually spent. A Wabisabi coordinator gets desired inputs and outputs from clients, which would allow them to learn something about which inputs are linked to each other, and which outputs were desired by the owner of those inputs, if the coordinator succesfully "sybil" attacks the client. This class of attack might be interesting if Wasabi reused outputs after rounds failed, in subsequent rounds. I have not verified whether or not this is actually true; AdamISZ did confirm to me that JoinMarket does *not* do this, resulting in large gaps between used outputs in typical operation (it's normal for a high % of rounds to fail). This is an implementation issue due to gap-limits in HD wallet implementations; Silent Payment-like functionality may be a way around this problem. Additionally, this class of attack would impact pay-in-coinjoin functionality, where a payment address is added directly to a coinjoin. # Attacks via "Successful" Rounds If the round actually completes, the transaction fees must actually be paid, and liquidity must be provided. So if the attacker wants to do a cheaper attack than the "dumb" attack that is always possible, they must find a way to get other participants to provide that liquidity and pay those fees. You keep bringing up lite clients, e.g. in your statement that: Unfortunately only full nodes can verify that a coin really is unspent. If a user has configured Wasabi to use a full node this is ideal but probably would not be the norm. -https://github.com/WalletWasabi/WalletWasabi/issues/5533 Your focus is mistaken. In fact, it's irrelevant whether or not a txin in a proposed coinjoin round is spending a coin that exists or not. The reason is there are two possible situations: 1) The coin is either spent, or never existed at all. The round will fail as the transaction is invalid, meaning we're actually dealing with a form of Attack via Failed Round. As described above, these aren't particularly interesting attacks. =20 2) The coin is unspent, and the round succeeds. Whether or not a reduced-cost sybil was successful depends on round identity consistency. Clients do *not* need to validate coins in coinjoin rounds. Whether or not they're real is irrelevant, as the Bitcoin consensus itself validates this for you. ## Consistency of Round Identity As you mention, here we have a form of MITM attack, leveraged to perform a sybil attack: if Alice and Bob are coinjoining at the same time, from Alice's perspective, if the coordinator can pretend to be Bob, the coordinator can run two simultaneous "rounds" that are actually creating the same transactions. Thus the coordinator is re-using Bob's liquidity and fees to sybil attack Alice. This type of sybil even works with N participants: for each participant the coordinator can create a round with N-1 other fake participants, MITM attacking each simultaneously. Since Wasabi already has coin ownership proofs and distributes them, I believe we can easily validate the round ID consistency of a coinjoin transaction after it's fully signed and confirmed by simply validating that the signatures on the inputs were in fact signed by the pubkeys of the corresponding coin ownership and round ID proof. Wasabi already evaluates the anonymity score of outputs. So performing this check would simply mean that we're validating that the round was not sybilled, and the anonymity score is valid. The only question left for this technique is a cryptography one: Is it possible to create an alternate pubkey p', that such that a valid signature s signed by arbitrary pubkey p for message m, also validates for p' for signature s and message m? I believe the answer is no for schnorr. But I'm not a cryptography expert, and I may have missed something. # References 1) https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/oJTF8wqRDgAJ > ### WabiSabi >=20 > This affects Wasabi Wallet, and Ginger Wallet which is a fork of > Wasabi. Trezor Suite was also affected, but has subsequently removed > support for coinjoins[^18]. They too were made aware of various issues > and chose to ignore them, despite contributing the limited (read: > purely theater for privacy, only addressing hardware wallet specific > theft scenario) ownership proof verification. >=20 > Here the issue is more complex, but ultimately reduces to key > consistency as well. >=20 > In the protocol clients register their Bitcoin UTXOs independently. A > valid input registration request includes a BIP-322 ownership proof, > which commits to the so called *Round ID*. This in turn is a hash > commitment to the parameters of the round, including the server's > anonymous credential issuance parameters (analogous to a public key). >=20 > The parameters are obtained by polling the server for information > about active rounds. If inconsistent round IDs are given to clients, > this effectively partitions them, allowing deanonymization. >=20 > Although clients obtain the ownership proofs of other clients and > seemingly verify them, BIP-322 proofs verification requires knowledge > of the spent outputs `scriptPubKey` which light clients cannot obtain > on their own. This public key is included alongside the ownership > proofs, which makes their verification non-binding, the server can > generate unrelated public keys, and create ownership proofs with those > keys that commit to the per-client round IDs, which the client will > accept as valid. >=20 > This issue was described before the initial release[^7] but never > addressed. Although subsequently ownership proofs were given to > clients[^8], this change only addressed the use of ownership proofs to > identify a wallet's own inputs in a stateless signing device, without > addressing the consistency issues. Because the server provides the > public key against which unknown inputs ownership proofs must be > verified, that places them under adversarial control. >=20 > Related issues and comments I have posted over the years: >=20 > - unimplemented consistency check that does not depend on prevout also > not implemented[^9] > - no commitment to coordinator address in the round parameters[^10], > although this was temporarily fixed the fix was reverted[^11] > - additional missing fields in the round parameter commitments, and > rationale addressing tagging attacks[^12] > - initial description of blind signature based protocol, which > predates my collaboration and design of the anonymous credential based > protocol which also addresses this explicitly[^13] >=20 > Finally, although not in scope I will also note that poor coin > selection (bad randomization and de-randomization), improper > randomization of input registration timing, and tor circuit management > increase the probability of the success of such an attack, by making > it easier to target specific users. Additional concerns exist for > alternative clients due to use of JSON and HTTP in the protocol, in > the C# implementation serialization by a 3rd party JSON library, which > may canonicalize JSON differently (e.g. ordering of properties in JSON > objects), etc. Additionally, although designed with coordination fees > in mind, the anonymous credential mechanism did not enforce that > coordination fees are fair or incentive compatible (nor can it with > non-binding ownership proofs, though the main privacy concern there is > the coordinator lying about the values of other clients' prevouts > leading to poor amount decomposition), resulting in thefts of user > funds[^14][^15], but this has now been removed[^16]. >=20 > Again a version of this with some preliminaries is also on github.[^17] >=20 > [^7]: https://github.com/WalletWasabi/WalletWasabi/issues/5533 > [^8]: https://github.com/WalletWasabi/WalletWasabi/pull/8708 > [^9]: https://github.com/WalletWasabi/WalletWasabi/issues/6394#issuecomme= nt-920225648 > [^10]: https://github.com/WalletWasabi/WalletWasabi/issues/5992 > [^11]: https://github.com/WalletWasabi/WalletWasabi/pull/8708/files#diff-= 04b849802b4adf5b34756a49b498f2ac97247cbb64424e5a69ee64c28a7033bcR120 > [^12]: https://github.com/WalletWasabi/WalletWasabi/issues/5439 > [^13]: https://gist.github.com/nothingmuch/61968fde675a596758bffd4c278ac0= 96 > [^14]: https://github.com/WalletWasabi/WalletWasabi/discussions/13249 > [^15]: https://bitcointalk.org/index.php?topic=3D5499439.msg64309927#msg6= 4309927 > [^16]: https://archive.is/xFRHO > [^17]: https://gist.github.com/nothingmuch/4d717e12e451ff4ce43474972e41c6= ba > [^18]: https://blog.trezor.io/important-update-transitioning-from-coinjoi= n-in-trezor-suite-9dfc63d2662f >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CAAQdECCdRVV%2B3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg%40mail.gmail.com. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= Z5JtilN2k7HwRRXt%40petertodd.org. --4eHEatFitjb6mP2G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmeSbXQACgkQLly11TVR LzfOAQ//YnMYgYylWQqhKLxg1khCjrwQc3yQ2Bi0/oQeCZZmoWrljYDh3Z5rVBq0 sfidCODGOE8v1J+TgbvI3wfRuRVgmsG7MCVyMYptINOnoKrnklOjmnzS8hVV5eyJ 46QgTbazMKXHOKn32FkfQduw+akNv8RqL6Lf5Qoy7S4P3RvzHT3eGTmP2LYQFKxE UjYnCFrZ2e8L59jXeCvyn468vBnFc7CVKgAwmafV8AlhOaSArwAAJsFZQWQBpFcM KXJT8aI8+QGRaqSY4nYdiB2/lFYz2Va/bhIPCNLpOkEHVNhW1cxxLBa5i4wJyYb5 QcjrEKc+itk0N/1IjCfOVYjGD6qM/VGBJgrFtSiichJSLOSykXJin9sLxrjeUDaZ cpbSZTuaKI0ogmumUbyQcCrk+uroWt4LSmgHwIBltHeoaPhqMNfoZDNbfMkOMIVf NLd8f4dWdXLgrYrprUstaCyav/BxdVkOSI6c2ge13Mn/5HuzSUerncHjFUpevpQU MEy0j6t3wnaFomzvf53bxPdhSYSENPh28NT7hynIKwyEwdfrC4b25YirnSgWs8bO 8yJvpChnO8kg0VaR99jc16QnhSMXxjMx+2gFl3S9w6NH5diMFZN3bFhHQo+ggHYX 5lbrlzfKnhKEhu/z1LirragJPAT6rGcZjdbaDerhDmmHHaRNFzo= =sUsB -----END PGP SIGNATURE----- --4eHEatFitjb6mP2G--