Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Subject
- Posted on
- very basic quextions: public key encryption
- 08-04-2004
- walterbyrd
August 4, 2004, 3:22 pm
1) Sender encrypts plaintext, sends it to me along with public key.
2) I decrypt with my private key.
Q: What exactly is my private key? How do I get it? Where is it
stored? Do I only use it once? Do I have some special program that
generates it? Do I have to be using a specific software application
that is in sync with the senders software application?
Does the sender send everybody the same public key? If not, what makes
it "public"? If so, how can that be secure?
Although there seems to be thousands of sources that explain the basic
process, in about the same level of depth that I use in steps 1) and
2) above; I can't find any source that answers these sufficient
detail. Without understand simple details like "what exactly is a
private key?" I can't really get my mind around the process. Any help
is appreciated. Thank you.
Re: very basic quextions: public key encryption
WB> Although there seems to be thousands of sources that explain the
WB> basic process, in about the same level of depth that I use in
WB> steps 1) and 2) above; I can't find any source that answers these
WB> sufficient detail.
http://www.schneier.com/book-applied.html
--
Richard Silverman
res@qoxp.net
Re: very basic quextions: public key encryption
]> As I understand it:
]> 1) Sender encrypts plaintext, sends it to me along with public key.
No, the sender almost never sends the plaintext encrypted with public key
system. They are far too slow.
The sender sends a random key for a symmetric ordinary encryption system.
The plaintext is encrypted with that symmetric system. That key is
encrypted using the public key of the recipient (you).
]> 2) I decrypt with my private key.
You decrypt the symmetric key with your private key corresponding to the
public key the sender encrypted it with, and then you decrypt the message
using that symmetric key.
]> Q: What exactly is my private key? How do I get it?
You make it. the public key system will have a program (gpg --gen-key ) to
enable you to generate a private/public key pair.
]> Where is it
]> stored?
In a file on your system, usually protected by a symmetric key password
which you have chosen.
]> Do I only use it once?
It? What? The public/private key pair is used until you feel or have
evidence that it is comprimised.
]> Do I have some special program that
]> generates it?
See above.
]> Do I have to be using a specific software application
]> that is in sync with the senders software application?
]> Does the sender send everybody the same public key?
It is the recipient's public key which is used, not the senders. The
recipient can use the same public key for everyone, or have many of them
for different purposes.
]> If not, what makes
]> it "public"? If so, how can that be secure?
It ( the recipient's public key) is public. It is secure because given the
information of the public
key, noone can figure out what the private key is to decrypt with.
Re: very basic quextions: public key encryption
At a guess, you're talking about signing rather than encrypting. Sender signs
with his private key, and you use his public key to verify it. He's
(presumably) including the public key in case you don't have it, and want to
use this message as the start of a trust relationship.
If you use the key provided, you get no assurance. however, if you use the
public key you already had from him, you know that his private key signed the
message.
If you get future messages that the given public key validates, you know the
same private key signed them all.
You can't, unless it was encrypted with your public key.
A private/public key pair is generated for you by some program (gpg --gen-key
if you're using gpg). As implied by the names, keep your private key secret,
and give out your public key. Give it out in a way that people actually know
that this public key came from you, preferably in person. Collect public keys
from your friends, in such a way that you know it's really your friend's key.
When signing a message, use your private key, and it can be verified with your
public key. When encrypting a message, use your friend's public key, and only
his private key can decrypt it. Often, you'll sign then encrypt using your
private and his public key.
If you want this to be automatic, you need to use an e-mail program that
does it for you.
Yes, everyone has the same public key for the sender. It's secure because a
lot of people have it and can verify it's the same one for each message he
sends.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/
Re: very basic quextions: public key encryption
the fundamental technology is asymmetric key cryptography ... a key
pair ... where either key is used for encoding and you need the other
of the key pair for decoding (as opposed to symmertic key cryptography
uses the same key for both encoding and decoding). the generation is
somewhat more envolved than secret key generation since there is a
complex relationship between the two keys in an asymmetric key pair.
public key cryptography is a business process using asymmetric key
cryptography technology. one of the key pair has a business
designation of "private" and the other of the key pair has the
business designation of "public".
this is can be used to address two business problems/opportunities in
symmetric key cryptography
1) secure key distribution
the designation of "public" (in theory) means you don't care who
is allowed to know your public key ... it can be sprayed all over
the world so that everybody has it. this actually only addresses
the security confidentiality problem of hiding the key. there is
still the security integrity problem of whether somebody actually
knows any specific public key is yours.
2) needing a unique shared secret (symmetric key) for every
relationship
since everybody can know your public key ... there is no security
confidentiality requirement for a unique shared secret for every
relationship ... say worst case (for shared secret symmetric key):
N*(N-1)/2 .. where N is the number of people in the world (and every
key might have to be changed every month). The problem reduces to N
asymmetric key pairs (or 2*N keys).
... so the full process ... replacing an exchanged share-secret
symmetric key ... we each have the other's public key. Instead
of symmetrically encrypting the message, where you know only
I could have encrypted the message and I know only you can
decrypt the message ....
1) I compute a secure hash (say fips180) of the message and
encode the secure hash with my private key. this is typically
referred to as the digital signature
2) i combine the message and the digital signature ... and
encrypt the combination with your public key.
3) i transmit the message
4) only you, with your corresponding private key are capable
of decrypting the message (nobody else can see it)
5) once you have decrypted the message, you verify the digital
sigatnure with my public key; i.e. a) decode the digital signature
with my public key to get the original secure hash, b) recalculate
the secure hash on the message, c) compare if the recalculated
secure hash and the decoded digital signature secure hash are
identical.
only your private key could decode the message and only my
public key can verify the digital signature.
If there isn't a concern about the secrecy of the data, then it is
possible to only digitally sign it ... this still gives you whether or
not the data has been modified in transit (integrity) and the verifies
the origin.
If there isn't a concern about the origin of the data, then it is
possible to simply encrypt the data w/o a digital signature. This is
sort of like when you send off you credit card number in a SSL
encrypted session.
SSL does an additional modification. asymmetric encryption tends to be
a lot more expensive than symmetric encryption. So when the
client-side starts up ... it generates a random session secret key
... which it uses to encrypt the actual data ... and then the session
secret key is encrypted with the server's public key. Since only the
server's private key can decrypt and obtain the random session secret
key ... it is still viewed as public key operation (from the
stand-point of key distribution problem) ... but the performance is
that of symmetric cryptography since the server then decrypts the
actual data with the randomly generated session secret key (that they
got from the client). The server doesn't actually know who the client
is ... but the client is (pretty) sure that only the server (with the
correct private key) will see the actual data.
sender/receiver or client/server ... at least need to have the other's
public key ... and have support for commonly selected cryptography
algorithms (i.e. there can be variables like key sizes and/or specific
type of asymmetric cryptography technology).
recent thread discussing RSA and ECC asymmetric cryptography
technology issues:
http://www.garlic.com/~lynn/2004h.html#30
recent thread discussion what might a digital signature actually
mean:
http://www.garlic.com/~lynn/2004h.html#13
http://www.garlic.com/~lynn/2004h.html#14
recent thread in this (comp.security.ssh) newsgroup about basics of
(public) key authentication
http://www.garlic.com/~lynn/2004h.html#21
http://www.garlic.com/~lynn/2004h.html#23
http://www.garlic.com/~lynn/2004h.html#32
http://www.garlic.com/~lynn/2004h.html#37
which included some side-thread about whether some of these questions
were class assignments ... and the etiquette of using usenet for doing
homework
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn /
Site Timeline
- » sftp keys
- — Next thread in » Secure Shell Forum
- » tunneling on port 80 and web server on port 80
- — Previous thread in » Secure Shell Forum
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum
- » Dell Battery Slice LED codes
- — The site's Newest Thread. Posted in » Laptop Computers Forum