Is encrypting data once enough?

Question

If I encrypt my data and want to send it from point A to point B, is the end to end encryption is necessary?

Although it's dependent on a) the encryption method and b) my security policy but is one encryption theoretically not enough?

When we transmit data from point A to point B there are many untrusted hops in between and they have the ability to capture data without permission. Data tampering is technically always possible.

It concerned to make sure that data arrived at the destination without any unwanted changes, but at the same time having the end to end encryption imposes overhead costs.

Is encrypting data once enough?

Answer 1

You've described a method, but not the goal or any circumstances:

1. What is the situation and your goal therein?
2. What adversaries do you want to protect against?

The assumed scenario

I assume that you want to:

• you want to send data,
• without a passive eavesdropper being able to obtain the contents,
• where you own both computers (or perhaps a friend owns the destination computer).

In this case, there is an alternative channel available: you can talk to your friend (or yourself) over the phone or in real life, so you can give them the password. Use an encrypted 7z archive and email it or something.

To verify the integrity, in case an active attacker might have tampered with the transmission, you could compute the hash (generated using, for example, the sha256sum command on GNU-based systems) and include that in a file in the 7z archive. The archive itself already has checksums, but that does not qualify as authenticated encryption (cryptographic integrity + confidentiality) so you should verify it separately. You could also, when giving the password, give the hash to your friend so they can check it that way.

But you could also mean...

• you want to send data,
• to someone whom you never met before (such as a visitor of your website),
• without an active eavesdropper being able to obtain or modify the contents.

In that case, how are you going to exchange keys? Any password you send over the line, an eavesdropper can intercept. And any key exchange algorithm which protects against passive intercepts, can be defeated by active attackers. The way https solves it, is by having trusted third parties. By having a certificate by one of those trusted parties, such as Let's Encrypt, the recipient can be reasonably sure that the encryption keys it received were not from an attacker.

So what you need really depends on the situation. From your description, I assume that an encrypted 7z archive is sufficient; but if you want a more specific answer, you need to ask a more specific question.

As for "is single-layer encryption sufficient?"

Well, how much do you trust any given algorithm? I can sell you a super deluxe algorithm for only $500, but nobody checked it. You could use AES: designed by Belgians, used in USA standards, and lots of people have studied it for flaws. The odds of that one being broken are, in my opinion, negligible. But maybe you are afraid of the NSA having backdoored AES, in which case you might want to use Russian algorithms like GOST. But what if the Russians backdoored that one? You could use both and mix the two, but while that is in theory not an issue, in practice slight modifications of recommended usage can result in catastrophic failures. It would smell like homebrew crypto soup.

To make a long story short: yes, using only one layer of encryption is definitely enough. (Assuming a standard situation.) However, the question is: is the algorithm secure? Choose your encryption method wisely!

Answer 2

Not Necessarily

To answer your question generally: Not necessarily.

That isn't to say that it's a waste of your time.

Encryption on it's own isn't always enough to guarantee the confidentiality of your data, but the specifics rely upon the details of your use case.

---

An Example

For example, let's say that you used an unpadded encryption scheme like AES-256 in CTR mode, and you properly managed your IVs and keys, and your system was designed to send encrypted JSON strings in the following format:

{evil:[true|false]}

AES-256 in CTR mode is quite secure, but the length of the encrypted output will be 11 bytes if true, and 12 bytes if false. Other cipher modes would suffer from this as well, though possibly to a lesser degree.

But as the pedantic example shows: your data could theoretically be leaked from its metadata.

---

Furthermore

Now, let's assume that you manage to normalize your data, and safeguard its output against meta cryptanalysis,

If your data is parsed and used by an algorithm, you almost certainly will want to authenticate its integrity (because of known plaintext substitutions).

For example: If you were implementing a web browser protocol without authenticated encryption, one might be able to swap out part of your cipher text (usually the head) and inject a script tag, or any remote resource tag. This injected resource could be used to expose the contents of your encrypted data.

A similar vulnerability was exploited in quite a few PGP email clients, allowing attackers to view the contents of an email without technically "breaking the encryption."

---

tl;dr

Use authenticated encryption, and know your data. You might need to safeguard it against meta-analysis.

Answer 3

If you only want to make sure that nobody has access to the plain data during transit and that the data cannot be modified then it is enough to encrypt the data once, assuming that it is done correctly, i.e. strong key, strong encryption algorithm and strong integrity protection.

But, there are cases were more is needed, like strong authentication, hiding meta information like who communicates with whom, hiding traffic pattern like size and timing of data etc. In this case one might to want to transfer the already encrypted data over a tunnel which provides additional protection.

Answer 4

Security people like to talk about encryption "at rest" and "in transit". They are slightly different things. Encryption also comes with other features than just making your data unreadable to the recipient. File encryption is often used in conjunction with signing - proving the origin of the file. Transport encryption is usually done with a private key at the far end proving you've sent the file to the right place.

Of course, both approaches can be implemented in such a way to provide the benefits of the other - but this is a little more esoteric than using the software as it came out of the box.

They have different weaknesses though: file encryption requires you and your correspondent to agree one or more keys - which should be done (or at least verified) via another channel than the way you send the encrypted data. Transport encryption can be done without first agreeing a key (assuming it uses a certificate based mechanism - the obvious one being TLS). OTOH TLS, SSL and SSH are not encryption algorithm but protocols for agreeing on algorithms then implementing them for the channel. In the case of TLS and SSL, the negotiation has historically been an area of weakness - it has been possible, in some instances to trick an end point into agreeing to a relatively insecure algorithm.

So while it's not quite comparing apples and oranges, they are different things, and hence there may be an advantage to using both.

Answer 5

When implemented properly, single encryption via a protocol that provides authenticated encryption is enough to verify:

1. the contents of the encrypted file cannot be recovered without the secret key,
2. the contents of the encrypted file have not been tampered with by someone who does not have the secret key.

Authenticated encryption uses both an encryption function to map a plaintext to create a ciphertext based on a secret key, but it also generates a Message Authentication Code (MAC) based on the text and a secret key. Someone who does not have the secret key cannot generate a valid MAC for a message (and any recipient trying to decrypt a corrupted message will quickly discover it was corrupted). One simple message authentication code algorithm is MAC = Encrypt(Hash(ciphertext), Key) (Encrypt-Then-MAC) where you append this MAC to your ciphertext and check it prior to decryption.

That said, there are many situations where multiple-levels of encryption are appropriate and the norm (even if each encryption protocol provides a MAC to verify integrity). For example, you upload an already-encrypted file to a remote server using SSH protocol; or you connect to your work's intranet via a VPN which uses IPSec to encrypt your network traffic; then you use SSH or visit an HTTPS webpage over that VPN; or you use encryption over WiFi and then connect to an HTTPS website, etc. Encrypted transfer protocols like SSH or HTTPS may still be preferred even when transferring files that began encrypted, because you can verify the identity of the server you are uploading the contents to (unlike with telnet or http, where a network eavesdropper could intercept requests and secretly impersonate the correct server and the files will never arrive at their intended destination. That said, the interceptor will not be able to decrypt your strongly encrypted file without the secret key).

Please note that network eavesdroppers can in all scenarios listen to the amount of traffic being sent as well as where the next hop is.