<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.3.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-case-ppm-binomial-dp-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 -->
  <front>
    <title abbrev="Binomal DP in MPC">Simple and Efficient Binomial Protocols for Differential Privacy in MPC</title>
    <seriesInfo name="Internet-Draft" value="draft-case-ppm-binomial-dp-00"/>
    <author initials="B." surname="Case" fullname="Ben Case">
      <organization>Meta</organization>
      <address>
        <email>bmcase@meta.com</email>
      </address>
    </author>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <date year="2024" month="July" day="08"/>
    <area>Security</area>
    <workgroup>Privacy Preserving Measurement</workgroup>
    <keyword>oneplusoneplusoneplus</keyword>
    <keyword>noise</keyword>
    <keyword>counting coins</keyword>
    <abstract>
      <?line 75?>

<t>TODO</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://private-attribution.github.io/i-d/draft-case-ppm-binomial-dp.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-case-ppm-binomial-dp/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Privacy Preserving Measurement Working Group mailing list (<eref target="mailto:ppm@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ppm/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ppm/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/private-attribution/i-d"/>.</t>
    </note>
  </front>
  <middle>
    <?line 80?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Using multiparty computation (MPC) to compute aggregate statistics has some very
promising privacy characteristics. MPC provides strong assurances about the
confidentiality of input values, relying only on the assumption that the parties
performing the computation do not collude. Depending on the MPC system in use,
the cryptographic assumptions involved can be conservative.  For instance, MPC
is the basis of the Verifiable, Distributed Aggregation Functions (VDAFs)
<xref target="VDAF"/> used in DAP <xref target="DAP"/>.</t>
      <t>Depending on how the system is used, particularly for systems where the MPC
system offers some flexibility in how it can be queried, concrete privacy
guarantees are harder to provide.  Multiple aggregations over similar input data
might be computed, leading to aggregates that can be compared to reveal
aggregates over a small set of inputs or even the value of specific inputs.</t>
      <t>Differential privacy (DP) <xref target="DWORK"/>) offers a framework
for both analyzing and protecting privacy that can be applied to this problem to
great effect.  By adding some amount of noise to aggregates, strong guarantees
can be made about the amount of privacy loss that applies to any given input.</t>
      <t>There are multiple methods for applying noise to aggregates, but the one that
offers the lowest amount of noise — and therefore the most useful outputs — is
one where a single entity samples and adds noise, known as central
DP. Alternatives include local DP, where each noise is added to each input to
the aggregation, or shuffle DP, which reduces noise requirements for local DP by
shuffling inputs.</t>
      <t>Applying noise in a single place ensures that the amount of noise is directly
proportional to the sensitivity (that is, the maximum amount that any input
might contribute to the output) rather than being in some way proportional to
the number of inputs.  The amount of noise relative to aggregates decreases as
the number of inputs increases, meaning that central DP effectively provides an
optimal amount of noise.</t>
      <section anchor="dp-noise-in-mpc">
        <name>DP Noise in MPC</name>
        <t>There are several approaches to adding noise in MPC.</t>
        <t>Use of local or shuffle DP is possible. As noted, these methods can add more
noise than is ideal.</t>
        <t>Noise can be added by each party independently. Each party adds noise in a
fraction that is based on its understanding of the number of honest parties
present. In two-party MPC, each party has to assume the other is dishonest, so
each adds the entire noise quantity, ultimately doubling the overall noise that
is added. In a three-party honest majority MPC, each party can add half of the
required noise on the assumption that one other party is honest, resulting in a
50% increase in the amount of noise.</t>
        <t>Finally, an MPC protocol can be executed to add noise. The primary drawback of
this approach is that there is an increased cost to generating the noise in MPC.
However, MPC protocols can avoid having to include additional noise in order to
compensate for the risk of information leakage from a dishonest participant.
Adding noise using MPC provides strong assurances that noise is not known to any
party, including the parties that perform the computation, up to the limits of
the MPC scheme in use.  Finally, the costs of computation in MPC scale only with
the privacy parameters for the differential privacy, not the number of inputs.
Amortizing this cost over large sets of inputs can make the additional cost
small.</t>
      </section>
      <section anchor="binomal-noise">
        <name>Binomal Noise</name>
        <t>The Bernoulli distribution provides approximate differential privacy (DP)
<xref target="DWORK"/>. This is sometimes named (epsilon, delta)-differential privacy or (ε,
δ)-differential privacy.  The epsilon value in approximate DP bounds privacy
loss for most contributions to the output, however the delta value is a non-zero
bound on the probability that a higher privacy loss occurs.</t>
        <t>A binomial, <tt>Bin(N, p)</tt>, distribution is the number of successes out of <tt>N</tt>
Bernoulli trials, where each Bernoulli trial is a coin flip with success
probability <tt>p</tt>.</t>
        <t>Due to the central limit theorem, a binomial distribution with large <tt>N</tt> is a
close approximation of a Normal or Gaussian distribution, which has a number of
useful properties.</t>
        <t>This document describes a simple MPC protocol, with several instantiations, for
efficiently computing binomial noise.</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="BCP14"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="the-binomial-mechanism-for-mpc">
      <name>The Binomial Mechanism for MPC</name>
      <t>The binomial mechanism for DP generates binomial noise in MPC and adds it to
outputs before they are released.</t>
      <t>Our parameter choices rely on an analysis from <xref target="CPSGD"/>, which provides more
comprehensive formulae for a range of parameters.</t>
      <t>To sample from a <tt>Bin(N, p)</tt> distribution in MPC, two things are needed:</t>
      <ul spacing="normal">
        <li>
          <t>A protocol for Bernoulli trials, or coin-flipping protocol, that produces a
value of 1 with probability <tt>p</tt> and 0 otherwise.</t>
        </li>
        <li>
          <t>A means to sum the value of <tt>N</tt> trials.</t>
        </li>
      </ul>
      <t>This protocol sets <tt>p</tt> to 0.5. This value of <tt>p</tt> provides both an optimal
privacy/utility trade off and good efficiency for computation in MPC. Each
Bernoulli sample requires a single, uniformly distributed bit, which can be done
very efficiently. Using <tt>p = 0.5</tt> also requires the fewest samples for any set
of parameters, except for cases with extremely low variance requirements, which
we consider to be out of scope; see Section 2 of <xref target="CPSGD"/>.</t>
      <t>There are several ways to instantiate a coin flipping protocol in MPC depending
what MPC protocol is being used.  <xref target="protocols"/> describes some basic protocol
instantiations.</t>
      <t>For any given set of privacy parameters (epsilon, delta) and for a known
sensitivity, <xref target="compute-n"/> describes how to determine the number of Bernoulli
samples needed.</t>
      <t>To count the number of successes across these <tt>N</tt> trials, the MPC helpers simply
run an aggregation circuit over the secret shared results of the <tt>N</tt> Bernoulli
trials, each or which is either 0 or 1.  The result of this sum is a sample from
a <tt>Bin(N, p)</tt> distribution. This binomial noise value is then added to the
output inside the MPC and then the final noised result revealed to the
appropriate output parties.  That is, if the MPC computes <tt>f(D)</tt>, it outputs
shares of the result <tt>f(D) + Bin(N,p)</tt>.</t>
      <t>The party receiving the output can then postprocess this output to get an
unbiased estimate for <tt>f(D)</tt> by subtracting the mean of the <tt>Bin(N,p)</tt>
distribution, which is <tt>N·p</tt>.</t>
      <section anchor="document-organization">
        <name>Document Organization</name>
        <t>In the remainder of this document is organized as follows:</t>
        <ul spacing="normal">
          <li>
            <t><xref target="scale"/> introduces an additional quantization scaling parameter that can
be used to optimize the privacy/utility tradeoff.</t>
          </li>
          <li>
            <t><xref target="compute-n"/> details the process of determining for a given function <tt>f()</tt>
and privacy parameters how to determine the optimal number of trials, <tt>N</tt>.</t>
          </li>
          <li>
            <t><xref target="protocols"/> describes some instantiations of the coin flipping protocol and
the aggregation protocol.</t>
          </li>
          <li>
            <t><xref target="cost"/> includes a cost analysis of different instantiations in both
computation and communication costs.</t>
          </li>
          <li>
            <t><xref target="comparison"/> compares the binomial mechanism to other DP approaches that
might be used in MPC.</t>
          </li>
        </ul>
        <!-- TODO: overview of some use cases where this approach would be beneficial to use. -->

</section>
    </section>
    <section anchor="scale">
      <name>Quantization Scale</name>
      <t><xref target="CPSGD"/> provides an additional "quantization scale" parameter, <tt>s</tt>, for the
binomial mechanism that can be tuned to make it more closely approximate the
Gaussian mechanism and get an improved privacy/utility tradeoff.</t>
      <t>The paper defines the application of the binomial mechanism as:</t>
      <sourcecode type="pseudocode"><![CDATA[
f(D) + (X - Np) * s
]]></sourcecode>
      <t>where <tt>f(D)</tt> is the value that is protected and <tt>X</tt> is a sample from a <tt>Bin(N,
p)</tt> distribution.  This produces a scaled and unbiased output.</t>
      <t>The value of <tt>s</tt> is typically smaller than one, meaning that the sample noise is
effectively able to produce non-integer values. However, operating on
non-integer values in MPC is more complex, so this documents uses a modified
version where the MPC computes:</t>
      <sourcecode type="pseudocode"><![CDATA[
o = f(D) / s + X
]]></sourcecode>
      <t>For an MPC system, the output of the system is shares of this scaled and biased
value. The recipient can reconstruct the an unbiased, unscaled, noised value by:</t>
      <ul spacing="normal">
        <li>
          <t>Adding the shares it receives: <tt>o = sum(oᵢ, o₂, …)</tt></t>
        </li>
        <li>
          <t>Correcting for bias: <tt>o - N·p</tt></t>
        </li>
        <li>
          <t>Scaling the value: <tt>f′(D) = s * (o - N·p)</tt></t>
        </li>
      </ul>
      <t>The resulting value is always within <tt>N·p·s</tt> of the computed aggregate, but it
could be negative if that aggregate is smaller than <tt>N·p·s</tt>.</t>
      <section anchor="compute-n">
        <name>Determining number of Bernoulli trials</name>
        <t>Applying noise for differential privacy requires understanding the function
being computed, <tt>f()</tt>, and the private dataset, <tt>D</tt>.  For an <tt>f</tt> that is a
<tt>d</tt>-dimensional query with integer outputs, the output vector is in <tt>ℤ&lt;sup&gt;d&lt;/sup&gt;</tt>.  That
is, the output is a <tt>d</tt>-dimensional vector of natural numbers.</t>
        <t>The binomial mechanism requires understanding the sensitivity of the result
under three separate norms.</t>
        <section anchor="sensitivity">
          <name>Sensitivity</name>
          <t>Differential privacy describes sensitivity in terms of databases.  In this,
databases are considering "neighboring" if the additional, removal, or sometimes
the substitution of inputs related to a single subject turns one database into
the other.</t>
          <t>For two neighboring databases <tt>D₁</tt>, <tt>D₂</tt>, the sensitivity of <tt>f</tt> is:</t>
          <sourcecode type="pseudocode"><![CDATA[
||f(D₁) - f(D₂)||ₚ
]]></sourcecode>
          <t>For <tt>f(D)</tt> that produces output that is a <tt>d</tt>-dimensional vector of integer
values, the <tt>p</tt>-norms of interest for use with the binomial mechanism is the L1,
L2, and L∞ (or Linfty) norms.</t>
          <t>The L1 norm of <tt>x∊ℤ&lt;sup&gt;d&lt;/sup&gt;</tt> is:</t>
          <sourcecode type="pseudocode"><![CDATA[
sensitivity_1 = ||x||₁ = sum(i=1..d, |xᵢ|)
]]></sourcecode>
          <t>The L2 norm is:</t>
          <sourcecode type="pseudocode"><![CDATA[
sensitivity_2 = ||x||₂ = sqrt(sum(i=1..d,xᵢ²))
]]></sourcecode>
          <t>Finally, the L∞ norm is:</t>
          <sourcecode type="pseudocode"><![CDATA[
sensitivity_infty = ||x||∞ = maxᵢ(|xᵢ|)
]]></sourcecode>
          <t>These properties of the function <tt>f()</tt> are all specific to the use case and need
to be known.</t>
        </section>
      </section>
      <section anchor="epsilon-and-delta-constraints">
        <name>Epsilon and Delta Constraints</name>
        <t>The privacy parameters for approximate DP are epsilon, ε, and delta, δ.  These
parameters determine the bounds on privacy loss.</t>
        <t>Epsilon may vary considerably, though is typically in the range <tt>[0.01,
10]</tt>. Often, multiple queries spend proportions of a larger epsilon privacy
budget.  For example, a privacy budget of <tt>epsilon=3</tt> might be spent in three
separate queries with epsilon 1 or as four queries with epsilon of 2, 0.1, 0.3,
and 0.6.</t>
        <t>Delta is often be fixed in the range
(2<sup>-29</sup>..2<sup>-24</sup>). Typically, the only constraint on delta is
to ensure that <tt>1/delta &gt; population</tt>; that is, expected number of contributions
that will suffer privacy loss greater than epsilon is kept less than one.  For
MPC functions that include very large numbers of inputs, delta might need to be
reduced.</t>
        <t>Theorem 1 of <xref target="CPSGD"/> gives a way to determine the fewest Bernoulli trials,
<tt>N</tt>, needed to achieve approximate DP.  There are two main constraints that need
to be satisfied which we call the <tt>delta_constraint</tt> and
<tt>epsilon_delta_constraint</tt>.</t>
        <t>As the number Bernoulli trials increases, each constraint monotonically allows
for smaller epsilon and delta values to be achieved.  To find the smallest
number of Bernoullis that simultaneously satisfies both constraints, find the
minimum <tt>N</tt> determined by the <tt>delta_constraint</tt> and the minimum <tt>N</tt> determined
by the <tt>epsilon_delta_contraint</tt> and then take the maximum of these two values.</t>
        <t>A possible approach to satisfying both constraints is to perform a binary search
over <tt>N</tt> to find the smallest one satisfying both constraints simultaneously.  A
search might be acceptable as the computation only needs to be performed once
for each set of parameters.  An alternative and more direct approach is
described in the following sections.</t>
        <section anchor="bounding-n-by-deltaconstraint">
          <name>Bounding <tt>N</tt> by <tt>delta_constraint</tt></name>
          <t>The <tt>delta_constraint</tt> is a function of delta, the dimension, <tt>d</tt>, the
<tt>sensitivityᵢnfty</tt>, the quantization scale, <tt>s</tt>, and <tt>p</tt> (which is fixed to 0.5
in this document).  This produces a simple formula for determining the minimum
value of <tt>N</tt>:</t>
          <sourcecode type="pseudocode"><![CDATA[
N >= 4·max(23·ln(10·d/delta), 2·sensitivityᵢnfty/s)
]]></sourcecode>
        </section>
        <section anchor="bounding-n-by-epsilondeltaconstraint">
          <name>Bounding <tt>N</tt> by <tt>epsilon_delta_constraint</tt></name>
          <t>The <tt>epsilon_delta_constraint</tt> is a function of epsilon, delta, <tt>s</tt>, <tt>d</tt>,
<tt>sensitivity_1</tt>, <tt>sensitivity_2</tt>, <tt>sensitivity_infty</tt>, and <tt>p</tt> (0.5).  It is a
more complicated formula.</t>
          <t>For the <tt>epsilon_delta constraint</tt>, <xref target="CPSGD"/> defines some intermediate
functions of the success probability, <tt>p</tt>. For <tt>p = 0.5</tt>, these become fixed
constants:</t>
          <sourcecode type="pseudocode"><![CDATA[
bₚ = 1/3
cₚ = sqrt(2)·7/4
dₚ = 2/3
]]></sourcecode>
          <t>The <tt>epsilon_delta_constraint</tt>, as written in formula (7) of <xref target="CPSGD"/>,
determines what epsilon is currently attained by the provided <tt>N</tt> and other
parameters:</t>
          <sourcecode type="pseudocode"><![CDATA[
epsilon =
  sensitivity_2·sqrt(2·ln(1.25/delta))
    / (s/2·sqrt(N))
  + (sensitivity_2·cₚ·sqrt(ln(10/delta)) + sensitivity_1·bₚ)
    / ((s/4)·(1-delta/10) · N)
  + (2/3·sensitivity_infty·ln(1.25/delta)
      + sensitivity_infty·dₚ·ln(20·d/delta)·ln(10/delta))
    / ((s/4)·N)
]]></sourcecode>
          <t>The value of <tt>N</tt> for a fixed set of values for epsilon, delta, sensitivity, and
<tt>s</tt>, is a quadratic equation in <tt>N</tt>.</t>
          <t>To see this first write equation (7) as with other variables gathered into
constants <tt>c₁</tt> and <tt>c₂</tt>:</t>
          <sourcecode type="pseudocode"><![CDATA[
epsilon = c₁ / sqrt(N) + c₂ / N
c₁ = 2·sensitivity_2·sqrt(2·ln(1.25/delta))
c₂ = 4 / s·(
    (sensitivity_2·cₚ·sqrt(ln(10/delta)) + sensitivity_1·bₚ)
      / (1-delta/10)
    + 2·sensitivity_infty·ln(1.25/delta) / 3
    + sensitivity_infty·dₚ·ln(20·d/delta)·ln(10/delta)
  )
]]></sourcecode>
          <t>The formula for epsilon can then be written as a quadratic equation in <tt>N</tt>:</t>
          <sourcecode type="pseudocode"><![CDATA[
0 = (epsilon / c₁)^2·N² + (2·epsilon·c₂ / c₁² - 1)·N + (c₂ / c₁)^2
]]></sourcecode>
          <t>Once the values of all the other parameters are fixed, this can be solved with
the quadratic formula.</t>
        </section>
        <section anchor="setting-the-quantization-scale">
          <name>Setting the Quantization Scale</name>
          <t>Setting the quantization scale correctly can help get the best privacy/utility
trade offs for the mechanism.  An additional equation to note is the error of
the mechanism which we would like to minimize subject to the privacy constraints</t>
          <sourcecode type="pseudocode"><![CDATA[
error = d·s²·N·p·(1-p) = 4·d·s²·N
]]></sourcecode>
          <t><xref target="CPSGD"/> discusses more about why 0.5 is the optimal choice for <tt>p</tt>.  When it
comes to setting the quantization scale s, making it smaller will decrease the
error directly but also require a larger <tt>N</tt>.</t>
          <t>It is generally the case that making <tt>s</tt> smaller will continually decrease the
error, but at some point there is necessarily a performance constraint from the
MPC cost of how large an <tt>N</tt> is practical.</t>
          <t>One approach to setting the scale parameter would be to first determine an upper
bound allowed for <tt>N</tt> and then set <tt>s</tt> as small as possible within that
constraint.  Another approach would be to look for a point at which decreasing
<tt>s</tt> and increasing <tt>N</tt> leads to diminishing returns in reducing the error of the
mechanism.</t>
        </section>
      </section>
    </section>
    <section anchor="noise-generation-algorithm">
      <name>Noise Generation Algorithm</name>
      <t>Once the optimal number of Bernoulli trials has been determined, there are two
phases to the algorithm:</t>
      <ol spacing="normal" type="1"><li>
          <t>Perform a distributed coin flipping protocol so that all helpers hold secret
shares of 0 or 1 with probability, <tt>p</tt>.</t>
        </li>
        <li>
          <t>Sum up these secret shared samples into a sample from a <tt>Bin(N, p)</tt>.</t>
        </li>
      </ol>
      <t>This document uses <tt>p = 0.5</tt>, so the coin flipping protocol can use a
uniformly-distributed source of entropy.</t>
      <section anchor="protocols">
        <name>Coin Flipping and Aggregation Protocols</name>
        <t>The use of the binomial mechanism for <tt>p = 0.5</tt> in a concrete MPC requires a
protocol for jointly computing a number of random bits. Different systems will
have different requirements. This section describes three basic protocols that
can be used to compute the binomial distribution.</t>
        <section anchor="three-party-honest-majority">
          <name>Three Party Honest Majority</name>
          <t>A three party honest majority system is appealing because there are very
efficient protocols for performing multiplication; see <xref target="MPC-MUL"/>.</t>
          <t>Two protocols are described:</t>
          <ul spacing="normal">
            <li>
              <t>A binary circuit allows the coin flip to be performed without any
communication cost using PRSS <xref target="PRSS"/>. Aggregation requires the use of an
addition circuit, which requires one binary multiplication per bit.</t>
            </li>
            <li>
              <t>A circuit using prime fields allows the aggregation to be performed without
communication, but the coin flip protocol, which also uses PRSS, requires a
modulus conversion operation.</t>
            </li>
          </ul>
          <t>Overall, the binary circuit is more efficient in terms of communication costs,
but it might be easier to integrate the prime field circuit into a system that
uses prime fields.</t>
        </section>
        <section anchor="three-party-binary-field-protocol">
          <name>Three Party Binary Field Protocol</name>
          <t>A coin flip protocol in a three party honest majority system simply samples a
random share using PRSS.  The result is a three-way, replicated sharing of a
random binary value.</t>
          <t>Aggregating these values can be performed using a binary circuit in a tree.  Two
bits, <tt>a</tt> and <tt>b</tt>, are added to form a binary value, <tt>{a∧b, a⊕b}</tt>.</t>
          <t>This process is continued pairwise. The resulting pairs, <tt>{a1, a2}</tt> and <tt>{b1,
b2}</tt>, are also added pairwise to produce a three-bit value, <tt>{a1∧b1,
a1⊕b1⊕(a2∧b2), a2⊕b2}</tt>.</t>
          <t>Each successive iteration involves one more bit and half as many values, until a
single value with <tt>log₂(N)</tt> bits is produced.</t>
          <t>This aggregation process requires at most <tt>4N</tt> binary multiplications.</t>
        </section>
        <section anchor="three-party-large-prime-field-protocol">
          <name>Three Party Large Prime Field Protocol</name>
          <t>Addition of values in a prime field with a modulus greater than the number of
samples (N) can be performed trivially. However, producing a replicated secret
sharing across three parties using a single bit sample from PRSS results in a
value that is uniformly distributed between 0 and 2 inclusive.</t>
          <t>A modulus conversion operation can be used to convert that into a sharing in the
prime field.  This requires two multiplications, though some parts of those
multiplications can be avoided; see <xref target="KIMHC"/>.</t>
          <t>Three bits are sampled by each pair of parties.  These are turned into three
shared values, where two of the shared values are filled with zeros. The
exclusive OR of these three values is computed using two multiplications in the
form: <tt>x⊕y = x + y - 2xy</tt>.  This produces a three-way replicated sharing of a
bit in the prime field.</t>
          <t>Shares can then be aggregated through simple addition.</t>
        </section>
        <section anchor="two-party-protocols">
          <name>Two Party Protocols</name>
          <t>Obtaining multiple random bits in a two party protocol might involve the use of
an oblivious transfer protocol.  Ideally, these are obtained in a large prime
field so that addition is free.</t>
          <t>Details of OT protocol TBD.</t>
        </section>
      </section>
    </section>
    <section anchor="performance-characteristics">
      <name>Performance Characteristics</name>
      <t>A binomial function is relatively inexpensive to compute in MPC.</t>
      <section anchor="cost">
        <name>Cost Analysis</name>
        <t>With large epsilon and delta values (that is, low privacy) the use of the
binomial mechanism can be very efficient.  However, smaller values for epsilon
or delta can require significant numbers of Bernoulli trials.</t>
        <t>The following table shows some typical values and the resulting number of
trials, along with approximate values for the quantization scaling factor (<tt>s</tt>)
and error.</t>
        <table>
          <thead>
            <tr>
              <th align="right">epsilon</th>
              <th align="right">delta</th>
              <th align="right">N</th>
              <th align="right">s</th>
              <th align="right">error</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="right">3</td>
              <td align="right">10e-6</td>
              <td align="right">TODO</td>
              <td align="right">TODO</td>
              <td align="right">TODO</td>
            </tr>
            <tr>
              <td align="right">1</td>
              <td align="right">10e-6</td>
              <td align="right">TODO</td>
              <td align="right">TODO</td>
              <td align="right">TODO</td>
            </tr>
            <tr>
              <td align="right">0.1</td>
              <td align="right">10e-6</td>
              <td align="right">TODO</td>
              <td align="right">TODO</td>
              <td align="right">TODO</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="comparison">
        <name>Comparison with Alternative Approaches</name>
        <t>Two other approaches that should be compared with are:</t>
        <ul spacing="normal">
          <li>
            <t>simply having each helper party add noise independently <xref target="DWORK"/></t>
          </li>
          <li>
            <t>amplification by shuffling <xref target="SHUFLDP"/> where
local DP is added by clients and used to get a central DP guarantee</t>
          </li>
        </ul>
        <t>A binomial will alway give better privacy/utility trade offs compared to
independent noise.  An MPC system has to ensure that <tt>t</tt> out of <tt>P</tt> parties can
reveal their shares without degrading the privacy of outputs.  Consequently, the
noise that each party adds needs to be proportional to <tt>P/(P-t)</tt> times the
target amount, assuming that noise can be simply added.  For a three party
honest majority system, <tt>P</tt> is 3 and <tt>t</tt> is 1, producing 50% more noise than is
ideal.  For a two party system, the amount of noise needs to be doubled.</t>
        <t>Shuffling and any scheme that makes use of noised inputs results in noise that
increases in magnitude as the number of inputs increases, which degrades
utility.  The binomial mechanism does not result in any additional noise.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA considerations.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="PRSS">
          <front>
            <title>High Performance Pseudorandom Secret Sharing (PRSS)</title>
            <author initials="M." surname="Thomson" fullname="Martin Thomson">
              <organization/>
            </author>
            <author initials="B." surname="Savage" fullname="Ben Savage">
              <organization/>
            </author>
            <date year="2024" month="July"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-thomson-ppm-prss-00"/>
        </reference>
        <reference anchor="MPC-MUL">
          <front>
            <title>Efficient Protocols for Binary Fields in the 3-Party Honest Majority MPC Setting</title>
            <author initials="B." surname="Savage" fullname="Ben Savage">
              <organization/>
            </author>
            <author initials="M." surname="Thomson" fullname="Martin Thomson">
              <organization/>
            </author>
            <date year="2024" month="July"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-savage-ppm-3phm-mpc-00"/>
        </reference>
        <referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14">
          <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
            <front>
              <title>Key words for use in RFCs to Indicate Requirement Levels</title>
              <author fullname="S. Bradner" initials="S." surname="Bradner"/>
              <date month="March" year="1997"/>
              <abstract>
                <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
          </reference>
          <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
            <front>
              <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
              <author fullname="B. Leiba" initials="B." surname="Leiba"/>
              <date month="May" year="2017"/>
              <abstract>
                <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
          </reference>
        </referencegroup>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="CPSGD">
          <front>
            <title>cpSGD: Communication-efficient and differentially-private distributed SGD</title>
            <author initials="N." surname="Agarwal" fullname="Naman Agarwal">
              <organization/>
            </author>
            <author initials="A. T." surname="Suresh" fullname="Ananda Theertha Suresh">
              <organization/>
            </author>
            <author initials="F." surname="Yu" fullname="Felix Yu">
              <organization/>
            </author>
            <author initials="S." surname="Kumar" fullname="Sanjiv Kumar">
              <organization/>
            </author>
            <author initials="H. B." surname="Mcmahan" fullname="H. Brendan Mcmahan">
              <organization/>
            </author>
            <date year="2018" month="May"/>
          </front>
        </reference>
        <reference anchor="VDAF">
          <front>
            <title>Verifiable Distributed Aggregation Functions</title>
            <author fullname="Richard Barnes" initials="R." surname="Barnes">
              <organization>Cisco</organization>
            </author>
            <author fullname="David Cook" initials="D." surname="Cook">
              <organization>ISRG</organization>
            </author>
            <author fullname="Christopher Patton" initials="C." surname="Patton">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Phillipp Schoppmann" initials="P." surname="Schoppmann">
              <organization>Google</organization>
            </author>
            <date day="8" month="July" year="2024"/>
            <abstract>
              <t>   This document describes Verifiable Distributed Aggregation Functions
   (VDAFs), a family of multi-party protocols for computing aggregate
   statistics over user measurements.  These protocols are designed to
   ensure that, as long as at least one aggregation server executes the
   protocol honestly, individual measurements are never seen by any
   server in the clear.  At the same time, VDAFs allow the servers to
   detect if a malicious or misconfigured client submitted an
   measurement that would result in an invalid aggregate result.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-vdaf-10"/>
        </reference>
        <reference anchor="DAP">
          <front>
            <title>Distributed Aggregation Protocol for Privacy Preserving Measurement</title>
            <author fullname="Tim Geoghegan" initials="T." surname="Geoghegan">
              <organization>ISRG</organization>
            </author>
            <author fullname="Christopher Patton" initials="C." surname="Patton">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Brandon Pitman" initials="B." surname="Pitman">
              <organization>ISRG</organization>
            </author>
            <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="21" month="May" year="2024"/>
            <abstract>
              <t>   There are many situations in which it is desirable to take
   measurements of data which people consider sensitive.  In these
   cases, the entity taking the measurement is usually not interested in
   people's individual responses but rather in aggregated data.
   Conventional methods require collecting individual responses and then
   aggregating them, thus representing a threat to user privacy and
   rendering many such measurements difficult and impractical.  This
   document describes a multi-party distributed aggregation protocol
   (DAP) for privacy preserving measurement (PPM) which can be used to
   collect aggregate data without revealing any individual user's data.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ppm-dap-11"/>
        </reference>
        <reference anchor="DWORK">
          <front>
            <title>The Algorithmic Foundations of Differential Privacy</title>
            <author fullname="Cynthia Dwork" initials="C." surname="Dwork">
              <organization/>
            </author>
            <author fullname="Aaron Roth" initials="A." surname="Roth">
              <organization/>
            </author>
            <date year="2013"/>
          </front>
          <seriesInfo name="Foundations and Trends® in Theoretical Computer Science" value="vol. 9, no. 3-4, pp. 211-407"/>
          <seriesInfo name="DOI" value="10.1561/0400000042"/>
          <refcontent>Now Publishers</refcontent>
        </reference>
        <reference anchor="KIMHC">
          <front>
            <title>Efficient Bit-Decomposition and Modulus-Conversion Protocols with an Honest Majority</title>
            <author fullname="Ryo Kikuchi" initials="R." surname="Kikuchi">
              <organization/>
            </author>
            <author fullname="Dai Ikarashi" initials="D." surname="Ikarashi">
              <organization/>
            </author>
            <author fullname="Takahiro Matsuda" initials="T." surname="Matsuda">
              <organization/>
            </author>
            <author fullname="Koki Hamada" initials="K." surname="Hamada">
              <organization/>
            </author>
            <author fullname="Koji Chida" initials="K." surname="Chida">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="Information Security and Privacy" value="pp. 64-82"/>
          <seriesInfo name="DOI" value="10.1007/978-3-319-93638-3_5"/>
          <seriesInfo name="ISBN" value="[&quot;9783319936376&quot;, &quot;9783319936383&quot;]"/>
          <refcontent>Springer International Publishing</refcontent>
        </reference>
        <reference anchor="SHUFLDP">
          <front>
            <title>Distributed Differential Privacy via Shuffling</title>
            <author fullname="Albert Cheu" initials="A." surname="Cheu">
              <organization/>
            </author>
            <author fullname="Adam Smith" initials="A." surname="Smith">
              <organization/>
            </author>
            <author fullname="Jonathan Ullman" initials="J." surname="Ullman">
              <organization/>
            </author>
            <author fullname="David Zeber" initials="D." surname="Zeber">
              <organization/>
            </author>
            <author fullname="Maxim Zhilyaev" initials="M." surname="Zhilyaev">
              <organization/>
            </author>
            <date year="2019"/>
          </front>
          <seriesInfo name="Advances in Cryptology – EUROCRYPT 2019" value="pp. 375-403"/>
          <seriesInfo name="DOI" value="10.1007/978-3-030-17653-2_13"/>
          <seriesInfo name="ISBN" value="[&quot;9783030176525&quot;, &quot;9783030176532&quot;]"/>
          <refcontent>Springer International Publishing</refcontent>
        </reference>
      </references>
    </references>
    <?line 615?>

<section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA618XW8cyXX2ff2KCoUXIO2ZIYfU7trKam2uuPIKlkhmpY1t
BHl3enpqOG31dI/7g+SsJMNZ5MLwdXKTiyB48SK5N2LoXj/A/+HVL3nPc86p
6uqZobxBImCXZHd1fZw6H8/5qBoOh6bJmtw9sHvPs+UqdzYpZvaL+TxLM1c0
9vOsKJdZktvLqmzKtMxrOy8re5bN566iBvIqu07Stc0K++zy0Z5JptPKXVOP
/DE1OLsM79KkcVdltX5g62ZmzKxMi2RJo8+qZN4M06R2w9VqOZzqsMPZanh0
ZOp2uszqOiuLZr2i1k++ePHYpGVRu6Ju6we2qVpnaMQTk1QuwVpc2lZZs94z
N2X18qoq2xU99RO9rFztquusuLLPXFK3lVvSUvbMS7em5rMHxg5tWbhV3tb9
H3hRlFnt8EtatrR+6iMts6I2165oHX1qv+9o1spi9n5BU8Tbn+FDPF8mWU7P
iRA/zVwzH5XVFR4nVbqgx4umWdUPDg/RCo+yazfyzQ7x4HBalTe1O6TvD/Hd
VdYs2ik6xIwaN0yapsqmbUP0PMyGM7TJ6XndRL3vaDuSjkZZia8O796y0aJZ
5nvGJG2zKCuQk0awVnb6c1fYRwlISP9oykmRfZug+wdEnibhx04oMF2i958u
6fEoLZf9fp4lFVHfvliUS9qeXb2V32Z53utw2fw0L2+I+lW5Wo8K1xhTlNWS
PrimraOWl189f/6Av/BS8WV2tbCXrpqjXZE6e1m7dlZWJCbl0hKfVa6xzxdJ
hR3cx/cHe9zBjKj3wB4fHd8fHn1i79kXF2cX+8vmgF8SQ2Suzop5KaNZ+6Ro
XEUzGp6BrF4gGlkdE3hV1TWEAa0DZfnfUH9+gDTbjbAPz5Pr5Mph4SScw2df
P+2vvVMDfeknuU6qtX2cuXxWQ7SbhbMnw0sadm2/JFmpG5rDr0tIIHomMjWQ
lP9BwtQ8c6bLyWqxHC5X6fejTbTs70U8g7kEFrH20eXzn531yZSu8Mg+KpfL
tshSZr+hC7SDQp1F+jJfD1W46HEt0uVmlvro02f8o+HRR99jRecJMaY9vUqq
myS/o81pQbNIaFHOVc0isc9JC9WLOxo/dnl2a3/V3vH6eVL8Oru2P2+XSXVH
ky9H9nNa7Yzm9SxdJouE6GiGw6FNprTgJCW5w67rw2U2m+XEhfew11U5a1NQ
0Jiva8jUss2bbMWsRTpg1TZMX7tPfHVgm1Ifkt26uqrcFahao0ndZGltF0lt
63Lp7LWr1mZVkYbiTleqm1MSXJoOMR23HzG3UrPrbOboS5oNNU5qUtqQ/Zrm
X7YN2B3WZ06NeEfB5uWcBIEmYq+TvHX1wFYuX2OossjprcgIelqueP60C9yR
xdKI5c1KdAw+weN4rbOSrE5Dj/K8nbmRPXMrIq50zo0x63pdN24JaWxrNzDc
R7VeNeVVlawWWRoNDpm9LvNr4rqUtmiK0QrYKObykbWPScjJpjVY9AC9m6zm
gaZJTb/RWvHH3xLZ5lkyzanNWcTJp7oTmPrjtkhlyP2/PTt9XB+YV69+gt8e
PhmejbKqmQ/TeXU1vJ4l8zdvMPUZlnB2emmpIf2QdmTeWNZnyerNm5ExPQos
yhuej6dAzd0MhLJpS0aSdgB6SxrU9mZBsugJZ/SzEhKq3DLP3W02zXhjMxkg
azytftNCR1H/RDRof+e5yVy1xE2krsAoNADx1sxV4FHlKKLsM+bmvGNXpk1J
7GnrbAmDrmxEWiAxSzI+jewPMzkNmruE1029Bo6vhZvCXi5p5URHakI4zJFS
iFryUImtCZflpG2bwLj0qrLUXDiKuRjv6pVLaZdTbQTax9jPC9L+2eUB79gv
Lr76+cOziyej8dFo/NHH48Oj+0f87/7xmzcHnsqJnVekKQDODHZmWjYLUpRJ
vv4Wi4PKJJo1Lm1iaY1XmaxWeSaLbBa05dScGHFJfxtaK7UjBUyfE8k/X9tk
xjTjvU2WwG1YGiO5PiEHXua7rTQ64DKZuU7+o2787PKy1o2QudXcdbEm/AWq
Mv2IfC+Y+cAfS88LBHAW5UxsK75lvbFzdlMdnWwsD2WUnngGZEOGd3N973/3
T0zPBuPSCML4y5KakpjM29zSknj/0TKrDfoWCSE2oZnQBLHZJAp1Ag+h5u6I
pLWMMLAvi/KmIP1iU0Ar4rezy5E9zWG3WaNA36RQXTTHlP2BgY7gknSh86Q9
pD5lR/mxyAHtJ5O7E5cBGLVetHOSUu0qo+bE8S1UtPRWud+0mSBtoasf2U7X
Rj4GkQNTn/bJTkIfFr/KkxQkAHKvO729SWea/4xGTJucDc2qrDBZGpM5lLQT
9ZARNUDIfe4low3lvUhus2W79D0KCxVrmZzqANI1ql99f7JrB7ZKsLP4Cmwq
ixJOv0nWdmMmTMuiXU7piyD4JCMvdiyIDBjv3oaqmQHyEiyn7ap3dofNlhYD
4mwC5GzRILnCHdgEEU7qPF935pZQQkn2CR7jxlxog8y9e/jw3G8PNHckSzVp
LvRN4lOVxD0qfSL3RfTRCLiCNZtwRI+XsIkrEuOMVAlxMJiJlS4ts+7EFAqB
eiYZqpxRMQX16WNaR5LTEDJNr6qYradrYWuBMlkxYxNGJMnXI/tF96YTLOZC
MwdACYiBxiAbTN3Rg4xo3VIXFQy1GEMxzN2OLASMB4wBV7QgpfiEursphzIi
UWUQzw2gCcQDXhBtUTKLMYfX0iUpytLwNzxfNIKSoJ2Qqf+mTVhnDCyUHMFn
7PSsbKe5Bzglb1huAwEb41UAzy+hZ5VzOkddyDLyKnpz9nuySPK5ksGoDpjp
EHdgMKg7WZ/uTG39EolamL2IVGI+Ovpfgbe917PNqI/JOSKMP7BJ4dEku06e
G9ytSxkmCX/qdyyBZEmWcKzIxbmZJulL6tawcfNcbbNOAVWiMoswJQJzUOrU
7ZUriLaNp3Sf/b8kM0GkH/Qmp0x9XWYg4bUCDK+1IUaqQkJfpWIbA7hBqg3A
G3oWAxKafin6QF0nojXhlpfkdJHdJ7c56RhJURohfOJLcxoLbMtQ/S8gciZH
0MCAyWKNxPYa3tOBrsQTRMVBvlXcvQm6iXFXXtXmhMyAj+YmgG3SMEunYBuA
2W+69FJz6x6GF/LTh0nuxCe4yZoFd+gBBE2LMFEDe+4pOduBtQa8yp2K3Jwu
oey/lYUSPZgjGPIRsryCmpSZqabGpi+TlyLk0S7jM8MQUTWvj+SxXmO9S450
VZRtnmedF4t1dtocPHvLor9zGQwZjYeMhOpJBKBBBYKTzoAtJ3rM7L5b1VmO
LZm5vEkOhju7I4rt//lPA/Pn/9zdQK2c9qUAF3IdzRPwgOR5VgdIz6AOu8GA
KVhhRu09QzyAlwDBkn3DRP0YgLtFWQy/dVVpuH+viwBaE/UzxOzbBZl76KIY
VJZp2laMUqyPsg3shPZk/5y8nIPJoL8F6qt13FG3KYkKTDbQKz2YnE9Mt3/0
ZZLXPUi28VLWgDgnuUbZilnX92riRUxWE3gIbUAp3uazCOEJ2cwl6cawkP7U
uWNhVZojD2tSooGLtgntaA0JMWO1FAv+s6Qlo03MHHfmgSHMWdJRwyjqBTJy
rAcYlMO4lWkLwEi7V6fUC5gYXhkgeqwsB7p+hRziKBOrMVcMwC0mRH9yH7WA
SIY1x6DmqxipPk0K8jyuVMReOtISpGhru/fs6+cv9gby055f8O9fffE3Xz/5
6osz/P78y9OnT8MvRls8//Li66dn3W/dl48unj374vxMPqantvfI7D07/dXe
gIH+3sXliycX56dP98TmxYQC8qKNnkKQSG+t4A3PgAs9BdmZ//zR5bt/G98n
9/Cv6NfxffLzidUK6V5UIf9J3LE2tM+OnWALcJAmq6xh5kQgZwHFDiYl0v3g
70CKv39gP52mq/H9z/QBVth76InUe8hE2n6y9bFQbcejHcME8vWeb5C2P9/T
X/X+9oSOHn76E8JLzg7HP/rJZwb8wjosJGWeuZSAZ1YvWUV5SNzx2bL3nrSb
IgPi7D4vevMUPLuMPS/vGU6D47jmPSfXgBEH7cNFW3WGy6aLMoNVRvALSg6g
Al49okZs+V+94gDqmzdeOoO9YDQNWancAq7SNeMJ8pETARYJeTrFFSP3zlBC
hl6U6ph6bBFpxg3FWAhuJOgLRi6uJE5TOEeg8wHxlD3t4BoHurd0JD2EGhxC
Da4kNuGVgqAJjl9CcxjbBVHGojE2NCVT+0jA540oBMwAPhMbF8Kp/VgMVKJM
xKusMFs27OiTvjsafaTGtPuS3gRKa7DFqrNl1NYcEpHEElUIdZTzOU/wqixn
1uuzVAJp28BGXJjIqOiWKAavgztNuKrIsLHwB6Kg4TRrPEsoUJ4RPjSI29pI
m46sRIUnK/sQCyUi5nXZDQN6zR0HQny0gpmH3GkikekxDzkQt6lbNbIkdml5
m9xtA32cw/reEA2J4kj8xCEFnaq5kdBppnG+qfMWtk7Juvw1jemQI2JCHeN5
4P/RLu+VPPZagLc3KS62uz2G8yI786FQcwMG7Lkc8BY5JICAKAGgV68C4Ccl
3Jk5DhcgtpuGb03frMGxUTpKOEtDhzuw6yZcYy4SCWZobqJIyICmpLHNYdGb
Egd1S3pAfS6zwm1AmsBoxm+zSPGI9UGqgZTdIChJKwnVwanvZGoQQukLl684
FgzbvzZVK4osCmunWZW2mUJrie5wIrBecORVHMcQKMcY3YT9aAy0iCzC9LRV
LmM39AgPxwpXpSfpCNC4XQoWizSeuVvjqRrY0PUBltJwRRd0g8ssCh/8Rywd
6KHhQ8Gs8yz4gX6hGmbuumGwRqwB/tUu1efiZWnsK5uHEZQHSIXN988AaEFb
MT6GaRpoqSNyO/tDKwundYs8qQ9fudRl1yHSIDOAWuFVrAjK0/zADUJVbcCe
M0Jvpi2mGXvUpEfEMwD/ytwQyKnbKaex/AhQ2WGzw5TMLjRKw03O371lnIyQ
lodSF1Hu2pgnhS52mSBSVAUGCNAL05ZPGHHRBHPSVjVbsVev2M0keco0ocbR
tdjDk/iMDMdOKauWYMd9pJ2M2NRJVoaowwaDBrSR19q3GmQ0RjKDvlQ3SZbX
3uVhwtOCvGxjaNEPolrmmjMCwYmKVtMBW4pmp4rwEcRO8L28kRTq3D6gBPta
z+/pHRqY5oUqjn54OrwOhKgb3gmOpYgfhTC9h0UghHdXN4enUWGsaZDY4oIc
aZxslohDRHgyWXUJymsuSJN327AQm8pKh7BhHDpFNM7akH7yaTmJn376V8Mh
Z+0fsP67ztwNK1jQr+WwJ5tSTbLF4asb0oAzdDglHAqbLuFxjqEMh58xwP2b
mDOfc7jk1T3hZ3of7GccNo4Ze2+Ls91exzTEBfVk4MMrZhdFohxT0xbC+Bwj
IZUEjGrZHyVwEAcO0FlwQrvOGD+xSrFkSmjCbvYhuREFRqaHuJLUrG4bZ5PS
4PfesZMJRP+3v/2tXXF9SlrOnFEduf9LO7TnqwP7A1ujiTGyN6rPNFwgVsEH
mTX7Bt1Ca5j8crJldjqgbbbNjvXoVHWPbIR0FpSrqF1ddwdVa5nSekWLzonO
HIfyGQ7ChBtZBba+Mi0fBjRxegH5ac3BYjIciYG3ekVdSq5+ZENMFCEBCZyS
Ft5u6TFXVisrlBj3FsHwvnrmFDTWvSxJuDM3A5CtOcIR556D3dveu5LwLe/f
oa1pD38pGycYLMr3D2ILp9zR5cFj04k/u02QLTC8rJEijTRbccEKuJ/+IgXU
VG2q2a4i7BsQvPQ08DBANm+6Fh9qFgKtOn7WqEWmhdoJVkY4Zr/8f3/6P0Tx
9999N7Dvf/fvpOl/YB+VVaVJX04L04D8BfEvbCa1eK62KrAsvZ+//90fQSrq
l3h83zenHk2HofBRF5DLGWoD7tOWskF+95YYL+h7Sbd3eS9JvWYNeaiqwgrW
9+SlMoxB7C4UoIDUMdOG/n0eKzJ8OyCtWixSe50R3cpQgjw746DBFeqnhhi6
qWE14hR0RQVsaAce59lQnpQ0tOHkl03OJloVgtXMJ0FNJGYymwxn2RKQXoEF
PDb2o7zsKJDrseo17XLJKSXQ//0//t9P63b12ezTQ/yYKEo0Wf8jVkGbA2pP
yMAkTVsF01+P7gyGfIBEcZa2hzgNt5WcFLWCRWmgTKplzUjuHvl54dM7iiQi
rBENg6gasYMgAaI48nvAyU8k2jYw4SH7it7fxIz3Ckcmelrijz2PpztjiAzW
srzGL0hz+rA6Jx0IwhK2bVpvVjQjwElfTU75BDg1/bWDHmgrQKLChWliiyWn
zChCnUSEV6KJdYsiPnr/3T9MBvzzu8lgF8XBXdkOffj6NWlD+vqAhJt/++7g
9ev33/1LpxfVnPXDMB7ae379APsouxpfwMVgfjUZ8h77BhUiC5A9AB3m8jvs
sVrVp+OBeXosovX0/e//lbRTZZ9mxbxZHwTuecEN+U8mwe373/9hUyR2EiWi
3TdjUn+vX9+CKP+gGjZ7OB6NSLxf35KqfX0gpOLBjmWwv9Tncdfnd+jzN1Wz
H3WMbt/98UA77uXAeK3fawymRRiHvnqIggjqeX9z2rWLgvZeOvvOAksIVzb5
siXNQ3hcyhuBUIGRcA1HJFQtf6GpITQ54wTOI7aB5IKRG2pe3J2q28ghYRIh
CPLnP8nuczCE/vxP8exrZ6JO+j6M5qDYl+jSQDRLP8NlskZcah2UAYEcJnzZ
Xi366Enz1BI7nfzd0eiIOHJ89PekYy/mDcLuoQxJCttq0E7qr7RypJZ0C6dl
qpBA8xmyaTsjiKvmwd0yEkOCx09d3jNf66cPTyada4HBGpklaVYTNKufjETk
dMwx9Bg7u221uwUNQ9J2NBrjfycDwyHW0cdcMogdZYeLlo2h59mtuDWBQGb/
mIVuePxjEbvRyD+4Lw8OCCx52qptKnLZB2EU7NpMhwKPSd2QKKDJ+FBefWZX
5arNGdNP/tqGaiB3uxLQ3aGCXsrRcMubDAzewsD084Rc+OZBh6cIrfglgpy5
hDsEQ8t2GeDIeajQlGlozp8Dr5KJU3vaWQmN7OkmQpok+GmkBmsmKg2ZPuxY
FPRkBx9aGKVJW667xm23gu6GPPeBxvfYMKWLjOD6htSJWGlAFSYIoZNoY3yp
QCf7NcqEAc41NINgLnQHK35e4Tfd5xytN56Fv9l6jexsL++6BeeisigO/UU8
syyLsikLFdmEIzlcF+lhpItUU5RbrjXorBRBiPdFiQid4Dj5um7MDpCp5Kgz
iH9SuLKt4WspSTRJEFFvELo1QK6oV0NYM+wgFzjdTTkJk+380PgPt2i78T0J
qq9V8CVzYgRq2XD15pAm90VcXegB+RReHGPozdWxzixDLQinp6Ffa4cDNYbD
vBwp3kFdRkQf6rtPY9qjUyP9dlowSZGIYFc1qTdLUUTFgHH9fus8uQwsdcwp
zFI+KN/lx2gwZFJDKSbTkn1XKVaMS4v6WVuWSA4qcumsJDFqMZX37OcwUZyI
OeeI6Paui8HcwQ0Mw4LZ5jggW0apd1FkNgBQ42dmEqEFAgSACwodt0M9Gt/h
mMVqYvdDzFV0vSTHzGYe+2BXwELy/pqCFHcrctsidjZxfm4b65zbzx7a++/e
EsvuH5+8e5sX++Ojd29nYgoOBvaYPMOtFR7Wint2U/tONaRUv/P9NvX72Rol
IIjfI/w3YzztYcPNB5nuTCA+kRqUfaKeYhcxQTTLzTxtwVKPtd6pP/FIiiaD
yIr46JhGbLErboZkg+mMmY+FSNYnTr0OuEqF4UrIIvoSz6lLuf4f3MIHDBGN
3QFgp+R50KfjwxOTyq+MjY8P3r395PC+mcmzY3odMPfde8LFDTdV1jRcJh54
bv+Tg571JE/QK02EV1Hj3tn4tK0qqTdJmiaJFbIGSmfMPFxyAV8tQp/by/P9
PjTW9vacWJXXKWw8Ov5IuVgObx3a/frQtznnhz+kR/0OQC9twqLge6CmPX57
9xZEDh1Tz/eJuvvjIbc/HB8d2Hdv7bkOQqTuiZFw4+Y09ZhSfyRtOeN5Ufvj
SDpVXDdXqZM5j1yqXpJeshmic1Qnq71mVb0hcb18KKMMiCALKmm4GQKSqXX0
q8+3SyYDdQ9OI+zzrCJDBB5yXUvwT6L4WKL8nMueIlt6xVXjrOm5hlM53U5S
eOgiwymc9A8wh0VbxCdlu4ms+IIenJtUnNC+avsQ+6TiYd5Hd7TLTOj/Cc7h
7Yp4xsj+H38PZqEvT8x/h13o44hBYkviSRhSkmTTvQJIPrjv29txRGTzKXea
Mih/8L9pfefv/siC8e6tvmQCfqdN6OXQjsHDaBS9oG9lzheoeQhRVvEBFRyH
cmnvvgJyM7cPtOxU8ie1nDELha7dqiLVL6GzJuRSt/M/xsTvt40+mYlKDl7w
wMjec9aFXWkuMe6nXEwocOkKbUPgRhFTl1AKG9DwKTyfOLeuqjhuZHqfd66E
5Lry7CVnHxgrIHUagmllnEWN8eK2wPFID+2MmPbdH7GziCYTV68Q8iZoEV7I
zkWGMqvTlmse2PjK6aWbxRo2z6/DJ0yldEsS3bCP9hdgTI54L8XRqD+8Czju
kfBB9qwJjgv7qv7ICMM5WY0/KsNh9biEpws0iJYT9CB1a3COGBsnemLAD4ic
UW9EOA9Z0fIX26NLMB/eD4z9qsyKqKK+cAAMpChhSj3S5gKgyGHjBBj6kyRO
3chhixv1mDnmP5E8GsoEUj4UclFs+CMRPYWEXQI+ZErZ44By73xl5GJWNDGt
JWZ3UeBUMPGsVGB5QJlE0xH4JThGmvrgTG+3MOZ+Ee/tpC1NJS/Ll2rdhGwI
RzDHK5VRh8RjFjPv8HrcipOLzEcE8kkaahTg0a5LVDkr5ACXp4eXLnE4g3By
hlgO1/xMDzkQ/53mVzgVslhGWmu7DmDLIUdh8NS5IvJFB8oHGkMwqwXHrVVY
Ez8OaeHxyN8KIKcZQiHbHbUCnCFEloj2wdcXLcp8ppVDMDRdtk5KgLaKBgda
X308ss/J+cUBBUat/eIjXxAFy35Xytb6ipm4pIRTlhEkrssPFT9A1SKqmphQ
0DeM6VCXbZUyIvL3LUiU9RG6e+y7A5/E54W7iwZe3evKNMSCtnJu646A+zzG
83KALxzQhZR2lYimV+P5a/Bxr0w7Kha3es/DNMMxuZDU6U4Sk7Ixi+Q6OuLQ
qxPUAiz1nqMEkOSR+iV3WnehxtMX3fjz7b1l97LtakRfcJc7L2FASERG3H2a
qssYc/k1J1jJFUpa0ZoqEHyGvrvXYNW7EyI6vq4BZa1ZkCLIV6/0hgmpfLwp
o8/Rdwg9aBmuxl98nZ2ExPrsuBULgbjAwOHcj91RIaMHinBHB80HP3DqJOa+
XhmpshsXQXk84CfUHTrVDxAD0jn3l4/5gX20uNcvqPXXELC3yfdoRGuMy4nu
WOXmCruzwR2BogMLPFu2syzlWPwgFgmLSoU2b3FkqPC1CloNwSx2Icf1Bp4P
493x5RAdb8Q5zR2lSgMj2fQuAAY7ITW0nIartKgmplA3nCo2YVqWGV5UTM1d
QhFfWxIUDURjm2KiP76HyEiJaHcy2qjCYF0cMVy/nJN9OzneeJOssREhKFLr
VTLgPBO0D09cijVowp47xFbWAaKr5uh4RcZPtvaLF0ejY1Zk5aDdyLYk6vdN
EZGoXFcZ2o+J8mDU/FXy/vf/MaWm7//wz9M3wZz4Aj8+fcYoDEVPSSYl7hEV
pOIwQx029TWmjo7f6AxeTcfEIvSnTgR8K7PxHcUVPZ6UtIxocmPMjrqhX2h+
+N9+coxnxwcYCg+PedZ89lbjRFzP0XhcobdkiHQzh2MIzJCPmRJ8WKIg2ieM
cR0UgSyjaXOJCLANn+TlFblY5CRP2JTYLtY483TbKCFkGnYC2sgBtMl9BAB3
6ZmdHP+U0egly8UW23uV1gUnmC9iiePJJ0E19PJLUaqDnCAvAIgDbLEhmapr
vvgmqrSS5Qt7xuwvaMhLQSjV9oKI1ITnaqUz9iQGOazffQU2H9ztl7bdcf7A
NTfAgke8v8eSBwM/cD7hQ8rRbhlstPE1B6qrdD0SVzcRjX3ouTM9SF31tzZk
dsVfITJofLOsCRz324ZD5zjL62be+v7k50+effkoXMxxdPTJ4Y8/+dHwZHgy
/vHwxycfn9Dv33ykxxIYmoBN+WwCkzY+v55VmmQIBd3QQQyZCctrTMnncwWT
ehHR6jdaoo/Pxu81jpDnauYsTkwyhiLH7Vb3w158FaV9eK6efeuucEt4ZAct
/RaABR6g1OIP/4zqg1v7Q7u2Q3t8u57syAYEXX2nqp5mjc+axLtrzHNB9XGo
J1SKwVGrZGf18j0VyiDMtAAR5QCMyRRPEeCNkJaLYapqdyAs/jCYNLG1qtMi
hGOQEp7mJKIlcTj5gUUtmWUtY7b2CW410Hy37nQ51SAzjyZeL6/biOYI7o7X
MnwAzDlOxEs1OJHt4kU3vRefn4l7F1+29qh/P1N8ArZLYmR1uKuCCx6QRZcD
ZBF8DtXL4oOQLj31Fdios6sbcjJ+0Z0+vTPh2l3dgcNBGr45iAFjs7uwWOWy
f6CJiBs0og9gbEeKDSefOCGSBJBKLHNVoMQlIbwVpeg33dyRDz/6VJ6kGXGY
UjMoWiwShFDzm52V7tS8r6VPchzDF/MQZeGjqe8MEnFdZ8IFV/uTenLA5Rns
6tMsXweiv9bVvian+Jz+w8+af0pY4LV5PdR/D17/pZ/U74leTvbajo/c8GP6
iep1u/2T2o7/C21JkX7Ptsp1vjJfKBfdkGNPu+J7KfvUEn7xlfoRGX9zAW2h
RmbClU+yI5VjL0qxqd7nwMpbIg/dTSPh9Gd0G4ntzuSjF6h/ZjPeRRx+Cbfn
UMPnX379+OnZ5Q7DcnRyNBx/8vFHJ8Pjb8Yncua3wqV74SaecOMPdZrmGZdN
c4G4GlKunI9vjQmXMvX0AAf8uKCXy0tgyZuuMmb7VGMd35BloqX7qzgQAI5u
VNPrUHqFPM0kHKW/nARgggMzchQK7J9VPqLjHdMZHJvuFgp/ccHcV8jS0Kg4
I/nmjZD0d3c/SnzfidwSE5cEbFw5NLk83L8cNiiI5KsU0FUD1eZviBrITSih
jr6Ir6xR1tHbWKTyN3aHzG53aMDkoH09ERwv+eZxjPZwiQpD6d7FOUYuzgkj
BesVV7lvXlAUL5+vlnFibz178mFmHPyUyzp8wJgRpAvdzLrS1wAZ4ztpfNUO
ni8TUrkNX4myecfC9t1HPi6KPXe1UT5UR3CHgZiVTi4w8U5iwbPfvHxlJOfA
/Q23zDFcAigVYv5ixXv2yen56fbbXsQPrF2U0jLttRzp3Yy4hgadnaaolCQK
X3FcS4f5/wQ87QM/WAAA

-->

</rfc>
