jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-sframe-enc

Commentary: Specifically : Acknowledgements Overhead Test Vectors 
 Merging my own pull request because this is purely editorial .
The encryption overhead will vary between audio and video streams,
because in audio each packet is considered a separate frame, so it
will always have extra MAC and IV, however a video frame usually
consists of multiple RTP packets.
The constant 1 is the SFrame header byte and 4 bytes for the HBH
authentication tag for both audio and video packets.
Up to 3 bytes frame counter (3.8 days of data for 20ms frame
duration) and 4 bytes fixed MAC length.
RFC8723 has significant overhead over SFrame because the overhead is
per packet, not per frame, and OHB (Original Header Block) which
duplicates any RTP header/extension field modified by the SFU.
I-D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/
SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't
use the OHB anymore, however it still does per packet encryption
using SRTP.
Below the the overheard in I-D.murillo-perc-lite implemented by
Cosmos Software which uses extra 11 bytes per packet to preserve the
"PT", "SEQ_NUM", "TIME_STAMP" and "SSRC" fields in addition to the
extra MAC tag per packet.
For a conference with a single incoming audio stream (@ 50 pps) and 4
incoming video streams (@200 Kbps), the savings in overhead is 34800
- 9600 = ~25 Kbps, or ~3%.
This document makes no requests of IANA.
An implementation should be able to encrypt with the input values
and the plaintext to produce the ciphertext.
An implementation must be able to decrypt with the input values
and the ciphertext to generate the plaintext.
Line breaks and whitespace within values are inserted to conform to
the width requirements of the RFC format.  They should be removed
before use.  These test vectors are also available in JSON format at
TestVectors.
Draft: draft-ietf-sframe-enc

Commentary: Replaces , using bytes instead of bits and rebasing on current main .
In the "AES" suites, the length of the authentication tag is
indicated by the last value: "_128" indicates a hundred-twenty-eight-
bit tag, "_80" indicates a eighty-bit tag, "_64" indicates a sixty-
four-bit tag and "_32" indicates a thirty-two-bit tag.
In the suite names, the length of the authentication tag is indicated
by the last value: "_128" indicates a hundred-twenty-eight-bit tag,
"_80" indicates a eighty-bit tag, "_64" indicates a sixty-four-bit
tag and "_32" indicates a thirty-two-bit tag.
Draft: draft-ietf-sframe-enc

Commentary: I was n't sure if CM was meant for " Counter Mode " , if so , I thought using the standard terminology would be better ... : ) 
 I also originally got very confused by the CM acronym so definitely suggest taking the change . 
 would you be able to rebase your commit ? 
 Should be good now . ( ~Note that I did not update the label in to avoid affecting the test vectors.~ Pushed a commit with updated test vectors . ) 
 This PR looks good to me . I agree with the terminology change and the changes to the known - answer test generator . I re - ran the known - answer test generator locally and confirmed that it produced the test vectors in the PR.LGTM . This might conflict with depending on which PR gets merged first .
The AEAD encryption and decryption functions are then composed of
individual calls to the CM encrypt function and HMAC.  The resulting
MAC value is truncated to a number of bytes "tag_len" fixed by the
ciphersuite.
The AEAD encryption and decryption functions are then composed of
individual calls to the CTR encrypt function and HMAC.  The resulting
MAC value is truncated to a number of bytes "tag_len" fixed by the
ciphersuite.
Draft: draft-ietf-sframe-enc

Commentary: The signature mechanism was removed from SFrame some time ago . This PR removes a few remaining references to it . 
 Seems good but needs rebasing 
 I think we are ok to merge this PR ?
If the participants in a call have a pre-existing E2E-secure channel,
they can use it to distribute SFrame keys.  Each client participating
in a call generates a fresh encryption key and optionally a signing
key pair.  The client then uses the E2E-secure channel to send their
encryption key and signing public key to the other participants.
If the participants in a call have a pre-existing E2E-secure channel,
they can use it to distribute SFrame keys.  Each client participating
in a call generates a fresh encryption key.  The client then uses the
E2E-secure channel to send their encryption key to the other
participants.
If a new participant joins mid-call, they will need to receive from
each sender (a) the current sender key for that sender, (b) the
signing key for the sender, if used, and (c) the current KID value
for the sender.  Evicting a participant requires each sender to send
a fresh sender key to all receivers.
If a new participant joins mid-call, they will need to receive from
each sender (a) the current sender key for that sender and (b) the
current KID value for the sender.  Evicting a participant requires
each sender to send a fresh sender key to all receivers.
MLS also provides an authenticated signing key pair for each
participant.  When SFrame uses signatures, these are the keys used to
generate SFrame signatures.
participant's media.  Note that in order to prevent impersonation by
a malicious participant (not the SFU) usage of the signature is
required.  In case of video, the a new signature should be started
each time a key frame is sent to allow the receiver to identify the
source faster after a switch.
participant's media.
Note that in order to prevent impersonation by a malicious
participant (not the SFU), a mechanism based on digital signature
would be required.  SFrame does not protect against such attacks.
Draft: draft-omara-sframe

Commentary: PR fixes PR also updates AES - CTR test vectors accordingly . PR clarifies that decryption ought to work but comparing encrypted data may sometimes fail . 
 The spec says :   ( LEN ): 3 bits This field indicates the length of the CTR fields in bytes . This probably means 000 is 1 byte , 001 is 2 bytes , and so on ... It would be good to clarify this .
Reserved (R): 1 bit This field MUST be set to zero on sending, and
MUST be ignored by receivers.  Counter Length (LEN): 3 bits This
field indicates the length of the CTR fields in bytes.  Extended Key
Id Flag (X): 1 bit Indicates if the key field contains the key id or
the key length.  Key or Key Length: 3 bits This field contains the
key id (KID) if the X flag is set to 0, or the key length (KLEN) if
set to 1.
Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR):
(Variable length) Frame counter value up to 8 bytes long.
Key length (KLEN): 3 bits The key length in bytes.  Key id (KID):
(Variable length) The key id value up to 8 bytes long.  Frame counter
(CTR): (Variable length) Frame counter value up to 8 bytes long.
Reserved (R): 1 bit This field MUST be set to zero on sending, and
MUST be ignored by receivers.  Counter Length (LEN): 3 bits This
field indicates the length of the CTR fields in bytes (1-8).
Extended Key Id Flag (X): 1 bit Indicates if the key field contains
the key id or the key length.  Key or Key Length: 3 bits This field
contains the key id (KID) if the X flag is set to 0, or the key
length (KLEN) if set to 1.
Frame counter byte length (LEN): 3bits The frame counter length in
bytes (1-8).  Key id (KID): 3 bits The key id (0-7).  Frame counter
(CTR): (Variable length) Frame counter value up to 8 bytes long.
Frame counter byte length (LEN): 3bits The frame counter length in
bytes (1-8).  Key length (KLEN): 3 bits The key length in bytes
(1-8).  Key id (KID): (Variable length) The key id value up to 8
bytes long.  Frame counter (CTR): (Variable length) Frame counter
value up to 8 bytes long.
An implementation should reproduce the output values given the input
values.  Encryption with the input values and the plaintext should
produce the ciphertext.  Decryption with the input values and the
ciphertext should produce the plaintext.
An implementation should reproduce the output values given the input
values: * An implementation should be able to encrypt with the input
values and the plaintext to produce the ciphertext.  * An
implementation must be able to decrypt with the input values and the
ciphertext to generate the plaintext.
Draft: draft-omara-sframe

Commentary: This PR adds test vectors for SFrame encryption . A Go script is provided that implements the header encoding and the relevant encryption routines , generates test vectors for salient cases , and serializes them as Markdown or JSON . The Markdown version is included in the specification directly .
This document makes no requests of IANA.
An implementation should reproduce the output values given the input
values.  Encryption with the input values and the plaintext should
produce the ciphertext.  Decryption with the input values and the
ciphertext should produce the plaintext.
Line breaks and whitespace within values are inserted to conform to
the width requirements of the RFC format.  They should be removed
before use.  These test vectors are also available in JSON format at
TestVectors.
Draft: draft-omara-sframe

Commentary: I do n't think we should not reference the inner / outer encryption , as we only define the e2ee encryption in the draft
The cipher suites defined in this draft use short authentication tags
for both inner and outer encryption, however it can easily support
other ciphers with full authentication tag if the short ones are
proved insecure.
The cipher suites defined in this draft use short authentication tags
for encryption, however it can easily support other ciphers with full
authentication tag if the short ones are proved insecure.
Draft: draft-omara-sframe

Commentary: Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
It uses AES counter mode for encryption with 128 bit key, SHA256 hash
for the HKDF key derivation.
Unlike messaging application, in video calls, receiving a duplicate
frame doesn't necessary mean the client is under a replay attack,
there are other reasons that might cause this, for example the sender
might just be sending them in case of packet loss.  SFrame decryptors
use the last received frame counter to protect against this.  It
allows only older frame pithing a short interval to support out of
order delivery.
The KeyId field in the SFrame header is used to find the right key
for that user, which is incremented by the sender when they change to
a new key.
Unlike messaging application, in video calls, receiving a duplicate
frame doesn't necessary mean the client is under a replay attack,
there are other reasons that might cause this, for example the sender
might just be sending them in case of packet loss.  SFrame decryptors
use the highest received frame counter to protect against this.  It
allows only older frame pithing a short interval to support out of
order delivery.
o A hash function This is used for the Key derivation and frame
hashes for signture.  We recommend using SHA256 hash function.