Open catid opened 5 years ago
I'm fond of the architecture used by tcpcrypt-- the transport layer provides an ephemerally keyed connection and makes available a session ID to the application which will match on both sides if and only if there is no MITM. Then it's on the application to authenticate the session ID, or not... This makes sense because what "talking to the right party" even means is highly application specific and often requires interacting with the user in non-trivial ways. But establishing a DH protected transport requires no such interaction with the user and seldom has much interaction with the rest of the application (things like zero round trip establishment being an obvious exception).
As far as the risk of messing up, not having crypto is just another way of having really broken crypto. The null cipher is still a cipher. I think it's totally reasonable to say that "Foo isn't designed for high security applications and hasn't been reviewed for those purposes. The author of Foo believes that its irresponsible to not even attempt to provide cryptographic privacy, so foo does so, but for most purposes you should probably act as if foo did not use cryptography when making decisions about protecting your data.". There are cases where there really is no reason for cryptography but as technology becomes more critical in our lives and the ways of exploiting it become more sophisticated these cases are fewer and fewer. Pretty much every one of the applications listed on tonk's "Appropriate applications" would be kinda crazy to deploy without crypto, and it would be a lot harder for applications to gain authentication and privacy on top of tonk. :)
[As an aside, Tonk looks really cool.]
Many modern applications care about data security in flight. Making it part of Tonk makes a lot more sense than hacking it in at the application layer, but will require a lot more effort.
Major problems to overcome: (1) 0-RTT does not really work with public key cryptography. There are some complicated nonce-reuse strike register schemes that could solve this problem but it's not cheap or easy. (2) Public key cryptography requires public key infrastructure, which is a whole other system to build and incorporate. Alternatively I could assume the user will take care of that.
Drawbacks to incorporating cryptography: (1) Additional CPU and packet overhead (more expensive to run servers) (2) Additional complexity (more bugs) (3) Liability for the author - If I mess it up then it causes problems for people