Key Management
David E. Ross
issues of key management; I might add other issues later.
I would appreciate review comments about the page. Please remember that
my PGP pages are not intended to be rigorously technical. Instead, they
are oriented to the average user.
The page is at <http://www.rossde.com/PGP/key_mgmnt.html>.
--
David E. Ross
<http://www.rossde.com/>
Q: What's a President Bush cocktail?
A: Business on the rocks.
dj3v...@csclub.uwaterloo.ca.invalid
David E. Ross <nob...@nowhere.not> wrote:
>I am adding a new Web page to my PGP pages. Currently it addresses two
>issues of key management; I might add other issues later.
>
>I would appreciate review comments about the page. Please remember that
>my PGP pages are not intended to be rigorously technical. Instead, they
>are oriented to the average user.
>
>The page is at <http://www.rossde.com/PGP/key_mgmnt.html>.
The section on transferring private keys may be improved by working in
a mention that the point of the exercise is to create a secure channel,
and that once you have found some way to set up that secure channel you
can safely send your private key through it.
(I prefer to use scp, but that's probably way more detail than would be
suitable for your target audience.)
I also did some looking at the rest of the site and came across this
(in the public/private-key section of the "PGP encryption" page):
It uses one key (the public key) to encrypt the target data, using a
mathematical operation far more complicated than merely adding the
two together. There is no known mathematical operation that can take
that same key and use it for decryption.
Ow, my math. There *is* a simple mathematical operation that can give
the private key given the public key; it's just extraordinarily hard to
compute. (Factoring products of large primes or solving the discrete
logarithm problem aren't complicated-hard, they're just lots-of-work-
hard.)
Here's an attempt at re-working the second sentence to correct that
without losing accessibility for the average user:
It's extremely hard to go the other way and use the information in
the public key to decrypt a message. (How hard? Hard enough that
nobody has *ever*, with all the computing power in the world, done it
with the types of keys currently in use.)
(There's probably more improvement that could be done. Moving this
part after the next sentence, introducing private keys, may make it
flow better.)
dave
--
Dave Vandervies dj3vande at eskimo dot com
You're right of course. Stupid mistake on my part. That'll teach me
to post while using a rented brain.
--Keith Thompson in comp.lang.c
David E. Ross
I have revised both the new page and also the Encryption page, as you
suggested but not with your phrasing. However, I'm holding off
uploading them until I get comments from others. I'll repost here when
I do upload the revisions.
Yes, all 300+ pages on my Web site can always use some improvement. I
do revise them on occasion, trying to improve my writing style while
also making the information more current (especially checking whether
external links have gone 404). It's a hobby, however, not paid
employment (from which I'm retired). Thus, I sometimes put a higher
priority on working in my garden or doing volunteer work in my community.
dj3v...@csclub.uwaterloo.ca.invalid
David E. Ross <nob...@nowhere.not> wrote:
>On 10/22/2008 1:32 PM, dj3v...@csclub.uwaterloo.ca.invalid wrote:
>> I also did some looking at the rest of the site and came across this
>> (in the public/private-key section of the "PGP encryption" page):
[...]
>> Here's an attempt at re-working the second sentence to correct that
>> without losing accessibility for the average user:
>> It's extremely hard to go the other way and use the information in
>> the public key to decrypt a message. (How hard? Hard enough that
>> nobody has *ever*, with all the computing power in the world, done it
>> with the types of keys currently in use.)
>> (There's probably more improvement that could be done. Moving this
>> part after the next sentence, introducing private keys, may make it
>> flow better.)
>I have revised both the new page and also the Encryption page, as you
>suggested but not with your phrasing.
I'm used to talking to technically oriented people, so you're probably
a better person to choose the phrasing than I am.
>Yes, all 300+ pages on my Web site can always use some improvement. I
>do revise them on occasion, trying to improve my writing style while
>also making the information more current (especially checking whether
>external links have gone 404).
The web would be a much better place if more people did that. (Though
my "more improvement that could be done" was referring specifically to
the re-working I suggested for the sentence I pointed out, not to the
site in general.)
> It's a hobby, however, not paid
>employment (from which I'm retired). Thus, I sometimes put a higher
>priority on working in my garden or doing volunteer work in my community.
Fair enough. You've obviously put a lot more work into it than I ever
have for anything of the sort, so I'm not exactly in a position to
complain.
dave
--
Dave Vandervies dj3vande at eskimo dot com
If Jesus was a white, English-speaking, anglo-saxon male, then we should
*ALL* be white, English-speaking, anglo-saxon males.
--Mark "Kamikaze" Hughes in the scary devil monastery
Neil W Rickert
Hash: SHA1
"David E. Ross" <nob...@nowhere.not> writes:
>I am adding a new Web page to my PGP pages. Currently it addresses two
>issues of key management; I might add other issues later.
>I would appreciate review comments about the page. Please remember that
>my PGP pages are not intended to be rigorously technical. Instead, they
>are oriented to the average user.
>The page is at <http://www.rossde.com/PGP/key_mgmnt.html>.
On the question of transferring keys, I'll agree with what
Dave Vandervies posted. I regularly use an SSH channel, typically
scp or rsync over ssh to copy keyrings. Or pscp (the PuTTY version
of scp) to copy between windows and unix.
I'll also add that direct binary copying of keyrings works just
fine between windows and unix. There's no need to convert to ascii.
There are format differences between gnupg and pgp for keyring files.
In that case, I typically import the binary keyring from one into
the other. It seems that the folk who designed for formats did it
pretty well, in that both manage to be able to at least read the
format of the other. Importing from private and public key rings
works in either direction.
---------------------------
On the question of replacing key pairs - I'm currently in that
situation. I'll probably be changing email address, and have to
decide whether to just add the new email address to an existing key,
or start afresh.
My current inclination is to create a master signing key, with
my name but no email address. Encourage a few folk to sign that,
and perhaps sign that with my current key. Then use the master
key to sign any keys that have email addresses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkj/+rkACgkQvmGe70vHPUNK0gCgmbKkrL2j/AzhMHB5dQwqQkFg
9nkAoNdhESTIeYmeOgZX61BrIrMOKe8a
=qWQx
-----END PGP SIGNATURE-----
David E. Ross
Secure communication channels (e.g., SSL) are often not available to
ordinary users. In my case, when I used the third method, I did have a
secure channel. However, another department in my company controlled
that channel. Personnel in that department had appropriate security
clearances but not the necessary need-to-know for the project on which I
was working. Thus, I had to encrypt the key-pair when sending it over
that channel. That's why I developed this method (about 8 years ago,
before I retired).
dj3v...@csclub.uwaterloo.ca.invalid
David E. Ross <nob...@nowhere.not> wrote:
>> On the question of transferring keys, I'll agree with what
>> Dave Vandervies posted. I regularly use an SSH channel, typically
>> scp or rsync over ssh to copy keyrings. Or pscp (the PuTTY version
>> of scp) to copy between windows and unix.
>Secure communication channels (e.g., SSL) are often not available to
>ordinary users.
I would prefer "not usable by" over "not available to", but that's just
splitting hairs over terminology. The average user probably has or can
easily get the tools needed to set up an SSH-based secure channel, but
can't reasonably be expected to have the knowledge needed to use them.
With that in mind, it's a lot easier to tell them "You have (and
presumably know how to use) these tools already, here's how to use them
to set up a secure channel" than to tell them about still more tools,
even if somebody skilled in the art would probably find those other
tools easier to use for the purpose.
(If somebody has SSH available and knows how to drive it, then as soon
as you say "secure channel" they should realize that they can do that
with SSH. Users at that level can just stop reading there without
needing to be told how to set up a secure channel using SSH.)
> In my case, when I used the third method, I did have a
>secure channel. However, another department in my company controlled
>that channel. Personnel in that department had appropriate security
>clearances but not the necessary need-to-know for the project on which I
>was working. Thus, I had to encrypt the key-pair when sending it over
>that channel. That's why I developed this method (about 8 years ago,
>before I retired).
Putting it in these terms is probably a bit above the level you're
targeting, but that's an excellent illustration of what public key
cryptography really accomplishes: Fundamentally, it's just a way to
bootstrap a confidential channel (Alice can talk to Bob and Eve can't
listen in) using only authenticated messages (Alice knows it came from
Bob and not Mallory, but Eve can easily read it).
dave
--
Dave Vandervies dj3vande at eskimo dot com
> And you haven't defined what you mean by an "expression".
He doesn't have to. C defines it for him.
--Keith Thompson and Richard Heathfield in comp.lang.c