Natanael writes: > This assumes performance requirements only comes from settings like > datacenters, but this is also likely to eventually get used in embedded > devices some of which may be battery powered. Consider NFC devices such as > security keys (typically 1-10 mW, less than 100 Kbps, and few available > cycles).
Sure, security tokens could move from signatures to KEMs. The security token's public key is then a KEM public key. To prove it's online (and optionally approve and/or send some data), the token receives a KEM ciphertext from the verifier, and uses the KEM session key as the key for a MAC (or for an authenticated cipher to send secret data). For Kyber-768, communicating 1088 bytes of ciphertext at (say) 106 Kbps (minimum-speed NFC) takes 82 ms plus lower-layer overhead. Meanwhile the "few" cycles that you're talking about would be on, say, a Cortex-M4 running at tens of MHz (see https://eprint.iacr.org/2022/1225 running Dilithium on an OpenSK security token), and this CPU would hash 1088 bytes with SHA3-256 in about 2 ms (even without Keccak hardware). How is the user of the security token supposed to notice those 2 ms, or another 2 ms to also hash the public key? ---D. J. Bernstein _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
