It's a common belief hybrid cryptosystems are better than asymmetric only. Is that allways like that?
What's the benefit of using symmetric and asymmetric encryption for small data blocks (< 100 bytes)?
asked Oct 20, 2014 at 20:05
-
perhaps you need to clarify or cite your source for "hybrid is better than asym" - because it does depend on how it is applied– schroeder ♦Oct 20, 2014 at 20:09
-
Well, you're right about that. An answer was given to me yesterday and i didn't quite get why a hybrid cryptosystem was preferred, even with padding.– Andras GyomreyOct 20, 2014 at 20:18
-
These are the people more in the know: crypto.stackexchange.com/questions/2789/…– Jeff Ferland ♦Oct 20, 2014 at 20:29
-
Your source says that hybrid is more flexible. I'm not sure how much further you can take that.– schroeder ♦Oct 20, 2014 at 20:34
Add a comment
|
2 Answers
If you have messages to send, and you use an asymmetric encryption algorithm, and that algorithm happens to be able to process each message wholesale because the messages are small enough, then indeed you can design the protocol without any recourse to extra symmetric encryption.
However this may lose some flexibility, and have a non-trivial performance cost. The flexibility is about the possibility to replace, in an ulterior version of the protocol, the asymmetric encryption algorithm (e.g. RSA) with another algorithm that can only do key-exchange (e.g. Diffie-Hellman); in the latter case, you absolutely need to couple it with symmetric encryption.
For the performance, a critical point is whether you envision two parties to send to each other several messages in a short time. With "pure RSA" and a 4096-bit RSA key, each encrypted message will need 512 bytes. With an hybrid system, successive messages may reuse an already negotiated session key, and thus need only 120 bytes or so (if the plaintext messages are about 100-byte long). Of course there is also the issue of CPU cost (RSA-4096 decryption are not exactly free), but network bandwidth issues are often more important.
Take note that if several messages are sent and each of them is encrypted separately, then it is your responsibility to include in the messages something which allows the recipient to detect whether some messages were dropped, or duplicated, or arrived out-of-order. You may also want to add some specific countermeasures to detect alterations of messages, and completely phony messages.
More generally, with RSA encryption, the public key is public, hence everybody can use the key to encrypt messages. If you have a notion of a "stream of messages" then you will need some more crypto to avoid external insertion of extra messages. This is linked with notions of authentication. There again, systems that rely on hybrid encryption can reuse an initial handshake procedure, and thus guarantee that all messages protected (through symmetric encryption and MAC) with a given session key all come from the same source.
To sum up: you should use TLS or DTLS. Designing your own protocol is a path fraught with perils.
answered Oct 20, 2014 at 20:35
-
Thank you very much. This clears a lot. I'm not planning a message protocol. It's like a mail box: Many people drop a message at the server at separate times trough the day. The receiver doesn't necessarily look at all the packages (he may never read them), but some of the packages may be needed by the receiver. Then again, he opens one per 5-10 minutes. It seems like a good scheme then. Oct 20, 2014 at 20:42
-
Emphasis on the network latency making the cpu cost utterly insignificant. Don't be that programmer that obsesses over a 10ms difference. ;) Oct 20, 2014 at 20:45
-
Well he's right about the 4096 RSA key, it costs between 300ms and 1.5secs to decode in javascript. It's a cost i can afford because of the low reading rate (of the received packages). Oct 20, 2014 at 20:49
-
Oh, right. You where talking about the cost of the latency for the CPU, misread. Oct 20, 2014 at 20:54
If you do decide to use asymmetric crypto alone, you must include some randomness in each message. If you don't:
Suppose an eavesdropper captures a military communication and he knows the message will be one of two things:
- Attack from the East
- Attack from the West
Although he can't decrypt the message, he knows the public key, so he can try encrypting each possible message in turn, and see if it matches the ciphertext.
It's because of subtleties like this that people always say "don't roll your own crypto".
-
2