Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit analysis #3

Merged
merged 7 commits into from
Jul 5, 2024
Merged

Limit analysis #3

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
de44f9a
No normative, just an option
martinthomson Jun 24, 2024
8acb6b6
An updated usage limit analysis
martinthomson Jun 24, 2024
a6c4aa3
q
martinthomson Jun 24, 2024
f43bd48
Get it right
martinthomson Jun 24, 2024
7e55ac6
Revise language for clarity
martinthomson Jun 24, 2024
88c7d1a
article
martinthomson Jun 26, 2024
d367e3a
sign-not
martinthomson Jun 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 59 additions & 27 deletions draft-thomson-ppm-prss.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -162,8 +162,8 @@ in most cases.

This document uses the system of describing, naming, and identifying KEMs
defined in {{!HPKE=RFC9180}}. For use in PRSS, a KEM is first chosen for use.
KEM identifiers from {{Section 7.1 of !HPKE}} MAY be used for identification or
negotiation.
KEM identifiers from {{Section 7.1 of !HPKE}} are used for identification and
can be used in negotiation.

Once a KEM is chosen, one participant is assigned the "sender" role; the other
participant becomes the "receiver".
Expand Down Expand Up @@ -208,7 +208,8 @@ to the KDF to produce a shared value that is unique to that context.

This document uses the system of describing, naming, and identifying KEMs
defined in {{!HPKE=RFC9180}}. A KDF is first chosen for use. KDF identifiers
from {{Section 7.2 of !HPKE}} MAY be used for identification or negotiation.
from {{Section 7.2 of !HPKE}} are used for identification and can be used in
negotiation.


## Entropy Extraction {#extract}
Expand Down Expand Up @@ -334,8 +335,8 @@ information is summarized in {{table-prf}}.

| PRF Name | Identifier | Nk | Mi | Mo |
|:--|--:|--:|--:|--:|--:|
| PRF_AES_128 | 0x0001 | 16 | 2<sup>64</sup> | 2<sup>128</sup> |
| PRF_AES_256 | 0x0002 | 32 | 2<sup>64</sup> | 2<sup>128</sup> |
| PRF_AES_128 | 0x0001 | 16 | 2<sup>42</sup> | 2<sup>128</sup> |
| PRF_AES_256 | 0x0002 | 32 | 2<sup>43</sup> | 2<sup>128</sup> |
{: #table-prf title="Pseudorandom Function Summary"}

Both AES PRFs use the same process:
Expand Down Expand Up @@ -425,7 +426,7 @@ simplest indexing scheme sets `M` to 1.
Indexed usage is best suited to applications where individual records might be
processed concurrently. Using indices based on identifiers from an application,
such as record indices, can ensure that the same PRF input is only used once and
frees the randomness context from needing its own counter.
frees the randomness context from maintaining its own counter.

Binary sampling ({{binary}}) or oversampling ({{oversampling}}) are best suited
for use with indexed modes. Rejection sampling ({{rejection}}) is likely to be
Expand Down Expand Up @@ -488,10 +489,11 @@ without bias. However, rejection sampling can require an indefinite number of
PRF invocations to produce a result. Rejection is more likely -- and so the
expected number of PRF invocations increases -- when `m` is closer to
2<sup>n-1</sup> than 2<sup>n</sup>. This can make rejection sampling unsuitable
for use with indexed randomness ({{indexed}}). Rejection sampling might be used
a limited number of times before falling back to oversampling
({{oversampling}}), which can reduce oversampling bias while capping the number
of PRF invocations.
for use with indexed randomness ({{indexed}}).

Rejection sampling might be used a limited number of times before falling back
to oversampling ({{oversampling}}), which can reduce oversampling bias while
capping the number of PRF invocations.


## Oversampling {#oversampling}
Expand Down Expand Up @@ -521,7 +523,8 @@ more general analysis of these mechanisms.
## Usage Limit Analysis

The usage limits in {{aes}} ensure that attacker advantage remains small.
Theorem 4 of {{?GKWY20}} shows that advantage comprises two components:
Theorem 4 of {{?GKWY20}} models the underlying permutation function as an ideal
PRP and shows that attacker advantage comprises two components:

* a computational limit of `q^2/(2*2^k)` that is based solely on attacker work
(`q`) and the key size (`k`) of the permutation
Expand All @@ -530,22 +533,51 @@ Theorem 4 of {{?GKWY20}} shows that advantage comprises two components:
of uses of the PRF (`p`), with the entropy of the pseudorandom function (`b`)
acting to counteract attacker advantage

This analysis will focus on the second component, as the first component is
unaffected by usage of the PRF.

The first component applies to an idealized PRF. This provides statistical
security of 2<sup>-64</sup> for AES-128 based on the birthday bound.

Consequently, there is no significant benefit to limiting the second component
to be significantly smaller than 2<sup>-64</sup>. This analysis assumes the
same limit for AES-256 for simplicity. AES uses the same block size for all
variants, so the entropy (`b`) is the same at 128 bits.

For an overall advantage of 2<sup>-63</sup>, the usage component is limited to
2<sup>-64</sup>, leading to a limit of 2<sup>64</sup> uses of the PRF, as shown
in {{table-prf}}.

This assumes that AES is modeled as an ideal pseudorandom permutation.
The number of uses (`p`) are only affected by the second component, as the first
component is unaffected by usage of the permutation. However, the first
component guides our assumptions about the number of times the attacker might be
willing to invoke the permutation (`q`). The result shows that statistical security is
provided based on the birthday bound. For instance, `q` being 2<sup>-64</sup>
results in a disastrous advantage of 0.5 for the AES-128 key size of 128 bits.
This first term therefore places an upper bound on the value that `q` can take
before an attacker can rely solely on this computational limit.

<!--
2^{-a}/2 >= q^2/2^k/2
2^{-a} >= q^2/2^k
2^{k-a} >= q^2
2^{(k-a)/2} >= q

With this value of q, the second component then becomes:

2^{-a}/2 >= 2pq/2^b
>= 2p.2^{(k-a)/2}/2^b
>= 2p.2^{-a/2}.2^{k/2-b}
2^{-a/2}/4/2^{k/2-b} >= p
2^{b-k/2-a/2-2} >= p
p <= 2^{b-(k+a)/2-2}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have you build a good intuition around ρ value from that paper? I read it a few times but I don't seem to understand the role of pseudo-random function in AES encryption

Copy link
Member Author

@martinthomson martinthomson Jun 28, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way to think of AES is as a PRP (which is a narrower formulation than a PRF). The $\rho$ parameter is defined as the entropy of $\mathcal{R}$.

image

Follow this through to Theorem 4, where they look at their $\mathrm{MMO}^\pi$ function:

$$ \mathsf{MMO}^\pi(x) \overset{\mathrm{def}}{=} \pi(x)\oplus x $$

There, they use $\mathcal{R}$ to mask the input, in addition to the masking from $\pi(\cdot)$ (i.e., AES) and say:

In the real world, the second oracle is $\mathcal{O}^\mathrm{cr}_R(\cdot) = \mathsf{MMO}^\pi(R\oplus\cdot)$ (for $R$ sampled from a distribution $\mathcal{R}$).

From this, $\rho$ is a limit on the entropy that can pass into the permutation. AES has a similar limiting effect, so effectively $\rho$ is equivalent to the entropy of AES. So $\rho$ is, in effect, the block size of 128 bits.

(Edited to correct differences between $\rho$ and $\pi(\cdot)$.)

-->

We use this first component to bound the value of `q` for the second component.
If advantage is equally divided between each component we can bound `q` to be at
most `2^((k-a)/2)`, where `a` is the desired attacker advantage in bits (that
is, advantage is at most 2<sup>-a</sup>).

Using that value for `q` and an advantage of `(2^a)/2` for the second component
leads to a limit for `p` of `2^(b-(k+a)/2-2)`. For example, to obtain 40 bits
of security, the value of `p` for AES-128 is limited to 2<sup>42</sup>, which
assumes a value of `q` no more than 2<sup>44</sup>.

For AES-256, the larger key size means that the first component is negligible
for any value of `q`, unless `p` and `a` are both very small. This is due to
AES-256 having the same 128-bit block size as AES-128. Consequently, increasing
`q` only reduces the value of `p`.

On this basis, the same `q` value can be used for AES-256 as for AES-128. The
usage limit for AES-256 can be doubled to `2^(b-(k+a)/2-1)` (2<sup>43</sup> for
40 bits of security; the first component is a negligible 2<sup>-169</sup>).

This analysis models AES as an ideal pseudorandom permutation.


## Formal Analysis
Expand Down
Loading