On Fri, Jun 20, 2014 at 12:09 PM, Cathal Garvey < cathalgarvey@cathalgarvey.me> wrote:

I wouldn't say "true", I'd say "proto". In the end, you're still relying on a central point of trust, in this case Keybase, for a lot of the key distribution, but as a way to bootstrap a WoT that can outgrow Keybase I think it looks really promising. I'm not one to shirk hackish solutions in favour of purity, because purity has barely worked in decades of PGP WoT building.

Speaking of Keybase, anyone got an invite? :)

I've been very impressed with how Keybase has evolved, and how well they explain their model to users. It is without a doubt what I'd recommend to a semi- or un-technical user to get them started. They have a walkthrough of their approach to security and threat models here: https://keybase.io/docs/server_security And they explain "tracking" in detail here: https://keybase.io/docs/tracking

...

Hello, guys

Keybase.io seems to be a great tool to create a true WoT. Are anybody in

On 20/06/14 17:03, MrBiTs wrote: there? They are working with invitations.

...

CheerS

-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com

-- konklone.com | @konklone https://twitter.com/konklone

Wait, do you *have* to keep your private keys in keybase? I thought it was mostly pubkey operations? I'm much more skeptical if they keep private keys, that's dark stuff. Imagine how many private keys are protected with terrible passwords, and what damage you could do to the WOT if you could just quietly crack enough keys in the WOT and use them to sign a fraudulent cert? On 24/06/14 12:22, MrBiTs wrote:

...

I've been very impressed with how Keybase has evolved, and how well they explain their model to users. It is without a doubt what I'd recommend to a semi- or un-technical user to get them started.

...

They have a walkthrough of their approach to security and threat models here: https://keybase.io/docs/server_security

...

And they explain "tracking" in detail here: https://keybase.io/docs/tracking

More than only create a great documentation, the wrapper they wrote in NodeJS abstracts GnuPG commands making easy to any un-technical person to use cryptography constantly. Of course a little bit of paranoya is always good, and I don't agree with the idea to host my private keys in a server I don't control, even cyphered with a password, but I think it can solve the problem that users forget or loose your keys and our keychain remains with unuseable, no revogated keys.

CheerS

-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com

So, as I told, a little bit of paranoya is good, and this "feature" makes me believe a little less in Keybase, unfortunatelly. The main idea is pretty good and I'm trying to implement this culture in Brazil for a long time, but I use to say that ordinary people don't like computers: they like Skype, Facebook, Instragam... So, people don't care about privacy. If the same people see that movie about Asange, or read his book, or see the last news about privacy and Google and start to learn about cryptography, they will store private keys with lame passwords, and we'll have this fraudulent cert risc.

I'm not against cloud-keys as long as they're encrypted, and I've thought of services that make use of cloud-stored keys in the past. But the critical ingredient to getting this right is CPU/RAM-hard key generating functions to make "bad" passwords "barely acceptable", and "userland" code that rejects stupid passwords entirely. Of course, hackers will be able to circumvent shitty-password-restrictions, but we hope that the band of people competent enough to circumvent password quality checks yet stupid enough to use a bad password is small. The problem with Keybase is that the infrastructure they're based upon, PGP/GPG, is probably not using modern key generation algorithms by default for symmetric encryption of keys. So, how many keys are encrypted using key algos that are easily cracked? If they were using hard keygen algos, then even bad-but-not-terrible passwords would be not-entirely-trivial to crack. But keybase can't even enforce that, because the PGP infrastructure is too legacy-laden. On 24/06/14 12:57, MrBiTs wrote:

On 06/24/2014 08:28 AM, Cathal Garvey wrote:

...

Wait, do you *have* to keep your private keys in keybase? I thought it was mostly pubkey operations?

...

I'm much more skeptical if they keep private keys, that's dark stuff. Imagine how many private keys are protected with terrible passwords, and what damage you could do to the WOT if you could just quietly crack enough keys in the WOT and use them to sign a fraudulent cert?

You don't HAVE to, but they give this possibility. You can (if you want) store your private key in Keybase. They ask you to cypher your private key locally and send it to Keybase's servers. If you don't store your private key in its databases, you are unable to use some online services they offer, like to sign documents. You only will be able to do that using his NodeJS tool. But, your point is my point. I believe serious security professionals or people that understand the importance of cryptography first don't will send the private keys for Keybase and, second, if they do, they will use a strong password. We never must forget http://xkcd.com/936/

But, we know average people uses very weak passwords and only one password for everything. So, as I told, a little bit of paranoya is good, and this "feature" makes me believe a little less in Keybase, unfortunatelly. The main idea is pretty good and I'm trying to implement this culture in Brazil for a long time, but I use to say that ordinary people don't like computers: they like Skype, Facebook, Instragam... So, people don't care about privacy. If the same people see that movie about Asange, or read his book, or see the last news about privacy and Google and start to learn about cryptography, they will store private keys with lame passwords, and we'll have this fraudulent cert risc.

In my opinion, nothing will replace a good key signature party, anyway.

-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com

...

So, as I told, a little bit of paranoya is good, and this "feature" makes me believe a little less in Keybase, unfortunatelly. The main idea is pretty good and I'm trying to implement this culture in Brazil for a long time, but I use to say that ordinary people don't like computers: they like Skype, Facebook, Instragam... So, people don't care about privacy. If the same people see that movie about Asange, or read his book, or see the last news about privacy and Google and start to learn about cryptography, they will store private keys with lame passwords, and we'll have this fraudulent cert risc. I'm not against cloud-keys as long as they're encrypted, and I've thought of services that make use of cloud-stored keys in the past. But the critical ingredient to getting this right is CPU/RAM-hard key generating functions to make "bad" passwords "barely acceptable", and "userland" code that rejects stupid passwords entirely. Of course, hackers will be able to circumvent shitty-password-restrictions, but we hope that the band of people competent enough to circumvent password quality checks yet stupid enough to use a bad password is small.

The problem with Keybase is that the infrastructure they're based upon, PGP/GPG, is probably not using modern key generation algorithms by default for symmetric encryption of keys. What do you mean by that precisely? I don't think PGP/GPG/OpenPGP is meant to encrypt private keys on servers. In what way OpenPG or GnuPG would be linked with keybase.io

On 24/06/2014 14:15, Cathal Garvey wrote: private key encryption scheme or algorithms choice? I don't know everything about OpenPGP standard but I'm pretty sure it doesn't deal with such things.

So, how many keys are encrypted using key algos that are easily cracked? If they were using hard keygen algos, then even bad-but-not-terrible passwords would be not-entirely-trivial to crack. But keybase can't even enforce that, because the PGP infrastructure is too legacy-laden. Again, what has PGP/GPG/OpenPGP to do with keybase.io good or bad choices (you don't seem to know anything about that either by the way :-) regarding encryption of secrets on their servers? I don't get it.

On 24/06/14 12:57, MrBiTs wrote:

...

On 06/24/2014 08:28 AM, Cathal Garvey wrote:

...

Wait, do you *have* to keep your private keys in keybase? I thought it was mostly pubkey operations? I'm much more skeptical if they keep private keys, that's dark stuff. Imagine how many private keys are protected with terrible passwords, and what damage you could do to the WOT if you could just quietly crack enough keys in the WOT and use them to sign a fraudulent cert?

You don't HAVE to, but they give this possibility. You can (if you want) store your private key in Keybase. They ask you to cypher your private key locally and send it to Keybase's servers. If you don't store your private key in its databases, you are unable to use some online services they offer, like to sign documents. You only will be able to do that using his NodeJS tool. But, your point is my point. I believe serious security professionals or people that understand the importance of cryptography first don't will send the private keys for Keybase and, second, if they do, they will use a strong password. We never must forget http://xkcd.com/936/

But, we know average people uses very weak passwords and only one password for everything. So, as I told, a little bit of paranoya is good, and this "feature" makes me believe a little less in Keybase, unfortunatelly. The main idea is pretty good and I'm trying to implement this culture in Brazil for a long time, but I use to say that ordinary people don't like computers: they like Skype, Facebook, Instragam... So, people don't care about privacy. If the same people see that movie about Asange, or read his book, or see the last news about privacy and Google and start to learn about cryptography, they will store private keys with lame passwords, and we'll have this fraudulent cert risc.

In my opinion, nothing will replace a good key signature party, anyway.

Pontifex www.cryptoparty.fr

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/24/2014 04:28 AM, Cathal Garvey wrote:

Wait, do you *have* to keep your private keys in keybase? I thought it was mostly pubkey operations?

You do not. keybase.io works just fine as a CLI app if you don't. - From the frontpage: "Keybase.io is also a Keybase client, however certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server, >>>an optional feature we didn't mention above<<<." keybase.io does an okay job of making some GPG commands easier to use and remember. At the very least it files a few of the rough edges off. gpg -s -o something.gpg -r "bob@laundry.gov.uk" -e fooble.txt vs keybase encrypt bob -o something.gpg -s -m fooble.txt It's got some pretty nasty warts of its own, though. For example, the user cannot encrypt to multiple recipients at this time (https://github.com/keybase/node-client/issues/152). It's a little slow on startup. The command to list your keybase.io keyring (which is distinct from the contents of ~/.gnupg/pubring.gpg) is highly unintuitive. It abstracts away fewer of the common GPG command line options than it seems. After playing around with it for a few weeks, I think that apps like gpg-crypter (http://gpg-crypter.sourceforge.net/) and GPG4win seem a little more intuitive for new users. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Maybe I'll be wantin' a bagel with my coffee.." -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTqbLdAAoJED1np1pUQ8Rkvh0P/j1oH9GwviuzxoX3/7SGhEdz gQIiBuwM5lMEuz+YWZRx9nWT4/4Nd8rtbOM6rRF3OqWiVGPpaf3DmcrFwdJsVl/u 5E0bHouQXMqxisQzNEJ7i/JAYqlMjAEbVb2Ot4ArWNovCk/IwgONyGh52uAujAYv 1GWsOC7tXFnETM+QhDgn78uKswPet0a8HizNdKPZQKK+qftgZDxtZ3A2q9Tc5oBn HxzB8Wrnm7jERMei41CYFn1O/Yk6hfYKD0Y9sPIAbui88b3y1XkE/KXCHma3626p oDstRhCMMI8ztjsa4AiEVZkrlbJWK8AoTlwpNybcbCW/aeqg6gX1SaPgNzX8OKe0 1iT6eD+NUDQdGjRmaiLKpP55oqmLsq/9/TunUluuCpB3TK1gUndgDeokOQu2lZci n80Re/mdIlutAgTTVMdzfFcOY92lePMGDI88bJUosY294tCvR8gRIHPJqF4YM+cD +LyTn2iUXOZH2xv6vRZyY0uI1W7Oa5mNrhXRnDfZNIrjo1s6aDAw9lgN6JhP3Bo7 AHFUddP2ULzI0jF3U/e9qz43dhMPPaLBODR6igBk4QY8MHtlTGHsZHnO1aAmIoeu u8zbBuSohGjThxHlR2FCjwJTR8ccIkuHqpi39rD+0dOf4XsVWyA/b/HthME5pCy0 BKRPni0zcO3+AXYP8FrI =3v6s -----END PGP SIGNATURE-----