+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Crypto / SSL library (/thread-866.html)
Pages:
1
2
Crypto / SSL library - xoft - 04-28-2013
Currently MCServer uses Crypto++ for the encryption required by the MC protocol. However, Crypto++ doesn't have SSL support and I cannot find a library that would use Crypto++, provide SSL support and be compatible with MCServer's license.
Therefore, I'm inclined to make a switch to a different library, that has both encryption and SSL support and is license-compatible with us.
Options so far:
- OpenSSL ( http://www.openssl.org/ )
- GnuTLS ( http://www.gnutls.org/ )
- CryptLib ( http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ )
Both OpenSSL and GnuTLS have the advantage of being OS-integratable on Linux; however, that also means the disadvantage that building MCServer would become a nightmare on Windows and complicated on Linux.
CryptLib seems to be easy to integrate into a project - just a collection of source file to add to a project.
RE: Crypto / SSL library - keyboard - 04-28-2013
I vote for CryptLib. Seems easier to integrate.
RE: Crypto / SSL library - bearbin - 04-29-2013
Cryptlib seems quite sensible
RE: Crypto / SSL library - xoft - 04-30-2013
Another possibility would be to write our own SSL / TLS support using CryptoPP. It feels like reinventing the wheel, but on the other hand, it could lead to a nice new minimalistic SSL / TLS library. And If I wrote it, I'd put it into public domain, to match CryptoPP's license. That'd be a first
Not sure how difficult the thing would be, though, and how little a subset of TLS we could afford to support.And of course there's a possibility of changing MCServer's license to be compatible with other libraries - CyaSSL for example requires a GPLv2-compatible license, and I like it can cooperate with CryptoPP, we wouldn't have two separate crypto engines nor would we have to change MCS to another one.
RE: Crypto / SSL library - bearbin - 05-05-2013
I wouldn't want the license to be changed to something more restrictive than what it already is but idk - do whatever you think best.
RE: Crypto / SSL library - xoft - 05-05-2013
Restrictive? Apache? Hey, come on, it's one of the least restrictive licenses around
Unfortunately it's GPLv2-incompatible, so we can't use any GPLv2 library.We'll see, I don't think this crypto stuff is all that important right now.
RE: Crypto / SSL library - bearbin - 05-06-2013
No, I'm saying I like how it is, I wouldn't want it changed to a more restrictive one
Cryptlib seems to have a quite good license as well. It wouldn't require a change as far as I can see.
RE: Crypto / SSL library - xoft - 01-14-2014
I have just found the PolarSSL project, it seems that it has all that we need:
- provides Crypto AND SSL
- is license-compatible with MCS (they explicitly say so
)- it builds using cmake
- it already is on GitHub (submodules, yay!
I also found another need for SSL: the authentication in 1.7 requires us to connect to https. So if we want authentication (which we do), we *need* SSL. And soon!
https://polarssl.org/
It even seems that someone is using it on ARM, successfully.
RE: Crypto / SSL library - bearbin - 01-14-2014
Would this be a replacement for CryptoPP?
RE: Crypto / SSL library - xoft - 01-14-2014
Yes, most probably. No point in keeping two crypto libs.