[148321] in cryptography@c2.net mail archive
Re: [Cryptography] Explaining PK to grandma
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Nov 28 13:56:10 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <3DC58178-5B9B-4C89-892C-3D6B7F91567C@lrw.com>
Date: Thu, 28 Nov 2013 13:50:11 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: Cryptography <cryptography@metzdowd.com>,
Ralf Senderek <crypto@senderek.ie>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6888192840377230076==
Content-Type: multipart/alternative; boundary=089e0158ace0f3fe5b04ec412ea5
--089e0158ace0f3fe5b04ec412ea5
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Nov 28, 2013 at 7:30 AM, Jerry Leichter <leichter@lrw.com> wrote:
> On Nov 27, 2013, at 4:39 PM, Phillip Hallam-Baker wrote:
>
> *But*, there is one thing that may need, no so much "explanation" in the
>>> sense of conveying a deep understanding, as "training". Somehow, a user of
>>> secure email has to know how to get a key for themselves; how to move that
>>> key to different machines;
>>
>>
> No!
>
> All the user needs to know is how to configure their email on a different
> machine. If it takes more than giving the machine the address of the
> account and authorizing the new machine to connect to it then it has failed.
>
> I'm not sure what you are saying here. "Authorizing the new machine" is
> just "how to move the key to a different machine" in different words.
>
The difference is that the machine might not have the key ever, merely the
ability to decrypt.
I got beaten up by MEZ for saying similar stuff about padlocks and green
bars when we did the UI work in the W3C, it really does make a difference.
We have to think in terms of user objectives, not mechanism.
For example, I have an iPhone, how much can I trust it? Well only to a
degree because I could easily lose it or it could get taken off me at an
airport by the type of government that does this.
http://upload.wikimedia.org/wikipedia/commons/4/4b/AbuGhraibAbuse-standing-on-box.jpg
So maybe it is better to not put the decryption key on the end point device
at all. Maybe it is safer in the cloud. Or maybe we use some sort of key
splitting scheme.
Going straight to a mechanism forecloses options that might turn out to be
simpler.
> OK, it says it even more broadly than I did, but you can't get *too* broad
> without losing important distinctions. The person undertaking the actions
> has to understand that some actions make the encrypted text visible, so are
> not to be undertaken lightly. If you really use the words "authorizing the
> machine", you're putting the emphasis in the wrong place: The machine.
> Who cares about the machine? What matters is what *people* you've
> implicitly authorized through this action. Handing your car keys to
> someone isn't about the keys - it's about who can drive away in your car.
>
I can walk instead of ride in a car but I can't do RSA at more than 512
bits in my head and I am not sure if I can do 512 any more.
So there is going to be a machine involved or machines even but Alice is
not a machine. The trust end points are people and organizations but the
technical implementation is machines.
--
Website: http://hallambaker.com/
--089e0158ace0f3fe5b04ec412ea5
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 Thu, Nov 28, 2013 at 7:30 AM, Jerry Leichter <span dir=3D"ltr">&=
lt;<a href=3D"mailto:leichter@lrw.com" target=3D"_blank">leichter@lrw.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"><div style=3D"word-wrap:break-word"><div><div><div>On Nov =
27, 2013, at 4:39 PM, Phillip Hallam-Baker wrote:</div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex">
<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">*But*, there is one thing that may need, no so much "=
explanation" in the sense of conveying a deep understanding, as "=
training". =A0Somehow, a user of secure email has to know how to get a=
key for themselves; how to move that key to different machines;</blockquot=
e>
</blockquote><div><br></div><div>No!</div><div>=A0</div><div>All the user n=
eeds to know is how to configure their email on a different machine. If it =
takes more than giving the machine the address of the account and authorizi=
ng the new machine to connect to it then it has failed.</div>
</div></div></div></blockquote></div>I'm not sure what you are saying h=
ere. =A0"Authorizing the new machine" is just "how to move t=
he key to a different machine" in different words. =A0</div></div></bl=
ockquote>
<div><br></div><div>The difference is that the machine might not have the k=
ey ever, merely the ability to decrypt.</div><div><br></div><div>I got beat=
en up by MEZ for saying similar stuff about padlocks and green bars when we=
did the UI work in the W3C, it really does make a difference. We have to t=
hink in terms of user objectives, not mechanism.</div>
<div><br></div><div><br></div><div>For example, I have an iPhone, how much =
can I trust it? Well only to a degree because I could easily lose it or it =
could get taken off me at an airport by the type of government that does th=
is.</div>
<div><br></div><div><a href=3D"http://upload.wikimedia.org/wikipedia/common=
s/4/4b/AbuGhraibAbuse-standing-on-box.jpg">http://upload.wikimedia.org/wiki=
pedia/commons/4/4b/AbuGhraibAbuse-standing-on-box.jpg</a><br></div><div><br=
>
</div><div><br></div><div>So maybe it is better to not put the decryption k=
ey on the end point device at all. Maybe it is safer in the cloud. Or maybe=
we use some sort of key splitting scheme.</div><div><br></div><div>Going s=
traight to a mechanism forecloses options that might turn out to be simpler=
.</div>
<div><br></div><div><br></div><div><br></div><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div style=3D"word-wrap:break-word">
<div>OK, it says it even more broadly than I did, but you can't get *to=
o* broad without losing important distinctions. =A0The person undertaking t=
he actions has to understand that some actions make the encrypted text visi=
ble, so are not to be undertaken lightly. =A0If you really use the words &q=
uot;authorizing the machine", you're putting the emphasis in the w=
rong place: =A0The machine. =A0Who cares about the machine? =A0What matters=
is what *people* you've implicitly authorized through this action. =A0=
Handing your car keys to someone isn't about the keys - it's about =
who can drive away in your car.</div>
</div></blockquote><div><br></div><div>I can walk instead of ride in a car =
but I can't do RSA at more than 512 bits in my head and I am not sure i=
f I can do 512 any more.</div><div><br></div><div>So there is going to be a=
machine involved or machines even but Alice is not a machine. The trust en=
d points are people and organizations but the technical implementation is m=
achines.</div>
<div><br></div><div>=A0</div></div><br clear=3D"all"><div><br></div>-- <br>
Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://halla=
mbaker.com/</a><br>
</div></div>
--089e0158ace0f3fe5b04ec412ea5--
--===============6888192840377230076==
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
--===============6888192840377230076==--
