Re: Problems with public key decryption with RSA

From: Michel Gallant (
Date: 02/02/05

  • Next message: William Stacey [MVP]: "Re: Problems with public key decryption with RSA"
    Date: Wed, 2 Feb 2005 15:20:05 -0500

    Part of this procedure in .NET is described here:
    (not including the signature part which is easy to implement).
     - Mitch Gallant
       MVP Security

    "William Stacey [MVP]" <> wrote in message news:uBiAgSUCFHA.392@TK2MSFTNGP14.phx.gbl...
    > > My final solution is, for encrypting :-
    > > Encrypt the data symmetrically with random key
    > > Encrypt the key / IV with fixed (pre-loaded) key
    > > Package as byte array
    > > Digitally sign hash (with Private key) on package and send to receiver
    > The "pre-loaded" key should be the public key of the server in your signed
    > assembly and/or embedded in your code. Also above you would have an issue
    > with securing the "Private key" at the clients. So a better solution may
    > become:
    > 1) Generate random symmetric key and iv.
    > 2) Encrypt key / IV with public RSA key of server.
    > 3) Encrypt data with symmetric key.
    > 4) Sign hash and sign data elements with HMAC-SHA1 using symmetric key.
    > Note we use the HMAC-SHA1 to sign as we don't have a RSA private key. We
    > could however create one dynamically for the session and encrypt our public
    > xml string in the request using RSA public key of server. However, as we
    > need the new RSA key only for signing the request, we can avoid that and
    > just use a keyed hash like HMAC-SHA1. You could also encrypt the resulting
    > signature using the server's public RSA key - but don't think that is
    > required.
    > 5) Server decrypts key / IV with it's private key.
    > 6) Server verifies hash with HMAC-SHA1 using the key.
    > 7) Server decrypts data with key / iv.
    > 8) Server generates reply.
    > 9) Server encrypts data with key / iv.
    > 10) Server signs data elements with RSA private key.
    > 11) Client verifies signature using RSA public key.
    > 12) Client decrypts data and uses.
    > This does not require any prior stored private key on client's - only during
    > the session. This follows the SSL pattern where key exchange is done using
    > RSA pki first and after that symmetric encryption is used. You could also
    > modify to allow server to contribute to the entropy of the shared key, but
    > that would require a request/reply pair before you could use symmetric
    > encryption and I am not sure how much value that would as with above model
    > you still can get the shared key unless you brute force pki to discover it
    > using all combinations keys. For that reason, I would keep your shared key
    > as large as possible - say 64-100 bytes. Then both sides will use the sha1
    > hash of the 64 bytes or just the first 16-32 bytes for your AES crypto. You
    > may also want to include a Timestamp and/or msg ID on the requests to help
    > prevent reply attacks. Cheers!
    > --
    > William

  • Next message: William Stacey [MVP]: "Re: Problems with public key decryption with RSA"