rsabase.dll

[Michael Jung]

On Monday 26 July 2004 00:14, Robert Shearman wrote:
> >- Implementation of "real handles", instead of "address-handles".
>
> This is useful. Address handles (pointers to objects in memory) have the
> disadvantage that they can leak memory if the application can't be
> bothered to free them, although this only really matters if the library
> is unloaded (as if the process terminates, all memory will be freed
> anyway) and can be just as easily accomplished with a separate heap.
> Hmm, maybe it isn't so useful. Why did you go down this route?

I think there are many reasons to favour "real handles": If a long running 
process is using rsabase (e.g. a webserver serving https: requests) with many
temporary connections and many keys, resource leakage is an issue. 
Furthermore, since rsabase is a cryptographic service provider, it might be 
important that a key, which is not referenced anymore is in fact destroyed 
(and the corresponding  memory be nulled). I would think that otherwise you 
will over time accumulate a lot of keys in your address space, which is 
probably a security problem. Now, I'm aware that wine is not in a state today 
to be used for security critical applications and first rsabase 
implementations will probably have security issues more severe than this. 
However, sometime I think rsabase will have to use real handles. Why not 
right from the start?

> >- Separating OpenSSL dependend code from CSP code. I consider
> >  this beneficial, since there seem to be some license issues
> >  with OpenSSL (at least for the ReactOS project - there was a short
> >  discussion on this on the wine-devel list). If the OpenSSL code is
> >  cleanly separated, it will be easier to support GNUTLS or something
> >  later.
>
> I think this is just making the job harder. Yes, OpenSSL possible has
> licensing issues, but that is for the OS. Is there anything stopping you
> creating an OpenSSL layer on top of GNUTLS (or any other crypto
> library), rather than going down this messy compatibility route?

In my opinion it would be nice for the end user, if rsabase works with either 
OpenSSL or GNUTLS, whatever is installed. I think telling the end user to 
install a GNUTLS/OpenSSL compatibility layer library before using rsabase 
with GNUTLS is messier than making rsabase work with both of them. 
Furthermore, we could implement a "dummy" implementation, which does not do 
any cryptographic operation at all. So if neither openssl nor gnutls is 
installed only the "skin" of rsabase works, no "guts". I would bet that there 
are some applications which will run anyway (As the "Implemented enough of 
rsabase to make Steam login" comment in the current rsabase implementation 
suggests).

However, as I've said, I didn't implement much of the "guts" upto now. Thus I 
don't know how similar openssl and gnutls are and how hard it would be to 
abstract from both. So if you consider this approach messy, I will be happy 
to keep it out.

> >- Basically, my code doesn't do any crypto stuff at all until now
> >  (Besides some first lines of code for MD5 hashing). I tried to
> >  get the MSDN CryptoAPI examples to compile and run, which only
> >  acquire contexts, hash data, derive keys, query CSP params and so
> >  on, but which never verify the results. So my code is mainly skin
> >  (but elephant skin), no guts.
>
> Yes, it is similar code to mine, except I used the EVP higher-level
> routines as they offer a similar framework to CryptoAPI and it is really
> no more work to add in new algorithms (except for a case statement in
> one or two switch blocks).
>
> >I've attached the current version of my patch.
> >
> >Do you have a certain application, which you want to get running?
>
> Not really. I went down this route because I thought it would be needed
> for a certain application, but it turned out that it didn't need it. I'd
> still to finish the work and to get it incorporated into the Wine tree,
> however. I can still use this application to test with though (it calls
> ExitProcess if it doesn't verify correctly).
>
> > Would it be
> >ok for you if we proceed as follows: I will wait until you submit your
> > patch (It would be nice if you could add some unit-tests that test for
> > behaviour you depend on). After this you give me a week or two to
> > incorporate my work.
>
> Sure, that sounds good.
>
> >Is there any area in rsabase, which you definitely will not implement in
> > the near future and which I could work on until you submit your patch?
>
> Well, pretty much everything that I was going to implement is in the
> patch I sent you. The only additional functions I was going to implement
> are RSA_CPSignHash and RSA_CPVerifySignature. However, if you want me to
> implement some more I would be only too happy to do so having gained a
> lot of familiarity with both CryptoAPI and the OpenSSL/Crypto library.

I don't have a certain application in mind either. So I don't have concrete 
wishes for functions to be implemented. I just wanted to find a start 
contributing to wine and ended up working on rsabase by chance. 

Michael