If I want to use RSA to encrypt query string data, what is the industry standards for such a thing? I understand how the RSA works. Based upon that alone, I would just need to get the public key. However, I understand that it is safer to use a PKI to obtain that public key?
Can someone tell me what is "best practice" for such a thing?
The security protocol used in https is TLS/SSL. This protocol typically uses RSA for key exchange and authentication. If there is such a thing as an industry standard, it is TLS/SSL.
Did the person you spoke with give you any more detail other than 'use RSA'? If not, that person doesn't really understand what is needed, because you'd need much more detail than that to ever have any hope of interoperating. It's possible this person actually meant TLS/SSL.
Can I write an https link into a html page like this? I'm kind of hazy on how the details would play out. I'd have to encrypt the querystring myself, but the utlimate exchange would be between the user agent that chose to follow the link and the 3rd party -- doesn't this kind of mess up the protocol?
I'm obviously not the knowledgeable here. Feel free to point out the obvious.
If the third-party-site supports https:, you do NOT have to encrypt anything yourself. That's what https is for - the communication between the user-agent and the server is encrypted as part of the protocol, and all the complicated parts of insuring a secure channel are handled for you.
If the secure site does not support htpps, then you can't use it. Which begs the question of why you are trying to do secure communication via HTTP POST with an insecure site.
To clarify, so we're sure we're talking about the same scenario - there's your server (A), which generates pages for a user-agent (B), which pages point to a third-party site (C). Are you trying to protect your data from eavesdroppers? Or are you trying to hide it from B?
In the first case, you have two options.
1) If both A and C supports https, then all you need to do is build pages with https: URLs pointing at C, and you're done. B hits A using https: URLs, it gets pages back that point to C using https URLs, lots of crypto-magic happens under the covers without you haveing to worry about it, and your data is protected.
2) If A and/or C do NOT support https, then you have to figure out how to encrypt communications between A and C. This is a private channel - we won't be able to help you much, because we don't know what C is expecting. Whatever C's protocol is, and whatever its key is, is what you'll need to implement in A, in order to talk to C.
(If you're actually trying to hide data from B, while sticking it into a page that B has to render - ew. Just...ew. It's wrong on enough levels that I don't think I can adequately describe them all.)
You asked about best-practices - 1) is it. 2) is not. Don't do that. No offense, but specially given your level of understanding of How Crypto Works, whatever you come up with is really really REALLY likely to be horribly flawed in a way that you won't see.
Crypto is both easier and harder than you think it is. Your best bet is to use the standards that the community has hammered out - your data is much, much safer that way.
Grant
Grant,
I appreciate your advice. And it has helped clarify things. However, as is often the case, I'm not making the decisions in this. If you don't mind, can you comment on the following idea.
In the terms of your post, A and C need to communicate the query string data to each other securely. What's more, despite your disgust ( which I whole heartedly agree with ), C wants to hide that data from 1) everyone, and 2) party B in particular ( so they don't tamper with the query string to pass manipulated data to the back end.
I do understand how PKI works. And I understand ruidimentarly how its used in such things as SSH ( I've not ready about how HTTPS works ). So I know how the following is not a good idea in terms of the security of the public key, but . . .
Party C wants to send me ( as in email ) their public key. And they want me ( on my server A backend ) to encrypt (RSA) the query string with their public key. The secure communication is one directional so this is secure AFIAK. Except for the glaring part about emailing the key to me.
By the way, they say that they need to send the key directly, versus aquiring it though a CA, because their keys have been locally generated. Can't you register a locally generated key with a CA?
Note: Even if you don't agree with what I'm propsoing, please don't think I'm not listening to your advice. Believe me, I'm listening and am eager to hear. Whether your advice informs this project or not, it informs me and I appreciate it.
Thanks.
OK, you're way ahead of the usual game here. You're stuck in a kinda gross place from a security standpoint - but you at least know it's gross, and it's not your fault :).
So HTTPS doesn't help you at all, because the real Bad Guy in this scenario is your user B, and he's the one HTTPS would protect. What fun.
To know that the query-string came from you, and to be readable only by C, the data has to be encrypted with C's public key, and that ciphertext has to be signed by your private key. On receipt, C has to check the signature with your public key, and then decrypt with their private key.
The only other hole, then, is the transfer of keys. If you and C make your public keys public, in ways where you both trust you got the right person's key, then you should be all set. A CA isn't really necessary - it just goes to some lengths to insure that the person a keypair is issued to has at least a passing connection to the credit card used to purchase the keys :)
sabre150 or ejb or anybody else wanna chime in here?
At any rate - good luck. I don't envy you at all on this one.
Grant
> Sorry Grant, I don't think I can help because, even
> though I have read the thread several times, I don't
> understand the scenario.
I'll take a stab at it.
A is server-1. C is server-2. B is a person browsing content served from A. Some of that content includes building a query that will extract content for B, from server C. Clear so far? "A" is our OP in this thread, and "C" is his (somewhat unreasonable) customer.
C is in communication with A. C wants A to build query-strings in such a way that they exist on B's web-page, but are encrypted, so that C a) knows they came from A, and b) B cannot know what the query-string is.
So - if A and C exchange public keys, A can encrypt the query-string with C's pub, sign and base64-encode the result, and make it the query-string for a link. We end up with HTML that looks something like<a href=http://c.com/awebapp/EncryptedQuery.do?querystring="a1b2c3def098....">
Click here to send encrypted query to C!
</a>
On receipt, C can decode querystring and be confident that it came from A and that B couldn't see/tamper with it.
chadmichael - did I get that right?
G
> > Sorry Grant, I don't think I can help because,
> even
> > though I have read the thread several times, I
> don't
> > understand the scenario.
>
> I'll take a stab at it.
>
> A is server-1. C is server-2. B is a person
> browsing content served from A. Some of that content
> includes building a query that will extract content
> for B, from server C. Clear so far? "A" is our OP
> in this thread, and "C" is his (somewhat
> unreasonable) customer.
>
> C is in communication with A. C wants A to build
> query-strings in such a way that they exist on B's
> web-page, but are encrypted, so that C a) knows they
> came from A, and b) B cannot know what the
> query-string is.
>
> So - if A and C exchange public keys, A can encrypt
> the query-string with C's pub, sign and base64-encode
> the result, and make it the query-string for a link.
> We end up with HTML that looks something like<a
> href=http://c.com/awebapp/EncryptedQuery.do?querystrin
> g="a1b2c3def098....">
>Click here to send encrypted query to C!
> a>
On receipt, C can decode querystring and be
> confident that it came from A and that B couldn't
> see/tamper with it.
>
OK Grant, this is roughly what I understood. The OP asked "Can someone tell me what is "best practice" for such a thing? " - I would expect C to define th protocol and not just perform a key exchange with A . To say 'use RSA', which is what C seems to have done, does not constitute a protocol.
I'm now moving on to considering the actual RSA encryption of the data. What parameters to the encryption, i.e. things like padding schemes, do both parties have to agree on to be able to encrypt and decrypt messages? Or is any RSA encryption, with a given public key, inherently decryptable by any RSA with that public key's private mate?
> I'm now moving on to considering the actual RSA
> encryption of the data.
It is well worth reading section 13.6 of Practical Cryptography by Ferguson and Schneier, published by Wiley - ISBN 0-471-22357-3 .
> What parameters to the
> encryption, i.e. things like padding schemes, do both
> parties have to agree on to be able to encrypt and
> decrypt messages?
Of course!
> Or is any RSA encryption, with a
> given public key, inherently decryptable by any RSA
> with that public key's private mate?
Of course but if the RSA key was chosen at random then the chance of getting two PublicKey/PrivateKey pairs the same is so small as to be negligable.
I don't see how you can be considering implementing anything until you have the specification from the recipient as to what algorithm details he is using.
Well, actually I'm not implementing anything. I'm still trying to find out what the important algorithm details are so that I can communicate with the other party. I've found that I don't have much success in obtaining information unless I already know what type of info I will need. Unless I have specific targeted communication, I recieve only vague answers.
Basically, I'm now in the stage of learning what details are relevant to the RSA encryption algorithm so that I can ask the necessary questions and get the important information. Then I will consider implementation.