When the server is providing the client with its crypto code, the server can read the plaintext no matter what. I don't like these bullshit false promises.
If you are worried that China may own one of the root certs in your browser, remove the certs you don't trust. Hell, remove all the certs. Every mainstream browser allows you to do that. In most of them, you can even set up permanent exceptions for Amazon.com after you strip your certs out.
Meanwhile, HTTPS/TLS has over a decade of the most intensive study anywhere on the planet, and your favorite half-assed ad-hoc bespoke random "crypto-cat" scheme... does not.
> When the server is providing the client with its crypto code, the server can read the plaintext no matter what.
What? I don't see how that's necessarily true. The crypto code can be verified and if it turns out to be fine, then the server shouldn't be able to read the plaintext "no matter what." That's silly.
> Hell, remove all the certs.
Is this seriously your solution?
> ...does not.
This borders on ad-homimen - under this logic, we should never strive to attempt creating new techniques but always rely on 10+year old ones. There will always be new techniques that need testing, and the fact that older ones exist is not sufficient to prevent the study and advancement of new research.
Yes. I'm saying that if your execution environment is a browser, and your security code comes from a server, that server is going to be able to read your plaintext no matter what.
Yes. If you think China is intercepting your HTTPS traffic, remove all the root certs in your browser. Then browse to the key sites you're worried about protecting and create exceptions for each of them. China will not be able to use "fake certs" to intercept traffic to those servers.
Yes. In cryptosystems, 10+ years of study does count for a lot.
> that server is going to be able to read your plaintext no matter what.
I'm truly sorry, I follow you on Twitter and actually really respect your opinion, but that's just nonsense. the HTML, CSS and JS can all be verified, either by a plugin or by researchers studying what the server is sending, or by a variety of other ways. This ultimatum you're giving is silly.
> Yes. If you think China is intercepting your HTTPS traffic, remove all the root certs in your browser. Then browse to the key sites you're worried about protecting and create exceptions for each of them. China will not be able to use "fake certs" to intercept traffic to those servers.
That is not a real solution.
> Yes. In cryptosystems, 10+ years of study does count for a lot.
Of course - I never suggested it didn't - but that doesn't mean that new research can't undergo and survive skepticism.
You just stuck a plugin into the mix. You can make crypto work from a browser plugin. Just use the plugin for all the crypto; what the hell is the point of Javascript cryptography if you have a plugin? That's reckless to the point of negligence.
Although I don't really appreciates the tone here, I think that point that you are trying to make is that, if we are just going to use plugin, just use plugin all the way; why bother with Javascript for crypto at all.
I seriously don't appreciate your debate style, but I feel obligated to point out that your question has been discussed at another section of this thread: http://news.ycombinator.com/item?id=2935473
I think the point you are missing is that even if researchers/people can verify what the server is sending in general, there's no way for you to verify that the HTML/CSS/JS it sends you at that particular point in time is the same as the generally vetted version.
If you are worried that China may own one of the root certs in your browser, remove the certs you don't trust. Hell, remove all the certs. Every mainstream browser allows you to do that. In most of them, you can even set up permanent exceptions for Amazon.com after you strip your certs out.
Meanwhile, HTTPS/TLS has over a decade of the most intensive study anywhere on the planet, and your favorite half-assed ad-hoc bespoke random "crypto-cat" scheme... does not.