Normally how this works is:
1) Client has your public key only.
2) You have Client's public key only.
3) Client encrypts data with public key and sends (optionally signs hash of
encrypted data using clients private key)
4) You verify signature using clients' public key.
5) You decrypt data using your private key.
6) You encrypt reply using client's public key (optionally sign hash of
encrypted data using your private key)
However asymmetric keys are normally only used to encrypt small amounts of
data like symmetric keys and sign and verify signatures. That is because
asymmetric encryption is many times slower then symmetric encryptions like
AES/Rijndale. So create a new random symmetric key for each request/reply
and encrypt it as above using the RSA keys. Then encrypt the data/payload
with AES and send both the encrypted data and the encrypted key to the other
party. The other party decrypts the symmetric key using its' private RSA
key and decrypts the payload using the session key. The reply can use the
same session key for the encrypted AES reply or start a new.
--
William Stacey [MVP]
"no game" <xi********@hotmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
The client will send us data encrypted using our public key, which use
RSA 1024bit algorithm, we use our own private key to decrypt the
message, the data send to us will be over 200 bytes, and we also need
to send reply data use their private key too, the data could be 300 or
more bytes. The configuration doesn't include any IV keys and symmetric
algorithm.
Thanks
