General PKI Question



bill
07-09-2005, 11:51 PM
Hi group,

Here's a basic PKI question that I'm having a hard time with finding an
answer to:

If in order to send an encrypted message using PKI, the sender encrypts the
message using their private key and the recipients public key, then how did
the sender get a copy of the recipients public key in the first? Must this be
published somewhere? Thanks.

Joe Rookie
07-09-2005, 11:51 PM
Most often, the sender and receiver exchange digitally signed e-mails first
to obtain the applicable public keys ...

"bill" <bill@discussions.microsoft.com> wrote in message
news:DBD435FA-E287-4D25-AC99-B2FB250C1AA9@microsoft.com...
> Hi group,
>
> Here's a basic PKI question that I'm having a hard time with finding an
> answer to:
>
> If in order to send an encrypted message using PKI, the sender encrypts
the
> message using their private key and the recipients public key, then how
did
> the sender get a copy of the recipients public key in the first? Must this
be
> published somewhere? Thanks.

Ted Zieglar
07-09-2005, 11:51 PM
First, a bit of background: If you want to send an encrypted message, you
encrypt the message with the intended recipient's public key. That way, only
the intended recipient can decrypt the message (with their private key).

If you want to send a signed message, you encrypt the hash of your message
with your own private key. If the recipient can decrypt the hash with your
public key, that proves that the message came from you.

Now to your question: Where does one obtain someone's public key? Well,
there are several methods but in general it works like this: If you're
encrypting a message your software obtains it from a PKI. If you're signing
a message your software will attach your digital certificate to the message.
The digital certificate contains your public key.
--
Ted Zieglar
"You can do it if you try."

"bill" <bill@discussions.microsoft.com> wrote in message
news:DBD435FA-E287-4D25-AC99-B2FB250C1AA9@microsoft.com...
> Hi group,
>
> Here's a basic PKI question that I'm having a hard time with finding an
> answer to:
>
> If in order to send an encrypted message using PKI, the sender encrypts
the
> message using their private key and the recipients public key, then how
did
> the sender get a copy of the recipients public key in the first? Must this
be
> published somewhere? Thanks.

Nestor Cabrera
07-09-2005, 11:51 PM
Ok, no offense Ted but your response was absolutely useless. My question was
very simple and did not require an explanation of how PKI works. Your last
line

"If you're encrypting a message your software obtains it from a PKI."

What the hell do you mean it obtains it from PKI????? PKI is the
infrastructure itself and this response tells me nothing! Perhaps I'm at
fault and I need to clarify my question:

If I send an encrypted message to someone (someon who I have never ever sent
a message to before, be it signed or otherwise), how does this person have my
public key? Example: I send an encrypted email to say, Bill Gates, using my
the private key my company issued me. I've never sent him an email before, he
does not have access to my GAL so if published my certs to the GAL he can't
get it. Will he be able to decrypt it?
Thank you and I'm sorry if I was a bit abrupt but this question has been
bothering me for some time.
--
Nestor L. Cabrera


"Ted Zieglar" wrote:

> First, a bit of background: If you want to send an encrypted message, you
> encrypt the message with the intended recipient's public key. That way, only
> the intended recipient can decrypt the message (with their private key).
>
> If you want to send a signed message, you encrypt the hash of your message
> with your own private key. If the recipient can decrypt the hash with your
> public key, that proves that the message came from you.
>
> Now to your question: Where does one obtain someone's public key? Well,
> there are several methods but in general it works like this: If you're
> encrypting a message your software obtains it from a PKI. If you're signing
> a message your software will attach your digital certificate to the message.
> The digital certificate contains your public key.
> --
> Ted Zieglar
> "You can do it if you try."
>
> "bill" <bill@discussions.microsoft.com> wrote in message
> news:DBD435FA-E287-4D25-AC99-B2FB250C1AA9@microsoft.com...
> > Hi group,
> >
> > Here's a basic PKI question that I'm having a hard time with finding an
> > answer to:
> >
> > If in order to send an encrypted message using PKI, the sender encrypts
> the
> > message using their private key and the recipients public key, then how
> did
> > the sender get a copy of the recipients public key in the first? Must this
> be
> > published somewhere? Thanks.
>
>
>

Ted Zieglar
07-09-2005, 11:51 PM
"...this question has been bothering me for some time.."

Evidentally. The exact mechanics vary with the particular e-mail or
encryption program, since it's not something that you do personally. The
software you're using does it for you.

In addition to having the software look up someone's digital certificate in
a directory, you can have them send you a signed e-mail message (which
contains their certificate and public key). Your application automatically
stores the certificate until you need to use it.

If you're interested in the details of how all this works with specific
programs, you might start with Verisign's web site, which has a pretty
detailed knowledge base, or check the technical areas of the web site of the
particular program you have in mind to use.

--
Ted Zieglar
"You can do it if you try."

"Nestor Cabrera" <NestorCabrera@discussions.microsoft.com> wrote in message
news:54B84BE3-11D9-4435-BAFF-A63E493238D8@microsoft.com...
> Ok, no offense Ted but your response was absolutely useless. My question
was
> very simple and did not require an explanation of how PKI works. Your last
> line
>
> "If you're encrypting a message your software obtains it from a PKI."
>
> What the hell do you mean it obtains it from PKI????? PKI is the
> infrastructure itself and this response tells me nothing! Perhaps I'm at
> fault and I need to clarify my question:
>
> If I send an encrypted message to someone (someon who I have never ever
sent
> a message to before, be it signed or otherwise), how does this person have
my
> public key? Example: I send an encrypted email to say, Bill Gates, using
my
> the private key my company issued me. I've never sent him an email before,
he
> does not have access to my GAL so if published my certs to the GAL he
can't
> get it. Will he be able to decrypt it?
> Thank you and I'm sorry if I was a bit abrupt but this question has been
> bothering me for some time.
> --
> Nestor L. Cabrera
>
>
> "Ted Zieglar" wrote:
>
> > First, a bit of background: If you want to send an encrypted message,
you
> > encrypt the message with the intended recipient's public key. That way,
only
> > the intended recipient can decrypt the message (with their private key).
> >
> > If you want to send a signed message, you encrypt the hash of your
message
> > with your own private key. If the recipient can decrypt the hash with
your
> > public key, that proves that the message came from you.
> >
> > Now to your question: Where does one obtain someone's public key? Well,
> > there are several methods but in general it works like this: If you're
> > encrypting a message your software obtains it from a PKI. If you're
signing
> > a message your software will attach your digital certificate to the
message.
> > The digital certificate contains your public key.
> > --
> > Ted Zieglar
> > "You can do it if you try."
> >
> > "bill" <bill@discussions.microsoft.com> wrote in message
> > news:DBD435FA-E287-4D25-AC99-B2FB250C1AA9@microsoft.com...
> > > Hi group,
> > >
> > > Here's a basic PKI question that I'm having a hard time with finding
an
> > > answer to:
> > >
> > > If in order to send an encrypted message using PKI, the sender
encrypts
> > the
> > > message using their private key and the recipients public key, then
how
> > did
> > > the sender get a copy of the recipients public key in the first? Must
this
> > be
> > > published somewhere? Thanks.
> >
> >
> >

John
07-09-2005, 11:52 PM
Nestor Cabrera wrote:

> If I send an encrypted message to someone (someon who I have never ever sent
> a message to before, be it signed or otherwise), how does this person have my
> public key? Example: I send an encrypted email to say, Bill Gates, using my
> the private key my company issued me. I've never sent him an email before, he
> does not have access to my GAL so if published my certs to the GAL he can't
> get it. Will he be able to decrypt it?

What you need to understand is what one should do with your private key.
A private key can have 2 purposes:

Decryption of stuff that is encrypted with your public key (eg. mails
someone sent to you)

Signing of stuff, to make clear it comes from you. (eg. when you send
someone a mail).

Also you need to understand what you can do with someone else's public
key. That public key has for you 2 purposes:

Encryption of stuff you want to sent to that someone else.

Verification of the signature on stuff that he sent to you.


These functions are usually combined, so that when you send someone a
secured e-mail, it is encrypted with the receivers public key, and
signed with your private key.

The receiver then opens the mail, upon which you signature is checked
using your public key, and decrypt it with his own private key.

To make it (just) a bit more complex: Nowadays it is becoming normal
practice to have different keypairs for encryption/decryption and
signing/verification purposes, at least in the X509-world.

Where to get keypairs (and certifates):
X509:
Roll your own using OpenSSL (or equivalent)
Rent/Lease/Buy from certificate providers.
Get other peoples public keys from their directories or have other
people give you their certificate.

PGP
Roll your own using PGP
Download other people's public keys from keyservers
Have other people give you their public keys, preferably manually (on
floppy, usb stick or whatever).

Sorry to butt in,
John

John
07-09-2005, 11:52 PM
John wrote:

> These functions are usually combined, so that when you send someone a
> secured e-mail, it is encrypted with the receivers public key, and
> signed with your private key.
>
> The receiver then opens the mail, upon which you signature is checked
> using your public key, and decrypt it with his own private key.

Allow me to add that this is a simplified representation.

Usually data is encrypted using TDES, AES or another symmetrical
algorithm, and only the key is encrypted asymmetrically.

Usually a hash is created from data, and only the hash is signed.

Signing = encrypting with private key, anyone with the public key
belonging to the keypair can decrypt (= verify the signature).

Encryption = encrypting with public key, only the person with the
private key belonging to the keypair can decrypt.

Private keys you keep private
Public keys you make public (or are made public for you).

Hope this adds not much to the confusion :-)

lynn@garlic.com
07-09-2005, 11:52 PM
Ted Zieglar wrote:
> First, a bit of background: If you want to send an encrypted message,
you
> encrypt the message with the intended recipient's public key. That
way, only
> the intended recipient can decrypt the message (with their private
key).
>
> If you want to send a signed message, you encrypt the hash of your
message
> with your own private key. If the recipient can decrypt the hash with
your
> public key, that proves that the message came from you.
>
> Now to your question: Where does one obtain someone's public key?
Well,
> there are several methods but in general it works like this: If
you're
> encrypting a message your software obtains it from a PKI. If you're
signing
> a message your software will attach your digital certificate to the
message.
> The digital certificate contains your public key.

basically there is asymmetric key cryptography as opposed to symmetric
key cryptography. in symmetric key cryptography, the same key is used
for both encrypting and decrypting the same message. in asymmetric key
cryptography they are different keys.

a business process has been defined for asymmetric key cryptography
where one key is designated as "public" and divulged to other parties
and the other key is designated as "private" and is never divulged.

some additional business processes have been defined

1) digital signature authentication .... a secure hash is computed for
the message, which is then encoded with the private key. other parties
with the corresponding public key can decode the digital signature and
compare the decoded secure hash with a freshly computed secure hash of
the message. this will validate a) the origin of the message and/or b)
if the message has been modified.

2) confidential data transfer ... people will encode messages with the
recipient's public key. only the recipient with their (never divulged)
private key can decode the message. frequently because of overhead of
asymmetric key cryptography ... a random symmetric key is generated,
the message is encrypted with the symmetric key and the symmetric key
is encode with the public key.
The encrypted message and encoded symmetric key are transmitted
together. only the corresponding private key can decode the symmetric
key ... and then, in turn decode the actual message.

In general, public keys can be registered with other parites ... in
much the same way shared-secrets and other kinds of authentication
materials are registered today ... using well established business
process relationship managment processes (some that have evolved over
hundreds of years, like bank accounts).

The initial kerberos pk-init ietf draft for adding public keys to
kerberos implementations specified registering public keys in lieu of
passwords
http://www.garlic.com/~lynn/subpubkey.html#kerberos
later specifications were added that certificate-based public keys
could be used

There have also been RADIUS implementations where public keys were
registered in lieu of passwords and digital signature authentication
operation was performed
http://www.garlic.com/~lynn/subpubkey.html#radius

>From 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* soemthing you know
* something you are

digital signature authentication schemes are a form of "something you
have" authentication .... only you have access and use of a (never
divulged) private key.

Certificate-based public keys (PKIs) were designed to address the
offline emails scenario of the early 80s; recipient dials up their
(electronic) postoffice, exchanged email, and hungup. They were then
possibly faced with some email from a total stranger that they had
never communicated with before.
Certificates were somewhat the "letters of credit" analogy (from the
sailing ship days) ... where the recipient/relying-party had no other
means of obtaining information about the subject ... either locally (or
heaven forbid using online, electronic means).

In the early 90s, there were x.509 identity certificates ... where the
CAs, not being able to reliably predict what information some future
relying party might need .... were looking at grossly overloading
certifictes with excessive amounts of privacy information. Later in the
90s, some number of infrastructures (like financial institutions) were
realizing that identity certificates, grossly overloaded with excessive
amount of information represented significant liability and privacy
issues.

At this time, you saw some appearance of relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

where the information in a certificate was reduced to little more than
a record lookup indicator (userid, account number, etc). a person would
create a message, digitally sign it, and package the message, the
digital signature and the certificate and send it off to the relying
party. the relying party then would use the indicator in the base
message to index the appropriate relationship record and retrieve the
associated information (including the registered, onfile public key).
the onfile public key would then be used to verify the digital
signature (authenticating the messsage). It was trivial to demonstrate
that the stale, static certificate was redundant and superfluous.

in the financial sector, these relying-party-only certificates were
also be targeted at payment transactions. the typical payment message
is on the order of 60-80 bytes. the typical relying-party-only
certificate from the period was on the order of 4k-12k bytes. not only
were the stale, static certificates redundant and superfluous, but they
could also contribute a factor of 100 times in message payload bloat.

a basic issue is that the certificate design point was addressing the
problems of a offline, unconnected world for first time communication
between total strangers. as the world transitions to ubiquitous,
online, certificates are looking more like horse buggies on an
interstate with 75mph speed limit.

we were asked to do some consulting with this small client/server
startup in menlo park that wanted to do some payment transactions on
their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and they had this thing called SSL that could encrypt internet
transmission.
slightly related, recent posting
http://www.garlic.com/~lynn/2005h.html#39 Attacks on IPsec

there was also a perceived integrity problem with the domain name
infrastructure ... so SSL server domain name certificates were defined
http://www.garlic.com/~lynn/subpubkey.html#sslcert

where the browser would compare the domain name in the typed-in URL
with the domain name in the digital certificate. Along with working on
the specifics of payment gateway ... we also got to go around and do
end-to-end business audits of several of the certification authorities
that would be providing SSL server domain name certificates.

The process has an applicant for an SSL server domain name certificate
providing loads of identification information. The certification
authority then performs the expensive, complex, and error-prone
identification matching process of checking the supplied identification
material with the identification material on file with the
authoritative agency for domain name ownership.

Note that the authoritative agency for domain name ownership is the
same domain name infrastructure that has the integrity issues that give
rise to the requirement for SSL server domain name certificates.

So somewhat from the certification authority industry, there is a
proposal that SSL domain name owners register a public key at the same
time they register a domain name ... as part of an attempt to improve
the integrity of the domain name infrastructure (so that the
information that goes into certification of SSL domain name
certificates is also more reliable).

Now, somebody can digitally sign their SSL domain name certificate
application. The CA (certification authority) can now retrieve the
onfile public key from the domain name infrastructure to validate the
applicant's digital signature ... note this is a certificate-less
digital signature authentication using online, onfile public keys
http://www.garlic.com/~lynn/subpubkey.html#certless

this also has the side-effect of turning an expensive, complex, and
error prone identification process into a simpler and more reliable
authenticatin process.

However, this improvement represents something of a catch22 for the CA
PKI industry ...

1) improvements in the integrity of the domain name infrastructure
mitigates some of the original requirement for SSL domain name
certificates

2) if the CA PKI industry can make the trust basis of their whole
infrastructure on certificateless, real-time retrieval of onfile public
keys .... it may occur to others that they could use the same public
keys directly
(potentially modifying the SSL protocol implementation to use public
keys directly obtained from the domain name infrastructure rather than
relying on stale, static certificates).

bill
07-09-2005, 11:56 PM
Thank you all very much for all the great responses. It was of great help!

--



"bill" wrote:

> Hi group,
>
> Here's a basic PKI question that I'm having a hard time with finding an
> answer to:
>
> If in order to send an encrypted message using PKI, the sender encrypts the
> message using their private key and the recipients public key, then how did
> the sender get a copy of the recipients public key in the first? Must this be
> published somewhere? Thanks.


General PKI Question