I understand that when sending a message, the message is encrypted with a public key and sent over, requiring a private key to open the encrypted message. However I wonder how both clients know the private keys. For example:
John sends a message to Alice saying "Hello World".
The message get's encrypted with a public key, and sent
Alice decrypts it with a private key.
But, how does Alice's computer know the private key, how does it get there, does it come with the encrypted message in another layer of encryption, or is it on both of the computer at the start, but how?
I am just wondering, and it would be great if anyone can please explain thanks!
Both parties generate their own private keys that stay with them. The public portion of these keys are then distributed to other parties that want to communicate with the owner of the private key.
The important part is ensuring that you are communicating with who you think you are communicating with, otherwise the middle-man could send his public key to both parties masquerading as the intended recipient.
This answer does, to some degree, assume we are talking about RSA. There are many asymmetric cryptosystems that use private/public keys that may not necessarily make sense with the terminology I've used.
In the simplest model:
Alice generates a keypair Apub / Apriv.
Bob doesn't need keys if this is RSA.
Alice sends Apub to Bob. She does this securely (exercise left to the reader).
Bob encrypts some data using Apub.
Bob sends his encrypted stuff to Alice.
Alice knew a priori (simple scenario, remember?) which key was being used, and uses Apriv to recover the data.
In more complex models entities may have many private keys. Aside from "try all of them" we can add some structure.
Alice generates a keypair Apub / Apriv. She saves these securely (exercise left to the reader).
Alice obtains an X.509 Public Key Certificate with Apub as the subject public key.
Self signed is fine here, or CA-issued is always good.
Bob still is a happy man who doesn't need to manage keys. That makes his FISMA/PCI/etc compliance audits easier.
Alice sends her certificate to Bob. She does this securely (ELTTR).
Bob (uses software which) extracts Apub from the certificate and encrypts data using it.
Bob('s software) builds a formatted message which includes a way to identify which certificate was used, and what the encrypted content is.
Maybe he just sends the whole cert back. (Probably not)
Maybe he sends the certificate Issuer Name and Serial Number values.
Maybe he sends the Subject Key Identifier extension value from the cert.
He has lots of options, as long as Alice understands what he's doing.
Bob sends this formatted message to Alice.
Alice identifies which of her several certificates was addressed in the formatted message.
Alice has a key management system and can figure out which private key to use based on the certificate.
Alice uses Apriv to recover the data.
The more complex model is a simplistic form of Enveloped CMS (Cryptographic Message Syntax) on Bob's part. Alice read the message and used something like the Windows Certificate Store (which is capable of carrying identifiers to Windows Cryptographic Key Stores for private keys) to determine the certificate and ultimately the private key.
Lots of different things could be done at the "more complex" layer. If Alice really likes managing keys she could make a different key for each person she talks to, and then know from a messages "Bobness" or "Daviosity" that she should use the private key matching the public key she gave to Bob, or Dave.
John uses Alice's public key to encrypt. Alice is the only one with the private key able to decrypt. Alice then responds, encrypting with John's public key, to which John decrypts using his private key.
Related
How is key shared between 2 people in symmetric encryption?
While i was studying about alice and bob example - (asymmetric )
case 1
when alice encrypts using bob's private key how do alice know bob's private key
case 2
when alice encrypts using bob's public key how do alice know bob's public key
How is Https a type of asymmetric encryption? I never see keys generating? Even if keys are generated then where are they stored?And how do i never decrypt those encryptions?
How is key shared between 2 people in symmetric encryption?
Via "a secure channel." There is no official definition of "a secure channel." Key sharing is outside the scope of the encryption algorithm and is simply assumed to happen. In practice, there are many mechanisms, from simple "Alice tells Bob the key" to elaborate key-exchange and key-agreement algorithms like Diffie-Hellman.
when alice encrypts using bob's private key how do alice know bob's private key
Alice never knows Bob's private key. That's why it's called "private."
when alice encrypts using bob's public key how do alice know bob's public key
There are many ways. Public keys are not secrets, so they can be broadly published. Exchanging public keys is trivial. The difficult part of public keys is trusting that they come from whom you think they come from. That is an entire field of study, but is generally handled by things like Certificate Authorities who everyone trusts, and who sign the keys vouching for them.
How is Https a type of asymmetric encryption? I never see keys generating? Even if keys are generated then where are they stored?And how do i never decrypt those encryptions?
The public key is sent as part of the initial handshake, and it is signed by a Certificate Authority. Then a symmetric key is agreed upon and used to encrypt session. The precise algorithm depends on the configuration, and the configurations are exchanged during the early handshakes. The reason you don't see any of this is that most HTTPS libraries do all of this for you and just show you the final result. Fundamentally, HTTPS is "HTTP over TLS" (plus a little bit of handshaking to get the TLS session started). See RFC 2817 for how TLS gets started, and see RFC 8446 for the latest version of TLS if you're interested in the details. You can also search for "Introduction to TLS" for numerous articles on the details.
I don't understand something which is probably very trivial but still doesn't make sense to me, why we need digital signature if they can be decripted with a public key. According to this article https://www.instantssl.com/https-tutorials/digital-signature.html Alice writes a message, then the message is hashed and encrypted using pk. The encrypted message is sent over, and Bob decrypts it using only the public key form Alice. They the hashes are compared etc...
I understand eveything apart from one step: if bob can decrypt the message with only a public key, how is that preventing the message to be decrypted by anyone else, and, if this is not the point of a digital signature (encryption), why do we even bother encrypting the hash of the message. Couldn't bob simply run the hash of the message received and compare it to what alice has send him as a hash ?
Encryption and Digital Signatures serve two very different purposes. You're getting them confused.
We hash the message, encrypt the hash with our private key, then send the plaintext message and the encrypted hash to our recipient.
Our recipient uses our public key to decrypt the hash, hashes the plaintext message themselves, and compares the two hashes.
If the hashes match, the recipient can tell that the message actually did come from us (or, at least, someone with the private key).
A digital signature is similar to paper signs. Professionals can verify that the signature on the paper belongs to you by comparing your previous signatures.
In digital signature, to verify your e-sign, 3rd party uses your publicly available key, public key, to verify your signature that can be only signed by your private key.
Alice writes a message, then the message is hashed and encrypted using pk. The encrypted message is sent over, and Bob decrypts it using only the public key form Alice.
I think you are confusing here.
If this is a message sent to Bob by Alice then Alice uses Bob's public key. Bob can decrypt this message by using his private key.
if Alice wants to sign a message that Alice uses her private key, to sign the message and sends to the Bob that he can verify the signature by using Alice's public key.
I understand eveything apart from one step: if bob can decrypt the message with only a public key, how is that preventing the message to be decrypted by anyone else, and, if this is not the point of a digital signature
Bob verify the signature by using Alice's public key. Everybody can verify. Signatures don't contain the message, the contains the hash of the message.
If the hashes match, the recipient can tell that the message actually did come from us (or, at least, someone with the private key)
This is not correct. . Matching hash only confirms that the message is not altered, but without signature B has no means to validate the whole message is coming from A
You can have an active attacker Eve, who could create a new fake message, generate hash, encrypt for Bob. Bob has no means to be sure who sent the message.
encrypting the hash of the message
Not really, the message is signed, not encrypted.
A uses her private key to apply decryption operation on the message hash and send it as a signature
B uses A's public key to apply encryption operation on the signature and the result must much the hash. Now B can be sure the signature is coming from A
Signing is mathematically the same operation as decryption, but in real use there are differences, mainly in padding
Additional to the other answers:
You may think, "If the signature is just an attachment, can't I just remove it?" Yes, you can. But it is not signed anymore, so most of the times it's not a valid document anymore, but just an ordinary file. A signature is only to verify that this exact version of this file/document has been signed/created from this user. So everybody should be able to verify that.
I'm going to re-phrase my question completely so it makes more general sense (and correct my blunder with AES/RSA).
Alice has a large block of data to send to Bob via a local mailbox that isn't secure. To keep her data from prying eyes, she does this:
She generates a random 256-bit key
She uses AES-256 encryption to encrypt the data using the key
She uses Bob's public key to encrypt the key she's used
She puts the encrypted data and the encrypted key in the mailbox addressed to Bob
Mike the mailman picks up the mail from the mailbox. However, he doesn't want to lug the data all the way across the internet to Bob's place if bob isn't going to be able to decrypt it.
The question is, how can Mike ascertain whether the key has actually been encrypted using Bob's public key?
In my application I need to transport sensitive data to a data centre. To achieve this, I have an upload process that accepts files (that have already been AES-encrypted with a key, then the key is encrypted with the recipient's public key) and sends them to the data centre. The corresponding private key is held at the data centre and used to decrypt the files on receipt. This is currently in the design stage so there is some flexibility on the public/private key technology to be used but it's likely to be a C# application that's doing the work.
I would like to protect against uploading files that have NOT been encrypted using the public key (because I may waste significant bandwidth and the receiving application at the datacentre will fail to decrypt them).
So, what I want to know is how can I tell at the sending end whether a file has been encrypted using a given public key?
In a nutshell, I have an encrypted file and a public key. Has the file been encrypted with that key?
Thanks in advance etc.!
This is about a test I did, but I'm asking because I'd like to understand these concepts, I am a little confused about them.
Maria encrypts her document with her private key.
Maria sends the document to John
John decrypt the received document using Maria's public key.
I'd like to know whether this process provides:
1) authenticity
2) integrity
3) non-repudiation
4) confidentiality.
I would also like to know which of these 4 items are provided by certificates, and by digital-signature.
Thanks!
Authenticity You can use public-private key pairs for authentication in there own right, if I'm not mistake ssh does something similar. In fact you can setup servers in such away you do not need to enter a login password based on this principal.
Integrity
I don't believe that the public -private key on its own accounts for this on its own.
Non-repudiation
Cannot be acchieved on its own without have a certifying body saying that the owner of the private key to which you encrypted your public key is the origin you expect it to be. For more
click here
Confidentiality
the way it works is that you have public-private key pairs the 'public' have access to a key which they used to encrypt data but only one person has the private key to decrypt it. Therefore it brings about confidentiality only the intended person can read the data.
Imagine that a server is serving public keys of the users to their partners to make encrypted communication possible. However, the server does NOT have access to the private keys..
Anyway - imagine the server is hacked and it sends not the requested public keys:
Alice requests Bob's public key
Server sends Eve's public key
Bob requests Alice's public key
Server sends Eve's public key
Alice sends a message to Bob
Server unpacks message, reads it and repacks it -> sends to Bob...
Bob sends a message to Alice
Server unpacks message, reads it and repacks it -> sends to Alice...
My question is - how to prevent such abuse? How can Alice be sure that she's using Bob's public key and vice versa?
Under the scheme you just proposed, you can't. The key here (no pun intended) is if the method used to verify the validity of the keys is compromised, you lose.
SSL tries to avoid this by creating a signature chain - some (very carefully guarded, and verified by other methods) key signs another key, signs another key, signs Alice's key. By verifying each step in the chain you can (in principle) know that the chain is valid - but if the private key along any step in the chain is compromised, you lose.
PGP (aka GPG) tries to solve the problem in a different, but similar way - keys can be signed by any number of other keys, forming a graph (called the web of trust). You select some keys that you have confirmed valid by, for example, verifying them in person, and mark them as trusted. Then any keys reachable by less than N steps (and/or from M distinct paths from different trusted roots) are also considered valid.
If you're really paranoid, you can, of course, physically hand the key to the other person. Of course, they have to be sure it's not someone disguised as you...
That said, the only truly foolproof way of verifying the validity of a key is generating it yourself... unless your hardware/OS/compiler/brain is compromised too :)
The crucial part missing here is authentication. Alice needs a way to know that she is really using Bobs public key. One way would be to exchange the keys personally but that is not always possible.
That is what the Web of Trust is for. Other parties can sign the public key of a user if they are sure that this key belongs to him. If enough (3) of your other contacts (which you trust) signed the public key of Bob, you can be relatively sure that it is his key.
This is the primary problem with public key encryption. You don't have any way to verify that the public key you receive is actually the public key for your intended recipient. The way HTTPS/SSL gets around this is through the use of trusted certificate authorities. The certificate authority signs the public key of the party in question with their private key, guaranteeing that the public key hasn't been changed since it was provided to the certificate authority. Even then, it is only guaranteed that the key provided to you when you request it is the same key that was originally provided to the certificate authority. However, if the server providing those certificates is compromised, you're still in trouble. Even having the server sign the keys as suggested above isn't fool proof if the sever itself is compromised. Ultimately, the security if your key distribution server must be maintained for this system to work.
The FAQ for PGP (Pretty Good Privacy) explains this issue.
I would also recommend reading Bruce Schneier's excellent book "Applied Cryptography" for "friendly and digestible" discussions of these topics.