Related
I am sorry but my mind suddenly goes blank for this question....
EDIT (Scenario)
If I want information to bypass simple filters like f-ck, is it OK to encrypt the information with public key, and sign by private key?
The public key may have already exchanged by both sides, and it is even hard to get the public key.
EDIT 2
The information itself may not that much credential.
The point of encryption and signature is for bypassing and integrity.
RSA is two algorithms: one for asymmetric encryption and one for signatures. It so happens that both algorithms can use the same private key structure (this is a source of confusion: many documentations, including the RSA standard, try to explain the signature as "an encryption with the private key", which is, at best, inaccurate).
Using the same key for both usages is possible, but not really recommended, because interactions between both kind of usages have not been fully explored; also, keys for encryption and keys for signatures usually have different life cycles with distinct protection mechanisms (for instance, you normally want to keep a backup of the private key for encryption, to prevent data loss: losing the private key means losing all data which has been encrypted with that key; while you do not want a backup of the signature key).
Your scenario is a bit unclear. Asymmetric encryption uses the public key, while generating the signature uses the private key. If A wants to send a message to B with encryption (for confidentiality) and a signature (for integrity), then A will encrypt the data with a public key for which B knows the private key; and A will sign the data with a private key for which B knows the public key. This calls for two pairs of key: one pair is used for encryption and decryption (A encrypts, B decrypts, B knows the private key), and the other pair is used for signatures (A signs, B verifies, A knows the private key). If both A and B know the private key, then they have a shared secret, and it is much simpler (and faster) to use symmetric encryption (AES) and integrity checks (HMAC).
Standard disclaimer: you look like you are designing your own cryptographic protocol. Do not do this. This road leads to the same security failures that countless other smart people have stumbled upon. Use a tried-and-proven protocol such as SSL/TLS or OpenPGP.
Yes:
encryption: you encrypt with public
key, decrypt with private (obviously)
signing: you encrypt the content digest (hash) with private key, verify with public
See http://en.wikipedia.org/wiki/RSA#Signing_messages
I have an exam tomorrow in Advanced Development, but I am stuck on the topic of Encryption. I have read up on it at http://support.microsoft.com/kb/246071. However I am still confused.
If a message is encrypted using Asymmetric Encryption, using the public key, how is the decryptor going to know the private key with which to decrypt it? Surely the only way to do this is to make the private key public, but that defeats the object of Asymmetric Encryption.
Can someone please explain this in a way that a non-techie would be able to understand it? Its only Asymmetric Encryption I dont understand, not Symmetric Encryption. Thanks in advance.
Regards,
Richard
Edit: So to sum up all the answers in the case of a web application (the specific use for which I need to know about this):
User visits a website;
User is requested to provide a public key;
User creates public and private key-pair, keep the private one private and sends back the public key to the server;
Server uses the public key to encrypt anything which needs to be sent to the user and sends the information to the user;
User uses his / her private key to decrypt the response from the server;
User does what they need to and sends back a response to the server, using the private key to encrypt it;
Server decrypts using the public key.
Steps 4 - 7 may continue many times, or they may only happen once, or only 4 and 5 may occur.
Is this all correct? If so then it should be all I need to know for the exam. I shouldnt think I would need to know any more to get the maximum 40% should a question on this subject come up - will mention the existence of certificates and signatures though.
Thank you for all the help.
Regards,
Richard
Edit: Well I have just got back from my exam and it went fairly ok I think. But no question on cryptography came up, however... The help was appreciated anyway. Thanks all.
Regards,
Richard
A private key is meant to be known only by its legitimate user and not distributed. Its counterpart, the public key, may be distributed to anyone.
Based on this, you can get 4 operations:
encrypt using the public key
decrypt using the private key
sign using the private key
verify the signature using the public key
The next problem you may encounter is the binding of an identity to a public key (as you wouldn't want to encrypt something with or trust something signed with the public key of an impostor). There are various models of public key distributions. Typically, you can have:
a web of trust, where people sign each other's association between the public key and the identity: this is typically the PGP model.
a public key infrastructure (PKI) where you get certification authorities to produce certificates, often with intermediates, in a tree-like hierarchy. (PGP can use this model too, but this seems less common.)
Alice creates her Private Key + Public Key. She keeps her Private Key private. She makes her Public Key public.
Bob takes Alice's Public Key (he should first verify, that it's really Alice's Public Key!), and uses it to encrypt a message, which he sends to Alice.
Alice can decrypt the message using her Private Key.
Others have provided a "generic" description and I'll go deeper into the real-life side.
Most modern asymmetric encryption standards operate not with raw public and private keys, but with more complex wrappers, such as X.509 certificates or OpenPGP keys (these are two most popular asymmetric encryption infrastructures today). Both certificates and OpenPGP keys contain extra information that lets them be easily identified, searched for and managed.
Now, the encrypted data block usually includes the public part (i.e. the certificate or public OpenPGP key) used for encryption, or at least the ID (hash of this public part). The recipient of the data usually has (or is supposed to have) both public and private parts (private keys are usually kept together with certificates or public openpgp keys) at hand. So when the recipient receives the encrypted data, he knows that he needs to look his private key storage for public part with given ID (or for given public part when it's included into the encrypted data).
There exist cases when nothing is included. Then the recipient has nothing to do but try all available private keys for decryption. But such cases are rare as by default the certificate or key id are present in the encrypted data block.
The public key is provided to the "encryptor" by the "decryptor", therefore, by definition, the "decryptor" knows the private key (because it is part of the key pair created by the "decryptor".
Let's say "decryptor" = D, and "encryptor" = E.
D previously sent his public key to E, so E can encrypt the mesage. Because only D knows his own private key, only D will know how to decrypt the message E just sent him (remember: one key is used to encrypt, the other to decrypt). In this way, you get privacy.
If I want to sign and encrypt a message using an X509 certificate, is there any reason not to use the same certificate for encryption and signing?
Update: Looking back, I think that this must be the most hair-brained question I ever asked on SO. I'm sorry.
The sender uses his own private key to sign a message. The message is encrypted with the recipient public key. A certificate contains a public key. Presumably, the sender public key (corresponding to the sender private key used for signing the message) is also represented in a certificate.
The recipient uses his own private key (corresponding to the public key in his certificate) to decrypt the incoming message. The recipient uses the sender public key (from the sender certificate) to verify the signature.
That being said, you may envision a generic scenario where everybody can send and receive email. Therefore, everyone has a key pair (with public part in a certificate) which is used to encrypt and decrypt emails (Bob's public key is used to encrypt emails sent to Bob, and Bob uses the corresponding private key to decrypt them, i.e. to read the emails). Also, everyone has a key pair for signatures (Bob uses his private key to sign the messages that he sends, Alice uses Bob's public key to verify the signatures purportedly computed by Bob).
The question is then: will Bob have two key pairs (one for encryption/decryption, and one for signature/verification), or only one key pair which is used for both jobs ?
It so happens that the RSA public encryption algorithm and the RSA signature algorithm can use the same kind of key, called (quite logically) "RSA keys". So this is doable, and actually it happens quite often.
However, generally speaking, signature keys and encryption keys have distinct life cycles and management procedures. In a business context, the direction keeps in a safe a copy of all private keys used for encryption, because losing an encryption key means losing data. And employees can become "unavailable" (employee is fired, employee retires, employee is hit by a bus...). Conversely, when a signature key is lost, previously emitted signatures are still valid and verifiable, so one simply has to create a new key pair to be able to produce other signatures. Besides, digital signatures may get a strong legal status only if there is no copy of the key in a safe somewhere. So the general advice is to keep encryption and signature keys separate. Using the same key for both is an approximation which may have unwanted side-effects (such as data loss or lack of legal value). Depending on the context, this may or may not be a problem.
An X509 certificate contains a public key. To encrypt, you use the recipient's public key presumably obtained from their certificate. To sign, you use your private key, presumably from a secure store. The recipient verifies the signature using your public key, presumably from your certificate. Those are the basics.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
What is the difference between encrypting some data vs signing some data (using RSA)?
Does it simply reverse the role of the public-private keys?
For example, I want to use my private key to generate messages so only I can possibly be the sender. I want my public key to be used to read the messages and I do not care who reads them. I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these. I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.
Is signing useful in this scenario?
When encrypting, you use their public key to write a message and they use their private key to read it.
When signing, you use your private key to write message's signature, and they use your public key to check if it's really yours.
I want to use my private key to generate messages so only I can possibly be the sender.
I want my public key to be used to read the messages and I do not care who reads them
This is signing, it is done with your private key.
I want to be able to encrypt certain information and use it as a product key for my software.
I only care that I am the only one who can generate these.
If you only need to know it to yourself, you don't need to mess with keys to do this. You may just generate random data and keep it in a database.
But if you want people to know that the keys are really yours, you need to generate random data, keep in it a database AND sign it with your key.
I would like to include my public key in my software to decrypt/read the signature of the key.
You'll probably need to purchase a certificate for your public key from a commercial provider like Verisign or Thawte, so that people may check that no one had forged your software and replaced your public key with theirs.
In RSA crypto, when you generate a key pair, it's completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other - it works in both directions.
So, it's fairly simple to see how you can encrypt a message with the receiver's public key, so that the receiver can decrypt it with their private key.
A signature is proof that the signer has the private key that matches some public key. To do this, it would be enough to encrypt the message with that sender's private key, and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.
Of course, this means that your message is not secret. Anyone can decrypt it, because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.
However, this means doubling the size of your transmission - plaintext and ciphertext together (assuming you want people who aren't interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. It's important that fake hashes can't be created, so cryptographic hash algorithms such as SHA-2 are used.
So:
To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
To verify a signature, make a hash from the plaintext, decrypt the signature with the sender's public key, check that both hashes are the same.
There are two distinct but closely related problems in establishing a secure communication
Encrypt data so that only authorized persons can decrypt and read it.
Verify the identity/authentication of sender.
Both of these problems can be elegantly solved using public key cryptography.
I. Encryption and decryption of data
Alice wants to send a message to Bob which no one should be able to read.
Alice encrypts the message with Bob's public key and sends it over.
Bob receives the message and decrypts it using his private Key.
Note that if A wants to send a message to B, A needs to use the Public
key of B (which is publicly available to anyone) and neither public
nor private key of A comes into picture here.
So if you want to send a message to me you should know and use my public key which I provide to you and only I will be able to decrypt the message since I am the only one who has access to the corresponding private key.
II. Verify the identity of sender (Authentication)
Alice wants to send a message to Bob again. The problem of encrypting the data is solved using the above method.
But what if I am sitting between Alice and Bob, introducing myself as 'Alice' to Bob and sending my own message to Bob instead of forwarding the one sent by Alice. Even though I can not decrypt and read the original message sent by Alice(that requires access to Bob's private key) I am hijacking the entire conversation between them.
Is there a way Bob can confirm that the messages he is receiving are actually sent by Alice?
Alice signs the message with her private key and sends it over. (In practice, what is signed is a hash of the message, e.g. SHA-256 or SHA-512.)
Bob receives it and verifies it using Alice's public key. Since Alice's public key successfully verified the message, Bob can conclude that the message has been signed by Alice.
Yeah think of signing data as giving it your own wax stamp that nobody else has. It is done to achieve integrity and non-repudiation. Encryption is so no-one else can see the data. This is done to achieve confidentiality. See wikipedia http://en.wikipedia.org/wiki/Information_security#Key_concepts
A signature is a hash of your message signed using your private key.
Signing is producing a "hash" with your private key that can be verified with your public key. The text is sent in the clear.
Encrypting uses the receiver's public key to encrypt the data; decoding is done with their private key.
So, the use of keys is not reversed (otherwise your private key wouldn't be private anymore!).
You are describing exactly how and why signing is used in public key cryptography. Note that it's very dangerous to sign (or encrypt) aritrary messages supplied by others - this allows attacks on the algorithms that could compromise your keys.
Signing indicates you really are the source or vouch for of the object signed. Everyone can read the object, though.
Encrypting means only those with the corresponding private key can read it, but without signing there is no guarantee you are behind the encrypted object.
Functionally, you use public/private key encryption to make certain only the receiver can read your message. The message is encrypted using the public key of the receiver and decrypted using the private key of the receiver.
Signing you can use to let the receiver know you created the message and it has not changed during transfer. Message signing is done using your own private key. The receiver can use your public key to check the message has not been tampered.
As for the algorithm used: that involves a one-way function see for example wikipedia. One of the first of such algorithms use large prime-numbers but more one-way functions have been invented since.
Search for 'Bob', 'Alice' and 'Mallory' to find introduction articles on the internet.
What is the difference between encrypting some data vs signing some data (using RSA)?
Encryption preserves confidentiality of the message ("some data"), while signing provides non-repudiation: i.e. only the entity that signed it could have signed it. There are functional differences as well; read on.
Does it simply reverse the role of the public-private keys?
Absolutely not. The use of the same private keys for signing and decryption (or, likewise, the same public keys for verification and encryption) is frowned upon, as you should not mix purposes. This is not so much a mathematical issue (RSA should still be secure), but a problem with key management, where e.g. the signing key should have a shorter live and contain more protection before it is used.
For the same message, you should use the senders private key for signing and the receivers trusted public key for encryption. Commonly sign-then-encrypt is used otherwise an adversary could replace the signature with his own. Likewise you should use the private key of the receiver for decryption and the trusted public key of the sender for verification.
Furthermore, you should understand that signature generation doesn't use "encryption with the private key". Although all RSA operations are based upon modular exponentiation, the padding scheme is entirely different for signature generation. Furthermore, the public key has entirely different properties than the RSA private key in all practical uses of RSA.
For example, I want to use my private key to generate messages so only I can possibly be the sender.
That's non-repudiation property, which can be achieved by signing.
I want my public key to be used to read the messages and I do not care who reads them.
The public key should be considered known by all. If you want everybody to read the messages, then you simply do not encrypt them.
Signing will generally not influence the content of the message. The message is is considered separate from signatures. Officially such signatures are known as "signatures with appendix" where the appendix is the message. It's a bit weird name as the message is considered more important than the signature over it, but yeah. Only few signatures offer (partial) message recovery; they are not used much anymore and are generally considered deprecated.
Note that signature protocols such as CMS may deploy a container format that includes both the message and the signature. In that case you'd need first get the - still unencrypted - message out of the container, much like unzipping a file from a plain .zip archive. So the message may be hidden from view and cannot be directly used in that case.
I want to be able to encrypt certain information and use it as a product-key for my software. I only care that I am the only one who can generate these.
Encryption is used to achieve confidentiality. In the past RSA signature generation was often thought of as "encryption with the private key". However, the operations are quite different as explained above, and the later standards desperately try and separate encryption and signature generation.
I would like to include my public key in my software to decrypt/read the signature of the key. I do not care who can read the data in the key, I only care that I am the only verifiable one who can generate them.
Yes, this is called establishing trust in the public key. However, protecting your program code is very different from protecting messages. You can perform code signing but then you'd need something to check the signature outside of your code. There are operating systems that offer this.
There is Microsoft Authenticode for instance. Application stores like the iStore and Android app store may or may not use code signing, but they offer some reassurance that your application isn't cloned or at least not cloned within the store. Cryptography is not always the solution after all.
Keeping your code from being cloned / altered at all is much harder, and you'd be solidly in DRM territory if you go that way.
Is signing useful in this scenario?
Yes, absolutely. It can certainly help making sure that the messages were only signed by you, if there is trust in the public key. If it can be helpful for authenticating your application code / integrated public key depends entirely on the environment that you expect to run the code in.
In your scenario, you do not encrypt in the meaning of asymmetric encryption; I'd rather call it "encode".
So you encode your data into some binary representation, then you sign with your private key. If you cannot verify the signature via your public key, you know that the signed data is not generated with your private key. ("verification" meaning that the unsigned data is not meaningful)
Answering this question in the content that the questioners intent was to use the solution for software licensing, the requirements are:
No 3rd party can produce a license key from decompiling the app
The content of the software key does not need to be secure
Software key is not human readable
A Digital Signature will solve this issue as the raw data that makes the key can be signed with a private key which makes it not human readable but could be decoded if reverse engineered. But the private key is safe which means no one will be able to make licenses for your software (which is the point).
Remember you can not prevent a skilled person from removing the software locks on your product. So if they have to hack each version that is released. But you really don't want them to be able to generate new keys for your product that can be shared for all versions.
Python
The PyNaCl documentation has an example of 'Digital Signature' which will suite the purpose. http://pynacl.readthedocs.org/en/latest/signing/
and of cause NaCl project to C examples
What is the difference between encrypting some data vs signing some data (using RSA)?
RSA merely the only public-key cryptosystem that naively supports both public-key encryption and digital signatures.
This usually confuses beginners since various sources/lecturers that say
RSA decryption is the RSA signature.
No, it is not!
The confusing comes from the textbook RSA
the textbook RSA encryption;
message m and calculates c = m^e mod n for encryption and m = c^d mod n for the decryption.
the textbook RSA signatures;
message m and calculates sg = m^d mod n for verification and m == sg^e mod n for the signature verification.
Both are not secure and they are not used in the real-life!
Does it simply reverse the role of the public-private keys?
No, it is not!
Encryption
For RSA encryption one must be using either RSASSA-PKCS1-v1_5 padding or Optimal Asymmetric Encryption Padding (OAEP). These paddings have overhead to the message. For example, PKCS1-v1_5 defined as
It has an EM structure as this
EM = 0x00 || 0x02 || PS || 0x00 || M.
so what are they;
PS is at least eight FFs block
M is the message
the first 0x00 guarantees that EM is less than the modulus.
The rest details like the size of FF block etc. can be found in rfc 8017 section 7.2.1
So it has a special message structure to be secure which is proven to be secure very lately (2018). The padding has at least 11-byte overhead.
Signature
The correct term for signature is signing and verification. For secure signing, RSA needs RSA-PSS (Probabilistic signature scheme). The structure is a bit complex, a picture will tell most of it
Once you hash the message and properly padded, then you can use your private key to sign your padded message!
For the verification, use the public key on the signed message and verify using the padding rules.
Prefer OAEP since RSASSA-PKCS1-v1_5 hard to implement correctly and those incorrect implementations caused many attacks over the year despite that is is proven to be secure.
Let finish all with the Cornell University page;
RSA Signing is Not RSA Decryption
In AES encryption (.net framework), how are the public and private keys used?
Are the public and private keys combined to form a full key, and then the algorithm uses the public + private key to encrypt the data?
(simplified keys used below for example purposes)
e.g.
public key = 12345
private key = 67890
so the key used when generating the encryption result is: 1234567890
As others have said, AES is a symmetric algorithm (private-key cryptography). This involves a single key which is a shared secret between the sender and recipient. An analogy is a locked mailbox without a mail slot. Anybody who wants to leave or read a message needs to have a key to the mailbox.
If you really want to know the gory details of AES, there's a superb cartoon to guide you along the way.
Public-key cryptography involves two related keys for each recipient involved - a private key which is a secret known only by the recipient, and a related public key which is known by all senders.
The sender encrypts the message using the recipient's public key. That message can only be decrypted by a recipient with a private key matching the public key.
An analogy for public-key encryption is a locked mailbox with a mail slot. The mail slot is exposed and accessible to the public. Its location (the street address) is the public key. Anyone knowing the street address can go to the door and drop a written message through the slot. But only the person who possesses the private key can open the mailbox and read the message.
AES is a symmetric algorithm, so it does not have public and private keys - only a shared secret.
In the simplest form:
AES is a symetric algorithm, it uses the same key for encryption and decryption.So tat whoever has the key can read your message.
The private and public key is for Asymetric alogorithms like RSA, normally people use public key to encrypt and private key to decrypt( only HMAC or MAC will use private key to encrypt, and public key to decrypt).The public key is known to everyone, the private key is only known to yourself, so no one can read the message sent to you.
I do not know how the .net framework specifically works (the question should probably have been tagged .net) but by your question it sounds like it implements public/private key crypto, just using AES for its symmetric component.
The usual mode of doing public key encryption is to
Generate a symmetric key
Encrypt the data with this key, using a symmetric algorithm like AES.
Encrypt the symmetric key with the public key, using a asymmetric algo like RSA.
Bundle the encrypted sym key with the encrypted data
The reason symmetric algos are preferred for the data itself is that asymmetric ones are very slow.
Given that they couldn't test security (all they really had was the absense of breaks, for several og the candidates), the reason for choosing Rijndael for AES was (mostly) performance related.
A public key is linked to a private key. The public key (RSA) is distributed to the 'wild' and anyone who wants to send an encrypted file (generically speaking here), they will request the public key and encode against it. The cypertext is unreadable to anyone who gains access to the file, even if they have the public key.
The private key is needed to decode the file. As long as the private key is kept private, it is statically improbable that anyone will guess or hack the the key. Improbable, not impossible.
The real issue is keeping the private key private. Most cracks are done with social hacking. Extortion, loggers and monkey-in-the-middle public key conversion are other ways more probable than brute forcing the password or key.
In your comment to Brawndo you asked
what's the point of having a public
and private key then if both can
decrypt others? Why not both have the
same key?
What you are describing is Symmetric-key algorithms, which AES is one. The reason for public-private keys are that with Symmetric-key algorithms how do you pass a Symmetric key over unsecured networks, mail, phone or what not without the key being intercepted. Perhaps encrypting the key, but then how do you pass that key? With a public-private key combo, that becomes LESS relevant.
"In most cases, there's a greater
probability that the sun will burn out
before all the computers in the world
could factor in all of the information
needed to brute force a 256-bit key,"
said Jon Hansen, vice president of
marketing for AccessData Corp, the
Lindon, Utah, company that built the
software that powers DNA.