2

I just read about PGP encryption scheme here, and started wondering what is the need to encrypt the file with a one time random key? In other words, how is this scheme more secure than simply sending the file which is directly encrypted using the public key? (Because the one time key is anyways sent along with the data)

  • What research have you done? Read the Wikipedia article on [hybrid encryption](https://en.wikipedia.org/wiki/Hybrid_cryptosystem); it gives a reasonable primer. – D.W. Aug 01 '14 at 00:05

2 Answers2

6

There are two reasons:

  1. RSA and other assymetric algorithms are very slow. It is faster to encrypt a small key using the assymetric algorithm, and encrypt the message using that key with a faster and symmetric cipher.

  2. In its default setup, RSA is insecure. It needs a padding scheme to get full security. This "random key" method is part of such a padding scheme.

user10008
  • 4,355
  • 21
  • 33
  • 2
    Good answer. You could also add that it's the only way to send an encrypted message to several recipients without having to re-encrypt the whole message for each one. – Stephane Jul 31 '14 at 15:34
5

This is called hybrid encryption. It is needed for the following reasons:

  • Asymmetric encryption algorithms like RSA or ElGamal are very limited in the size of messages that they can process. If you use a 2048-bit RSA key, the maximum size of the data that you are going to encrypt is 245 bytes, no more.

    There is no currently known, clear, fully specified and heavily reviewed method by which a longer message could be somehow "split" into individual elements, each small enough to be RSA-encrypted, then reassembled. That is, it is easy to define a simple split/concatenate procedure, but it would not be safe. This area has not been thoroughly explored by cryptographers, so, in practice, that's a no-go.

  • Even if we knew how to securely perform an only-RSA asymmetric encryption for bulk data, it would entail a substantial message size increase (not a fixed overhead, rather a multiplicative factor). Network bandwidth is often a primary concern (especially in embedded systems).

  • We sometimes prefer to use key exchange algorithms, like Diffie-Hellman, for a variety of reasons (e.g., before 2000, RSA was patented, which was a powerful reason, from the US Federal government point of view, to mandate usage of DH instead of RSA). Such algorithms are not exactly encryption in that you end up with a shared secret, but you do not get to choose that secret value. A shared secret is enough to serve as key for a symmetric encryption algorithm, but you need a symmetric encryption algorithm.

  • The most often quoted reason, and actually the least compelling, is performance. Asymmetric encryption algorithms can entail some non-negligible CPU cost. E.g., RSA decryption (not encryption, which is faster) with 2048-bit RSA key will proceed at a rate of a few hundred instances per second on a modern laptop (a few thousands if you use several cores).

    The reason that this reason is what is always said about hybrid encryption is that it is what crypto teachers have repeated for years, starting from a root piece of wisdom dating from the late 1970s. The point about RSA being very slow was perfectly true at that time. But remember that computers of that era were like that one. A basic smartphone from 2014 has a lot more punch, by a factor of more than 10000. Even the chip from a recent credit card outperforms a 1980 desktop computer by a very wide margin. This "piece of wisdom" is severely outdated.

    Right now, we may still encounter performance issues if we are too heavy-handed on public-key crypto, but certainly not as much as is usually feared. Hollywood has trained people to think of cryptography as something ponderous, expensive, and graphic; this is all a lie, as unrealistic as Mark Hamill's hairdo.

Summary: we don't "directly encrypt" files with the public key because we do not know how to do it securely; even if we did, it could be expensive; and we want to keep the possibility of using algorithms and key types which don't actually support encryption, only key exchange.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480