一种保护通过网络发送数据的方法？

Question

I have just finished an application, a simple messenger client and I am looking to encrypt all of the data, whether a phrase of 3 or 200 letters .

What's the best algorithm for this type of app? At this moment I am trying to use 3DES with crypto++ (on VC10), but padding and others things seem a bit difficult.

I am not familiar with cryptography, so any helpful advice is welcome.

Answer 1

Use TLS , say, OpenSSL, which is tried-and-tested technology for protecting data in transit (although you need a trusted root node, and there are PROBLEMS with that so you may want to self-sign).

After that, you should ask whether you need to store these messages locally, and if so whether to encrypt them then. The security requirements are different -- a password-protected symmetric cipher might be more appropriate.

If you're concerned about a secure chat service, then you may be concerned about a secure anonymous chat service, in which case you might want to look at key exchange protocols .

Answer 2

One important factor is how reliable the network connection is expected to be. If you don't expect many dropped packets, or packets that arrive quite late, then you can use a stream cipher, or a symmetric block cipher in chaining mode. If you expect more network unreliability, then a symmetric block cipher in ECB mode would be more appropriate, because lost data would simply be lost data, and wouldn't throw the whole thing out of sync. You'd want to pad each cleartext block with some random data; eg, if each block is 64 bits, make at most 32 bits of that data, and the rest random. That way, it won't be obvious if the same data is sent multiple times.

Generally speaking, PKC isn't used to encrypt messages. It's used to encrypt a random session key, which is then used with a fast symmetric algorithm such as 3DES, AES, or Blowfish.

Answer 3

First of all, nearly the only reason to use 3DES is to be compatible with something else that already uses 3DES, and doesn't support anything newer. 3DES was mostly a quick hack to allow pre-existing implementations of DES (especially in hardware) to continue to be used until they could be replaced -- but it's a pretty lousy choice in general. DES was really designed to be implemented in hardware -- in software, it takes a lot of CPU time for the security achieved.

Second, you haven't really told us enough about the situation to give a real answer. Are you talking about a basically closed system, where you can pre-share the key(s) to the users, or get a key to them by some out of band means (eg, call them, agree on a key, and after that they can use it without further calls?) or do you need to be able to accept arbitrary users without any manual setup (much more complex)? Do users need some way of verifying the identity of the server, or do you want them to just trust that whatever responds to the correct URL will be the right server (again, adding such verification adds a lot more complexity)?

For the sake of argument, let's assume you want encryption but not authentication (ie, no necessity to verify connection to the correct server). In such a case, I'd start by choosing AES -- well-known, easily available, heavily studied, and as far as is publicly known, quite secure.

From there, you need to choose a key. One typical way is to use some public-key protocol (eg, RSA) to exchange a key. One possible way is for the client to send its public key to the server. The server generates a session key (just a random number the right size to use as an encryption key), encrypts it with the client's public-key, and sends the result back to the client. For the remainder of that session, all of the data exchanged between the two is encrypted with the symmetric protocol (eg, AES) using that session key.

As far as how to generate the random number goes: do not use rand() or anything on that order. The usual method is to use the same encryption algorithm (AES) in what's called counter mode -- you just keep a counter, and to create a key you increment a counter you keep internally, encrypt that with some secret key, and use the result as a session key.

Since others have mentioned the mode of operation to use with the encryption, I'll chip in my two cents worth on that as well: you probably do not want to use ECB unless you really expect a horrendously noisy connection, and it's really crucial for the receiver to get all possible data, even at the risk of exposing data to an attacker.

CBC (for only one obvious possibility) gives almost as good of capability to recover from lost packets (it's self-synching, so a burst of noise in transmission can destroy two packets instead of one like in ECB), but does a great deal more to hide the data from an attacker.

Answer 4

我认为RSA可以完成这项工作，您可以使用哈希检查数据是否已更改