[Cryptography] How to build trust in crypto (was:recommending ChaCha20 instead of RC4)

[Guido Witmond]

On 03/16/14 15:57, Ralf Senderek wrote:

> The challenge is this:
> 
> "Show me the whole practical process anyone on this planet can use to
> have a secure online communication with someone else."

Ralf, I'll pick up the gauntlet. I think I've come up with a worthy
contestant to your challenge.

Not only, I'll show how someone can have a secure online communication
with someone else. I'll create a secure channel between two people who
have never met before.

Here's how:

1. We create a web site, say a blog site.

Before anyone can sign up we do these:

2. Create an RSA Root CA, with our own private key.
2a sign our server certificate with it;
2b publish the Root-CA public key in DNSSEC/DANE;

3. we create a subCA private key and sign its public key using our RootCA.
3a. we use this subCA to sign client certificates for our blog.
3b. we configure our blog site to accept only our subCA.

4. people sign up for our blog, they create a nick name and request a
client certificate at our blog's subCA.
4a. people create the nick name themselves;
4b. their user agent creates a new private/public keypair for each account;
4c. the subCA makes sure the (nick name @ sitename) is unique
4d. it signs (nick name @ sitename, pubkey) using the subCA privkey.

5. User A signs up, requests and get a certificate bearing CN: A @ site.
5a. A writes a blog entry,
5b. A signs it with her private key and
5c. publishes (message, sig(message)) on our site.

6. User B reads the message of A
6a. B signs up likewise.
6b. B writes a comment on A's blog.
6c. B signs it using his private key;
6d. B publishes the (comment, sig(comment)) on our site.

7. A want to talk to B over VOIP.
7a A creates a voip endpoint on her computer: IP: x, port y.
7b A configures it to accept only connections identified by B's public key.
7c. A writes a private message to B, specifying IP x, port y, pubkey B.
7c'. This is encrypted using B's public key. only B can decrypt it.
7d. A waits until B connects

8. B receives the private message, decrypts using his private key.
8a. He connects to IP x, port y;
8b. sets up a Diffie-Helman key exchange;
8c. signs the key with their own private key;
8d. validate the others' key against their signature;
8e. and if matches, lets the voip session go on.
8f. on failure to match, disconnect and explain.
8g. both strangers have an authenticated connection with the person they
expect it to be. (whomever it may be)

9. Two strangers, who have never met before have successfully created a
secure channel between them.

Q.E.D.




How it works:

A. DNSSEC and DANE let any site publish their own Certificate Signer
(authority).
A1. Only ICANN and agencies that copied their keys (NSA) can impersonate
a site

B. Our blog site doesn't care about the true identity of the people. It
requires that the CN of each user is unique. Ie, the nick name is unique.
B1. This uniqueness makes CN a substitute key for the pubkey, the real
identity.

C. Every blog entry or comment is either totally anonymous, or it is
signed with the authors public key.

D. Reading a blog comment requires verifying the message signature
against the public key. When verification succeeds, the pubkey proves
ownership of the message.
D1. When verification succeeds, you have effectively validated the
pubkey of the author. Only the corresponding private key can have
created that signature.

E. By responding to a blog entry, with a message signd using your
private ke, you have transmitted your public key to those who have
validated your message, including the blog author (A);
E1. Effectively, you have exchanged public keys between each other.

F. One more thing to do: verify that the CN of the other party is unique
at teh global registry. It makes sure there is no Man-in-the-Middle,
making the CN truly a substitute key for the pubkey.

G. These public keys are used to identify the other party in the
Voip-call. Only the owner of the private key can connect.



That's the essence of Eccentric Authentication, my protcol to implement
all of this.

See
http://eccentric-authentication.org/eccentric-authentication/global_registry_of_dishonesty.html
or start at the home page.

> The proposals must not be reduced to technical specifications but need to
> show how exactly we can achieve the results of trust building. In this
> process individuals must play an important role. As a precondition the
> process must be entirely comprehensible and verifiable, so that a variety
> of smart people - including the President and the God King - can expose
> themselves to say "Yes, I've checked this approach, I know of N capable
> colleagues that I know have scrutinized the code and the inner workings.
> I might be wrong, but I sincerely would recommend to use this to my wife."

Heck, I think it appeals to John Doe. It just works. And when there is a
duplicate signed CN, the user agent complains loudly and the nerds of
the world will investigate. (side effect of the global registry of
(dis)honesty).

All it needs is support from the browsers and some easy to use server
side software.

> The successful winner of this competition won't be perfect, it won't
> guarantee that the NSA cannot subvert it, it wouldn't even guarantee
> that it'll be widely used in practice, but it would be a foundation
> for the mammoth task that lies before us, to take back the internet.

Feel free to take shots at my approach. I'd like to get feedback on how
far I get with this competition.

Regards, Guido Witmond.

http://eccentric-authentication.org/

PS. check out my Alien Dating Site. Here is the walk-through:
http://eccentric-authentication.org/blog/2013/06/12/walkthrough-datingsite.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140317/109559a7/attachment.pgp>