Who and what are you trying to guard against?
If you are trying to shield values of the query string from an attacker who is trying to intercept traffic between you and a valid user, then use HTTPS. In this case, securing the transport layer will give you most bang for your buck and be the easiest, most straightforward way to implement it. Hackers won't be able to make sense of anything you're sending back and forth, much less the individual parameters passed in your query string.
If you're trying to shield values of your query string from a malicious user of your application, then I think you're probably going about it the wrong way. First off, you have to consider the fact that in order for the client to send you an encrypted query string, they will have to first build an encrypted query string. How can they do this without knowing specifically which parameters and values to ecrypt? In the case of a web app, preventing a user from being able to see what logic you're using to build and encrypt a query string would be near impossible.
Secondly, you have to ask yourself WHY it is so dangerous for a user to be able to manipulate this query string however they see fit? One reason may be that they are able to see information they're not authorized for. For example, I might modify
carId to some arbitrary value 123, and then get illegal access to info about that car. Rather than avoid me sending you that number, you inspect the request when it comes in, and validate whether or not I am actually allowed to see that data. If not, don't send it, it's that simple.
If a user is able to pass in values that would somehow break the app, then the answer is to validate and sanitize your input. If me passing
carId=DROP+TABLE+[Cars] blows up your database, then simply make sure that you don't accept those values!
If carId <=0 throw new ArgumentException("carId") for example.