Isn’t Noise the exact opposite of what we should providing developers? We need near-zero choices for non-crypto-expert developers and a misuse-resistant API:
secure_connect(endpoint,my_keypair);
And pretty much nothing else. No options. No choices. Even nonces and message serializaion are handled by the API. What NaCl should have been.
Part of the issue is that if there are no choices for common scenarios, developers go and invent something (poorly).
In an https competitor style situation, what is my_keypair from your example? The server doesn't care who you are. You do however care who the server is, so you need an input for server identity.
If I'm starting a chat session with anonymous people I might only care about the endpoint, or if we care about everyone it would be more like secure_connect(endpoint, their_keys, my_keys).
But the very existence of this matrix will make Noise insecure in actual applications.
It’s like WS-Security/OAUTH/PGP/JOSE all over again. Another overly-flexible “framework” that’s a minefield of footcannons for people to misuse if they’re not trained and experienced in crypto.
If the security bar is going to be raised, repeating history isn’t the way to do it.
We should have the safe, just-connect version of Noise; my understanding is NoiseSocket wants to be that.
I disagree with the comparison you made to JOSE et al. The problem with those specs is the specification and implementation complexity of the product. But actual noise implementations like WG are counterexamples to this pathological mode: they have 1 mode with well-known properties. The real problem is that people think of Noise as a protocol spec and it’s really a roadmap for designing a protocol.
6 comments
[ 5.5 ms ] story [ 44.3 ms ] threadsecure_connect(endpoint,my_keypair);
And pretty much nothing else. No options. No choices. Even nonces and message serializaion are handled by the API. What NaCl should have been.
In an https competitor style situation, what is my_keypair from your example? The server doesn't care who you are. You do however care who the server is, so you need an input for server identity.
If I'm starting a chat session with anonymous people I might only care about the endpoint, or if we care about everyone it would be more like secure_connect(endpoint, their_keys, my_keys).
Pretty soon you've built this matrix.
It’s like WS-Security/OAUTH/PGP/JOSE all over again. Another overly-flexible “framework” that’s a minefield of footcannons for people to misuse if they’re not trained and experienced in crypto.
If the security bar is going to be raised, repeating history isn’t the way to do it.
I disagree with the comparison you made to JOSE et al. The problem with those specs is the specification and implementation complexity of the product. But actual noise implementations like WG are counterexamples to this pathological mode: they have 1 mode with well-known properties. The real problem is that people think of Noise as a protocol spec and it’s really a roadmap for designing a protocol.
“Do not use this library or try to implement this spec without formal training in applied cryptography. Use X instead”.
Make it very clear who the target audience is, or we’ll end up another generation of ad-hoc insecure crypto.