71–80 of 84 posts
No such thing as a secure keystore? He needs to look harder. Aside from hardware which is tamper proof... which exists in smart cards and TPM chips... most operating systems use file system ACL's. Yes running as "root" means you can get the keys... you have to protect them...
Earlier quoted context omitted.
Let me say it again: As a user, you can't verify that you're secure against the attackers.This is my important point, not whether a particular chosen attack was blocked. Therefore, if you care at all about security, you can't trust the channel. You're only looking from the POV of the attacker, but you've got to consider all the POVs, including the users, and not impute to them knowledge that they can't have about the…
The problem with this argument is that you stop passing the buck when it's convenient for your argument, not to its actual conclusion. The only reality any one of us can actually be sure of is each of our own minds[0], therefore the only way to keep information secure is to never share it. Even then, our brains in vats could be under constant monitoring and decoding, therefore making secrecy a futile exercise altoget…
Earlier quoted context omitted.
Let me say it again: As a user, you can't verify that you're secure against the attackers.This is my important point, not whether a particular chosen attack was blocked. Therefore, if you care at all about security, you can't trust the channel. You're only looking from the POV of the attacker, but you've got to consider all the POVs, including the users, and not impute to them knowledge that they can't have about the…
This is an example of the Perfectionist Fallacy I was talking about in the article. You can't verify that someone isn't MiTM'ing with a stolen certificate. You can't verify that the CA hasn't been coerced into forging a valid certificate. You can't verify that your government hasn't ordered that computer manufacturers install surveillance devices. That doesn't mean that the internet is unusable. Some things are vulne…
You expected to see a Perfectionist Fallacy argument, so you saw one. But it's not, because "active attacks" in this context don't require anything close to "perfection" to achieve. It's exactly the other way around... it requires near perfection to prevent them in the real world!
I understand the strong reaction to the actions of the NSA, but all this is doing is providing the appearance of security while not making it any more difficult for adversaries like the NSA.
Earlier quoted context omitted.
> When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server? If you don't take any steps to verify the integrity, then you don't know. The big difference, as I see it, is that the JS code gets served over and over again to the same clients. Every time you visit the website, it can load a new version of the JS.
Even if you do verify the integrity of the package, then you still can't know for absolute certain that the package maintainer hasn't somehow exposed their private key or been otherwise compromised. You have to trust them.
No such thing as a secure keystore? He needs to look harder. Aside from hardware which is tamper proof... which exists in smart cards and TPM chips... most operating systems use file system ACL's. Yes running as "root" means you can get the keys... you have to protect them...
Why did this get downvoted? No one even replied!
Wow. A construction or implementation is secure if an adversary, given a certain level of power, is unable to achieve a given objective. The level of power an adversary is assumed to have and their ultimate objective is called the threat model. If a new construction is secure under a new threat model that either increases the amount of power an adversary can have or makes the adversary's objective broader, the new co…
This sounds important, but the distinction between "passive" and "active" attackers has come up in every discussion of JS crypto I can remember on HN, and indeed in every discussion of TLS (see, for instance, every discussion of why certificate authorities are necessary and why self-signed certificates are insecure "despite using exactly the same cryptography as CA-signed certificates"). I do not believe this is a di…
Oh come on, was that sneer called for? If you really feel that none of the security discussions here on HN are getting way out of hand over what's really a misunderstanding on some basic assumptions, then you haven't been looking. Note, I didn't say "JS crypto discussions", I said "security discussions".
In fact, I'm mostly referring to the kinds of discussions that did not start as a security topic, but evolved into them. There, there's often people like me, who care about security but who are far from experts, and these people (myself included) often mix stuff up. Clearing out definitions and which threat model to assume would really help in such discussions. I thought that this blog post did that in a very clear and non-opinionated way in that little paragraph there, so I complimented it.
Is that really so bad?
Earlier quoted context omitted.
Thanks for the report. I'll take a look and get back to you. Where can I contact you? Edit: I've just filed https://code.google.com/p/end-to-end/issues/detail?id=82 . We can discuss the problems of IDEA there. Thanks!
That link gives me a 403 error? In any case, I've put an email in my HN profile.
Earlier quoted context omitted.
This sounds important, but the distinction between "passive" and "active" attackers has come up in every discussion of JS crypto I can remember on HN, and indeed in every discussion of TLS (see, for instance, every discussion of why certificate authorities are necessary and why self-signed certificates are insecure "despite using exactly the same cryptography as CA-signed certificates"). I do not believe this is a di…
> but perhaps you can use the search bar below to find a debate about JS crypto where it was missing and where the result was misleading to readers. Oh come on, was that sneer called for? If you really feel that none of the security discussions here on HN are getting way out of hand over what's really a misunderstanding on some basic assumptions, then you haven't been looking. Note, I didn't say "JS crypto discussion…
Ten years from now, when web security is even more laughable and anemic than it already is, some of us are going to remember discussions like these where application developers at large ignored the warnings from the established crypto community. Some of us are old enough already to remember this pattern happening before. I understand the strong reaction to the actions of the NSA, but all this is doing is providing th…