starting part II of the handbook: Decentralize

[Michiel B. de Jong]

first episode in the second part :)

https://unhosted.org/decentralize/17/Cryptography.html

if you see a flaw in the security reasoning, then please reply to this
thread, so we can fix it before other people get unnecessarily confused
by it.


cheers!
Michiel

[Justin Cormack]

I think it really needs to start with a clear explanation of what the security problems being addressed are. It seems to start in the middle not the beginning. Because security is a big issue I think it is worth iterating over the explanation a lot. We don't want people thinking that third parties might be looking after security better than they can themselves. It is often best to start with a threat analysis rather than assuming the reader understands the threat model you are addressing.

I don't think this is good enough yet (unlike the previous parts). Not saying there are technical issues with crypto but that it does not read convincingly yet for someone who has only been following intermittently.

I will try to write up some questions as a starting point for the bits I am not sure about.

BTW the previous parts of this series have been brilliant and maybe I am just paranoid about reaction to security parts... Hope this is helpful.

Justin

> cheers!
> Michiel
>
> --
>
> --- You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[rhapsodhy]

Justin Cormack (2013. Apr. 09. 23.M):

> I think it really needs to start with a clear explanation of what
> the security problems being addressed are. It seems to start in the
> middle

I agree, it's a bit sudden, without context.

I'd also mention specific products like yubikey or a cryptostick to
put storage in perspective, because it's a bit vague, and I wouldn't
know guess how this works if I didn't know already.

it would make sense to advise using a password store (keepassx) or
a password manager that generates a password from a secret and
site/username (i can't recall, but someone mentioned one web-based
here recently). keeping private keys in these is still a better idea
than keeping them unencrypted in a safe, i think.

The DNS + TLS problem is a bit vague, too, but I think what you mean
is addressed by DNSsec, which is afaik implemented on more and more
pages.

You could also mention tahoe-lafs in the conclusion, as a specific
software that solves the untrusted storage problem, and works quite
well.

rhapsodhy

[Bryce Lynch]

On Tue, Apr 9, 2013 at 3:30 PM, Michiel B. de Jong <anyt...@michielbdejong.com> wrote:

https://unhosted.org/decentralize/17/Cryptography.html

"If your communication partner knows your domain name, then publishing your public key "only" requires a trusted https server with a TLS certificate on your domain name."

Not necessarily true.  Comparison of multiple copies and fingerprints will accomplish much the same thing.  This is why PGP keyservers are networked for synchrony.  If one has it, they all have it.  Publishing one's fingerprint far and wide (say, in the .signature appended to one's e-mails) makes it more difficult to substitute a public key with a fake.

"The party hosting your public key can fool your peers, pretending to be you when sending a message."

Not true.  Public keys are used for encrypting messages /to/ the keyholder, not /from/ them.  That is why anyone can and should download them for the purpose of sending messages securely to the address(es) stitched into the public key.  Public keys are also used for verifying cryptographic signatures from the keyholder (which are generated with the private key and publically verifiable with the public key).  If someone fakes a signature on a public post which does not verify with copies of your key floating around, the game is up.

--
The Doctor [412/724/301/703] [ZS]
https://drwho.virtadpt.net/
"I am everywhere."

[Michiel de Jong]

On Wednesday, April 10, 2013 12:30:44 AM UTC+2, Justin Cormack wrote:

I think it really needs to start with a clear explanation of what the security problems being addressed are. It seems to start in the middle not the beginning.

you are absolutely right, in my attempts to keep it short, I totally messed that up. I added an Alice/Bob/Charlie part to the beginning, and added a thank-you note linking back here. I hope it is a bit better now, i think i'll also generate a diagram illustrating things visually, to make it still a bit clearer.

Thanks!!

[Michiel de Jong]

On Wednesday, April 10, 2013 6:29:24 PM UTC+2, Bryce Lynch wrote:

PGP keyservers are networked for synchrony.  If one has it, they all have it.

aaah, right! that was the part i was missing! thanks a lot for clearing that up, i corrected it, with a link back to this post.
 

"The party hosting your public key can fool your peers, pretending to be you when sending a message."

Not true. [...] If someone fakes a signature on a public post which does not verify with copies of your key floating around, the game is up.

yeah, those "copies floating around" are what make it not true. so Charlie will not be able to publish a fake key on Alice's server, because Bob will be able to check its validity not only on Alice's webserver, but also on any keyserver. This assumes, though, that the keyserver has Alice's version and not Charlie's version of her key. if Charlie manages to get a fake key into the keyservers network, then that would allow him to sign messages as Alice, right?

[Bryce Lynch]

On Fri, Apr 12, 2013 at 5:03 AM, Michiel de Jong <mic...@unhosted.org> wrote:

yeah, those "copies floating around" are what make it not true. so Charlie will not be able to publish a fake key on Alice's server, because Bob will be able to check its validity not only on Alice's webserver, but also on any keyserver. This assumes, though, that the keyserver has Alice's version and not Charlie's version of her key. if Charlie manages to get a fake key into the keyservers network, then that would allow him to sign messages as Alice, right?

 

That is a potential threat.  It's happened in the past.  It's been shaken out in roughly this fashion over the years, backed up with the PGP Web of Trust:

- Eve generates a fake public key for Alice.  Eve doesn't have access to the e-mail account that Alice has been sending stuff from for years, so Eve creates a plausible fake address on another service and ties the fake key to it.

- Eve publishes the fake key and starts posting from the fake address as Alice.

- Alice, who has a public, well-known address because she's been using it for years cries foul.  Let's assume that Alice didn't have a keypair before, so she generates one and sends the public key to some people she's been corresponding with for years.  She also posts the fingerprints for her pubkey far and wide, starting with the .signature file in all of her posts, static pages on her website, profiles on the socnets she hangs out on, basically strafing the net.

- Bob, Charlie, and Danielle, whom Alice has been corresponding with for years, recieve Alice's public key.  They check the fingerprint on the key, maybe phone her up for a chat about it, possibly get together and verify IDs.  They sign her pubkey with their keypairs.

- Alice posts her real public key to the keyserver network and whatever fora she posted the fingerprints on.

- Bob, Charlie, and Danielle post their signatures on Alice's public key to the keyserver network, which merges them together.  Those signatures can be verified with their public keys.

- Alice says that Eve (fake Alice) is an imposter pretending to be her.  Alice makes the case that she's been using al...@realalice.com as her address for years, posts to the following fora (for the sake of argument, mailing lists and newsgroups) from it, and there is a volume of users who have been corresponding with her from that address for that period of time.  She adds a link to her public key, states that it's been signed with the pubkeys of the people she's been corresponding with for years, signs the message, and posts it.

- Bob, Charlie, and Danielle reply to real Alice's post and back her claims up.  They sign their posts.

- Concerned users hit up Google and verify Alice's claims.  They also verify the identities associated with Alice's pubkey and the identities of everyone who signed her key to verify it - they've been around for years, too, are active, and definitely interact with one another.  She's been around and about, and al...@fakealice.webmail.com hasn't.  SOMBUNALL sign her pubkey in solidarity and post their signatures to the keyserver network, too.

- Eve's fake Alice identity and pubkey get ignored, probably with an old-school Cypherpunks mailing list style flamewar.  Alice signs everything she posts thenceforth.

[Michiel B. de Jong]

On 2013-04-10 02:41, rhapsodhy wrote:
> I'd also mention specific products like yubikey or a cryptostick to

done. i'm not endorsing them as the True Way though, because i still
think that usb sticks are only useful for power users and for employees
whose bosses tell them to use them as part of their job. I don't see the
"general public" walking around with one any time soon, unless it
becomes part of their smartphone (which would make sense because they
already carry it for a combination many other reasons).

> put storage in perspective, because it's a bit vague, and I wouldn't
> know guess how this works if I didn't know already.

i'm afraid the text is still a bit unreadable for the uninitiated, it's
a complex topic and i want to make a lot of non-obvious statements in a
short text, but i did my best to improve it a bit.

> it would make sense to advise using a password store (keepassx) or
> a password manager that generates a password from a secret and
> site/username (i can't recall, but someone mentioned one web-based
> here recently). keeping private keys in these is still a better idea
> than keeping them unencrypted in a safe, i think.
>
> The DNS + TLS problem is a bit vague, too, but I think what you mean
> is addressed by DNSsec, which is afaik implemented on more and more
> pages.

thanks, i tried to fix that paragraph a little bit.

> You could also mention tahoe-lafs in the conclusion, as a specific
> software that solves the untrusted storage problem, and works quite
> well.

done. Thanks a lot for all the suggestions! Really helpful Sorry for
the delay in processing it, i was a bit busy with other stuff this week.


Cheers!
Michiel