Is there a way that my server can provide an encrypted string that can be decrypted on the client, but NOT re-encrypted on the client? I know this seems kind of backwards... here's what my need is.
I have a software key that needs to be activated against our remote server. The server needs to provide something back to the client that says "You are active" and contain info such as a date that it's valid until, how many licenses, etc. However, I need to prevent it from being easily tampered with to increase license count or the dates (i.e, re-encrypt the value with a new date using a key found in the de-compiled binary or w/e).
Is such a thing possible using public/private keys? Or perhaps hashes?
EDIT
Alternatively, can the server provide a hash that the client can validate is really from the server without giving the client the ability to spoof or generate a hash on it's own?
Thanks in advance.
Public/private key encryption should do what you need. Hashes are one way functions; a good hash function will make it impossible to retrieve the original value.
In this case, the server has a public/private key pair and the client has a public/private key pair. The server's public key is embedded into the client, and the server has the client's public key as well. The server can now encrypt your payload using it's private key and the client's public key. When the client wants to decrypt the payload, it uses it's private key and the server's public key. The client cannot re-encrypt the data without access to the server's private key.
http://en.wikipedia.org/wiki/Public-key_cryptography - for an explanation of how it all works
http://msdn.microsoft.com/en-us/library/e970bs09.aspx - as a starting point for .Net classes to make it easier
Sure. Use an asymmetric-key algorithm like RSA. Both keys are required to go from cleartext to cleartext; one will encrypt, the other will decrypt. You cannot use the same key you encrypted with to decrypt, and vice-versa. So, the client could not get ciphertext, decrypt it, then use any of the information it has to come up with the same ciphertext.
HOWEVER, asymmetric-key algorithms do not differentiate between the encryption and decryption keys until one is used to encrypt. They only require that the other key is used to decrypt a message encrypted by the first. So, theoretically, your client could "re-encrypt" a message using its "decryption" key that would be decrypt-able by the server using its "encryption key". I don't know of an algorithm that would disallow this; you'd simply have to build it into your communication library by omitting any way to use the decryption key for anything but decrypting.
Related
I am using a Token based authentication. My web server would generate and encrypt the token. I want the client to decrypt the token to read certain payload information.
What algorithm I should use to achieve this?
In my understanding if I use RSA, I can decrypt in c# using private key whereas the encryption has to happen from other hand so this doesn't fit-in my scenario. Is there any other asymmetric algorithm or ways to achieve this?
Server encrypt - private key.
Client decrypt - public key.
Is there any other asymmetric algorithm or ways to achieve this please suggest.
I want to correct your understanding of asymmetric encryption. Asymmetric encryption allows anyone with the public key to send a secret message to anyone with the private key. Since the public key is public, asymmetric encryption allows many possible senders to send private messages to a few special recipients.
My web server would generate and encrypt the token. I want the client to decrypt the token to read certain payload information.
In that case, with the server sending a secret message to the client, if you are using asymmetric encryption, then the server will encrypt with the public key, and the client will decrypt with the private key.
Server encrypt - private key. Client decrypt - public key.
That is not correct. In asymmetric cryptography, the public key does the encryption and the private key does the decryption.
What you might be thinking about is a digitally signed message. In that case, the sender signs the message with the private key and the receiver verifies the signature with the public key. Digitally signed messages are not secret, though, whereas encrypted messages are secret.
Is there any other asymmetric algorithm or ways to achieve this please suggest.
Since your use case is not entirely clear, I will stop the answer there, and leave it at correcting your understanding of asymmetric encryption. It might be that you need symmetric encryption or a digital signature. I encourage you to ask another, separate StackOverflow question as a follow up to this one.
As a final note, I'll refer you to the Internet Security Glossary. In particular, the section named "$ asymmetric cryptography" has a precise and brief description about how "Asymmetric cryptography can be used to create algorithms for encryption, digital signature, and key agreement."
From your other (unfortunately on hold) question https://stackoverflow.com/questions/49610839/protecting-jwt-signing-and-encryption-c-sharp-solution, it sounds like you require the following:
Send a payload from the server to the client.
Only the client can read the payload, because it is encrypted.
The client can verify who sent the payload, because it is signed.
The recommended approach is to sign-and-then-encrypt. If you are wanting to use asymmetric encryption for both:
use a private to key to sign the payload,
then use a public key to encrypt the signed payload.
I had a look on
configSection.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
but I had two questions:
Is there a way to encrypt config file with a key, because any one can decrypt my file if he knows this method, right?
Does the decryption done automatically when retrieving the connection string at run-time? (in any class, or in data-sets)?
thanks
Yes, Encrypting config file is common. DPAPI way uses symmetric key and therefore, if someone gets the key, he can decrypt.
In my case I used an RSA asymmetric key. That way encryption with public key is performed. Decryption can be performed only with private key protected and held by server in SQL database. On application side, users and application don't need the decrypted secret but need to stay encrypted. Simply, public key is to encrypt and private key is to decrypt. And nobody can easily get the private key.
Furthermore, when it comes to cloud platform like Microsoft Azure, we have to use certificate way which is of also RSA.
My case took almost 1 month to understand the complexity. I completed this task just recently.
The decryption is performed automatically by indicating the thumbprint of private key in the config file.
For learning purposes, I'm creating a chat application where the connections are done via SSL/TLS, and the messages are encrypted using AES-CBC-256 and the AES keys are encrypted with RSA-2048.
The AES key is randomly generated (AesProvider.GenerateKey()) per user per session (which means one key for every person an user is chatting with) and the IV is randomly generated (AesProvider.GenerateIV()) by passing in the key generated, each time a message is created (before being sent).
On the RSA side, I'm generating a secure random session name to store the private keys generated in containers, and sending out the public key. I'm also using the same model (one key pair per user per session) as in AES.
I should also state that I'm using HMAC-SHA512 to hash the messages and sending the HMAC key encrypted using the same public key that the AES key/Iv gets encrypted with. Since I've read that it doesn't need to be regenerated often, I'm planning on regenerate the HMAC key every 5000 or 10000 calls.
Questions:
1) Should I be creating only one RSA key pair per user and use it for all sessions, or is it good how it is right now?
2) Is using the same AES key and only changing the IV like explained above considered secure?
Not much to answer because what you are doing is the best practice aready.
Some notes though;
RSA key pairs per session is not required (and generating the key is expensve).
You can have only one 2048 bit strong RSA key throughout the lifecycle of your application or for years, since this is what even the most security demanding web applications like e-commerce sites or financial applications do.
You should have a random AES key/IV pair for each session, that is fine.
It is better to have one HMAC key per session (not process wide) since you are sending the key securely (RSA encrypted) and you are also sending the HMAC value securely (AES encrypted) on the wire.
Changing only the IV is almost equal to changing the key and IV (in a sense) because the encrypted output will be different for the same content if you change the IV.
One note however. To prevent a man-in-the-middle attack mimicking your server certificate, is your client code validating the certificate through means of signature checking, or is it just the public key that you are sending without any validation on the client side?
You should have either a self-signed persistent certificate or generate the random certificate (RSA Key Pair) as is issued by the persistent certificate (eg, CN=FrozenDeathChatServer) where the clients during installation of your client software install under the trusted root certificate authorities.
I need an encrypted communication between C# and PHP and unfortunately can't use modules like OpenSSL on server-side. I found RSACryptoServiceProvider and this article.
It is said that I can't use the RSACryptoServiceProvider to encrypt and decrypt something, so there is an own implementation in the article. But I found provider.Encrypt(...) and provider.Decrypt(...), so why not?
If I have something to use RSA in C#, I thought about something like this:
If php wants to send some data:
php sends its public key to C#
C# encrypts an key for AES with the public key from php and sends it to php
php encrypts its message with AES and sends it to C#
(and backwards it's more or less the same)
Would that be possible or is there any security problem on this?
Basically, this is a classic method, with one important caveat: Unless you somehow verify the public key of the receiver (PHP), you are vulnerable to man-in-the-middle attacks.
E.g.:
PHP sends its public key to C#
an attacker intercepts this message
the attacker generates and sends his own public key to C#
C# encrypts a key for AES with the received key and sends it back, presumably to PHP, but, in fact, to the attacker in the middle
the attacker receives and decrypts (using his own private key) the AES key, re-encrypts it using the public key he received from PHP, and sends it to PHP
PHP encrypts its message with AES and sends it to C#
the attacker intercepts the encrypted message and is able to decrypt it, as he knows the AES key
To counter that, you need to be sure the public key does belong the PHP, not to anyone else. To do that, various methods are used in practice, most commonly, PKI, i.e. instead of just the public key, you send a certificate, which is basically a public key signed by a certification authority (i.e. a well-known entity with a known public key) that guarantees the owner of the public key.
And regarding your first question: It is definitely possible to encrypt/decrypt messages directly using RSA, there are only technical and performance reasons (AES is much faster than RSA) why RSA is used only to encrypt a session key and AES is used to encrypt/decrypt the messages themselves.
I have a very specific case for cryptography and I am just not sure what algorithms I need to use to achieve a result I am looking for.
So, it is as follows.
I will distribute an encrypted string to my clients, they will have a password to decrypt it. But I don't want them being able to create such encrypted strings themselves.
So, I need some particular algorithm that would allow me, and only me to encrypt something, and anyone can decrypt it if they have a password. but NOT encrypt.
Can you use certificate based encryption? This is exactly the way HTTPS/SSL encryption works.
The server has a certificate with public and private keys. The private key is used to encrypt data. The certificate with just the public key is distributed to the clients and the public key is used to decrypt data.