One way to solve this is to use the Diffie Hellman algorithm that will be included 
in .NET 3.5.  See this MSDN Magazine article: 
http://msdn.microsoft.com/msdnmag/issues/07/04/CLRInsideOut/default.aspx

(No comment was entered for this change.)

(No comment was entered for this change.)

I learned today that the BigInteger class added in .NET 3.5 is internal only.  So we
can't use it.  But as stated earlier, the Diffie Hellman algorithm as a whole is
available in .NET 3.5 and can perhaps be used to entirely replace the algorithm
that's included in dotnetopenid currently.

(No comment was entered for this change.)

Rats.  .NET 3.5 only includes the Elliptic-curve diffie-hellman algorithm, not the
standard DH algorithm.  So it looks like we have only a few options left for making
this library usable in partial trust environments:
* Have an option to compile with only safe code, which would remove DH algorithm and
switch consumer to "dumb" mode in the spec.  Pros: partial trust works.  Cons: dumb
mode is slower.
* Find an alternative DH algorithm that doesn't use a BigInteger class that has
unsafe code in it. Pros: partial trust works. Cons: possible licensing trouble.
* Leave it as is and require full trust to run.  Pros: it's done.  Cons: no shared
hosting environments will host the library.

Verifiable C# implementations of Diffie-Hellman appear to be hard to come by.  But
perhaps the one we have can be altered to work with another implementation of
BigInteger, since that is the class that actually has the unsafe code.  Here are some
alternative open-source implementations of BigInteger:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vjref98/html/java.math.BigInteger.asp
(BCL: java.math.BigInteger)
http://www.codeproject.com/KB/cs/biginteger.aspx
http://www.codeplex.com/biginteger

Tonight I tried my hand at rewriting the unsafe code in the BigInteger class to use
safe code.  I seem to have succeeded.  The two unit tests (small number, yes) for
this area still pass, and I was able to successfully use the ConsumerPortal sample to
login with my OpenID to both the ServerPortal sample and a live production OpenID
site.  It's looking very promising.

After more code review of my own and cleaning up my work I plan to check into the
trunk.  After which I'd be very grateful to have you guys try it out on as many
OpenID sites as you can (meaning use the ConsumerPortal with your OpenIDs from
various providers) to see if anything broke. 

Let me know what your thoughts are on this.  At the moment, I have the library
compiling without the /unsafe switch and it seems to be working, so I'm pretty
excited.  This fix could probably be merged to the 0.1 branch as well if we wanted to.

Fixed in trunk r118-r120.

Fixed in 0.1 branch in r190 (and a few subsequent revisions with bug fixes).

I learned that at least on GoDaddy, strong-named assemblies somehow inherit full
trust, or something akin to that.  When DotNetOpenId is strong-named, either #define
PARTIAL_TRUST must be set or AllowPartiallyTrustedCallers must be.  When it is not
strong-named neither of these is required.

From: http://support.microsoft.com/kb/839300

...use the AllowPartiallyTrustedCallers attribute of the assembly so that an assembly
that has a strong name can be accessed from a Web page...
An assembly that has a strong name can only be called by a fully trusted caller
unless the assembly uses the AllowPartiallyTrustedCallers attribute. 

The fix will be to use the AllowPartiallyTrustedCallers attribute whenever the
assembly is strong-name signed.  This is only a security concern if we use
PermissionSet.Assert, which we currently do not.  This API has security concerns
anyway, so we're not increasing our attack area by using this attribute currently.

(No comment was entered for this change.)