Skip to content

Commit

Permalink
Script updating gh-pages from 7ca309f. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Feb 29, 2024
1 parent 3b471e2 commit 9c75148
Show file tree
Hide file tree
Showing 3 changed files with 40 additions and 32 deletions.
20 changes: 12 additions & 8 deletions draft-ietf-sframe-enc.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1780,8 +1780,8 @@ <h3 id="name-sframe-header">
<dd class="break"></dd>
<dt id="section-4.3-6.3">Key or Key Length (K, 3 bits):</dt>
<dd style="margin-left: 1.5em" id="section-4.3-6.4">
<p id="section-4.3-6.4.1">This field contains the Key ID (KID) if the X flag is set to 0, or the key id
length, minus one, if set to 1.<a href="#section-4.3-6.4.1" class="pilcrow"></a></p>
<p id="section-4.3-6.4.1">If the X flag is set to 0, this field contains the Key ID. If the X flag is
set to 1, then it contains the length of the Key ID, minus one.<a href="#section-4.3-6.4.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
<dt id="section-4.3-6.5">Extended Counter Flag (Y, 1 bit):</dt>
Expand Down Expand Up @@ -1945,9 +1945,9 @@ <h4 id="name-key-selection">
<p id="section-4.4.1-1">Each SFrame encryption or decryption operation is premised on a single secret
<code>base_key</code>, which is labeled with an integer KID value signaled in the SFrame
header.<a href="#section-4.4.1-1" class="pilcrow"></a></p>
<p id="section-4.4.1-2">The sender and receivers need to agree on which key should be used for a given
KID. Moreover, senders and receivers need to agree on whether keys will be used
for encryption or decryption only. The process for provisioning keys and their KID
<p id="section-4.4.1-2">The sender and receivers need to agree on which <code>base_key</code> should be used for a given
KID. Moreover, senders and receivers need to agree on whether a <code>base_key</code> will be used
for encryption or decryption only. The process for provisioning <code>base_key</code> values and their KID
values is beyond the scope of this specification, but its security properties will
bound the assurances that SFrame provides. For example, if SFrame is used to
provide E2E security against intermediary media nodes, then SFrame keys need to
Expand All @@ -1959,10 +1959,10 @@ <h4 id="name-key-selection">
and the counter is incremented after successful encryption. When decrypting,
the <code>base_key</code> for decryption is selected from the available keys using the KID
value in the SFrame Header.<a href="#section-4.4.1-4" class="pilcrow"></a></p>
<p id="section-4.4.1-5">A given key MUST NOT be used for encryption by multiple senders. Such reuse
<p id="section-4.4.1-5">A given <code>base_key</code> MUST NOT be used for encryption by multiple senders. Such reuse
would result in multiple encrypted frames being generated with the same (key,
nonce) pair, which harms the protections provided by many AEAD algorithms.
Implementations MUST mark each key as usable for encryption or decryption,
Implementations MUST mark each <code>base_key</code> as usable for encryption or decryption,
never both.<a href="#section-4.4.1-5" class="pilcrow"></a></p>
<p id="section-4.4.1-6">Note that the set of available keys might change over the lifetime of a
real-time session. In such cases, the client will need to manage key usage to
Expand All @@ -1977,7 +1977,7 @@ <h4 id="name-key-selection">
<h4 id="name-key-derivation">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-key-derivation" class="section-name selfRef">Key Derivation</a>
</h4>
<p id="section-4.4.2-1">SFrame encrytion and decryption use a key and salt derived from the <code>base_key</code>
<p id="section-4.4.2-1">SFrame encryption and decryption use a key and salt derived from the <code>base_key</code>
associated to a KID. Given a <code>base_key</code> value, the key and salt are derived
using HKDF <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span> as follows:<a href="#section-4.4.2-1" class="pilcrow"></a></p>
<div class="alignLeft art-text artwork" id="section-4.4.2-2">
Expand Down Expand Up @@ -2028,9 +2028,13 @@ <h4 id="name-encryption">
def encrypt(CTR, KID, metadata, plaintext):
sframe_key, sframe_salt = key_store[KID]

# encode_big_endian(x, n) produces an n-byte string encoding the integer x in
# big-endian byte order.
ctr = encode_big_endian(CTR, AEAD.Nn)
nonce = xor(sframe_salt, CTR)

# encode_sframe_header produces a byte string encoding the provided KID and
# CTR values into an SFrame Header.
header = encode_sframe_header(CTR, KID)
aad = header + metadata

Expand Down
50 changes: 27 additions & 23 deletions draft-ietf-sframe-enc.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -371,9 +371,9 @@ Alice | (per-frame) (per-packet) | | |
Extended Key Id Flag (X, 1 bit): Indicates if the K field contains
the key id or the Key ID length.

Key or Key Length (K, 3 bits): This field contains the Key ID (KID)
if the X flag is set to 0, or the key id length, minus one, if set
to 1.
Key or Key Length (K, 3 bits): If the X flag is set to 0, this field
contains the Key ID. If the X flag is set to 1, then it contains
the length of the Key ID, minus one.

Extended Counter Flag (Y, 1 bit): Indicates if the C field contains
the counter or the counter length.
Expand Down Expand Up @@ -451,15 +451,15 @@ Alice | (per-frame) (per-packet) | | |
single secret base_key, which is labeled with an integer KID value
signaled in the SFrame header.

The sender and receivers need to agree on which key should be used
for a given KID. Moreover, senders and receivers need to agree on
whether keys will be used for encryption or decryption only. The
process for provisioning keys and their KID values is beyond the
scope of this specification, but its security properties will bound
the assurances that SFrame provides. For example, if SFrame is used
to provide E2E security against intermediary media nodes, then SFrame
keys need to be negotiated in a way that does not make them
accessible to these intermediaries.
The sender and receivers need to agree on which base_key should be
used for a given KID. Moreover, senders and receivers need to agree
on whether a base_key will be used for encryption or decryption only.
The process for provisioning base_key values and their KID values is
beyond the scope of this specification, but its security properties
will bound the assurances that SFrame provides. For example, if
SFrame is used to provide E2E security against intermediary media
nodes, then SFrame keys need to be negotiated in a way that does not
make them accessible to these intermediaries.

For each known KID value, the client stores the corresponding
symmetric key base_key. For keys that can be used for encryption,
Expand All @@ -471,10 +471,10 @@ Alice | (per-frame) (per-packet) | | |
encryption. When decrypting, the base_key for decryption is selected
from the available keys using the KID value in the SFrame Header.

A given key MUST NOT be used for encryption by multiple senders.
A given base_key MUST NOT be used for encryption by multiple senders.
Such reuse would result in multiple encrypted frames being generated
with the same (key, nonce) pair, which harms the protections provided
by many AEAD algorithms. Implementations MUST mark each key as
by many AEAD algorithms. Implementations MUST mark each base_key as
usable for encryption or decryption, never both.

Note that the set of available keys might change over the lifetime of
Expand All @@ -487,7 +487,7 @@ Alice | (per-frame) (per-packet) | | |

4.4.2. Key Derivation

SFrame encrytion and decryption use a key and salt derived from the
SFrame encryption and decryption use a key and salt derived from the
base_key associated to a KID. Given a base_key value, the key and
salt are derived using HKDF [RFC5869] as follows:

Expand Down Expand Up @@ -527,17 +527,21 @@ Alice | (per-frame) (per-packet) | | |
encryption operation, together with application-provided metadata
about the encrypted media (see Section 9.4).

def encrypt(CTR, KID, metadata, plaintext):
sframe_key, sframe_salt = key_store[KID]
def encrypt(CTR, KID, metadata, plaintext):
sframe_key, sframe_salt = key_store[KID]

ctr = encode_big_endian(CTR, AEAD.Nn)
nonce = xor(sframe_salt, CTR)
# encode_big_endian(x, n) produces an n-byte string encoding the integer x in
# big-endian byte order.
ctr = encode_big_endian(CTR, AEAD.Nn)
nonce = xor(sframe_salt, CTR)

header = encode_sframe_header(CTR, KID)
aad = header + metadata
# encode_sframe_header produces a byte string encoding the provided KID and
# CTR values into an SFrame Header.
header = encode_sframe_header(CTR, KID)
aad = header + metadata

ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext)
return header + ciphertext
ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext)
return header + ciphertext

For example, the metadata input to encryption allows for frame
metadata to be authenticated when SFrame is applied per-frame. After
Expand Down
2 changes: 1 addition & 1 deletion index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ <h2>Preview for branch <a href="secdir">secdir</a></h2>
<tr>
<td><a href="secdir/draft-ietf-sframe-enc.html" class="html draft-ietf-sframe-enc" title="Secure Frame (SFrame) (HTML)">SFrame</a></td>
<td><a href="secdir/draft-ietf-sframe-enc.txt" class="txt draft-ietf-sframe-enc" title="Secure Frame (SFrame) (Text)">plain text</a></td>
<td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://sframe-wg.github.io/sframe/draft-ietf-sframe-enc.txt&amp;url_2=https://sframe-wg.github.io/sframe/secdir/draft-ietf-sframe-enc.txt" class="diff draft-ietf-sframe-enc">diff with main</a></td>
<td>same as main</td>
</tr>
</table>
<h2>Preview for branch <a href="murray">murray</a></h2>
Expand Down

0 comments on commit 9c75148

Please sign in to comment.