On 5/18/2011 3:27 AM, G S wrote:
I'm probably being obtuse here, but I don't see how encrypting your
request with a public key would help you with your original problem.
What stops a rogue app from doing the same encryption?
They can't see what the parameters are. So what are they going to encrypt?
I think you're missing the point, or I'm misunderstanding what you mean
by "parameters". Your stated problem was to detect whether a request was
originating from your app or not. No solution to this will work unless
somehow your app can do something that a fake/spam app cannot do.
Your solution was:
> 1. Generate a random key and initialization vector to encrypt
> the block of text.
So a rogue app can generate its own block of text, presumably containing
the spam or what not, and it can also certainly generate a random key
and IV.
> 2. Encrypt that random key with the RSA public key.
A rogue app can do this unless you can somehow keep the public key
private. This may be possible, but most likely an attacker could extract
the key from your application.
> 3. Encrypt the data payload with the random key and IV,
> using Blowfish or other encryption.
Surely an attacker can do this.
> 4. Send the encrypted data payload, encrypted random key, and IV to
> the server for decryption.
Again, no reason an attacker can't do this.
So either I'm misunderstanding you, or your method won't actually do
anything. Or is the thinking that an attacker won't be able to extract
the public key? Or is that an attacker wouldn't be able to figure out
how to format the parameters?
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
