[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Keybase.io



> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <http://cpunks.org/pipermail/cypherpunks/attachments/20140624/e044a09a/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://cpunks.org/pipermail/cypherpunks/attachments/20140624/e044a09a/attachment.sig>