forked from cheng/wallet
113 lines
4.6 KiB
HTML
113 lines
4.6 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
p.center {text-align:center;}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>Squaring Zooko’s triangle</title>
|
||
</head>
|
||
<body>
|
||
<p><a href="./index.html"> To Home page</a> </p>
|
||
<h1>Squaring Zooko’s triangle</h1>
|
||
|
||
<p>
|
||
Need a system for handing one’s keys around that protects end users from the horrifying sight of actual keys or actual strong hashes of keys.</p>
|
||
<p>
|
||
But at the same time the system has to not say, "I can’t deliver your message to that person because an invisible gnotzaframmit that I won’t describe to you seems to be unavailable to me in the flabogrommit."</p>
|
||
|
||
|
||
|
||
|
||
<p>It seems like the clever bit of CT is the insight that some actions, like
|
||
a CA signing a cert, are intended to be public, and so should be forced
|
||
(via clever crypto) to take place in public. This makes me wonder what
|
||
other crypto actions should also take place in public, in a way that
|
||
doesn’t permit hiding them from the world. </p>
|
||
<p>Revocation </p>
|
||
<p>Software releases </p>
|
||
<p>Mapping of email address to public key </p>
|
||
<p>Delegation of DNSSEC keys </p>
|
||
<p> </p>
|
||
<p>Of course, globally visible events need to take place at a globally
|
||
visible time. The most widely available time is GPS time (which is 19
|
||
seconds off the commonly used time), and which is available from the
|
||
seldom connected pps line.</p>
|
||
<p>At present, unfortunately, anyone who wants gps time has to do his own
|
||
soldering and hack his own software. There is a pre soldered device
|
||
available, but it is hard to get. </p>
|
||
<p> </p>
|
||
<p> </p>
|
||
<p>
|
||
Imagine skype as originally designed, (central authority maps public and
|
||
private keys to user names) plus a key continuity feature, plus the seldom
|
||
used option of doing a zero knowledge shared passphrase to detect man in
|
||
the middle. </p>
|
||
<p>
|
||
The possibility that the zero knowledge check could be used would deter
|
||
powerful adversaries, even if seldom used in practice. The more powerful,
|
||
the greater the deterrent effect. </p>
|
||
<p>
|
||
It is not totally end to end, central authority can listen in, but the
|
||
check would limit the amount of listening. </p>
|
||
<p>
|
||
It can be made completely end to end for strong passwords. Assume login is
|
||
by zero knowledge password protocol, which means that the central
|
||
authority does not know the end user’s password, for strong
|
||
passwords. </p>
|
||
<p>
|
||
The secret key is generated from the strong secret supplied by central
|
||
authority, plus the password. </p>
|
||
<p>
|
||
When you change your password, you generate a certificate mapping your new
|
||
public key to your old public key, which certificate makes other people’s
|
||
key continuity check happy. </p>
|
||
<p>
|
||
If key continuity fails, people get a warning, but they don’t have to
|
||
click it away, for that just trains people to click it away. They can just
|
||
continue right on and not pay attention to it. </p>
|
||
<p>
|
||
Or they could use the zero knowledge shared passphrase procedure to detect
|
||
man in the middle. </p>
|
||
<p>
|
||
So, if non paranoid, and using easy passwords, works like skype used to
|
||
work. No interception except by central authority, and central authority
|
||
cannot intercept everyone, or even large numbers of people. </p>
|
||
<p>
|
||
If paranoid and using strong passwords, provides OTR like end to end
|
||
capability. </p>
|
||
<p><br/>
|
||
</p>
|
||
<p><br/>
|
||
</p>
|
||
<p>Key management is an unsolved problem. In my biased opinion the
|
||
best<br/>
|
||
solution was my Crypto Kong, which received limited takeup.<br/>
|
||
<br/>
|
||
So, in conclusion, don’t make people manage keys, though that should be an
|
||
option for the seriously paranoid.<br/>
|
||
<br/>
|
||
Instead, autogenerate the keys with zero knowledge passphrase logon.<br/>
|
||
<br/>
|
||
If he uses a password weak enough to fall to an offline dictionary attack,
|
||
this is equivalent to the old skype system, where central authority
|
||
manages his keys and he has password logon. If he uses a stronger
|
||
password, equivalent to a salted strong passphrase system.</p>
|
||
<p> </p>
|
||
<p> </p>
|
||
<p> </p>
|
||
<p> </p>
|
||
<p> </p>
|
||
<p> </p>
|
||
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
||
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
Commons
|
||
Attribution-Share Alike 3.0 License</a></p>
|
||
</body>
|
||
</html>
|