Re:Reversing 'France Identité': The New French Digital ID
by ewi_ on Friday October 06, 2023 @10:08AM
(#37790992)
> What I'd like to see is a standardized protocol for this exact use case
Does Noise Protocol provide what you're looking for? http://www.noiseprotocol.org/
Re:Reversing 'France Identité': The New French Digital ID
by qweqwe14 on Friday October 06, 2023 @10:56AM
(#37791613)
I've heard about Noise but didn't think to mention it for some reason. Yeah, Noise is basically what I was trying to describe. Such a protocol doesn't necessarily have to use Noise though, however Noise helps avoid some implementation pitfalls that people not very experienced with crypto can make.
Re:Reversing 'France Identité': The New French Digital ID
by runeks on Friday October 06, 2023 @10:09AM
(#37791001)
I agree that runtime algorithm negotiation makes sense to avoid sometimes. So just make a spec that factors out the algorithm, and make the choice of algorithm a compile-time thing.
Then there's no need to hardcode anything in the spec, you can just say you're using the protocol RFC-12345-ChaCha20Poly1305 — with RFC-12345 being the spec that leaves out the algorithm.
Re:Reversing 'France Identité': The New French Digital ID
by qweqwe14 on Friday October 06, 2023 @11:13AM
(#37791863)
Yes, that's pretty much what I meant by "standardized". You'd be able to pick AEAD cipher, KDF, signature algorithm, KEX algorithm etc., while the spec would only describe the protocol itself without enforcing specific algorithms. Noise Protocol pretty much does this already: you provide a string that describes the set of algorithms you will be using, e.g. "Noise_NN_25519_ChaChaPoly_BLAKE2s"
Another thing to consider is that TLS supports multiple use cases and has multiple versions, so it has stuff like algorithm negotiation, version negotiation and some other things that are really unnecessary when you just want a secure channel between two parties with pre-shared keys[1]. If you strip all those extra things from TLS you'll basically end up making your own protocol anyway.
What I'd like to see is a standardized protocol for this exact use case: two parties with pre-shared public keys, no algo negotiation[2], and only sending what's really needed over the wire without extra metadata. TLS is not quite right for this use case IMO.
[1] Yes, TLS-PSK exists but it's largely an afterthought and not always implemented by libraries, because it's considered a niche use case for TLS. To some degree, same thing can be said about client certificates.
[2] I think the article does say that they have algo negotiation in their custom implementation anyway. Personally I'd hardcode something like ChaCha20Poly1305, mainly because it's reasonably fast in software and on low-power devices.