[146505] in cryptography@c2.net mail archive
Re: [Cryptography] Thoughts about keys
daemon@ATHENA.MIT.EDU (Ben Laurie)
Sun Sep 1 14:10:16 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130825162942.68a6367a@jabberwock.cb.piermont.com>
Date: Sun, 1 Sep 2013 13:55:08 +0100
From: Ben Laurie <ben@links.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============0987760801358856585==
Content-Type: multipart/alternative; boundary=047d7bb0456621bbed04e551f72e
--047d7bb0456621bbed04e551f72e
Content-Type: text/plain; charset=ISO-8859-1
On 25 August 2013 21:29, Perry E. Metzger <perry@piermont.com> wrote:
> [Disclaimer: very little in this seems deeply new, I'm just
> mixing it up in a slightly different way. The fairly simple idea I'm
> about to discuss has germs in things like SPKI, Certificate
> Transparency, the Perspectives project, SSH, and indeed dozens of
> other things. I think I even suggested a version of this exact idea
> several times in the past, and others may have as well. I'm not going
> to pretend to make claims of real originality here, I'm more
> interested in thinking about how to get such things quite widely
> deployed, though it would be cool to hear about prior art just in case
> I decide to publish a tech report.]
>
> One element required to get essentially all messaging on the
> Internet end to end encrypted is a good way to find out what people's
> keys are.
>
> If I meet someone at a reception at a security conference, they might
> scrawl their email address ("alice@example.org") for me on a cocktail
> napkin.
>
> I'd like to be able to then write to them, say to discuss their
> exciting new work on evading censorship of mass releases of stolen
> government documents using genetically engineered fungal spores to
> disseminate the information in the atmosphere worldwide.
>
> However, in our new "everything is always encrypted" world, I'll be
> needing their encryption key, and no one can remember something as
> long as that.
>
> So, how do I translate "alice@example.org" into a key?
>
> Now, the PGP web-of-trust model, which I think is broken, would have
> said "check a key server, see if there's a reasonable trust path
> between you and Alice."
>
> I have an alternative suggestion.
>
> Say that we have a bunch of (only vaguely) trustworthy organizations
> out in the world. (They can use crypto based log protocols of various
> kinds to make sure you don't _really_ need to trust them, but for the
> moment that part doesn't matter.)
>
> Say that Alice, at some point in the past, sent an email message,
> signed in her own key, to such an organization's key server, saying in
> effect "this is alice@example.org's key".
>
> At intervals, the trustworthy organization (and others like it) can
> send out email messages to Alice, encrypted in said key, saying "Hi
> there! Please reply with a message containing this magic cookie,
> encrypted in our key, signed in yours."
>
> If a third party needing the key for alice@example.org queries the
> vaguely trusted server, it will then give them information like "For
> the past six years, we've been sending alice@example.org emails every
> couple of weeks asking her to reply to demonstrate she controls a
> particular public key, and she always has -- new keys have always been
> signed in the old one, too. Here's a log, including various sorts of
> widely witnessed events and hash chains so that if we were lying about
> this we had to be planning to lie about it for a very long time."
>
> Now of course, in the real world, who wants to go through the effort
> of hand replying to query messages to establish a key over time?
> Instead, Alice has some actually trusted software running on her
> computer at home.
>
> She can either leave it to automatically do IMAP queries against her
> mailbox (which could even be GMail or what have you) and reply on her
> behalf, or it could ask her to unlock her key while she's at home in
> the morning having her coffee. However, I think the former is actually
> preferable. We'd rather have an imperfect system that is effortless to
> use but can be bypassed by physically breaking in to someone's home.
> (After all if you did that you probably can bug Alice's hardware
> anyway.)
>
> Alice probably also needs to make sure someone isn't spoofing her
> replies by accessing her IMAP box and replying for her (using a key
> known to the attacker but presumably not to Alice) and then deleting
> the query, but the mere absence of periodic pings from the trusted
> party may be enough to create suspicion, as might doing one's own
> queries against the trusted parties and noticing that the key isn't
> your own.
>
> Presumably, of course, there should be a bunch of such servers out
> there -- not so many that the traffic becomes overwhelming, but not so
> few that it is particularly feasible to take the system off the
> air. (One can speculate about distributed versions of such systems as
> well -- that's not today's topic.)
>
> So, this system has a bunch of advantages:
>
> 1) It doesn't require that someone associated with administrators of
> the domain name you're using for email has to cooperate with deploying
> your key distribution solution. Alice doesn't need her managers to agree
> to let her use the system -- her organization doesn't even need to
> know she's turned it on. Yet, it also doesn't allow just anyone to
> claim to be alice@example.org -- to put in a key, you have to show you
> can receive and reply to emails sent to the mailbox.
>
> 2) You know that, if anyone is impersonating Alice, they had to have
> been planning it for a while. In general, this is probably "good
> enough" for a very large number of purposes, and much better than a
> perfect system that no one ever uses.
>
> You can always trade a key hash with Alice personally, of course, and
> if you do, perhaps she sets her software to personally alert you to
> key refresh events and such (which we'll gloss over.) However, you
> don't *have* to do it that way -- the system makes it possible to get
> a reasonable amount of de facto trust without needing you to make many
> decisions that ordinary people have trouble making, too. None of this
> "I know this is Charlie's real key, but do I think Charlie is
> trustworthy to sign Alice's key, or would he have been sloppy"
> business that PGP imposes.
>
> (We can gloss over details like a protocol for Alice to update her key
> at intervals, or to make repeated claims that she was stupid and lost
> her key and needed to generate a new one, or what have you. I think
> they're solvable, and I don't want to clog up the gist of the idea
> with them.)
>
> 3) The system can be extremely lightweight to implement.
>
Not sure about _extremely_, but I certainly agree it should be relatively
straightforward. And since I have an interest in the "Here's a log,
including various sorts of widely witnessed events and hash chains so that
if we were lying about this we had to be planning to lie about it for a
very long time." (not sure I agree about that last part, btw), I hereby
volunteer to implement that part if there are people willing to implement
the rest...
>
> Disadvantages are obvious. It isn't "perfect" in that mostly, it is
> just depending on temporal continuity and widely witnessed information
> to discourage forgery. On the other hand, that's a damn sight better
> than a universal key management system that doesn't exist.
>
> A few more notes:
>
> First, I said nothing about "certificates". I've contended for a very
> long time that I'm not sure what the function of the things really
> is. What I want in the real world is the sort of attestation of long
> term use that got discussed above. This system could use X.509 certs
> as a pure data format, of course, or PGP keys, or raw integers in the
> SSH style. Who cares.
>
> Second, I've said nothing really about what such keys could be used
> for. I'm thinking along the lines of next generation secure IM and
> Email systems, but really, such things could be used for anything. If
> people particularly insist on having separate keys for different
> purposes, they'll need to arrange to store some sort of label along
> with each of several keys in the key servers, of course, and they'll
> need to arrange to periodically sign round trips for all those
> keys. Personally, I think this is probably more trouble than it is
> worth, but I could be persuaded.
>
> Third, presumably one wants a means to query such databases that
> doesn't allow traffic analysis. Mix networks including Tor are
> probably the answer on that. Without such a mechanism, listening in on
> the query traffic becomes a very good way to trace out social
> networks.
>
> Perry
> --
> Perry E. Metzger perry@piermont.com
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--047d7bb0456621bbed04e551f72e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 August 2013 21:29, Perry E. Metzger <span dir=3D"ltr"><<a =
href=3D"mailto:perry@piermont.com" target=3D"_blank">perry@piermont.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">[Disclaimer: very little in this seems deeply new, I'm=
just<br>
mixing it up in a slightly different way. The fairly simple idea I'm<br=
>
about to discuss has germs in things like SPKI, Certificate<br>
Transparency, the Perspectives project, SSH, and indeed dozens of<br>
other things. I think I even suggested a version of this exact idea<br>
several times in the past, and others may have as well. I'm not going<b=
r>
to pretend to make claims of real originality here, I'm more<br>
interested in thinking about how to get such things quite widely<br>
deployed, though it would be cool to hear about prior art just in case<br>
I decide to publish a tech report.]<br>
<br>
One element required to get essentially all messaging on the<br>
Internet end to end encrypted is a good way to find out what people's<b=
r>
keys are.<br>
<br>
If I meet someone at a reception at a security conference, they might<br>
scrawl their email address ("<a href=3D"mailto:alice@example.org">alic=
e@example.org</a>") for me on a cocktail<br>
napkin.<br>
<br>
I'd like to be able to then write to them, say to discuss their<br>
exciting new work on evading censorship of mass releases of stolen<br>
government documents using genetically engineered fungal spores to<br>
disseminate the information in the atmosphere worldwide.<br>
<br>
However, in our new "everything is always encrypted" world, I'=
;ll be<br>
needing their encryption key, and no one can remember something as<br>
long as that.<br>
<br>
So, how do I translate "<a href=3D"mailto:alice@example.org">alice@exa=
mple.org</a>" into a key?<br>
<br>
Now, the PGP web-of-trust model, which I think is broken, would have<br>
said "check a key server, see if there's a reasonable trust path<b=
r>
between you and Alice."<br>
<br>
I have an alternative suggestion.<br>
<br>
Say that we have a bunch of (only vaguely) trustworthy organizations<br>
out in the world. (They can use crypto based log protocols of various<br>
kinds to make sure you don't _really_ need to trust them, but for the<b=
r>
moment that part doesn't matter.)<br>
<br>
Say that Alice, at some point in the past, sent an email message,<br>
signed in her own key, to such an organization's key server, saying in<=
br>
effect "this is <a href=3D"mailto:alice@example.org">alice@example.org=
</a>'s key".<br>
<br>
At intervals, the trustworthy organization (and others like it) can<br>
send out email messages to Alice, encrypted in said key, saying "Hi<br=
>
there! Please reply with a message containing this magic cookie,<br>
encrypted in our key, signed in yours."<br>
<br>
If a third party needing the key for <a href=3D"mailto:alice@example.org">a=
lice@example.org</a> queries the<br>
vaguely trusted server, it will then give them information like "For<b=
r>
the past six years, we've been sending <a href=3D"mailto:alice@example.=
org">alice@example.org</a> emails every<br>
couple of weeks asking her to reply to demonstrate she controls a<br>
particular public key, and she always has -- new keys have always been<br>
signed in the old one, too. Here's a log, including various sorts of<br=
>
widely witnessed events and hash chains so that if we were lying about<br>
this we had to be planning to lie about it for a very long time."<br>
<br>
Now of course, in the real world, who wants to go through the effort<br>
of hand replying to query messages to establish a key over time?<br>
Instead, Alice has some actually trusted software running on her<br>
computer at home.<br>
<br>
She can either leave it to automatically do IMAP queries against her<br>
mailbox (which could even be GMail or what have you) and reply on her<br>
behalf, or it could ask her to unlock her key while she's at home in<br=
>
the morning having her coffee. However, I think the former is actually<br>
preferable. We'd rather have an imperfect system that is effortless to<=
br>
use but can be bypassed by physically breaking in to someone's home.<br=
>
(After all if you did that you probably can bug Alice's hardware<br>
anyway.)<br>
<br>
Alice probably also needs to make sure someone isn't spoofing her<br>
replies by accessing her IMAP box and replying for her (using a key<br>
known to the attacker but presumably not to Alice) and then deleting<br>
the query, but the mere absence of periodic pings from the trusted<br>
party may be enough to create suspicion, as might doing one's own<br>
queries against the trusted parties and noticing that the key isn't<br>
your own.<br>
<br>
Presumably, of course, there should be a bunch of such servers out<br>
there -- not so many that the traffic becomes overwhelming, but not so<br>
few that it is particularly feasible to take the system off the<br>
air. (One can speculate about distributed versions of such systems as<br>
well -- that's not today's topic.)<br>
<br>
So, this system has a bunch of advantages:<br>
<br>
1) It doesn't require that someone associated with administrators of<br=
>
the domain name you're using for email has to cooperate with deploying<=
br>
your key distribution solution. Alice doesn't need her managers to agre=
e<br>
to let her use the system -- her organization doesn't even need to<br>
know she's turned it on. Yet, it also doesn't allow just anyone to<=
br>
claim to be <a href=3D"mailto:alice@example.org">alice@example.org</a> -- t=
o put in a key, you have to show you<br>
can receive and reply to emails sent to the mailbox.<br>
<br>
2) You know that, if anyone is impersonating Alice, they had to have<br>
been planning it for a while. In general, this is probably "good<br>
enough" for a very large number of purposes, and much better than a<br=
>
perfect system that no one ever uses.<br>
<br>
You can always trade a key hash with Alice personally, of course, and<br>
if you do, perhaps she sets her software to personally alert you to<br>
key refresh events and such (which we'll gloss over.) However, you<br>
don't *have* to do it that way -- the system makes it possible to get<b=
r>
a reasonable amount of de facto trust without needing you to make many<br>
decisions that ordinary people have trouble making, too. None of this<br>
"I know this is Charlie's real key, but do I think Charlie is<br>
trustworthy to sign Alice's key, or would he have been sloppy"<br>
business that PGP imposes.<br>
<br>
(We can gloss over details like a protocol for Alice to update her key<br>
at intervals, or to make repeated claims that she was stupid and lost<br>
her key and needed to generate a new one, or what have you. I think<br>
they're solvable, and I don't want to clog up the gist of the idea<=
br>
with them.)<br>
<br>
3) The system can be extremely lightweight to implement.<br></blockquote><d=
iv><br></div><div>Not sure about _extremely_, but I certainly agree it shou=
ld be relatively straightforward. And since I have an interest in the "=
;Here's a log, including various sorts of widely witnessed events and h=
ash chains so that if we were lying about this we had to be planning to lie=
about it for a very long time." (not sure I agree about that last par=
t, btw), I hereby volunteer to implement that part if there are people will=
ing to implement the rest...</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<br>
Disadvantages are obvious. It isn't "perfect" in that mostly,=
it is<br>
just depending on temporal continuity and widely witnessed information<br>
to discourage forgery. On the other hand, that's a damn sight better<br=
>
than a universal key management system that doesn't exist.<br>
<br>
A few more notes:<br>
<br>
First, I said nothing about "certificates". I've contended fo=
r a very<br>
long time that I'm not sure what the function of the things really<br>
is. What I want in the real world is the sort of attestation of long<br>
term use that got discussed above. This system could use X.509 certs<br>
as a pure data format, of course, or PGP keys, or raw integers in the<br>
SSH style. Who cares.<br>
<br>
Second, I've said nothing really about what such keys could be used<br>
for. I'm thinking along the lines of next generation secure IM and<br>
Email systems, but really, such things could be used for anything. If<br>
people particularly insist on having separate keys for different<br>
purposes, they'll need to arrange to store some sort of label along<br>
with each of several keys in the key servers, of course, and they'll<br=
>
need to arrange to periodically sign round trips for all those<br>
keys. Personally, I think this is probably more trouble than it is<br>
worth, but I could be persuaded.<br>
<br>
Third, presumably one wants a means to query such databases that<br>
doesn't allow traffic analysis. Mix networks including Tor are<br>
probably the answer on that. Without such a mechanism, listening in on<br>
the query traffic becomes a very good way to trace out social<br>
networks.<br>
<span class=3D""><font color=3D"#888888"><br>
Perry<br>
--<br>
Perry E. Metzger =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"mailto:perry@pie=
rmont.com">perry@piermont.com</a><br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</font></span></blockquote></div><br></div></div>
--047d7bb0456621bbed04e551f72e--
--===============0987760801358856585==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============0987760801358856585==--
