We analyse the difficulty of the LPN problem in restricted memory.
In this paper, we study implementations of post-quantum signature schemes on
resource-constrained devices. We focus on verification of signatures and
cover NIST PQC round-3 candidates Dilithium, Falcon, Rainbow, GeMSS, and
SPHINCS+. We assume an ARM …
We make KEMTLS more efficient in scenarios where the client already has the server's long-term public key, for example through caching or because it's pre-installed.
We present an alternative to TLS 1.3, by authenticating using only Key-Encapsulation Mechanisms.
This allows us to get rid of handshake signatures, as post-quantum signature schemes are expensive,
both in bytes and computation times.
We investigate getting rid of signatures in TLS
In the RFC for TLS 1.3 (RFC8446) especially, the key exchange is defined in terms of (EC)DH key shares being exchanged. This limits us to algorithms which support non-interactive key exchanges, while this is not necessary for the security of TLS 1.3 as defined by RFC8446.1 As we would like to implement (post-quantum) KEMs into TLS 1.3, we will now describe the changes to the spec that would be required. As we can phrase (EC)DH key exchange as a key exchange with Key Encapsulation Mechanisms, this does not actually change TLS.
The new TLS 1.3 standard  does not yet provide any support for post-quantum algorithms. In this blog post we’ll be talking about how we could negotiate a post-quantum key exchange using a (post-quantum) Key Encapsulation Mechanism (KEM). In the NIST Standardisation effort , many KEMs are currently under consideration.