ok, the distro has an outdated version of x software. This is a pretty common issue with older distributions. The great thing about debuntu is that you can pin packages to newer versions!
Refusing to verify myself: I am liz on Keybase.io
61–70 of 114 posts
Re: Refusing to verify myself: I am liz on Keybase.io
#62Earlier quoted context omitted.
And worse -- it only needs to send that special password prompt page to a specific IP or user of interest, and maybe only when it comes from a mac box (if the victim is known to do auditing on a linux box, but uses it as a regular client on mac). Shipping packaged software with evil inside to ~everyone is risky because at least one user is likely to find a bug (accidentally) and try to trace/reverse/whatever (or, at…
We're definitely worried about the hushmail attack, and we disclaim browser-based crypto on the site for those who want to protect against powerful adversaries. Some users might not have those concerns. You've obviously indicated valid concerns, but note, they're not indictments of storing an encrypted private key on the server so much as they are of browser crypto.
Yeah -- from what malgorithms says, you're actually on the path to removing dependency on a given binary being "near" my key material. I trust you guys more than enough for now; I just don't want to have to trust you if this gets wide adoption in 2 years once you become an actual target.
Re: Refusing to verify myself: I am liz on Keybase.io
#63I like the idea of Keybase.io, but I would prefer to use it in a way in which I don't have to trust them at all. As it stands, you need to install their command-line tool and have it directly manage your GPG keychain. For that, I'd prefer to have a platform-neutral tool that's been independently audited and managed by my OS's package manager rather than their keybase-installer tool which seems to want to update very…
While we like being #1 on Hacker News, bad (good?!) timing is what earned us this spot. It will be the case very soon that you can push your key to Keybase and prove all your identities, without ever installing the client the OP dislikes. Technically, you can already, we just need to put together very explicit instructions and documentation that's different for each kind of proof. By ugly necessity, what it takes to…
good Job, that is the info I was looking for..really good work..keep it up!
Re: Refusing to verify myself: I am liz on Keybase.io
#64Earlier quoted context omitted.
We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes? If you think yes, then you are making a strong judgment about the relative difficulty of two very different problems in Crypto that are thought to be quite hard. I realize there are i…
Imagine that Keybase is compromised. It starts serving a password-prompt page that looks identical to the previous, but now sends your decrypted key straight to the malicious attacker. Storing your private key on Keybase allows Keybase to become a single point of failure, which pretty much defeats the whole point of distributed social verification in the first place.
As an aside, the web is an extremely convenient application distribution platform, it seems like a shame we can't securely use it for anything remotely sensitive. Is there a middle ground somewhere? e.x. signed bundles of HTML/CSS/JS?
Re: Refusing to verify myself: I am liz on Keybase.io
#65Earlier quoted context omitted.
Imagine that Keybase is compromised. It starts serving a password-prompt page that looks identical to the previous, but now sends your decrypted key straight to the malicious attacker. Storing your private key on Keybase allows Keybase to become a single point of failure, which pretty much defeats the whole point of distributed social verification in the first place.
We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe. BTW, this argument does not extend to the CLI or other uncompromised clients. People who sync their private keys across devices with the CLI are unaffected.
I'm confused. It sounds like users are able to sync their private keys with the CLI, or with the web interface. It also sounds like if they do it with the web interface, they are at risk, whereas with the CLI they are not at risk.
If my understanding is correct, my question is: What is the reason for this difference in security for the two use cases, and isn't there some way to provide web access without reducing security? What about browser add-ons? Client certificates?
Re: Refusing to verify myself: I am liz on Keybase.io
#66Curious: Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?
Why do people choose python or ruby to write command line apps over traditional languages like BASH, PERL, and C?
Exactly - I read:
"Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?"
and was agreeing with the first part of the sentence and then laughed out loud at the end ...
Are we really in a world where ruby is the old school traditionalist way to write unix utilities ?
Re: Refusing to verify myself: I am liz on Keybase.io
#67This talks much more to me, tho:
http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vinde...
And of course, I like that it's distributed and not a business. I don't want people to do business on my identity.
Re: Refusing to verify myself: I am liz on Keybase.io
#68In reality, the biggest risk for routine comsec with pgp is that no one uses it because it's difficult, but the very specific app of code signing is something where keys need a lot of protection IMO. (I am mostly fine with START TLS for email security 99.99% of the time) The thing which terrifies me is that the npm keybase app asks for my GPG key directly in the same window, and it's impossible for me to (easily) tel…
Anyone using gpgme will trigger the pinentry program, which you can make recognisable if you need a trusted UI.
Or, if paranoid enough, you can store the key on a stick (like a cryptostick) - in this case, it doesn't matter what you type in since the key never escapes.
Note that this is all while assuming that you do not trust what runs on your computer.
Re: Refusing to verify myself: I am liz on Keybase.io
#69Earlier quoted context omitted.
As the article pointed out, what if your key (AES_k) is compromised? I mean what is the point of storing `AES_k(p,q) if k is random` unless you keep k somewhere? What do you use that for? I like the idea of a common way of proving one owns certain social identities. It is probably worth pointing out that the level of trust we give varies - Google "trusts" I own the domain when I put their random key on my homepage. I…
k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.
So when you say "if k is 256 random bytes" it's a flat out lie?
e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.
Re: Refusing to verify myself: I am liz on Keybase.io
#70Earlier quoted context omitted.
I also like the idea of Keybase.io, though I wish it was based on something a little more decentralized. The unfortunately-named WebFist looks cool: http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-w...
Have you checked out OneName? It runs on the Namecoin blockchain, so it's quite decentralized. I've not actually tried it yet, but it looks pretty damn cool. https://onename.io/
Then again, why not use namecoin ? They (we ?) have a spec with what format your records should look like:
https://wiki.namecoin.info/index.php?title=Identity
Basically, there's a whole id/ namespace where you register your personal information, and there's a d/ namespace where you register domain names (akin to DNS). Onename is the same except they use i/ (they haven't even tried to discuss it and basically did it all from scratch to start clean)
The major problem is that you basically need a namecoin client to interact with the data... unless you use dnschain [0], which act as a HTTP-to-Namecoin and DNS-to-Namecoin bridge. Try this:
$ dig @dns.dnschain.net otokar.bit
$ curl http://dns.dnschain.net/d/otokar
both are my personal domain, delivered to you through plain old protocols. The last one even works in your browser !
Come and join us, this is actually the future. Oh and by the way I'm id/rakoo.