Three fallacies in secure document transfer

The way you send and receive documents is probably vulnerable. Discover why.

Posted by Franco Graziosi on June 01, 2023

How many times per day do you exchange electronic documents and files? Do you think it is secure? Unhappily this is usually an illusion, as explained below.

Fallacy 1: Your Email is secure

Yes, you need a password to access it, but this is only the last step of a long journey that your messages undertake. In fact, before reaching your email provider, each message passes through a chain of other servers.

All those servers (including your provider) have complete visibility of your message as well as whatever hacker or authority conveniently placed on the route.

To see the complete list of servers that have read a message of yours, ask the message header (for example, choose "Show Original" in the GMail menu), and you will get something like this:

Then check all "received by" entries. Apart from the last one (your provider), you probably don't know the others, even though they have read your message up to its last byte.

Fallacy 2: You can always zip your document and files with a password

That is a common practice. However, it primarily serves to call the attention of the hacker which sniffing a password-protected ZIP gets curious about its content and breaks it in less than a minute.

To understand how that is possible, let's explore the basic principles of cryptography.

Keys vs. Passwords

Let's start with the old physical lock. How does it work? The key has a sequence of shafts. When you turn the key, each one moves a corresponding pin to a specific position. Once all pins are aligned, then you can turn the key.

Suppose there are five pins, each with four possible positions; then there will be 1024 combinations (45). Trying them all is called a brute-force attack. Supposing a burglar wants to break into your home using a brute-force attack, and each attempt with a different key takes 5 seconds; he will probably take more than one hour to succeed, which is too much.

You see that three factors are essential:

  • The length of the key
  • The time to make an attempt
  • The total time available for the attack

How do we measure the length of the key? In bits, that precisely measure the challenge. Each additional bit doubles the difficulty. The physical lock uses only 10 bits (210 = 1024), but each attempt demands 5 seconds and the burglar have limited time.

Let's now consider a password, for example, of eight characters. You can encode a character in 6 bits. Thus the key length will be 8 x 7 = 56 bits, but a computer can make thousands of attempts per second and crack such a key in seconds.

There is a sold software product to crack zip keys, just in case somebody forgot the password. Its authors even admitted to add a little extra time to justify the price.

Still worse, once a hacker intercepts and copies your message, he has plenty of time to perform the brute attack. That is why a password is not a secure key. It is too short!

So, how long shall be a secure key? Again, it depends on the three-factor we already identified. All keys are breakable, but the encrypted information will lose value if it takes hundreds of years.

But how long is a secure key? Today keys of 128 bits are considered safe because it would take billions of years to crack, but soon things will change with the introduction of quantum computing.

Keys over 512 bits are considered military-grade and virtually uncrackable. However, GPG, which we will see in the next article uses keys between 512 and 4096 bits.

At this point, one thing shall be clear: a safe key is not something you can memorize, like a password.

Fallacy 3: End-to-end service is secure

There are alternatives to email that promise end-to-end encryption, like Telegram, to cite one. But think a little: who is performing the decryption? Telegram, of course, or whatever other similar service. And if they do, that is because they have access to your private key!

So you have only shifted the problem. Instead of trusting the network, you are trusting a single provider with access to all your sensitive traffic. Better or worse? You decide, but a single entity, differently from a network, is easily exposed to "forced decryption."

Third-party services can use a long and secure key, but they manage that key and can disclose your information.

From our first article, we have gathered a critical point: to ensure secure encryption of a file or document, you would require a key that is a separate file kept in a safe location accessible only to you.

Since you can't memorize a long ley, we will explore how to manage the keys in the next post. Finally, in the last article, you will make actual practice using open-source software.