Which public-domain encryption libraries would you prefer to use with .NET?
I found http://www.bouncycastle.org/csharp/, but I don't how trustworthily The Legion of the Bouncy Castle is. Its seems not to be maintained frequently.
Which cryptographic primitives do I want to use?
If the operating system is your enemy (i.e. has potential backdoors) then you are in a bad situation indeed... because a backdoored OS can inspect everything in your application code and memory.
I suppose that your question comes from the unspoken assumption that if the .NET (Windows) implementations of cryptographic algorithms have been maliciously altered (e.g. to leak critical data elements), then maybe those backdoors would not apply to some external code ? Unfortunately, this is not the case. Indeed, the most plausible backdoor, for these matters, is to spike the system PRNG. It is possible to modify a given PRNG so that its output looks random but can be predicting by someone who is privy to the generation details. If done properly, such a backdoor cannot be detected from the outside, and even if he problem is revealed (through reverse-engineering of the PRNG implementation), one can always claim incompetence rather than malice (the Debian maintainers managed to do exactly that).
To give an example, imagine a PRNG which works by encrypting a 16-byte counter with AES, the key being a 16-byte seed obtained through hashing "random events" such as timings of hardware interrupts. Then, suppose that some unfortunate programming bug in copying the hash output into the output results in about 80 bits of the key to be predictable. Attackers who know this flaw can predict the PRNG output by doing an exhaustive search on the 48 remaining bits, which is not free, but highly doable with a few PC. You would say, how can you botch a memory copy that bad ? Surely it would appear quite artificial, and could not be plausibly denied. Yet the Openwall people, of John-the-Ripper fame, achieved such a failure in their bcrypt implementation.
Now, imagine a fully open-source (say, "public domain", although this notion tends to have a precise legal meaning which is much stronger than "we can see the source code") implementation of cryptographic algorithms. That code will use some keys, and such keys will have to be imported or, crucially, generated. Key generation requires usage of some good randomness. In C#/.NET code, where will you look for when you need randomness ? Your code executes in the CLR Virtual Machine which is a very abstract execution model -- meaning that everything happens in a very deterministic way, and your code cannot escape well-established rails. No way to read arbitrary bytes in RAM, for instance; hardware is abstracted away and you cannot access it directly. The bottom-line is that if you want good randomness in .NET, you have to get it from the operating system, i.e. System.Security.Cryptography.RNGCryptoServiceProvider. And then you are back to using the PRNG that could, potentially, be predicted by your enemy.
(The same point could be made about Java.)
Therefore, while using an external implementation of cryptographic algorithms is possible, it does not guarantee protection against backdoors in the cryptographic layer of the operating system.
On the other hand, there are good usability reasons to use the cryptographic algorithms provided by the OS:
To sum up, IF you believe your OS to be hostile to you, THEN you will have trouble escaping its evilness -- using "public-domain" implementations of cryptographic algorithms might not suffice for that; but you would lose some very interesting features by doing that. So I would suggest that you trust your OS and let it do the job for you. If that worries you to much, then don't switch to an open-source cryptographic library; switch to an open-source operating system altogether. There are many possibilities, with all the Linux brands, the *BSD (NetBSD, FreeBSD, OpenBSD...), even OpenIndiana (a derivative from Solaris)...
Bouncy Castle is pretty well known and used in a fair number of production apps. I came across it myself a few times when I worked as a C# developer. However, most of the implementations in there simply piggyback off the .NET framework implementations anyway. The added value that they're selling is additional cryptographic primitives that .NET doesn't provide, and more convenient / simplified interfaces for people who don't understand how to use cryptography. However, it does have flaws and shouldn't be relied on for anything critical. It's also, to my knowledge, ever been formally reviewed by cryptographers.
That said, you should definitely use the .NET framework stuff, rather than rolling your own implementations. For a large part, it's just a managed wrapper around the underlying CAPI or CNG implementations in the operating system, so it's as trustworthy as the OS. The bits that aren't wrappers are explicitly named Managed, e.g. SHA1Managed. If you don't trust the CAPI or CNG implementations, then you shouldn't trust the rest of the OS, and your problem becomes moot anyway.
Even better, the .NET framework is shared-source. You can go review the reference source at at any time. There are plugins for Visual Studio (e.g. ReSharper) that let you right click any .NET type and jump to the source, and it'll automatically download the appropriate reference source files for your viewing. It's pretty awesome, and has helped me solve loads of bugs over the years.
So yeah, tl;dr is that the .NET framework implementations are solid, so use them. BC is also useful, but then you're adding bloat and potential licensing issues, so if you can get by without it then do so.
