Author Topic: Understanding Encryption: Here's The Key  (Read 153 times)


  • Freelancer
  • *****
  • Posts: 1292
  • Rating: +0/-0
Understanding Encryption: Here's The Key
« on: Sep 19, 2013, 07:31 PM »
We've grown inured to news about cyberthreats and electronic intrusions. But Edward Snowden has done more to disrupt our assumptions about online privacy and security in the past couple of months than any number of headlines about hackers.

The former National Security Agency contractor, now reportedly living under the radar in Russia, has released incredibly eye-opening documents to the media that seem to demonstrate a deliberate and systematic effort by U.S. and U.K. intelligence services to undermine the most basic safeguards private citizens and corporations use to protect their data.

Those safeguards are known as encryption, a tool Snowden himself has said that is key to online security.

Here's why encryption matters, how it's facing more threats than ever, and what we can do about it.

Unsafe At Any Computing Speed The most recent set of documents, now being released piecemeal by Snowden's media contacts across the world, seem to indicate that the U.S.'s NSA has somehow managed to render encryption, a tool used to obfuscate data and text, completely worthless.

But it turns out that while the NSA may have compromised some specific technical standards for encryption, the larger notion of encryption, properly implemented, remains valid.

To get a sense of how encryption works, it helps to actually see what encrypted text looks like. The following text, for instance, was encrypted using Text Mechanic, a Web-based tool which uses the Tiny Encryption Algorithm and Base64, a scheme for encoding letters and numbers. It looks pretty strange, but if you use the password provided at the end of this article, then you can translate this back into English words at Text Mechanic.

This may seem like incomprehensible gibberish. And yet, because of the way I've encoded it, you could break it, given enough time or computing power or trickery. (The easiest way would be to get me to give away the password.)

In this example, I used symmetric key encryption, where the same encryption key or password is used to both encode and decode data.

Using symmetric encryption, some string of data—a short text message or an entire data file—runs though an encryption program like the one used at Text Mechanic. You can provide the password yourself, or have the encryption program provide the password or key. Sometimes the key can even take the form of a separate data file itself.

When the encrypted file is given to a recipient, they can use the encryption key to "unlock" the encoded document and decrypt it into plain text or a readable file. But this exposes a security flaw in this method: Somehow or other, the encryption key has to be delivered to the recipient, too—otherwise the encrypted data will stay encrypted. A password sent as plain text is an inherent risk: If it's intercepted, the encrypted communications become fair game.

You could encrypt the password with another password and send the result—but then that password becomes the weak point.

Keeping Secrets By Going Public To plug this security hole, most secure online transactions now use a variant of what is known as asymmetric encryption or public-key encryption. Public-key encryption uses two keys for locking and opening up data: a public key that is shared with anyone, and a private key that stays with the sender of encrypted data.

To illustrate the mechanics of asymmetric encryption, we'll use two classic celebrities from the land of cryptography, Alice and Bob. Alice and Bob have been used to explain how secure communications work since the introduction of public-key cryptography in 1978. (The pair, it should be noted, are a rather rambunctious couple, with a host of supporting characters, such as Eve, the eavesdropper, and Victor, the validator.)

In an asymmetric transaction, Alice asks Bob to send his public key to her through an email. In the world of encryption, email is considered unsafe—it can be intercepted and read. Bob can use email because he is just sending Alice his public key. His private key he keeps very much to himself.

After Alice gets Bob's public key, she uses it to encrypt the file she plans to send Bob. Once she sends it, he can then decrypt the file with his private key to read it.

If the passing of data is reversed, then Bob will need to get Alice's public key before he can send encrypted files or messages to her.

The immedate benefit of public-key encryption is readily apparent: Neither Alice nor Bob ever sent their highly secret private keys in the clear. Only the public keys—the ones used to encrypt data—are out in the open. And the public key can't be analyzed to find out the private key.

If Eve, she who eavesdrops, intercepts the messages, she can't decrypt them, since she doesn't have Alice's or Bob's private keys.

If Bob somehow let Eve get ahold of his private key, then Eve would be able to read Alice’s messages and sent data to Bob, with predictably bad results. But Eve would only see one side of this conversation, because she would also need Alice's private key to see what Bob had sent to Alice.

The Security Of The Bazaar When you buy something on the Internet, or conduct banking transactions on a financial website, encryption is very much involved. At least, it had better be.

You can see whether you are using secure encrypted communications within your browser, typically by the presence of a padlock icon in the URL bar and "https://" in the very first part of the website's address. The "s" stands for secure, and if you don't see that one little letter on a site with which you are about to conduct a financial transaction, stop what you are doing: Your financial information, including your banking or credit card data, is at risk of being intercepted.

When encryption was initially used for online, browser-based transactions, it used the SSL (Secure Sockets Layer) protocol. These days, that technology has largely been replaced by the Transport Layer Security (TLS) protocol, which is regarded as more secure.

TLS uses a combination of asymmetric and symmetric key methods, as did SSL before it, to complete an e-commerce transaction. When Alice wants to buy Bob something on a website—let's call this fictional site "Danube"—she will visit the site, find the item she wants to buy, and start the transaction. Her browser will request a secure page from Danube's Web server—she can tell by the "https://" string in the Web address.

The Danube server sends Alice's browser its public key, as well as a certificate. Certificates are issued by trusted vendors known as certificate authorities. Certificates are there to ensure that the site being visited is indeed the site you intended to conduct the financial transaction. It ensures to Alice that the site she is visiting is really Danube's online store, and not some spoofed copy designed to look like it.

Once Alice's browser has confirmed the authenticity of the site, it uses Danube's public key to encrypt a random key of its own. This is an old-fashioned symmetric key, the kind that's vulnerable to interception, but it's protected by an asymmetric, public key. This key is sent to the Danube server, along with other data from the browser that is also encrypted using the symmetric key.

When the Danube server receives the information from the browser, the next thing it does is decrypt the encrypted symmetric key using its private key. Once the symmetric key is released, that key is in turn used to decrypt the other data the browser sent along.

At this point, both Alice's browser and the Danube server have a copy of the symmetric key that Alice's browser created and will continue to use that key to encrypt all of the remaining data passed back and forth between Alice and Danube until the transaction is completed.

The Keys To The Solution Even though the both symmetric and asymmetric encryption use keys to encrypt and decrypt data, they each use different methods to generate those keys. Key generation is very important, because keys need to be truly random, in order to make sure no machine can easily figure out what the key is through mathematical guesswork.

Symmetric encryption breaks data into smaller blocks in a method called block ciphering. Block ciphering moves letters in the data, converts information within a block into numbers, compresses and expands the data, and runs those numbers through mathematical formulas, which include the key.

A public-key encryption algorithm takes an approach that uses a hash value to encrypt data. With hash values, the data is treated as one big number, which is multiplied by another very large number, with the remainder calculated after dividing the data with a third very large number. That remainder is converted to text.

This would be nearly impossible to reverse engineer, because without knowing any of the factors in the formula—the original number being multiplied (which represents the actual data), the multiplier or the denominator—there is virtually no chance that you're going to get the algorithm. These aren't small numbers, either: Hash values worth anything these days are 128 bits long, which gives 3.4 trillion billion billion billion combinations. And there are far more secure hashing algorithms out there, that use 192- or 256-bit values in their algorithms.

Strong Vs. Weak The recent news that the U.S. National Security Agency has figured out how to get around encryption might lead you to wonder if the secretive agency has managed to build computers powerful enough to brute-force their way through any known encryption algorithm.

Actually, that's not the case.

Instead, the NSA is using other ways to render encryption moot, not actually breaking it wholesale. For instance, if an intelligence agency were to obtain the private encryption keys used by an Internet service provider and its users, then they could decrypt user data with ease.

Or, as recent revelations show, the NSA could work with commercial security software vendors to weaken known encryption algorithms in ways the NSA can later take advantage of. The danger here is that bad guys might figure out how to take advantage of the same vulnerabilities—a risk that has attracted strong criticism for the NSA.

On top of that, there are still some weak encryption algorithms out there that the NSA—and nearly anyone else with enough time and computers on their hands—can smash thorough with brute force.

Open-source encryption software is regarded as a more secure, because the code that generates the hash values and ciphers can be examined for any evidence of sneakiness and back doors.

Start With The End Points At the end of the day, however, what law enforcement and intelligence agencies want, they can get. All the encryption in the world does not make a lick of difference if your computer has been compromised and data and messages can be examined right off your hard drive or your cloud-storage account before they are encrypted. Weak passwords, social engineering, and downloadable malware are all easy ways for anyone to get to your system and its data—far simpler than tinkering with encryption.

This is what security experts warn about when they speak of "end-point security vulnerabilities". End points, in security jargon, mean the devices you actually use—computers, tablets, smartphones, and servers in data centers where your files are stored.

Oh, and you can encrypt your data to your heart's content, but if your password is something simple like (ahem!) ReadWriteHack, then if you're targeted, you're probably vulnerable.

The good news, if there is any, is that encryption itself, when strong enough, still works and can even keep the NSA at bay. Then you're left with an even more complex task: keeping all the machines you use to connect to the Internet secure.


The InfoStride Forum

Understanding Encryption: Here's The Key
« on: Sep 19, 2013, 07:31 PM »