Schneier on Security

Justin • September 27, 2014 10:10 PM

@Miksa

You are absolutely correct.

When Bruce was talking about cloud backup and the risk of loss of data, I was thinking in terms of something critical in terms of both loss and security, like the customer credit card billing information of a small home business.

I was most emphatically NOT thinking of some scenario like:

“Whohh dewd you were sooooo drunk – no seriously, dewd you were WASTED – Check it out – I have a pic here on my iPhone – oh CRAP I accidentally wiped it – wait! – I thik I got it on iCloud – yeh there it is, I’ll send it to U”

Sorry if that seems, sarcastic, apparently in our world, you can either have simplicity, or security, but not both, and I hate to see the ‘smart phones for dumb people’ crowd controlling the dialog, because apparently they lack the technical sophistication to understand what is possible, what is not possible, or even what the stakes are (outside the context of some brainless super model’s nasty selfies getting stolen and posted to the Internet).

The sad thing is that, if the current generation really cared, they could have BOTH simplicity AND security, by simply forcing their will at the ballot box.

Believe it or not, it’s not the technology, that can quite easily be solved, it’s the political will, to GET IT DONE.

The solution? Simple, just pass a law forcing providers to offer secure encryption of all uploaded user data, with encryption at the source (on your device) with the user in sole control of the password – and full discretion about what gets shared and what does not – with NO back doors.

Then make it a class one felony for any entity public or private to willfully attempt to bypass that security.

Help ANYONE (even the government) steal anyone’s private data, by ANY means – ever – anything – and everyone involved goes to jail, no excuses, no exceptions – period.

Heinous hacker, or Head of the NSA, and the same rule applies, you go to jail, no excuses, no exceptions – period.

Problem solved – but nobody in our current ‘Tech Savvy’ generation of ‘smart’-phone users even seems to care…

… not as long as ‘Angry Birds’ and ‘Candy Crush’ still run, and they can follow every mindlessly stupid ‘tweet’ uttered by their favorite celebs.

Justin • September 28, 2014 1:38 PM

@Nick P

While we are drifting a little off topic, I thought I would take a moment to respond to your comments about IDEA and Polymorphic encryption.

I also like IDEA as a cipher. I can still remember tweaking Colin Plumbs original C code to compile on my machine almost 20 years ago.

So far as the 2012 Bicliques attack by Khovratovich, Leurent, and Rechberger which claims to ‘break’ full 8.5 round IDEA goes- this attack only shaves 2 or 3 bits off of the 128 bit key’s strength, and requires something like 2^56 data to do that, which may be interesting from an academic perspective, but is pretty useless from any practical point of view.

On the subject of ‘Polymorphic’ encryption, there was a reason Bruce was skeptical.

Running lots of ciphers in parallel, as they were proposing with their silly Polymorphic Encryption is SNAKE-OIL pure and simple, because it means that your encryption is only as strong as the WEAKEST cipher in the bundle (not as strong as the STRONGEST as it is with proper one-after-the-other serial super-encryption).

This is because with parallel ciphers, as soon as one cipher is broken you start leaking plain-text, and the ridiculous argument that “then the attacker still can only get a fraction of your data” is just idiotic.

Also, from a purely mathematical perspective, the idea that just interleaving cipher blocks from different ciphers and making the attacker have to guess which cipher was used for each block adds significantly to the cryptographic strength is ludicrous – let’s see, the attacker is willing to brute force your 56 bit DES key with trillions of operations, but when faced with the extra effort of then trying each key against 8 whole different blocks to find out which was encrypted with DES they throw up their hands and give up – yeh right. Snake oil.

In fact, as described, their ‘Polymorphic Encryption’ had pretty much ALL the hallmarks of pure unadulterated Snake Oil Cryptography . . .

1) First grandiose claims of “super-security” that no one else has.

2) Followed by the ‘maximum buzzword’ kitchen sink approach of throwing around the names of as many ciphers as possible (They must know practically EVERYTHING about crypto, just look at all the ciphers and buzz words they know!)

3) And finally, design principles that demonstrate a fundamental lack of understanding about basic cryptographic principles and mathematics.

Justin • September 29, 2014 2:06 AM

@ Figureitout

I’m interested in older ciphers for running on my older/slower machines I’m building…

Good strong crypto, even on older hardware is indeed possible.

Anyone interested in a simple file encryption utility that can be used to encrypt files before archiving them locally or on the web using cloud storage may want to check out the openssl command line utility.

(please excuse the long reply, as simple instructions for openssl, especially on on MS hardware, are not always easy to find on the web, so I hope some of you will find this useful).

If you are running any MS based OS from DOS forward to Win8, one of the simplest and most flexible solutions for simple file encryption and hashing is to grab a copy of the Openssl package from:

GnuWin Utils Openssl

The package you will want to download is openssl-0.9.8h-1-bin.zip

This is a small 5.9MB package with many crypto libraries, test programs, etc which most folks won’t need, but also including something that is really really handy, a MS compatible 1.7MB standalone version of the openssl.exe command line tool which is very simple to use from a DOS prompt or batch file and which can support most of the ciphers and hashes you are likely to want to use:

Hashes: MD5, SHA, SHA1, SHA256, SHA512

Ciphers AES128, AES256, Blowfish, IDEA, RC4

No need to install anything, just download and open the above zip file and open the “bin” folder and find “openssl.exe” and put it in some folder that is in the executable path for your CMD command prompt.

Here are the MD5 and SHA1 hashes for the openssl.exe file so you can double check the integrity of the version you download.

File name: openssl.exe
File size: 1802436
MD5 hash: f604c26ddaa13680a3278620c485212c
SHA1 hash: 7f3461882cfc8d40d2991131fda025a3bfa900f1

If you are wondering about the trustworthiness of this implementation, Sourceforge is generally a fairly safe reliable source, and this particular project is hosted by the GNU project, the same folks who provide the GNU utils for Linux, as well as GCC which is used to compile basically the entire Linux kernel and operating system. Since Linux is used for literally millions of e-commerce servers and desktop systems around the world, if you can’t trust GNU utils, you pretty much can’t trust anything.

Speaking of Linux, if you are running Linux the above .exe will not work except under wine, and there is no need to fiddle with that in most cases, since a native Linux openssl version will always be provided. One possible exception where Linux users might want to run the openssl.exe version provide in this package under wine would be if you need access to the IDEA cipher, as that IS provide in this package but is NOT provided in most Linux openssl implementations due to past licensing concerns.

To test openssl, you can simply open a terminal and type:

openssl version

It should respond with the version info (0.98)

Then create a quick test file with:

echo "this is a test" > file.in

Then to test encrypt that file type:

openssl enc -aes-128-cbc -e -in file.in -out file.out -k "my password"

Later, you can just replace file.in, file.out and “my password” as appropriate with the actual file names and pass phrase you want to use.

To decrypt just replace -e with -d and make sure that you list the encrypted file as the -in file.

So to decrypt the file.out created above:

openssl enc -aes-128-cbc -d -in file.out -out file.txt -k "my password"

If you now open ‘file.txt’ with a text editor it should be the same as the original file.in

Only a few cautions:
Openssl tries to open both it’s input and output files at the same time, so if you accidentally REVERSE the -in (which exists) and -out (which does not yet exist) Openssl will try to open the not-yet-existing file for input, and FAIL, but NOT BEFORE it opens the other file, your actual input file, FOR OUTPUT AND TRUNCATES IT TO ZERO LENGTH DESTROYING YOUR INPUT DATA. So either work with backup files or be VERY careful to get the -in and -out file names correct.

Another caution is that, absent the above accidental deletion mistake, openssl never deletes your input file, YOU HAVE TO DO THAT, and obviously, you will want to use some kind of secure shredder tool, but note that if your hard drive is not fully encrypted you will probably still be left vulnerable in any XP or later Windows version due to their used of a journaled NTFS file system.

With DOS and Win95/Win98 FAT and FAT32 file systems there is no journaling, so shredder programs work more reliably, but hard drives and thumb drives can also leave copies of your original plain text files accessible, due to automatic wear leveling and error control algorithms, over which you have no control. So ideally, if you really are concerned about security, sensitive data should never reside, even temporarily, on a drive that is not full-disk encrypted.

Also, when selecting passwords or passphrases, note that though Openssl does salt and hash your supplied -k password (which is good), it doesn’t iterate it (which is bad), so with only one simple MD5 hash cycle of ‘work’ associated with your password, it is susceptible to dictionary attacks if the pass-phrase is short or predictable. Bruce has some good advice about picking good non-dictionary-attackable passwords or pass phrases.

Fortunately, because openssl hashes the pass phrase, you can use arbitrarily long pass phrases (limited only by the command line buffer) so in general, if you use some easily memorable nonsense phrase, with goofy spelling and punctuation, at lest 30 characters long, you should be quite secure.

You may find alternate syntax examples on the web. This is because, to shorten the command line, openssl accepts some shortcut command syntax:

As a shortcut for the longer ‘enc’ syntax:

openssl enc -aes-128-cbc -e

You can use:

openssl aes-128-cbc -e

(note the missing enc command and ‘-‘ before the cipher definition)

You can also use this with the hash function commands:

openssl md5 file.in

will work as a shortcut for:

openssl dgst -md5 file.in

Sadly, this does NOT work for all modes, so to run a SHA512 hash you still must use:

openssl dgst -sha512 file.in

(also note the slight inconsistency in syntax, here since there is only ever one file for a hash, we don’t use -in before the file.in as we do with the ‘enc’ command)

Once you get past some minor quirks in syntax, openssl is a simple to use command line cryptographic tool that has strong, well vetted, technically correct cipher and hash implementations that you can utilize with just a few simple keystrokes.

In Windows OS’s from Win95 forward, openssl.exe should run perfectly as a standalone file right out of the box in any command prompt session, but for command line use in DOS it will require a 32 bit extender that it can recognize so it can use extended memory.