are crypto classes supposed to work on w2k?

[Gregory L Priem]

i have been unable to get any of the classes in the
System.Security.Cryptography namespace to work on my w2k machine, so i
created a vmware session starting from scratch, to remove any possible
external issues. [when run on winxp, no exceptions are seen]

setup: w2k pro with sp4 plus .net 1.1 redistributable. exe's are being
run interactively, by a user who is a member of the administrators
group.

i compiled the code from the command line [ie: csc crypto.cs] , which
gives the following info when run:

Microsoft (R) Visual C# .NET Compiler version 7.10.3052.4
for Microsoft (R) .NET Framework version 1.1.4322
Copyright (C) Microsoft Corporation 2001-2002. All rights reserved.

this whole process started with the following simple attempt to use
RijndaelManaged:

namespace n {
class c {
public static void Main() {
System.Security.Cryptography.RijndaelManaged aes =
new System.Security.Cryptography.RijndaelManaged();
}
};
}

this compiles without warnings, but produces the following exception
when run:

Unhandled Exception:
System.Security.Cryptography.CryptographicException: CryptoAPI
cryptographic service provider (CSP) for this implementation could not
be acquired.
at
System.Security.Cryptography.RNGCryptoServiceProvider..ctor(CspParameters
cspParams)
at System.Security.Cryptography.RijndaelManaged.GenerateKey()
at RijndaelManaged_Examples.MyMainClass.Main()

i soon discovered that exceptions are also thrown when trying to
create other classes [using default ctors]: DSACryptoServiceProvider,
DESCryptoServiceProvider, RC2CryptoServiceProvider,
RSACryptoServiceProvider, RNGCryptoServiceProvider,
MD5CryptoServiceProvider, SHA1CryptoServiceProvider. [i did not try
other classes, but i expect that they would have thrown exceptions as
well]

it looks like this error is typically seen by people using encryption
from asp.net, which is not what i am doing. just in case the normal
solution of using the machine key set might work, i tried the
following commonly-suggested code for the body of main:

CspParameters param = new CspParameters();
param.Flags = CspProviderFlags.UseMachineKeyStore;
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(param);

this also generated an exception:

Unhandled Exception:
System.Security.Cryptography.CryptographicException: Cryptographic
service provider (CSP) could not be found for this algorithm.
at
System.Security.Cryptography.RSACryptoServiceProvider.HasEnhancedProvider()
at
System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32
dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
at n.c.Main()

installation of the w2k High Encryption Pack had no effect.

am i missing something? MSDN indicates that w2k is supported.

greg priem kb0erz
bark, fido, bark [neither of us speak for my employer]

 

[Pieter Philippaerts]

am i missing something? MSDN indicates that w2k is supported.

The crypto classes work on Windows 2000. However the exceptions you're
getting indicate that your key store may be corrupted.
Take a look at the following thread for more information:
http://tinyurl.com/t4vp

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

 

[Gregory L Priem]

The crypto classes work on Windows 2000. However the exceptions you're
getting indicate that your key store may be corrupted.
Take a look at the following thread for more information:
http://tinyurl.com/t4vp

after giving up on this for a while, i played with it again this
morning. i wrote a little CryptoAPI program to test if that was
working correctly - and it was not. anything asking for the enhanced
provider [MS_ENHANCED_PROV] returned NTE_BAD_SIGNATURE [0x80090006]..
the base provider worked, but the enhanced provider did not.

i used filemon to see if it would shed any light, but only noticed
something a little odd - it was accessing rsaenh.dll in the same
directory as the exe.

it turns out that i had an old version of rsaenh.dll in the exe's
directory! since the loader looks in the current directory before
anywhere else in the search path, an invalid signature was seen, and
an error resulted.

the vmware session which i had set up exhibited the same behavior due
to me running the test exe via a unc path [so the bad dll was again
being used]

thanks for the post - it helped get me thinking about the problem in a
fresh way which eventually led me to my self-imposed problem.

greg priem kb0erz
bark, fido, bark [neither of us speak for my employer]