151–160 of 166 posts
I just hope that however google and yahoo implement PGP into their mail offerings, they do it in a way that cannot be intercepted by governments/bad guys.
but they are not allowed to tell you if it can be intercepted...
However, if the government comes to Yahoo/Google, and says: give us a backdoor.. how can we be sure it doesn't happen?
Learning to drive a car is hard. You have to watch the road, coordinate hands and feet, anticipate other drivers' moves and so on. No one bats an eye about this, because "it's a skill you have to learn". If you don't play by the rules of the road, you'll end up killing someone, or getting killed. But for some reason (maybe because it's generally less life-threatening), people seem to expect deeply complex subjects, l…
I can't drive. Not for lack of trying. I seemingly can't develop the the muscle memory of unintuitive (to me) concepts like "clockwise is right" and "counter-clockwise is left", nor can I get used to the way a gas pedal actuates non-linearly. These are just two examples of a long list of problems that I have with the controls. Then there is the utterly confusing signage. I just can't do any of it, not without sweatin…
"Please don't make the assumption that other's experience of the man-made world around us is in any way similar to yours, that's just not true." Where did s/he? I'm genuinely stumped.
Learning to drive a car IS inherently hard (as in complex), just as "e-mail encryption and identity management", and that is a fact. If you for some reason are more or less adept than the average person at either of these things, I don't see what difference that makes to the reality of the situation. Like driverdan said, if you simply can't do something, you'll have to find a workaround.
Problem: PGP is complicated (VERY complicated, to the average user), resulting in next to zero adoption. Suggestion: Simplify the goals in a way that can be upgraded at at some later date. I think we need a browser plugin (All browsers. Other non-browser tools too, ideally, but the browser is important) that lets you securely SIGN posts locally in a style more or less like GPG's --clearsign option. Ideally, this shou…
My design has a REST endpoint that runs locally, and a JS client/SDK then connects to it on a known endpoint. My "MVP" version is to have the user running an interface with the request queue in a separate tab, and the server always at a fixed localhost:port endpoint. The client page would then issue a REST request that hangs until the user responds to the request in the separate tab.
This would conceivably work as a browser plugin as well since I'm planning to write it in JS for Node--basically the server logic would instead live in the plugin and the SDK would check for presence of the plugin before making a REST call. IMO the advantage of making it a REST endpoint though, is protecting private keys from whatever else might be going on in the browser process(es)--based on my own worst-case on assumptions, unsure if it's actually an issue with the plugin architectures.
I'm an aspiring interaction/UX designer so that is the aspect I am focusing on, and my motivation is that I am personally starting to use GPG with a Yubikey + offline master. So yea, collaborators hit me up, especially if you're in SF.
Earlier quoted context omitted.
That's probably because like most people, you don't really need to have a completely secure communications channel with your wife. All security decisions boil down to some calculus of risk, impact and cost. The most sensitive conversations that my wife and I typically have remotely aren't ones that justify the cost (both in terms of hassle and $) of carrying a secure device around. Personally, if I were in a situatio…
Someone else might need to have a secure communication channel with his wife. I never read the comment as "I can't communicate securely with my wife", more "My wife is not in the set of people with which anyone can communicate securely" (because secure key management is hard).
> Except maybe not: if you happen to do this with GnuPG 2.0.18 -- one version off from the very latest GnuPG -- the client won't actually bother to check the fingerprint of the received key. Even in it's long form, it's relatively easy to generate different keys that have the same fingerprint.
I'm aware of simple brute-force attacks on short key IDs [0], which are just the last 32 bits of the fingerprint (e.g. 438CF0E2). With significant effort, one might be able to extend that to 64 bits. I'd be much more surprised by a full fingerprint match. Wouldn't that imply a SHA-1 collision? [0] http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...
I'm using TextSecure on my Android phone as a Messaging replacement and it is great. However it appears to me that the service is not decentralised in any way. Is that assumption correct? I like the email model such that anyone can install and run an email server. I'd actively push friends, family and colleagues to use a decentralised email replacement that was as easy to use and secure as TextSecure.
I don't trust TextSecure. It's too transparent. It is entirely unclear what happens if it can't send an encrypted message. It's unclear where and how much I'll be billed (important to those of us outside the US). And sans user authentication, there's no real trust model there.
The billing criticism is fair and warranted; currently if your sending over SMS, the first message can only contain 60 chars due to protocol overhead, so you often end up with short messages costing multiple SMS.
There is a way to verify keys (manually!) but no indication that you have verified them.
Earlier quoted context omitted.
> […] with a very few exceptions (that probably prove the rule) Off topic and pedantic but exceptions do not prove rules. A specific exception like “you are allowed to do X when Y is true” may be used as proof of an (unwritten) rule about X being forbidden. I.e. here we use the exception (when Y is true we are allowed to do X) to prove that there is a general rule saying that X is forbidden.
That's also wrong. The expression uses an archaic transitive "prove," which means "to test." Thus, "the exception tests the rule," which makes more sense.
From http://en.wikipedia.org/wiki/Exception_that_proves_the_rule
"The exception [that] proves the rule" means that the presence of an exception applying to a specific case establishes ("proves") that a general rule exists. For example, a sign that says "parking prohibited on Sundays" (the exception) "proves" that parking is allowed on the other six days of the week (the rule). A more explicit phrasing might be "The exception that proves the existence of the rule."
Earlier quoted context omitted.
I haven't used the "original" PGP program for a very long time, but IIRC it had the option to use RFC 1751 or a similar scheme. A quick web search finds to options to use this scheme in GnuPG. Strange!
You're probably thinking of: https://en.wikipedia.org/wiki/PGP_word_list [edit: See also this thread: http://lists.gnupg.org/pipermail/gnupg-devel/2001-March/0170... I think they're missing (what I think was) the point of the list -- I seem to recall this was meant for use over the phone, and the words were selected by machine learning to all sound different. I've always thought this was a massive case of over-engine…
Earlier quoted context omitted.
This elitist attitude is why I have no faith in typical "security experts" improving the overall situation with communication security for normal people. Widely adapted open-source "bad crypto" can: - Raise user's level of awareness about security. - Create a market that can later be serviced by better crypto. - Encourage creation of infrastructure that can be later used in better crypto. - Encourage investigation of…
> Widely adapted open-source "bad crypto" can ... raise user's level of awareness about security. You know that study that showed that people wearing seatbelts drive more recklessly, effectively exactly compensating for the increase in safety provided by the seatbelts? I have a feeling people who think they're using a secure cryptosystem will speak much more freely than those who don't--meaning that the net effect of…
I'd rather have that than the society where everyone silently accepts global surveillance as a norm and treats any kind of self-expression that gets you into trouble as pure stupidity on the part of the speaker (e.g. blames the victim).
What we have right now is a vicious cycle. "Normal" people have no cryptographic capabilities. So they simply adapt their beliefs and behavior to this reality. This makes them think of themselves as different from people who do have cryptographic capabilities. This means they develop "us and them" mentality and can no longer empathize with anyone seeking any level of digital privacy. This means there is no popular support for crypto. So "normal" people have no cryptographic capabilities.
I believe that "consumer cryptography", even if it's weak, would break this cycle.
Earlier quoted context omitted.
In many cases, this is an acceptable trade-off. Security is not one size fits all; your average user cannot afford to be NSA-level paranoid. Otherwise we would spend all of our time verifying keys and not actually doing anything.
True. But he will think he is NSA safe, if he uses an App on his iPhone with the word Secure in the name. And this is actually what many of the Apps out there are promising without being able to say for sure themselves.