Better to keep JScript.NET dll or try converting JScript.NET code to C#? [closed]

Let me explain the back-story to my question:

I have made a .NET program that logs into an account on a website and scrapes various pages of information. In order to login to the website, I must perform an RSA encryption on the password using a public key and exponent (which are both provided by the Server's HTTP response). So far, I cannot find an RSA library that you can call from C# which will perform this encryption in such a way that the server won't throw a security error.

Since none of the C# RSA options can successfully talk to the server I must use a modified version of this Javascript RSA library in order to encrypt a password the server will recognize:

http://www-cs-students.stanford.edu/~tjw/jsbn/

The javascript code above is also provided by the server when you attempt to login.

Initially, I called the Javascript library by using a Jurassic.DLL Javascript engine which would compile the Javascript code into CIL and easily allow me to perform the encryption that the server would accept. However, this introduced an unwanted dependency on a javascript file to my program. So, I decided to take it one step further.

I wrapped the functionality of the javascript file into a JScript.NET class and created a function that would do the encryption. I compiled it to a .NET DLL using the JScript.NET compiler and now I can call that DLL to get the encryption that I need. This works great since the server accepts the result without my program depending on some javascript file, but it still isn't quite as 'tight' as I would like.

I was considering the following options, and I need some educated opinions on either one:

1. Painstakingly convert the RSA code to C#. This is very, very difficult since JS by nature doesn't have static types, and it is difficult to deduce what variable is what type in the RSA code, not even mentioning the idea of mapping one js data type to a C# one. Moreover, the RSA code has undescriptive variable names like c, x, w, etc. In spite of these shortcomings, this option would bring the advantage of having one fewer dependency on a dll. Would this option really be worth the trouble, though?

2. Keep the RSA dll and continue using it. It would introduce another dependency, but at least it would work. The downside is that it was compiled from JScript.NET and is being called from C#. This may introduce some strange problems.

I would use RSACryptoServiceProvider in the .NET library or even ManagedOpenSSL.NET, but no matter what I try to do, I cannot get either of those libraries to send an encrypted password that the server won't reject after spending quite some time on it.