CFB is the only mode (based on discussions on the IRTF CFRG list) that
allows for "encrypt in place" in a field of 8 or 16 bytes. The IV can
be exchanged out-of-band, as there is NO room in the F3411 datagram (25
bytes) for anything extra.
ASTM F3411 (UAS Remote ID) is behind the ASTM paywall, but MAVlink has
implemented it so you can see there the System and Operator ID messages
(Type 0x4 & 0x5). The draft describes how the Operator Location and ID
fields are encrypted. We did consider CTR, but that has a raft of
challenges (like where to find those extra 2 bytes) that CFB does not
have. We cannot use ANY of the AEAD modes; totally not applicable.
Interestingly, it is the first responders that are calling out to
encrypt these fields, as they only want authorized observers to locate
their UA operators. The CAAs will most likely allow for this once we
have the other pieces in place.
BTW, I am struggling with some aspects of my proposal for security for
ADS-B and those messages are even smaller. :)
Robert
On 1/28/26 7:37 AM, Alex Gaynor wrote:
Is there a particular reason CFB is being used in a new RFC?
Alex
On Wed, Jan 28, 2026 at 5:57 AM Robert Moskowitz via Cryptography-dev
<[email protected]> wrote:
Paul,
I note in the changelog that CFB is being moved to deprecated.
Please review the use of CFB for "encrypt in place" for UAS Remote ID Operator
PII privacy:
https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/
Operator Privacy is being added into the next revision of ASTM F3411 Remote ID
and my draft is the only one put forward to provide this functionality.
I don't know if this is enough to sway the move to drop CFB, as I do not know
how Operator Privacy will be implemented over the next couple years.
But a "heads up" to one valuable use of CFB.
Thank you
Robert Moskowitz
On 1/27/26 7:34 PM, Paul Kehrer via Cryptography-dev wrote:
PyCA cryptography 46.0.4 has been released to PyPI. cryptography includes both
high level recipes and low level interfaces to common cryptographic algorithms
such as symmetric ciphers, asymmetric algorithms, message digests, X.509, key
derivation functions, and much more. We support Python 3.8+, and PyPy3 3.11.
Changelog (https://cryptography.io/en/latest/changelog/#v46-0-4)
* Dropped support for win_arm64 wheels.
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.5.5.
-Paul Kehrer (reaperhulk)
_______________________________________________
Cryptography-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/cryptography-dev.python.org
Member address: [email protected]
_______________________________________________
Cryptography-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/cryptography-dev.python.org
Member address: [email protected]
_______________________________________________
Cryptography-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/cryptography-dev.python.org
Member address: [email protected]
