magikarp

13 ms·

91.
AES on the iPhone is Broken by Default(log.nadim.cc)
39 points by magikarp 15y ago|25 comments
92.
Internet Censorship and Activism in China(log.nadim.cc)
1 points by magikarp 15y ago|0 comments
93.
Thoughts on Matasano Security's Critique of Javascript Cryptography(log.nadim.cc)
2 points by magikarp 15y ago|0 comments
94.
by magikarp 15y ago
It's you who's being circular, sir.
95.
by magikarp 15y ago
I'm sorry, but I've already answered this, as a reply to one of your own comments. Please scroll up.
96.
by magikarp 15y ago
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
97.
by magikarp 15y ago
Um, no. The plugin is the same for all users - not everyone who downloads and runs GnuPG knows how to verify it - but some people might go as far as to either compile it from source or ever decompile it. If they find something suspicious, t
98.
by magikarp 15y ago
Simply because a plugin can be verified locally at length whereas a compromised CA can issue a fake cert that is very, very difficult to detect.
99.
by magikarp 15y ago
> unless you're using HTTPS in addition to your ad-hoc solution. Yes, I don't see why not. > It's straightforward to address them yourself simply by not trusting any CAs you don't trust. From that standpoint, we're assuming that eve
100.
by magikarp 15y ago
I disagree, on the grounds that the code can always be verified.
101.
by magikarp 15y ago
...
102.
by magikarp 15y ago
Whether you consider it "utterly broken" or not without the validator depends on your trust of the server - similarly to HTTPS, which is vulnerable from the trust standpoint thanks to CA vulnerabilities. Furthermore, it's possible to verify
103.
by magikarp 15y ago
> 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
104.
by magikarp 15y ago
I don't understand why a protocol with known major problems that can be compromised by oppressive governments is a better solution to client-side crypto that can be verified for integrity and hides the plaintext from the server.
105.
by magikarp 15y ago
> 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 se
106.
by magikarp 15y ago
Don't get me wrong, browser plugin crypto probably works fine, but it's also possible to use a browser plugin to turn untrusted JS crypto code into trusted JS crypto code. The plus side of that is that the crypto code would still work witho
107.
by magikarp 15y ago
Actually, in the case of that particular plugin, every bit of code, including CSS, JS, and HTML, are verified. > It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff
108.
by magikarp 15y ago
> If you don't trust the server, why are you sending it the data? And how is JS crypto any better? JS crypto remains better since there exists techniques to verify the crypto, and the server does not receive plaintext. > This isn'
109.
by magikarp 15y ago
What about sslstrip? What about the fact that CAs are being hacked left and right, and that governments such as China are known to produce fake certs to wiretap dissidents? What about the fact that the server can still read your data? Aga
110.
by magikarp 15y ago
It is ridiculous that even in light of the COMODO HTTPS hack, the writer would go as far as to say that SSL/TLS is a better solution. The writer also ignores that there are potential solutions to many of the problems pointed out: In case
111.
Cryptocat releases Chrome extension that does integrity checks on crypto code(chrome.google.com)
1 points by magikarp 15y ago|0 comments
112.
by magikarp 15y ago
No it can't, that's the whole point! Are you trolling?
113.
by magikarp 15y ago
Right...
114.
by magikarp 15y ago
"If the server is compromised [insert disastrous result here]" applies more so to many other servers serving you crypto - I feel there's the advantage of being able to verify the .js files yourself in your browser here: <!-- cryptocat u
115.
by magikarp 15y ago
Why not? AES has been implemented in javascript half a dozen times.
116.
by magikarp 15y ago
AFAIK, the server does not rekey AES every 500ms - and your suggestion to use a server over TLS opens you up to the problem of the server itself being able to read all plaintext.
117.
Cryptocat: webchat with client-side encryption features(crypto.cat)
24 points by magikarp 15y ago|44 comments