SFML community forums
General => SFML projects => Topic started by: RaptorTeak on November 30, 2011, 02:09:04 am
-
Hey everybody !
This is an SFML plugin I created for one of my project a week ago : SSFML (Secure SFML).
It allows you to establish crypted connections between Sockets (for now only on TCP).
It's based off SFML 2
The process uses key encapsulation ( http://en.wikipedia.org/wiki/Key_encapsulation ), meaning that it first instantiates an RSA connection in order to transfer a symmetric algorithm key, and then all the data is crypted and transferred using a stream cipher (symmetric crypting algorithm)
Currently supported ciphers :
- RC4 (key size : 5-256 Bytes)
- AES (key size : 16/24/32 Bytes)
This plugin requires openssl as an additionnal dependency.
Git Repository : https://github.com/Elyotna/SecureSFML
Examples of using this module are in the repository. You'll be pleased to notice that it really isn't much different from a regular SFML-network implementation. (meaning that it won't be hard to convert your unencrypted architecture to this one if you wish to)
I also tried to make the compile/install phase as easy as possible. For now, it uses cmake and can be installed easily on linux (read README.Txt).
Note : For now, this doesn't support authentification/signature along with certificates, hence not protecting the data against a man-in-the-middle attack.
Of course, it is still in its developpement phase, so... feedback would be really appreciated (bugs/suggestions/critics..). The most important "problem" is that I have no idea whether this is gonna work on a 32-bit machine or not.
So if you can, I would gladly appreciate tests made between 32-32, 32-64 and 64-32bit machines.
The only one I'm sure about is the 64-64bit case where this should work just fine.
Thank you in advance for your feedback!
-
This is cool! Is it based off SFML 1.6 or 2?
Also, i think something like ssf::Socket would be more fit than "raping" sf::
-
That looks nice! I will give it a try! It really deserves it
This is cool! Is it based off SFML 1.6 or 2?
Also, i think something like ssf::Socket would be more fit than "raping" sf::
It doesn't use sf::Socket, it uses the word 'Secure' before everything (As I saw in the example)
-
This is cool! Is it based off SFML 1.6 or 2?
I'm sorry, I forgot the most important : it's based off SFML 2. I tried to do it on SFML 1.6, but the "sockets can be copied" architecture really screw it and wouldn't let me use selector with inherited socket types.
I edited the main post :) .
Also, i think something like ssf::Socket would be more fit than "raping" sf::
Well to be honest, I kinda liked the fact of "implanting" this module into SFML. And as Haikarainen said, I don't modify/overwrite anything, I just add functionnalities and classes (which all begin with Secure*).
Thank you both for your support :) .
-
Well to be honest, I kinda liked the fact of "implanting" this module into SFML.
But it is not official SFML. It will confuse people to see sf:: classes that are not in the official package.
-
Well to be honest, I kinda liked the fact of "implanting" this module into SFML.
But it is not official SFML. It will confuse people to see sf:: classes that are not in the official package.
People who will possess this module will also have installed it on their own, so I think they should be pretty aware of that...
But anyway, okay, I'll change the namespace. Still kinda new to this open-source world as a contributor :) .
-
People who will possess this module will also have installed it on their own, so I think they should be pretty aware of that...
I was thinking about people who visit the forum, or who find code snippets after Googling.
When you see a piece of code it should be clear which library it belongs to.
-
I agree with Laurent, and also the coding styles are slightly different, which could confuse some people. (For example, your project uses lower camel case for class methods while SFML uses upper camel case.)
-
I just updated the repository with a new namespace (ssf:: ) and different installation paths to prevent confusion with official SFML modules.
-
Will try this out right now, I'll check in if I come across trouble!