Key Management - PGP

This is a discussion on Key Management - PGP ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Key Management

  1. Key Management

    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 .

    --

    David E. Ross


    Q: What's a President Bush ****tail?
    A: Business on the rocks.

  2. Re: Key Management

    In article ,
    David E. Ross 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 .


    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

  3. Re: Key Management

    On 10/22/2008 1:32 PM, dj3vande@csclub.uwaterloo.ca.invalid wrote:
    > In article ,
    > David E. Ross 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 .

    >
    > 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
    >


    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.

    --

    David E. Ross


    Q: What's a President Bush ****tail?
    A: Business on the rocks.

  4. Re: Key Management

    In article ,
    David E. Ross wrote:
    >On 10/22/2008 1:32 PM, dj3vande@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

  5. Re: Key Management

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    "David E. Ross" 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 .


    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-----


  6. Re: Key Management

    On 10/22/2008 9:17 PM, Neil W Rickert wrote:
    > "David E. Ross" 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 .

    >
    > 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.


    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).

    --

    David E. Ross


    Q: What's a President Bush ****tail?
    A: Business on the rocks.

  7. Re: Key Management

    In article ,
    David E. Ross wrote:
    >On 10/22/2008 9:17 PM, Neil W Rickert 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

+ Reply to Thread