Ascon benchmarks results for tls1.2 and tls1.3
Mallikarjunarao Kosuri
John Preuß Mattsson
TLS 1.2 is obsolete since 2018 and will never be updated with Ascon. NIST requires support for TLS 1.3 by January 1, 2024. This applies not only to new systems but also already deployed ones. According the TLS standard you negotiate the latest supported version so in practice this means the the obsolete TLS 1.3 will never be negotiated by devices compliant with NIST. IETF has decided that TLS 1.2 is dead and that no new features will be approved.
Systems using Ascon is probably more likely to use a security protocol over UDP such as DTLS 1.3 or OSCORE/EDHOC which both rely on COSE
https://hal.science/hal-04382397/document
I notice that IEEE presentation had the following two bullets regarding Ascon:
Robert Moskowitz
On the topic of TLS, the primary issue is the limited number of resources on the mega as opposed to a complete lack of libraries existing. Doing some research after our last discussion, I found https://github.com/OPEnSLab-OSU/SSLClient, but its minimum recommended requirements are ~7kb of ram and ~110kb of flash storage which the mega barely hits. It likely would have issues running the microphone data transmission due to the large overhead.
So since, for this project, we are using a pershared secret, no key negotiation, I am looking for some stand-alone encryption envelope. Like, for example, ESP. It would be interesting if it is possible to find DTLS 1.3 without the key management code...
--
To unsubscribe from this group, send email to lwc-forum+...@list.nist.gov
Visit this group at https://groups.google.com/a/list.nist.gov/d/forum/lwc-forum
To unsubscribe from this group and stop receiving emails from it, send an email to lwc-forum+...@list.nist.gov.
Robert Moskowitz
Owner
HTT Consulting
C: 248-219-2059
F: 248-968-2824
E: r...@labs.htt-consult.com
There's no limit to what can be accomplished if it doesn't matter who gets the credit
John Mattsson
>It would be interesting if it is possible to find DTLS 1.3 without the key management code...
As today I think the only implementation of DTLS 1.3 is WolfSSL. Given a DTLS 1.3 implementation you can probably dig out the record layer code, but the record layer is quite simple so it is likely as easy (or easier) to implement the same thing yourself using Ascon. Then you can fine tune it according to your application. You probably don’t want the encrypted content format is you are not using DTLS 1.3 handshake.
What you need is [Epoch], [Sequence number], and AEAD Ciphertext.
- You need a bit epoch if you want to signal key change. QUIC uses a single bit. DTLS 1.3 uses two bits. If you do ratcheting, I would recommend to add a sequence
number as in MLS as this gives significantly better properties than in DTLS.
https://eprint.iacr.org/2024/220 - You need a sequence number if your packets arrive out of order. The sequence number can be fixed length like in ESP/DTLS 1.2, variable length as in OSCORE (a CBOR encoded int), or short and using a roll-over counter like in SRTP/DTLS 1.3. Replay protection is a must.
- If you want to encrypt sequence numbers you can do as in DTLS 1.3 and QUIC. Using the first ciphertext as plaintext/nonce and run a second pass Ascon/AES with a different key.
In the future I hope NIST will standardize a Ascon based accordion and derived functions.
https://csrc.nist.gov/Events/2024/accordion-cipher-mode-workshop-2024
https://csrc.nist.gov/csrc/media/Events/2024/accordion-cipher-mode-workshop-2024/documents/papers/comments-on-NIST-reqs-accordion-cipher.pdf
An AERO function based on an Ascon accordion could take care of nonce handling, nonce hiding, and replay protection while at the same time decreasing message overhead compared to doing sequence numbers and integrity independent of each other. That would be
an optimal stand-alone encryption envelope for constrained IoT.
Cheers,
John Preuß Mattsson
Robert Moskowitz
Pretty much parallels my thoughts but with more details, so I thank you for that.
It would be interesting to see how this might fly in the IETF. I will bring it up with Carston and others in Vancouver.
Bob