[GNU/consensus] Eccentric Authentication again

[Guido Witmond]

Hello all,


I've written two new blog entries on eccentric authentication. The
protocol that uses client certificates and a local CA to distribute
public keys between strangers in a secure way.

Please read in this order:

http://eccentric-authentication.org/blog/2013/08/31/the-holy-grail-of-cryptography.html

http://eccentric-authentication.org/blog/2013/09/05/a-subversive-idea.html



I'd love to hear comments, remarks, improvements.

Regards, Guido.

[hellekin]

Post by Guido Witmond
Hello all,

*** Hi Guido,

thank you for reaching out. I will not have a lot of time this month
due to the organization of the GNU 30th anniversary, and other tasks
pending, but I'd definitely like to look at it in more depth.

I already planned to move away from Certification Authorities for
Lorea as our current provider wants something Lorea cannot provide
(Lorea is not a "legal person", but an informal network) and move to
MonkeySphere certification.

I guess Eccentric Authentication might be useful there as well.

==
hk

[FA - ML]

Post by Guido Witmond
I've written two new blog entries on eccentric authentication.

They are interesting articles and I bookmarked them to read them when I am
not commuting. I am quite interestedin cryptography and identity problems.

One initial question, while I "digest" both articles: in "The Holy Grail of

Post by Guido Witmond
(There is a small chance that you might get tricked by a Man in the
Middle-attack. You have to do a little more work than just described,
but that’s easy.)

Can you explain/point me to a resource where those steps (to avoid the
mitm attack) are described?

[Guido Witmond]

Post by FA - ML

Post by Guido Witmond
I've written two new blog entries on eccentric authentication.

They are interesting articles and I bookmarked them to read them when I am
not commuting. I am quite interestedin cryptography and identity problems.

Glad you like them. :-)

Post by FA - ML
One initial question, while I "digest" both articles: in "The Holy Grail of

Post by Guido Witmond
(There is a small chance that you might get tricked by a Man in the
Middle-attack. You have to do a little more work than just described,
but that’s easy.)

Can you explain/point me to a resource where those steps (to avoid the
mitm attack) are described?

That would be in the manual of the voice/video/chat package. Usually it
means validating a SAS (Short Authentication String) once.

regards, Guido.

[hellekin]

Post by Guido Witmond

Post by FA - ML
Can you explain/point me to a resource where those steps (to
avoid the mitm attack) are described?

That would be in the manual of the voice/video/chat package.
Usually it means validating a SAS (Short Authentication String)
once.

*** You mean, beforehand, out of band? Doesn't it defeat the purpose
of authenticating strangers?

The MITM attack scenario nowadays seems quite... Normal.

I mean, who trusts the X509 infrastructure after the Snowden
Apocalypse? I thought the security model was "My node is secure.
Everything else is compromised." And even that does not seem to be
certain, so we *assume* our node not to be compromised.

==
hk

[Guido Witmond]

Post by hellekin

Post by Guido Witmond

Post by FA - ML
Can you explain/point me to a resource where those steps (to
avoid the mitm attack) are described?

That would be in the manual of the voice/video/chat package.
Usually it means validating a SAS (Short Authentication String)
once.

*** You mean, beforehand, out of band? Doesn't it defeat the purpose
of authenticating strangers?

Authenticating the SAS is part of the document where you do the
opposite: authenticating relatives after exchanging the keys via an
insecure channel.

You're right that it doesn't work for authenticating strangers. That's
the topic of the second part of the blog where I introduce my ideas on it.

Post by hellekin
The MITM attack scenario nowadays seems quite... Normal.
I mean, who trusts the X509 infrastructure after the Snowden
Apocalypse? I thought the security model was "My node is secure.
Everything else is compromised." And even that does not seem to be
certain, so we *assume* our node not to be compromised.

Nope, the model has always been that the end users' node is insecure.
That's why everyone limits http-sessions with banks. They even forbid
people from letting their browser remember passwords.

To solve that, take a look at capability operating systems such as
genode.org. More necessary than ever.

Guido.