RSACryptoServiceProvider by default creates a new key if no key is found (C#). RRS feed

  • Question

  • Is there a way to prevent RSACryptoServiceProvider from creating a new key if it doesn't find the key specified in the provided CspParameters?

    The default behavior of automatically creating a new key if the specified key is not found is rather weird i.m.o. Especially since there is no good way if listing available containers without going into interop (at least none that i have found). Is there a good reason for this behavior and can i prevent this from happening?
    Thursday, June 18, 2009 1:35 PM

All replies

  • Hi - I think my information can help you.

    Well, RSACryptoServiceProvider has it build-in.

    Here is a bit of the RSACryptoServiceProvider class:
    public RSACryptoServiceProvider(CspParameters parameters) : this(0, parameters, true)

    The CspParameters class:
    public CspParameters() : this(Utils.DefaultRsaProviderType, null, null)

    I used "Red Gate's .NET Reflactor tool" to get the code.
    Download from: http://www.red-gate.com/products/reflector/

    According, the behavior, I think its like this, because, it requires a key parameter input.

    I hope this information was helpful...

    Have a nice day...

    Best regards,
    Monday, July 6, 2009 3:18 PM
  • That doesn't really solve my problem.

    Let's say I want to try to open a RSA key in a container called "MyContainer".

    If I send "MyContainer" as the container name with CspParameters and the "MyContainer" container doesn't already exist, RSACryptoServiceProvider will SILENTLY create it for me. This is not the behavior I want. Either i would want an exception thrown ("Container not found") or at least a method called something like bool ContainerExists(string containerName) could tell me if it exists or not.

    For example, File.Open(string fileName) throws a FileNotFoundException if the filename provided does not exist. I would want RSACryptoServiceProvider to throw a ContainerNotFoundException if I didn't explicitly tell it to create a new key container. This is my problem. There is no easy way to tell if a container already exists or not (there is no CspParamers flag that demands that the key already exists).

    That's why I ask again: "Is there some way I can prevent RSACryptoServiceProvider from creating a new container if the container I told it to open doesn't exist?"
    Wednesday, July 15, 2009 11:37 AM
  • Hi,


    Check out the above link.

    Else, "prevent RSACryptoServiceProvider from creating a new container " do a search of that using Google Search.

    I hope this information was helpful...

    Best regards,
    Thursday, July 16, 2009 10:33 AM
  • Stebet,

      I appologize, but to many people try answering questions when they really don't know the answer.  It frustrates the heck out of me sometime.

      I found the solution to what you are looking for a while ago.  The answer is partially in that posting that Coder24.com submitted.  You have to enumerate each file in that folder for the key container's name.  Assuming your KeyContainerName is "MyCustomKeyContainer", you would enumerate each file in the "<userprofile>\AppData\Microsoft\Crypto\RSA\[Sid]" folder.  Open them using a StreamReader and search for that string.  Only one of them will pop with that name if the key container already exists.  If you need a code sample, please reply back and I can whip one up.  Please note:  I don't know where you are storing your key container (meaning local profile or the computer's MachaineStore), so the path may vary. 

      Things to keep in mind:

     - The same KeyContainerName can be used accrose different profiles and/or the computer's store.  Also, I used "AppData" in the path because I use Vista, but XP uses the full "Application Data" in the path.
     - A user's profile may not have a "Crypto\RSA" folder in it.  I'm not 100% sure, but I believe it will be created once the first RSA key is created.  This is the behavior I have observed.

    - Rashad Rivera
      Omegus Prime, LLC

    Monday, July 20, 2009 6:11 AM