Windows Cryptography
I in doubt if this is the right forum but there isn't a Windows specific one, so... there it go...
Does windows have a lib to deal with cryptography, to encrypt decrypt messages?
If yes, what algorithm does it has? RSA, DEC?
I looked in MSDN and find some thing but for .NET I want something to C++.... I found a RSA Class but it is abstract and the programmer who has to implement it...
Any help is wellcome, thanks
CryptoApi
It has a variety of algorithms that plug into it. Also like most MS API's it's not particularly easy to use. Expect to spend a lot of time studying and experimenting before you can do anything useful.
It has a variety of algorithms that plug into it. Also like most MS API's it's not particularly easy to use. Expect to spend a lot of time studying and experimenting before you can do anything useful.
Check the Forum FAQ, it talks about XTEA. Implementing XTEA will only add a hundred bytes or so of code to your program, and it's cryptographically strong!
I google for it and found something about it.... It is quite interesting the problem is that I need two implementation C/C++ and Java...
It is for a MMO so I thought it would be better to use a public key algorithm like RSA or something like that...
It is for a MMO so I thought it would be better to use a public key algorithm like RSA or something like that...
You're right; I took out the encryption stuff when I wrote the FAQ but didn't remember I did. The original papers can be found online. There's also a good resource here.
The problem with public-key systems is that they are significantly higher computational overhead. You really don't want to use them for your streaming data in a real-time system with shared servers -- although your message doesn't state what your requirements are.
A good alternative is to use public-key cryptography to exchange a randomly generated key, and use a fast, symmetric cypher like XTEA to actually exchange data. Perhaps easiest is to do Diffie-Hellman key exchange; I remember seeing code to do it somewhere on the web, so it should be google-able.
However, this still only protects against certain kinds of eavesdropping attacks -- if you're trying to secure an un-trusted end-user client, encryption won't get you far. Again, the right solution probably depends a large amount on what the specific problem is :-)
The problem with public-key systems is that they are significantly higher computational overhead. You really don't want to use them for your streaming data in a real-time system with shared servers -- although your message doesn't state what your requirements are.
A good alternative is to use public-key cryptography to exchange a randomly generated key, and use a fast, symmetric cypher like XTEA to actually exchange data. Perhaps easiest is to do Diffie-Hellman key exchange; I remember seeing code to do it somewhere on the web, so it should be google-able.
However, this still only protects against certain kinds of eavesdropping attacks -- if you're trying to secure an un-trusted end-user client, encryption won't get you far. Again, the right solution probably depends a large amount on what the specific problem is :-)
hplus0603
You are right, I am worry about how to start the connection.
Maybe a public key to change a randomly generated key for XTEA, for example, is the way to go...
But I am worried about how can I do that in client side in a secure manner... How can I be sure the client can't read the private keys in the code...
Something like, the client send a RSA message requesting a key and the server then creates a key and sends a RSA message... From now on they talk with XTEA... but the client still have the Private key some where... :(
You are right, I am worry about how to start the connection.
Maybe a public key to change a randomly generated key for XTEA, for example, is the way to go...
But I am worried about how can I do that in client side in a secure manner... How can I be sure the client can't read the private keys in the code...
Something like, the client send a RSA message requesting a key and the server then creates a key and sends a RSA message... From now on they talk with XTEA... but the client still have the Private key some where... :(
why on earth would you store the private key in your client code? (*hint*you wouldn't*hint*)
Generally, if you want a secure exchange from both sides, you generate a public/private key pair on both sides, exchange the public keys, and use those to encrypt the data you send between the hosts.1 Of course, this doesn't solve the man in the middle attack. Which can be solved by using digital signature authentication.
1Diffie-Hellman
Generally, if you want a secure exchange from both sides, you generate a public/private key pair on both sides, exchange the public keys, and use those to encrypt the data you send between the hosts.1 Of course, this doesn't solve the man in the middle attack. Which can be solved by using digital signature authentication.
1Diffie-Hellman
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement