I'm looking for something like an inverse RSA algorithm. Normally, e.g. in RSA, a public key is used to encrypt the text, but it's virtually impossible to decrypt the text without the private key. What I'm looking for is a method that can decrypt a text using a public key easily, but for encrypting the text and reaching the same ciphertext, a private and a public key should be needed. Is there such a method at all?
My first attempt was to use the RSA crypto service that's build into .NETs system.security.cryptography and just decrypt my plain text (instead of decrypting it). However, that doesn't work as the implementation (or the method, haven't looked at it in that detail) is not able to decrypt arbitrary text, even if the string length is ok. Afterwards I would have encrypted the cipher text to reach the plain text again, but as said, already the first step doesn't work.
The background is the following: From some known information, I want to be able to generate a string which serves as serial number for a program. That should involve some kind of key that I want to store only in the number generator but not in the program that I deploy. The program itself should only be able to decrypt the number and extract the information from the text. The reason for using that kind of asymmetric cipher is that even if the program got cracked, nobody should ever know the key that is used to generate the serial numbers.
Related
I'm looking for a secured way to implement a license file for my application, with flags and features. I read about Asymmetric key mechanism in C#, but the RSA purpose is little opposite from what I need.
I want to generate a license file: encrypted cipher. The application would have the key to decrypt the file - but wont have the ability to re-encrypt it. Everywhere I checked, the example shows how party A generates public and private keys and passes the public key to party B so it can use it for encryption. It's probably there between the lines, but I can't see it.
I checked this one: Encrypting and Decrypting
I can find a way to use the code I see to implement it, but I'm not sure it's really secured.
You can still use asymmetric encryption: generate a public-private key pair, encrypt with the private key, and the client (the "application" as you mentioned) can decrypt it with the public key.
Of course, a public key (and the private key too) can be used for both encrypting and decrypting.
But re-encrypting plain text with a public key would generate a completely different cypher than a cypher encrypted using a private key. Decrypting and re-encrypting with the same key would produce a different result, and so it's useless.
What dcastro said above is absolutely correct, and you should give him credit. I just want to add to it, but can't yet comment. If you encrypt the license information with our private key, and distrute your public key with the application, you would be able to decrypt the license information. Without the private key, it wouldn't be possible to re-encrypt a different version of the license that could be decrypted with the public key without using the private key.
Asymetric encryption works like this.
Information encrypted with public key can only be decrypted using the private key.
Information encrypted with the private key can only be decrypted using the public key.
Now for the kicker.. You're probably going to want to encrypt your license with a symmetric algorithm, and encrypt the key needed to decrypt it with the asymmetric algorithm. This way the length of your license data isn't limited by the asymmetric and the symmetric key can be customer specific.
Like I said, give the credit to dcastro.
I'm trying to retrieve the hash created with the RSACryptoServiceProvider class' SignData and SignHash methods. I need this to be able to store encrypted hashes that must be retrieved later because they're part of a hash chain.
Initially I wanted to encrypt and decrypt hashes manually, using the private key for encryption, but the library doesn't allow it.
I can't find a method that does this, and all my searches have returned answers about how private key encryption is a bad idea (when not using it for signing ...).
We are using TrafficScript running under a Stingray Traffic Manager to encrypt a string and store that encrypted value in a cookie. Like so:
$encrypt = "string to encrypt";
$passphrase = "passphrase";
$encrypted= string.base64encode(string.encrypt($encrypt, $passphrase));
http.setResponseCookie("encrypted", $encrypted, "path=/");
What I'd then like to do is decrypt that cookie value in C#, however, I've not been able to achieve it thus far. I suspect this is because the exact details of the algorithm used by the TrafficScript isn't documented fully. The reference guide states:
string.encrypt( string, passphrase ) - Encrypts a string using the provided pass phrase. The returned string is encrypted using the AES block cipher, using an expanded form of the passphrase as the cipher key. A MAC is also added to ensure the integrity of the string.
I've tried AesManaged but get an exception 'Length of the data to decrypt is invalid'.
Can anyone provide any pointers?
I didn't manage to find a way to do this purely with TrafficScript.
So I ended up writing a Java Extension and running that from inside my TrafiicScript rule. It was made possible by reusing some code posted in a blog by Joseph Ssenyange which details how to write cross platform encryption for Java and C#.
See the title for question.
In a nut shell, what I am trying to do is encrypt some data with the seed (keyword) provided by the user. Is there a way to know that the data has been decrypted wrong, or in other words that the seed is wrong?
Using .net 2.0, C#
Thanks!
It's quite normal to make a hash part of the encrypted data. Say, you have some data you want to encrypt. You then create an MD5 hash of this and add this to the end of the data. Then, when you decrypt it, you take the hash of the end of the encrypted data and verify that the hash hasn't changed.
Depends on your algorithm specifics. stream ciphers (like RC4) will not by themselves be able to detect any tampering. Block ciphers (AES) may detect some tampering because of the block padding algorithms (PKCS#5). This padding check is what causes ICryptoTransform.TransformFinalBlock` to throw exception that the decryption failed, but this detection is not cryptographically secure (in the worst case is 1/256 chances of not detecting tampering, if padding is one byte). This is not an omission of the .Net implementation, is a fundamental problem with using all encryption algorithms.
So given that the decryption operation itself basically cannot detect tampering (or the use of a bad key/IV) the solution is to add a digest of the message in the message. The industry standard is to use an HMAC digest, and have the key derivation process produce enough key material for the key/IV and HMAC secret (this is how TLS/SSL do it, which is pretty much 'industry standard', see 6.3 Key calculation of the RFC linked). The decryption step decrypts the message and then computes the HMAC of the message, comparing it with the original digest. If they match, the decryption was successful (correct key/IV used) and the message was not tampered with.
If you want to prevent tampering of the message use a HMAC.
Regular encryption doesn't tamper proofs messages. Learn from asp.net's team mistake, and put the extra validation in place - see how the asp.net padding oracle vulnerability related to getting different levels of access.
If you don't put the extra validation, it's likely you'll expose information that an attacker may use to try to game the system.
The formal way to resolve that issue is to use a key wrap around the key (which would itself be encrypted). This is because you should only trust entirely private keys, not keys which are given to you. If you were to use an invalid key for encrypting data, then things go bad.
There are no built in routines (that I know of) that perform key wrapping in .NET, but in essence you can achieve the same thing by prefixing and postfixing the actual key with a string of 16 (or whatever your blocksize is) 'A' characters. When you decrypt the key you ensure that it is pre & postfixed with 'A' and flag it as an error if not.
If you have less formal requirements then another option is to use the key to decrypt a string which is known to be encrypted with the correct key. If once you've decrypted that string you get an unexpected result, then flag it as an error.
One brute force way - depending of what are you doing with your data... Push it to any algorithm that expects it and see if it crashes. I have encrypted binary serialized data that I deserialize that way. Binary formatter throws an exception if data is decrypted wrongly and turned to noise.
Signing an assembly in .NET involves a public/private key pair. As far as I can tell from what I've read .NET uses the RSA algorithm and the private key to sign the assembly, checking it with the embedded public key.
I know how to retrieve the public key (Assembly.PublicKey). I was wondering, if that key could be used to decrypt a short string that contains some data encrypted with the private key.
The docs I've read so far (e.g.) seem to imply that only the other way round is possible: That I would have to use the public key to encrypt and the private key to decrypt - but I don't really want to include that in the assembly, do I.
I guess it would be ok, if I just signed the string. But how?
I'm a bit at a loss how to start this. Does anybody have a code snippet?
Also, encrypting / signing of the small string would ideally happen in PHP, since I want to offload that to a web server and all we have so far is your generic PHP/MySQL hosted website.
Use Case: I'm trying to come up with a lightweight licensing scheme for a software we are about to release to beta testers. Since the software will probably be freeware, all we really want to achieve is
know who has the software installed (email address)
let the software expire after a given period, after which the user will have to get a new license
this is as easy as filling out a form and waiting for an automated email with the key to arrive
we are trying to reduce the likelyhood of old versions coming back to bite our reputation / haunt us
Being able to encrypt a tuple (expiry date, fingerprint) and decrypt that at startup would make an easy licensing module: The first time the application is started, the user is asked for email address, name, organisation. This information is posted to the webserver along with an md5 fingerprint of some system info (nic, computer name, assembly major and minor version). The webserver answers by email (checks validity of email address) with an encrypted version of the tuple (expiry date, fingerprint) that is then saved to disk. On startup, this can be decrypted and compared with current date and regenerated fingerprint.
EDIT: OK, so I don't have all the answers to my question yet. But it looks like .NET won't make it easy to use the private key for encryption (if that is at all possible, the answers don't really agree on that).
The route I will take is this (based on my use case):
I will use the private key to sign the license.
I will use the public key to verify the license was signed by the private key
I will post another question aimed at PHP devs on how to use the .NET keys (produced by sn.exe) to sign some text
I am not really worried about the user seeing the license, as it is a hash anyway and computed from stuff he allready knows. All I want is to make it too hard to be worth any bother for your typical building architect to copy my software without me knowing (remember, the software will be freeware - all I want is a paper trail of who has it installed...)
Thank you very much for your answers.
You cannot decrypt using the public key. That way, the whole point of "public" would be lost.
(You might, however, be able to sign something using the private key, then verify the signature using the public key. That's what the framework uses the keys for - the assembly is signed, and the public key is used to verify the signature.)
This can be done using SignedXml http://msdn.microsoft.com/en-us/library/ms229745.aspx. At a lower level you can prob use RSAPKCS1SignatureDeformatter and RSAPKCS1SignatureFormatter. These work by encrypting a hash of the data then comparing the data with the (decrypted) hash the other end. I believe the hashing is used because private key encryption can only handle small data. Not sure about reusing the assembly public key, if it is causing problems just use a separate key pair.
Word of warning, check out this as these classes can result in 20 second hang ups! http://www.pcreview.co.uk/forums/thread-3428177.php
This approach is vulnerable to the signature verification code being tampered with using Reflexil but that is another matter.
I wrote the following but rereading I think you already got this: You aren't really trying to encrypt or hide data from the user, you want to stop them from creating or tampering the license. You are right that a public private key encryption algorithm can be used for this. This is known as Signing using a private key (server side license generation). And verification of the signature using a public key (license checking in the app). I mention this terminology as it'll help with research.
Not in .NET.
In many traditional public-key encryption algorithm, like RSA, you can encrypt and decrypt both ways, typically one way is called "encryption" and the other "signing", even though you actually end up with an encrypted version of something both ways.
However, in .NET the RSA implementation has been crippled, and when signing will only produce digests of the input, not the full processed information.
It seems there's some disagreement about what can and cannot be done with RSA, so let me edit my answer to be more specific.
I'm talking about RSA math, not any particular RSA implementation.
RSA math allows you to encode information either of the two keys (private or public), and the encoded data can only be decoded with the other of the two keys.
Typically, you encode with a public key, encrypting the information, and decode it with the private key, decrypting the information. Or, you take a hash of the information, encode it with the private key, signing the hash, and decode the hash with the public key, in order to compare and verify the signature.
Typical implementations does not allow one to do full encoding of data from private to public, only by hashing the data, but the math behind RSA fully allows this.
In RSA Public keys are used for encryption, private keys are used for decryption. You can't use a public key to decrypt anything...
In RSA the only actual difference between a public key and a private key is which one you keep secret.
So you can use a public key as the encryption key and decrypt with the private key, or use the private key as the encryption key and decrypt with the public key.
Encrypting with the private key is used for digital signatures (anybody can decode with the public key).
But as #Lasse V. Karlsen pointed out, .Net might make it more difficult than it should be...
I think both direction are possible encrypt with public and decrypt with private and encrypt with private key. The second is the way how digital signature works.
Warning! This answer is wrong but I'm going to leave it here none-the-less because the series of comments attached are, I think of sufficient interest to others to keep the answer around. Ok it makes me look like an idiot but thats nothing new to me ;) Vote as you wish.
A public key can be used to:-
Encrypt something that can only be decrypted with the private key
Authenticate something signed with the private key
It can not be used to decrypt something to encrypted by a private key. Its for this reason that the Public/Private key system is refered to as an Asymetric system.