Cracking PGP In the Cloud

pariax writes "So you wanna build your own massively distributed password cracking infrastructure? Electric Alchemy has published a writeup detailing their experiences cracking PGP ZIP archives using brute force computing power provided by Amazon EC2 and a distributed password cracker from Elcomsoft."

Comments

Distrubuted Computing

[Anonymous Coward]

If only they'd thought of using distributed computing for the first post, instead of password cracking!

And tons of carbon enter the air

[MillionthMonkey]

At least fold some proteins if you're going to do this. Or look for aliens.

Re:And tons of carbon enter the air

[HungryHobo]

I was under the impression that crypto like PGP was based on stuff which would (in theory) take millions of years to crack even with every machine on earth dedicated to it?

Re:And tons of carbon enter the air

[muckracer]

> I was under the impression that crypto like PGP was based on stuff which
> would (in theory) take millions of years to crack even with every machine on
> earth dedicated to it?

That's true if everything's equal. Including your passphrase. If the cipher
for encryption is 128-bit strong, then your password/passphrase needs to match
that. If it doesn't it's the weakest link, easier to attack than the actual
crypto algorithm and will take accordingly less time to crack.

Example: For a password composed only of lower-case a-z english characters,
you'd need 28 characters chosen in a true random fashion (think scrabble tiles
pulled out of a hat) to actually achieve a strength of 128-bit, that matches a
128-bit crypto or hash algorithm.
The strength of TFA 'sweetspot' passwords were somewhere around 60-bits.
Since even RC5 has been broken at 64-bits (distributed.net - though it took
some time), such passwords are OK for low-priority stuff but not, if say, the
NSA is after you ;-)

Re:And tons of carbon enter the air

[slim]

I was under the impression that crypto like PGP was based on stuff which would (in theory) take millions of years to crack even with every machine on earth dedicated to it?

Yes, but the search space is significantly lower if you assume an password that's 1-8 latin alphanumeric characters, as this exercise did.

It's still 122 days on 10 VMs. One tenth of that on 100VMs.

Re:And tons of carbon enter the air

[DNS-and-BIND]

Was that really your first thought on reading the headline? Sad how tainted people's minds are these days. Reminds me of the preacher who sees Satan's hand in everything or the policeman who is convinced that all teenagers are criminals. When your perspective is that skewed...jeez I don't know what to say.

Assuming I want to use some spare CPU cycles for some purpose or other, where should I apply to make sure it's OK? So far, we have protein folding and alien hunting as acceptable: what are some other uses of spare CPU that are acceptable and unacceptable?

Re:And tons of carbon enter the air

[noidentity]

[And tons of carbon enter the air] At least fold some proteins if you're going to do this. Or look for aliens.

How do you know they weren't cracking a PGP'd zip archive containing secret documents about alien protein folding technology?

Re:And tons of carbon enter the air

[Anonymous Coward]

I wonder why key strengthening is not used more, even '40-bit' passwords would be pretty tough to crack if each password took 1s to test.

Re:And tons of carbon enter the air

[buchner.johannes]

Schneier had an interesting piece on deriving a limit of the necessary key length from thermodynamics.
http://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html ... assuming your password is only bruteforce-able ... otherwise http://xkcd.com/538/

Re:And tons of carbon enter the air

[slim]

In this case, it sounds like the customer was pretty glad they'd used weak passwords.

The implication is that they'd locked some files up in an encrypted zip, forgotten the password, and wanted the contents back.

If they'd chosen a stronger key, they'd not have got their files back.

TFA:

This analysis may be insightful as you develop your enterprise password policies, or choose your personal passwords.

(A good password policy is: don't forget your passwords!)

Re:And tons of carbon enter the air

[psp]

you'd need 28 characters chosen in a true random fashion (think scrabble tiles
pulled out of a hat) to actually achieve a strength of 128-bit, that matches a
128-bit crypto or hash algorithm.

Scrabble tiles would be an exceptionally bad choice.

Re:And tons of carbon enter the air

[Anonymous Coward]

If the encryption software works as advertised, they would need the private key file to exploit this. So as long as you keep your private key file to yourself you should still be safe for a while.

Re:And tons of carbon enter the air

[Forthac4]

Sure, if your limiting it to 1 per second, but they can get into the hundreds of millions of passwords per second with GPU setups.

Re:And tons of carbon enter the air

[Torrance]

I'm also a bit confused. I've never used PGP to make an encrypted zip file, but I use GnuPG to encrypt emails all the time and I, too, was under the impression that it was infeasible in practice to brute force the encryption.

Is the difference that with PGP/GnuPG email encryption, our passwords are merely decrypting our keys which are themselves fully 128 or 256 bits long or whatever? Whereas in this situation with the ZIP file there was no separate key - the password was the key? (I haven't read all of TFA)

Re:And tons of carbon enter the air

[maxwell demon]

The company surely did have the private PGP key lying around. They just forgot the password.

As an analogy, think of a safe. A good safe is hard to break in if you don't have the key. If you have the key, it's quite easy. Now you fear that someone could break in your house, get the key and open your safe. Therefore you put the key for the big safe into another, smaller safe. If you need to open the big safe, you first open the small safe, take out the key of the big safe and then open that.

Now if you have lost the key for the small safe, and the small safe is less secure than the big safe, you'll certainly not crack the big safe, but just the small safe in order to get the key of the big safe.

Now, the key for the small safe is your password, and the key of the big safe is the PGP key. If someone has access to the small safe (the password-protected PGP key), then the security of whatever is in the big safe is certainly limited by the security of the small safe.

Now with emails, the point is that the big safe (the encrypted email) is out in the public, while the small safe (the password-protected PGP key) is in your home (i.e. on your computer, which hopefully itself has appropriate protection against intruders).

So the security of your PGP encrypted mail is limited by the combination of the security of your computer and the security of your PGP password. If your computer is basically unprotected, and your PGP password is weak, then anyone can read your encrypted mail by simply breaking into your computer, copying the private PGP key, and breaking the password. If your computer is well-secured, the attacker will have a hard time to get your private PGP key, and if you PGP password is strong, the attacker will have a hard time to break it if he manages to get the PGP private key.

Re:And tons of carbon enter the air

[SharpFang]

I thought the problem was that there was an infinite number of matching passphrases producing invalid results. Like, only a very simple hash or CRC - 1 or 2 bytes checks the validity of the passphrase to protect from common typos, but if you try even semi-hard, you will get a hash collision, the data decrypts, but it decrypts to garbage - a standard GIGO filter with a very weak anti-garbage protection on input.

This way, on top of one correct result you should get an infinite number of incorrect results and unless you have a clue how the correct result should look like and use some heuristics to distinguish it from garbage, you'll be no wiser than before... (and if it was additionally encrypted with anything that makes it look like white noise, there is simply no way to tell it apart from pure garbage.)

Re:And tons of carbon enter the air

[somersault]

Damnit, my password is all vowels again!

Re:And tons of carbon enter the air

[jargon82]

scrabble tiles pulled out of a hat is a bad example :)
They are not evenly distributed, so you'll have a higher occurrence of certain letters (namely the vowels and other common letters like s.)

Re:And tons of carbon enter the air

[jargon82]

and here is why (from wikipedia) English-language editions of Scrabble contain 100 letter tiles, in the following distribution: * 2 blank tiles (scoring 0 points)
* 1 point: E ×12, A ×9, I ×9, O ×8, N ×6, R ×6, T ×6, L ×4, S ×4, U ×4
* 2 points: D ×4, G ×3
* 3 points: B ×2, C ×2, M ×2, P ×2
* 4 points: F ×2, H ×2, V ×2, W ×2, Y ×2
* 5 points: K ×1
* 8 points: J ×1, X ×1
* 10 points: Q ×1, Z ×1

Re:And tons of carbon enter the air

[frozentier]

such passwords are OK for low-priority stuff but not, if say, the NSA is after you ;-)

If the NSA is after you, I would think the strength of your passwords is the least of your worries.

Re:And tons of carbon enter the air

[EIDETI]

Nope. Aliens use bittorrent.

Re:And tons of carbon enter the air

[VoidCrow]

To pick a trivial example.

Your password is 'password'.

Cracking algorithm attempts to open your encrypted archive using a list of, say, 20,000 english words. 'password' is 5th on the list. After 5 iterations, you notice that your decryption attempt has yielded data that looks like a valid zip archive, or contains english words. Result. You win the internets.

You can refine this.

1. Attempt a password list crack.
2. Attempt a Markov-chain based crack, looking for english-like words generated by your Markov Chain algorithm. Like, say. 'bibble' or 'foglet'. Tr
3. Repeat the above for all letter case combinations, and number/letter replacements - like B1bb7e, or f0Glet.

Et cetera,

The edge you have is that people often choose known words as passwords, or easy-to-remember nonsense words.

This reduces your password search space *hugely*.

For example, say your pgp doodad accepts up to 10 character passwords formed from any combination of letter case or number. 26 lowercase letter, 26 uppercase letters, 10 numbers. Your maximum search space would be the sum of all (26+26+10)^n, where n iterates from 1 to 10, or 853,058,371,866,181,866, or 8.5x10^17. This is the size of the set of all possible mixed case alphanumeric passwords up to a maximum length of 10. You would have to try each of these combinations to fully search this space. This is called 'brute forcing'.

It is a *much* larger number of passwords than the 20,000 in your dictionary list....

So, you use the search space limiting techniques *first*, which will yield a result in 95% of all cases. Then, you try brute force, or give up.

Re:And tons of carbon enter the air

[maxume]

Really, the set of scrabble tiles in a standard box is a bad example, it wouldn't be real hard to sort out 1 tile of each letter and use those 26 tiles to generate the password (placing the tiles back in the hat and shaking it a bit after each draw).

If we are going to split hairs, we might as well do it all the way.

Re:And tons of carbon enter the air

[muckracer]

> (from wikipedia) English-language editions of Scrabble contain 100 letter
> tiles

I meant using scrabble tiles in principle. So obviously 26 a-z
characters/tiles, not 100 with uneven and therefore non-random distribution. :-)

Re:And tons of carbon enter the air

[muckracer]

> If the encryption software works as advertised, they would need the private
> key file to exploit this.

You are confusing public key encryption (1 private key & 1 public key) with
conventional/symmetric encryption (gpg -c) where no separate key per se is
required. The encrypted file is all you have.

Re:And tons of carbon enter the air

[Provocateur]

Let's see, he already did some 'folding' in the bathroom, while browsing an old old issue of FHM, and
there were no aliens in his morning cereal (just spaceships in purply artificial grape flavor). Came
to work, punched in, and got started. Yup, on time, and right on schedule. boss.

Re:And tons of carbon enter the air

[Anonymous Coward]

scrabble tiles pulled out of a hat is a bad example :)

They are not evenly distributed, so you'll have a higher occurrence of certain letters (namely the vowels and other common letters like s.)

Unless of course you know not to do that and just use the 26 letters comprising the alphabet.

You could even generate a one time pad that way.

Re:And tons of carbon enter the air

[plover]

That's only a problem if you have no idea what the encrypted data might be. But in most reality-based cases, that's not the problem. You almost always have the clues you need.

In this case, for example, the file is a ZIP archive. That means the archive contains in the clear the original file names including any extensions, such as .jpeg, .bmp, .doc, .pdf, or whatever. All those file types have artifacts you can test for. They all have specific formats. They'll have version numbers, dimensions that must fall within reasonable boundaries, or other attributes that simply won't produce a coherent file unless they're correct.

For example, a JPEG image file is a container and is filled with markers identifying all the different sections. They all must be right or it won't display. So you'd start by looking for the SOI marker as the first byte of the file (0xffd8) or you'd throw it out. After the SOI you'd have to find another valid JPEG marker (two more bytes beginning with 0xFF.) So that's three bytes you'd have to match exactly, and the fourth byte would have to be on the list of valid markers. After you find the next marker, it'll probably be followed by a length (two or four more bytes). If that length is greater than your file size, it's a fail. Sure, if all that passes you'd have to decrypt more data to figure out if you're still in a valid file, but the chances are now only about 1 in 16 million keys tested. You then farm all these "potentials" to a machine or other process dedicated to deeper examination of the candidates.

If I were writing this, I'd have enough smarts in the key tester to look for all possibilities within the first blocksize of the cypher. Anything that looked reasonable at that point would be exported to the "evaluate potentials" system.

Every data file has its structure. You just have to look for it.

Re:And tons of carbon enter the air

[plover]

It wasn't carbon, but the fuel consumed that was my first thought. Back when distributed.net was busy burning energy to win these pointless challenges, I did some rough calculations on the electricity required to solve it.

Turns out that the energy spent breaking RC5-64 used somewhere between 2 and 50 *trains* full of coal.

And that was only the energy directly consumed by the computers involved, and not any of the heating or cooling costs associated with it. And sure, more modern CPUs are more energy efficient, and I extrapolated the figures from a lot of published sources and made a lot of assumptions. But regardless of CO2 or greenhouse gasses or dirty coal or any of that environmental stuff, that's a lot of irreplaceable fossil fuel that's now gone.

I don't think it's sad or tainted to consider the overall impact of what you do. Saying "oh, I want to help search for E.T." is one thing. It may cost you an extra 1440 kWh/day, but you have the money, no big deal. But understanding that SETI@HOME is causing tens of thousands of people around the globe to collectively burn tons of fuel every day might make some of the volunteers rethink their decision. Ignoring that is the kind of perspective that thoughtlessly sucks up our finite resources.

And no, I don't consider alien hunting a valuable use of energy, at least not at this time in our history. Once we have fusion reactors or some other form of "free energy", all that will change.

Go ahead and crack keys, search for Extra Terrestrials, or fold proteins, or whatever you want to do with your box. Leave your lights on 24x7. Run the furnace and the air conditioner together. Just understand that what you do today has an impact, and consider the value of the outcome.

Re:And tons of carbon enter the air

[bluefoxlucid]

You win the internets.

The Internets is full of furries, 4chan, and people having sex with dogs! I don't want this! Take it back!

Re:And tons of carbon enter the air

[omkhar]

That is just nonsense.

If the customer had used a proper PKI with key recovery/escrow this could have been avoided. The solution is NOT to make weak passwords so that you can crack them when you lose your passphrase. How on earth is this modded informative?!

Re:And tons of carbon enter the air

[MrMr]

No problem, I've got a monitor full with post-it notes. So my policy must be excellent.

Re:And tons of carbon enter the air

[MikeBabcock]

An irrelevant note I might add. All PGP/GPG encrypted data is symmetrically encrypted using a randomly generated key. It is only that resulting key that is then encrypted using the public key, for speed reasons.

The security of your data depends heavily on the random number source used for generating these session keys.

Re:And tons of carbon enter the air

[perzquixle]

This is called a known plain text attack. Most modern algorithms are hardened against this. So this technique wouldn't help unless the algorithm had a known weakness to this. But then again, maybe people still encrypt their archives using enigma machines these days. The world is a crazy place.

Re:And tons of carbon enter the air

[zippthorne]

If using a cloud, where you pay by CPU-Hour, wouldn't it make sense to use as many VMs as it takes to get it done in.. an hour? (if that many are available)

If I'm understanding right, there's no cost difference, but you get your results right away, instead of waiting half a year

Re:And tons of carbon enter the air

[muckracer]

> An irrelevant note I might add. All PGP/GPG encrypted data is symmetrically
> encrypted using a randomly generated key. It is only that resulting key that
> is then encrypted using the public key, for speed reasons.

Purely from method you're correct. But the distinction made prior between
public key and straight-symmetric is quite relevant to this discussion. If the
files were encrypted with public key encryption and the private key is lost,
you have no other choice but brute-force attacking the cipher with associated
cracking-time. Attacking the password is not even an option anymore, as
opposed to having the files symmetrically encrypted where you can still choose
between attacking the cipher or the passwords.

Re:And tons of carbon enter the air

[Anonymous Coward]

What's the carbon footprint of your post? Mine has fewer electrons that yours.

Re:And tons of carbon enter the air

[daveime]

I'd say pulling tiles out of a bag from a typical Scrabble set would be optimal to guessing a lot of passwords.

Ever wonder why the people who win at Hangman always pick E,T,A,I,O,N first ?

So why not reverse the distributions, so that lots of Q,W,X,Y are present, and only a handful of E,T,A,I,O,N, and use that to generate a random password ?

Re:And tons of carbon enter the air

[AlXtreme]

If using a cloud, where you pay by CPU-Hour, wouldn't it make sense to use as many VMs as it takes to get it done in.. an hour? (if that many are available)

If you can provision 30k CPUs, sure. As mentioned in the article this type of password cracking is trivially parallel.

Re:And tons of carbon enter the air

[daveime]

How about we all go back to living in the trees and eating coconuts ?

What is with this techno-guilt-trip lately ? Everything online now has to be weighed in terms of how much energy it is using ? Google datacenters, key cracking attempts, posts to Slashdot ? (Kind of ironic his post was tl;dr;, just think of the energy he could have saved if he'd been less verbose).

You want to do something concrete to save energy ? Turn down your aircon, stop driving that 5 litre SUV, invest in a set of solar panels for your house and get off the grid etc.

Don't try to pretend your making a contribution by saving a couple of milliwatts on CPU use. For every post made online, you already saved tons more energy in not producing newspapers, not burning gas so that some truck can deliver them to paper-shop, not even having a paper-shop consuming energy to stay open and sell you yor daily news.

Everything we do consumes energy, but these sensational claims about how much we could save if we used black screens and white text are nonsense. We already saved far more energy by being online in the first place.

Re:And tons of carbon enter the air

[zippthorne]

The problem is that people make the mistaken assumption that the easy-to-remember passwords have to be the same length as the ideal password.

It's true that nonsense words generated by markov chain do not use all of the bits available in their given output, but there is no need to limit pronounceable passwords to eight or ten characters. If they're easy enough to remember, you can go almost arbitrarily high.

A little back of the envelope calculation shows that adding characters on the end is almost linearly equivalent to adding characters to the depth, especially where your character depth is already greater than your password length.

I can tell you which one is easier to remember, though.

Re:And tons of carbon enter the air

[maxume]

Someone attacking a password they believe to be random isn't going to worry about English letter frequencies (adding duplicate symbols to the pool doesn't really increase it's randomness; think in terms of 'ab' vs 'aab' or 'aaaab', if I discover information about the pool you used, 'ab' is going to be 'more' resistant than the other two (in that it will take two guesses half of the time, instead of 1/3 or 1/5 of the time)).

Re:And tons of carbon enter the air

[muckracer]

> why not reverse the distributions, so that lots of Q,W,X,Y are present, and
> only a handful of E,T,A,I,O,N, and use that to generate a random password ?

When some characters have more chance to appear than others then it's by
definition more longer 'random'. Random is, when they all have equal chances
of being drawn, so you want 26 tiles, one per letter of the alphabet.

Re:And tons of carbon enter the air

[muckracer]

No longer 'random' I meant to say ;-)

Re:And tons of carbon enter the air

[TooMuchToDo]

Or even faster on 8000 VMs (8 cores * 1000 servers). Which a lot educational institutions have. Google "Rocks Clusters" and look for their cluster registrations.

Re:And tons of carbon enter the air

[Anonymous Coward]

If my power plant is burning any coal, something is very wrong.

Re:And tons of carbon enter the air

[Spazztastic]

No problem, I've got a monitor full with post-it notes. So my policy must be excellent.

I didn't know my old manager read Slashdot!

Re:And tons of carbon enter the air

[Anonymous Coward]

aying "oh, I want to help search for E.T." is one thing. It may cost you an extra 1440 kWh/day, but you have the money, no big deal. But understanding that SETI@HOME is causing tens of thousands of people around the globe to collectively burn tons of fuel every day might make some of the volunteers rethink their decision.

If your computer uses 1440 kWh/day = 1.4 MWh/day = 60kW, you ought to have a better use for it that SETI@home. My house, for example, has only 100A service, good for about 24 kW.

Turns out that the energy spent breaking RC5-64 used somewhere between 2 and 50 *trains* full of coal.

Except now we all think you have a factor of 1000 error in that estimate.

Re:And tons of carbon enter the air

[OldHawk777]

USB Flash - Linux-OS+Apps and 256b...1024b... random number generator ... plus..., anyone (I think) can have a very complex key-generator.

Isolated (air-gap) key-generator loads USB-flash drives, then sneaker distribution.... There may be other options... for information sharing, but (IMO) someone passing unbreakable encrypted files within an encrypted VPN, that is not a known business or government, would create a signature of interest on the W3. Governments have really good tools, and can domestically shutUdn (post hypothesis, evidence collection, and foundation...).

An old-school key-book, snail-mail, and postal-bulk camouflage, may be better, if you need to hide information.

Re:And tons of carbon enter the air

[Anonymous Psychopath]

In this case, it sounds like the customer was pretty glad they'd used weak passwords.

The implication is that they'd locked some files up in an encrypted zip, forgotten the password, and wanted the contents back.

If they'd chosen a stronger key, they'd not have got their files back.

TFA:

This analysis may be insightful as you develop your enterprise password policies, or choose your personal passwords.

(A good password policy is: don't forget your passwords!)

Alternatively, an disgruntled former employee may have refused to divulge the password. A third possibility is that this individual became unable to reveal the password through injury or death.

Re:And tons of carbon enter the air

[Anonymous Coward]

UGH.. can't.. understand.. lacks.. cars..

Re:And tons of carbon enter the air

[martin-sandsmark]

... but if you have a thermostat, you save in the 1440 kWh/day you would otherwise have spent on just warming up your apartment. Yay for thinking ovens.

Re:And tons of carbon enter the air

[MikeBabcock]

You used a lot of words to simply say "passwords chosen by humans are typically easier to crack than randomly generated ones."

Explicitly encrypting the file with symmetric encryption doesn't make anything any easier than using public key encryption, its the choice of symmetric key that matters (since one is used in both cases).

Re:And tons of carbon enter the air

[misterooga]

What if the content is hidden....say like 7zip encryption where file content can be hidden. Would it work then?

Re:And tons of carbon enter the air

[Anonymous Coward]

It's interesting to note that this would catch all but my strongest personal passwords. I tend to rely on english-like words.

Aside from swapping steps 2 and 3 (due to ease of implementation, and IMHO likeliness of being used by a victim) I would add three more steps:

Step 4: crack with minor (i.e. easily remembered) non-alphanumeric character additions. Up to now, "tits!" would foil this password algorithm. Coincidentally, this would also catch my strongest personal password.

Step 5: crack with geometric keyboard combinations. "qwerty" is probably in the dictionary attack, but there are many other rows, directions, and starting points to modifiy this, not to mention keyboard layouts.

Step 6: crack with knowledge of foreign languages, so it's not just english-like permutations. This would probably be non-trivial to implement, though extremely valuable if you're not targeting primarily english-speakers.

Re:And tons of carbon enter the air

[Anonymous Coward]

Isn't the point of altruistic distributed computing like folding@home or seti@home that the machines would be on anyway. Fans running, displays on, a/c going etc. Keeping the processor busy on a typical desktop machine isn't likely to add hugely to the power consumption is it? This is fuel that mostly was going to be burned anyway - why not get some useful information while we're at it?

Re:And tons of carbon enter the air

[Hucko]

Put the big safe in an expensive car, and the little safe in an old Holden. (Or use some American classic if you prefer.)

Re:And tons of carbon enter the air

[Hucko]

You want to do something concrete to save energy ? Turn down your aircon, stop driving that 5 litre SUV, invest in a set of solar panels for your house and get off the grid etc.

What do you do after you've don all that? And don't forget to count the energy used to make the solar panels. Feel guilty about that for at least 35 years. And how much energy does it take to generate one human baby? That has to count. And have you shaded your planet from the sun recently? It is throwing thousands of kilowatts at the earth every second! Get outside and cover as much as possible to keep it cool.

Re:And tons of carbon enter the air

[Anonymous Coward]

No.

Say that it takes 59 mins hours to find the password, if you pay for 10 vms, it will cost you 10 hours worth. If you pay for 1000s vms, it will still cost you 1000 hours worth, because you can't cancel them after they have done 59mins worth of work.

Re:And tons of carbon enter the air

[plover]

A "known plaintext attack" is a specific cryptographic technique where you use known plaintext material to help break the key. A very simple example might be a Caesar cypher where you know the word ROME is in the message. You could then try subtracting the values of ROME against the letters in the message BUUBD LSPNF, and you'd quickly find the last four letters where the differences are all -1,-1,-1,-1, thus the key is to shift each letter by one, yielding the message ATTACK ROME. Without the plaintext you'd have to solve the cypher the old fashioned way.

The ULTRA project who decrypted Enigma didn't use a known plaintext attack either. They couldn't reverse engineer the keys from the cribs they obtained. Instead, they used the cribs to solve a different problem (which happens to be the same problem I'm describing.) They had to put in "stop words" to get the bombes to mechanically stop spinning when they encountered a possible solution.

What I described is not a known plaintext attack. It is simply testing the output of the algorithm against possible solutions. No algorithm is hardened against this because this is the normal function of the cypher.

Re:And tons of carbon enter the air

[plover]

Nothing is an absolute in cryptography. You still have to make guesses as to when you hit upon the correct answer. And an adversary has every incentive to not make it easy for you.

But the adversary might be lazy, and let the tools do their jobs by default. When they decrypt their archive, they probably want to immediately use the results without going through a second deobfuscation step. Never discount the value of human nature and laziness -- they could save you tons of work.

As a cryptanalyst, you have to look for shortcuts. If I were given foo.7z and was told it was encrypted, I'd only have a few formats to try. It could be a bare 7z format (described here, or a compressed version. I'd have to figure out what possible artifacts I could look for in the decrypted file. But knowing it's in 7z format makes the job easier. (Of course, 7zip's key strengthening routine would not make it easier, as the key is encrypted 2^18 times!)

I'm not saying it's easy. There are thousands of file formats in common use out there. And I'd have only hope that the adversary is using one of them. But it's really not much different of a problem than "magic" already solves. And I could probably leverage a .magic file to help with the identification task.

Re:And tons of carbon enter the air

[plover]

The last time I measured the difference between an Athlon 2400 CPU sitting idle at a Windows explorer desktop (somewhere around 3% CPU usage) and the same CPU with its load peg at 100%, the difference was 60 Watts extra.

The reason I went looking was because I had installed distributed.net's cracker on one day, and the next when I went into the room I noticed that it was uncomfortably warmer than the previous day. So I used my battery backup's internal statistics to measure current draw, and I was very surprised to see the delta. I've since confirmed similar behavior with my latest desktop using a Kill-A-Watt, but I don't remember the exact numbers for load vs. idle.

Re:And tons of carbon enter the air

[plover]

Sorry, yes, I meant watt-hours, not kilowatt-hours. It was a think-o. I did the calculations several years ago, and I didn't bother to go look them up again when I posted this morning. It's probably time to redo them anyway, as CPUs are now much more energy efficient than they were back then.

The point is that the amount of fuel being burned to re-confirm a statistical theory was staggering. We knew it would take roughly X tests to crack a DES key, and it did. Proving it once was exciting. We knew it would take Y tests to crack an RC4-56 key, and it did. Proving that was somewhat less exciting. There was no point in burning up further fuel just to prove that we could crack an RC5-64 key in Z tests. Fine, we know it'll work, save the damn fuel.

Re:And tons of carbon enter the air

[plover]

Go back and reread what I said. "Consider the value of the outcome." That means you should make sure that what you're spending energy on is worth it, not that you shouldn't use energy.

I don't feel particularly guilty about consuming energy (certainly not enough to do anything more serious about it than to use mass transit.) But I seriously question the wisdom or validity to use energy to confirm that it's going to take roughly 50% of 2^72 tests to brute force the RC5-72 challenge. This after already proving that it took about 85% of 2^56 tests to brute force the RC5-56 challenge, and a similar percentage of 2^64 tests to brute force the RC5-64 challenge. It is an insane waste of energy.

At least SETI@home has the unknown factor that some people can believe in. Folding@home and the World Computing Grid may provide actual scientific or humanitarian benefits. Rendering WoW at 72 frames per second gives the player an immersive experience. All those offer benefits (or potential benefits) to one or more people.

So is cracking PGP providing a benefit? In TFA's case, yes, they're trying to recover some lost files for a client. For us to repeat the experience, just to prove we can copy their efforts to brute force a PGP passphrase? Sheer waste.

Imagine....

[Anonymous Coward]

Imagine a Beowulf cluster of those.

Pointless

[Kjella]

Yes obviously cracking passwords scales linearly, we've known that for a long time. Oh, you could get 100 machines brute forcing instead of one, but what good is that? Either the password is crap and you crack is easily, or it's helluva complex and scaling it up 100x won't do a damn thing. In this case it looks like they just picked some random range and said "Hey, this is unfeasible on a single machine and doable on a cloud, let's do that" but they haven't produced any credible evidence it is in this range. Not unless semi-complex password possibility matches their corporate password policy or whatever.

Re:Pointless

[Flibberdy]

It looks like they were cracking passwords which were 8 or less characters with simple Alphanumerics. In other words, weak passwords. While the cloud aspect makes it vaguely interesting, is it really news?

Re:Pointless

[Marcika]

Yes obviously cracking passwords scales linearly, we've known that for a long time. Oh, you could get 100 machines brute forcing instead of one, but what good is that? Either the password is crap and you crack is easily, or it's helluva complex and scaling it up 100x won't do a damn thing. In this case it looks like they just picked some random range and said "Hey, this is unfeasible on a single machine and doable on a cloud, let's do that" but they haven't produced any credible evidence it is in this range. Not unless semi-complex password possibility matches their corporate password policy or whatever.

It is significant because the lone hacker in his basement or the IT department of your unethical competitor might not have a spare server farm with 200 CPUs lying around. They show just how effortless it has become to do brute-force if you have a couple of minutes to set it up and a few spare bucks for the computing power... (And I bet that very few corporations have a password policy that mandates anything exceeding 8-char alphanumeric - which can be cracked for 45 bucks, as they show...)

Re:Pointless

[OverlordQ]

Even TFA story say to cover 50% of the keyspace for a length 12 password you're looking at $1.2M in EC2 fees.

Re:Pointless

[Pascal Sartoretti]

Either the password is crap and you crack is easily, or it's helluva complex and scaling it up 100x won't do a damn thing

Or maybe the password is apparently complex to the average user, but actually not so much. How would you classify "Hello123" or "Hottie69" ?

I am sure that there is plenty of money to be made with people who think that they are safe...

Re:Pointless

[TheLink]

It can only be cracked for 45 bucks if the attempt can be parallelized. Which is not always the case.

For example if the password is used for logging into a server, the admins will probably notice 100 amazon machines making brute force attempts, and if it takes seconds per try, that slows things down a lot. More so if the target server "falls over" or crashes in the process ;).

Re:Pointless

[wisty]

Yes, but what if they recover a hash of the password? It better be well salted ...

In reality, it wouldn't cost 45 bucks. A big botnet would do the heavy lifting, and crack millions of passwords at the same time. Ouch.

Re:Pointless

[jim.hansson]

every hacker worth ther salt [has|knows how to download] precomputed rainbow tables for so easy things, and it does not

Re:Pointless

[tokul]

PGP cracking is not about breaking passwords. They don't have private PGP keys. Crackers are trying to reconstruct zip file from encrypted data. PGP encrypted zip files are easy targets, because zip has checksums.

Re:Pointless

[SharpFang]

It isn't always true.

For a long time, Windows allowed pretty long samba passwords. Except it didn't make a hash from the whole password supplied, but sequenced it into 8-char pieces which it then hashed and concatenated the hashes.

In most cases, a 9-char password is some 96 times (number of printable characters) harder than an 8-char password, and 10-char password is 96 times harder than 9-char password and so on. In their case, a 16-char password was twice as hard as 8-char password, and a 10-char password was a simple sum of difficulty of an 8-char password and a 2-char one.

Of course if we're talking only about competent implementations, then it's a different matter...

Re:Pointless

[turing_m]

It looks like they were cracking passwords which were 8 or less characters with simple Alphanumerics. In other words, weak passwords.

If the guy whose file they are trying to crack uses a password manager, they're screwed. And with it being only trivially more difficult to use maximal passphrase lengths, combinations of uppercase, lowercase and numbers than it is not to, why not future proof yourself?

Of course, since you'll be typing the password for your password manager in all the time, you'd better be computing in a faraday cage if you have any Tempest capable adversaries (they would have to have found your password manager file though). And... at least backup your password manager file regularly. Otherwise the adversary you are fortifying against may well be yourself.

Re:Pointless

[gweihir]

Yes, but what if they recover a hash of the password? It better be well salted ...

Actually salting does not help against brute-force. It only helps against dictionary attacks.

However other things help, for example instead of running your password/phrase through a crypto-hash once, do it a million times or, say, for 100ms (store the number or iterations). This increases effort proportionally.

Example: SHA-256 does around 100MB/sec on a single modern CPU. That is roughly 3 million hashes/sec. Doing this for 0.1s gives no noticeable interactive delay, but increases the effort 300'000 fold, compared to a single hash iteration. With a 8 char a-z password (4.7 bits/char of entropy, i.e. a total of 37.6 bits), you will need on average 104*10^9 attempts. Each takes 0.1 sec and the EC2 cloud gives something like 8 modern cores for $0.3/h. That would be $7.8 Billion for brute-forcing the password.

See, 8 char a-z passwords are not so bad. The problem here is that the basic PGP design is rather old and these tricks were not used then.

Re:Pointless

[QuantumRiff]

I wonder if you can dump your rainbow tables to amazons simpleDB service? If I remember correctly, bandwidth between simpleDB and their virtual servers is free..

Re:Pointless

[blincoln]

Actually salting does not help against brute-force. It only helps against dictionary attacks.

It also helps against rainbow table attacks, which I believe the GP was referring to. Salting the hashes makes it much less feasible for someone to develop a rainbow table database, unless they are specifically targeting your system as opposed to every Windows instance on the planet.

Re:Pointless

[TheLink]

Normally if they can get the hash, they're in already... Cheaper ways of getting the actual password once you get to that point.

And the machine will join the botnet too ;).

Re:Pointless

[kalirion]

Heh, my password manager is all post-its. Let them get at that through the intertubes!

Re:Pointless

[sqlrob]

Once your webcam gets hacked, you're screwed.

Re:Pointless

[fbjon]

Didn't you hear? The Cloud is the new Internet.

1995: mail, shopping, and parallel computing.... on The Internet

2009: mail, shopping, and parallel computing .... in The Cloud

Re:Pointless

[tepples]

Example: SHA-256 does around 100MB/sec on a single modern CPU. That is roughly 3 million hashes/sec. Doing this for 0.1s gives no noticeable interactive delay

That depends on how many users expect to be able to start a session on your server at once, especially at the start of a work day or the start of home Internet prime time.

Re:Pointless

[Kjella]

It is significant because the lone hacker in his basement or the IT department of your unethical competitor might not have a spare server farm with 200 CPUs lying around.

No, they have a botnet with 10000...

Re:Pointless

[TooMuchToDo]

You dump the rainbow tables files into an EBS and have all your EC2 instances mount it. Cheaper.

Re:Pointless

[TooMuchToDo]

How much does it cost if I distribute the SHA256 generation to free workers running the BOINC client, and having the results pushed into SimpleDB with Amazon? Much cheaper.

Re:Pointless

[Korin43]

Ah but I'm one step ahead of you, my password is on a sticky note attached to the bottom of my webcam! Let's see them find it there!

Re:Pointless

[kalirion]

I won't believe this without pics.

Re:Pointless

[Fulcrum of Evil]

In most cases, a 9-char password is some 96 times (number of printable characters) harder than an 8-char password,

I'd believe 30 -40, but not 96. Most people are going to use letters and a small number of punctuation, and I'd wager that testing half of that will get you 90% of the possible choices. If it's just english words, I'll go with 16 as the multiplier, just given the info content of most english.

Re:Pointless

[Eivind]

The info-content of longer english texts is even lower. Just try zipping a plain ascii text to get an UPPER bound on the info-content. It's been estimated at 1.5 - 2 bits per character.

Wanna be careful

[aussie_a]

They will want to be careful or else they just might get arrested.

Re:Wanna be careful

[Anonymous Coward]

Just like what happened to Randal Schwartz.

In a word

[LizardKing]

So you wanna build your own massively distributed password cracking infrastructure?

No

Re:In a word

[ILuvRamen]

It's okay, I was just going to go add 3 more letters to all my zip file passwords and then you'd just end up pissed off. I wonder how long it'd take all those computers to calculate how stupid it is to try and crack the typical 31 character password that I use for all my zip files.

Re:In a word

[sootman]

I would have been more impressed if they had cracked a password using Mechanical Turk.

They should be discussing bits

[skangas]

They are only talking about "characters" in a password, which is a bit dubious. The important information is how many bits long the password provides. For a discussion on this see, for example: http://world.std.com/~reinhold/dicewarefaq.html#howlong For this reason and others, I'll take their "report" with a grain

Re:They should be discussing bits

[slim]

No, they've been approached by a client who's forgotten the password they used. The client's told them they used 1-8 alphanumerics in the password.

In this case, the mapping to a binary key is irrelevant to the size of the brute forcing task.

All communications securely encrypted

[Frans Faase]

One of the adversized features of ElcomSoft Distributed Password Recovery is that all network communications between password recovery clients and the server are securely encrypted. How is that possible, I wonder.

Re:All communications securely encrypted

[slim]

One of the adversized features of ElcomSoft Distributed Password Recovery is that all network communications between password recovery clients and the server are securely encrypted. How is that possible, I wonder.

SSL would do. There's no real magic going on in that network conversation. "Try passwords 'alphabet' through to 'backgammon' and tell me when you're done".

Re:All communications securely encrypted

[Frans Faase]

But SSL is based on the same kind of encryption methods that the system is aimed at breaking. Hence the word 'secure' no longer applies.

Re:All communications securely encrypted

[Abcd1234]

Noooo... their system is built to brute-force passwords. That has basically nothing at all to do with cracking an SSL session.

See, SSL uses asymmetric encryption to generate a large-ish session key between two parties, which can then be used in conjunction with a symmetric cipher to protect the session. So, while brute-forcing passwords is really just a matter of throwing hardware at the problem, brute-forcing an SSL session key likely requires more energy than is available in the known universe, which means you're forced to find a weakness in the cipher that you can exploit to reduce the computational complexity of the problem.

Re:All communications securely encrypted

[Anonymous Coward]

But SSL is based on the same kind of encryption methods that the system is aimed at breaking.

No, it isn't. How does running through all combinations of n characters relate to factoring prime numbers efficiently?

Re:All communications securely encrypted

[daveime]

Factoring prime numbers is easy. For prime P, the factors are 1 and P.

I think you meant to say "factoring the product of two prime numbers".

Bottom Line: Use Long, Unusual Passwords

[Constantin]

First of all, the article is a very nice summary of the issues involved with setting up a cloud to crack passwords - the nuts and bolts, if you will. I liked that the authors took the time to look into the economics of trying to crack passwords, how much money it would cost vs. how long it would take. Password cracking is one example of massively scalable computing, which is presumably why the NSA allegedly has had to keep upgrading the electrical infrastructure at their headquarters. Elcomsoft certainly made a splash with their PGP-cracking software and managing to harness the power of cheap GPU cards (which are set up for parallel processing) was a bit of genius. That said, even massive horsepower runs into a brick wall once the passphrases become long and the encryption algorithm is good.

On page 2 of the article, the authors nicely summarize the cost of cracking longer and longer passwords. Once passwords start incorporating special characters (per SPEC), the cost shoots sky high even for relatively short passwords (i.e. $10MM+ for a 9 character password, $1BN for a 10-character password, the US national debt for a 12-character password). The article so clearly lays out why the various law enforcement agencies have been focusing on being able to force folk to disclose their encryption keys. The cost of cracking a well-executed encryption scheme combined with a good password is simply too high. So, go ahead and use those special characters, upper and lowercase, etc. to make life interesting for would-be snoops. But realize that unless trends in privacy rights swing the other way, law enforcement will simply compel key disclosure, as they have for years in the UK, for example.

Lastly, the article underscores the value of keychain-type schemes that allow many long passphrases to be stored in a accessible format. Make it easy to have long, complex passphrases and it becomes more likely that people will actually use them.

Re:Bottom Line: Use Long, Unusual Passwords

[Anonymous Coward]

Passwords are protected in the US by the fifth amendment, for now...

The UK is a different story, though you can always claim to have forgotten your password.

Perhaps an interesting set up would be having 2 computers on separate power supplies running full disk encryption. Each can only boot by requesting a keyfile from the other.

Hence you can shut one down, but when both go down, the two systems become unbootable.

In a police seizure, they will likely disconnect both computers, and unbeknownst to them, completely destroy their chances of recovering the data.

Now no one can compel you to surrender the decryption keys, which can be a good thing or a bad thing. I leave you to think about the de facto punishment courts can issue for contempt.

Re:Bottom Line: Use Long, Unusual Passwords

[Anonymous Coward]

I use Diceware for all my obscenely long password needs

Re:Bottom Line: Use Long, Unusual Passwords

[Anonymous Coward]

The UK is a different story, though you can always claim to have forgotten your password.

No, you cannot do this. It is treated as admitting guilt under the criminal justice act.

Re:Bottom Line: Use Long, Unusual Passwords

[dissy]

Password cracking is one example of massively scalable computing, which is presumably why the NSA allegedly has had to keep upgrading the electrical infrastructure at their headquarters.

Naa, the current state of the art is in Rainbow tables, which lets you do the brute force method once ahead of time, then reuse those generated tables to crack literally any password covered by that table in seconds.

If your system only allows ASCII characters (255 different values per character) and lets say 256 characters max in your password, you can setup and generate a rainbow table that matches using the same hashing method.

At that point, throwing any hash (any hash that will allow one to actually login that is) into the table, and plaintext pops out in seconds. Rinse and repeat for the entire password file.

Generating the rainbow tables does take a lot of time, and is a great example where distributed processing greatly speeds things up.
The NSA already has access to such computing resources however and can generate said tables in a much quicker time than any of us most likely can. The generation process only needs done once per hashing method as well.

Brute forcing hashes in real time on an as-needed basis is so 90s ;}

Re:Bottom Line: Use Long, Unusual Passwords

[Anonymous Coward]

You should look up "salting hashes" and see why Rainbow tables are useless.

Re:Bottom Line: Use Long, Unusual Passwords

[R2.0]

"On page 2 of the article, the authors nicely summarize the cost of cracking longer and longer passwords. Once passwords start incorporating special characters (per SPEC), the cost shoots sky high even for relatively short passwords (i.e. $10MM+ for a 9 character password, $1BN for a 10-character password, the US national debt for a 12-character password)."

Ok, here's a question. Does the benefit of special characters in passwords derive from their actual use or in the expansion of the possible character set? If the possible character set includes the special characters, must they then be used in order to gain the advantage?

I ask because I always thought that "formula's" for strong passwords actually weakened them. First, because of human factors - make it too complex and everyone defaults to "Password-1", "Password-2", etc. But second, if the rules narrow down the possible contents of a password, doesn't that make it easier to crack? For instance, my current favorite is "Minimum X, maximum Y characters, must have an upper case, lower case, number, and symbol" So now the potential solution includes those rules as well - for instance, in a password X characters long, the maximum number of lower case letters is X-3. Doesn't that make the solution easier than if the character choice is wide open? I'm not trying to be a smartass, just increasing my knowledge.

Re:Bottom Line: Use Long, Unusual Passwords

[houghi]

The idea is good if you only have 1 login and password. However I and I asume many others have a multitude of logins and passwords. I access systems from different systems with different Operating Systems and different software.

Many logins and some passwords are not ones I can select myself. And then I am not even talking about the need to change passwords every month. (Some think that 30 days is a good idea.) So every first of the month I am changing as much passwords as I can, so I don't need to remember them all.

Obviously I forget some along the way.

Complex passwords? The more complex they must be, the more post-it notes I see on screens where I work.

I just checked and for my work I have 20 differnt logins and passwords that I did not made myself and where I have no influence on the login or the password. This due to many of them being third parties or shared ones with others. And now three devices that I need to type something in.

Sure it is very bad. It is however the situation I am in and I can imagine that I am not alone there.

Re:Bottom Line: Use Long, Unusual Passwords

[dissy]

You should look up "salting hashes" and see why Rainbow tables are useless.

So for the bulk of systems that do not salt hashes, why exactly are rainbow tables useless?

Re:Bottom Line: Use Long, Unusual Passwords

[zippthorne]

What systems aren't salting hashes any more?

Re:Bottom Line: Use Long, Unusual Passwords

[zindorsky]

Wrong. Dead wrong.
Reason 1: Rainbow tables only work when the cryptosystem doesn't use salt (or uses it incorrectly). These days everyone uses salt. It's not a big secret.
Reason 2: Even if salt wasn't used, Rainbow tables aren't feasible against long passwords. Rainbow tables are essentially just saving the results of one attack and using them on subsequent attacks. If the password in question is long enough, even the "one attack" (table precomputations) will never get to that password.

So, educate yourself. Rainbows tables are not some kind of magic crypto attack. They are very limited in scope. These days pretty much all they're good for is Windows passwords and old 40-bit MS Office documents. Definitely not PGP.

Re:Bottom Line: Use Long, Unusual Passwords

[fbjon]

Take a look at the rainbow table you described. ASCII and length 256? That's 256^256, i.e. huge. Even if you restrict yourself to a modest subset of 70 characters (easily typable), and no more than 10 characters in length (too short in many cases), you need to store about 2.8 * 10^18 passwords. Just the MD5 hashes for a table like that would take up over 40000 petabyte.

Re:Bottom Line: Use Long, Unusual Passwords

[gknoy]

Does the benefit of special characters in passwords derive from their actual use or in the expansion of the possible character set? If the possible character set includes the special characters, must they then be used in order to gain the advantage?

If one is going to crack passwords, one may need to (eventually) test the key space. If your passphrase is in the "easy" part of the key space (such as if you don't use special characters), it will be found very early on. So, yes -- you must use special characters (and not in a prescribed pattern) in order to put your key in the larger portion of the key space.

( (easy to crack) ........... hard to crack ...... )

One can think of the key space as a Venn diagram. If your key falls in the "easy" to crack space, it's much more vulnerable than if it's in the hard to crack space. As someone mentioned above, though, you really needto ensure the passphrase was random: if you're just replacing some letters in words with numbers, that will be crackable by a Markov chaining attack.

We can also look at our key space in terms of what tactic can be used to crack it:

( ( (easy: dictionary attack) ... medium: Markov chaining attack ) .... hard: brute force attack )

Re:Bottom Line: Use Long, Unusual Passwords

[arminw]

with a rubber hose or electric shock decryption key used on the owner of the password

Re:Bottom Line: Use Long, Unusual Passwords

[neurovish]

How many CPUs are in the latest botnet? Their Elcomsoft license was limited to 100 hosts. If they had 500,000, then it would take......about 20 seconds for their 8 character mixed up password?

Re:Bottom Line: Use Long, Unusual Passwords

[R2.0]

So there seems to be a bit of human factors here as well - "Assume that the user will use the least complex combination, and check that first". Correct?

Re:Bottom Line: Use Long, Unusual Passwords

[cenc]

What about other languages?

We all talk about brute forcing English, and the ASCII space. The English language and the alphabet are fairly limited.

What about say Chinese characters or Greek? Basically, are there other natural languages that are harder to crack when used as passwords? Chinese for example has better than 50,000 characters by some estimates (less than 3,000 are commonly recognized and used).

Re:Bottom Line: Use Long, Unusual Passwords

[vaporland]

Elcomsoft makes good cracking software - I've paid for and used their MS Office tools, and they work great on easy and even hard passwords. People are just not going to use 72 character passwords with ampersands and asterisks. I'd say this new cloud cracking tech will be put to effective nefarious use pretty quickly.

Re:Bottom Line: Use Long, Unusual Passwords

[gknoy]

Exactly -- much like, if one were to try to break into someone's house, one would first check the doorknob, then look for a key-hider, and then look for unlocked windows. ;)

Interesting but misleading

[Anonymous Coward]

People who would try to hack your password probably will not use Amazon's EC2, but something far more trivial, such as a botnet. Botnets are free, all you need is some time.

This is why I wouldn't think that 11-12 character bound has any meaning in practice. A more meaningful boundary is the one which can not possibly be cracked in reasonable time with a big computer network, regardless of the cost of operating it.

I use a composite password approach that gives a best balance between security and ease of use: use a good random generator for say 16 characters. Print it. This is not your password yet. You will come up with a few easy to remember, but hard to guess transforms, such as inserting several characters in a place only you know, using the printed sequence in a different order than linear left-to-right, and replacing all instances of printed "a" with "3" for example.

This ensures brute-forcing over the network will not be possible, as your password is truly random, and long. Finding the list would not lead to instant hack either as there's still reasonable information withheld from what's printed. You can also frequently change the "seed", the random characters you print, and apply the same rules you remember from before, to arrive at a completely new password, without having to remember anything new.

Can't you snoop on this ?

[absolovon]

If you are cracking through the cloud, then you are also vulnerable, and someone can use your efforts to get into the system before you...

Re:Can't you snoop on this ?

[slim]

Only if your communications with the cloud are in the clear. Why would they be?

new UBUNTU 9.10 distro HARBORING MALWARE !!

[Anonymous Coward]

Cracked big time !!

http://www.theregister.co.uk/2009/11/03/karmic_koala_frustration/?malware

If you're lucky install fails. If not, you are a fucking zombie !!

In other news

[Anonymous Coward]

Elcomsoft has been charged with conspiracy, aiding and abetting computer intrusion and wire fraud.

http://www.wired.com/threatlevel/2009/11/derengel/

Windows, yuck

[hey]

What chore that they need to use Windows. For a brute force password guesser, most Slashdotters could write it in 10 lines of perl.

Re:Windows, yuck

[rvw]

What chore that they need to use Windows. For a brute force password guesser, most Slashdotters could write it in 10 lines of perl.

I think ten lines of Perl would be the ideal password somehow.

Re:Windows, yuck

[Anonymous Coward]

What chore that they need to use Windows. For a brute force password guesser, most Slashdotters could write it in 10 lines of perl.

I think ten lines of Perl would be the ideal password somehow.

You'd never be able to remember the correct way to type it....

Hmm

[ShooterNeo]

I have an idea : how about a self destructing key? There would be a physical USB key that would have your passphrases on it. The passphrases would be quite lengthy strings of randomly generated characters, effectively un-forcable unless there's a massive weakness in the encryption algorithm.

The key would have a small CPU and lithium ion battery. All the components would be potted in epoxy, and you would be able to put an outer shell around the key resembling a common brand of USB stick.

In order to use the key, you'd have to enter a small password to unlock it. If the key has not been used in roughly 2 weeks of real time, it erases the passphrase from itself.

So if you get arrested or compeled to give up your password, you just have to keep silent for a couple weeks. Then, it's gone!

Re:Hmm

[jonwil]

The best solution (if you are dealing with a desktop system) is to have the pass-phrase and keys but also have a small GPS module. If the usb key is not close to where it should be (with a fairly big margin for the fact that cheap GPS modules arent exactly accurate) it would erase the pass-phrase

If they try to force you to hand over your password (e.g. UK RIP act), you just hand it over (to the guys who seized your computer and are now trying to use it somewhere else other than the required GPS location) and boom, the data is gone forever.

If you need to move house, just log in from the old house and reset the GPS then when you get to the new house, log in and put in the new coordinates.

Re:Hmm

[ickleberry]

falsifying the coordinates wouldn't be hard. serial port + null modem => fake GPS data and the password still works.

Re:Hmm

[jonwil]

The best answer of all is "physical seganography" i.e. 802.11 NAS built into something that the cops are unlikely to seize (yet which has a legitimate need to be plugged in and doing what it does)

Re:Hmm

[Sir_Lewk]

It seems like every time someone comes up with a new "unbreakable security scheme" on slashdot their pitch always starts with something to the effect of "so we start with this USB key...". Such measures are more about physical security, than crypto security. All you are really saying is "good long keys are more secure", which everyone already knows.

I might as well say, "Well if I light my computer on fire (and use longer keys) then ninjas won't be able to steal it".

Re:Hmm

[jwdb]

Unfortunately, GPS receivers don't work very well indoors...
Or in a valley...
Or under tree cover...
Or in many other places where you'd still need it to work for this scheme. No signal has to equal bad signal, because otherwise it's trivial to subvert.

I think the idea of a self destructing key is a good one, though. Maybe two sticks, both containing keys, both of which self destruct if separated by more than 10 m. Or maybe a usb key and something distinctly not-computer-related (fountain pen?), so that you can give both to the cops with assurances that they'll end up in separate locations.

I've always wanted to make a bike lock like that - a receiver and lock tuned to a transmitter in my wallet that automatically locks if there is no signal or the distance to transmitter is too great. I'm afraid to build it, however, because I'll likely end up superman-ing over my handlebars the first time the battery fails (locked has to be the default state or it's useless).

Same problem with this USB stick - the first time you forget and stick it into your friend's computer to show him "cool stuff", whoops there goes your key. You have to weigh the cost of your data being compromised by law enforcement vs it being lost by mistake.

Re:Hmm

[Anonymous Coward]

Basically an OpenPGP Card with an internal timer?

Use a bot net rather

[Anonymous Coward]

Much more horse power and it don't cost you anything. Thank god for windoze lusers.

uggboots

[Anonymous Coward]

Eric, thanks for such a great post- I really enjoyed it, actually reading this

I have been really interested in this topic .
girl ugg

Not the way of doing it

[julesh]

I looked at EC2 for raw processing power earlier this year (my company needs to train a lot of neural nets) and it just isn't worth it, unless you only need the power short term. A high-performance EC2 node gives you 8 cores running at (very roughly) the equivalent of a 2GHz P4, and costs $0.68/hr == about $460 per month, which is only a little less than what an equivalent box (probably a 2.83GHz Core 2 Quad or similar) would cost you. Put power to run that box down at about $0.05 per hour and you can build your own local cluster of equivalent performance for around the same amount of money as you'll save in your first month and a half of operation.

Re:Not the way of doing it

[gweihir]

I looked at EC2 for raw processing power earlier this year (my company needs to train a lot of neural nets) and it just isn't worth it, unless you only need the power short term. A high-performance EC2 node gives you 8 cores running at (very roughly) the equivalent of a 2GHz P4, and costs $0.68/hr == about $460 per month, which is only a little less than what an equivalent box (probably a 2.83GHz Core 2 Quad or similar) would cost you. Put power to run that box down at about $0.05 per hour and you can build your own local cluster of equivalent performance for around the same amount of money as you'll save in your first month and a half of operation.

Indeed. EC2 is rather expensive for most applications. It really only pays off if you may need a lot of power on short notice (but usually need none). The article describes one of the very few general applications. There is also the problem that even EC2 only scales so far. You would probably not get the cores to do a 12 char password in parallel. In addition, EC2 has problems like confidentiality and data transfer also costs money. And you have no control over how reliable and available the resources are.

Having done a (small) bit of high-performance computing myself, I believe the most cost effective way is to get some bright people that do understand current computer hardware and your problem, and then have them get the hardware they think does the job best, preferably of the white box variant. I went so far to get components, because having a student assemble them got me something like 20% more cores for the same money and exactly the hardware I wanted. Never had serious issues in several years with the resulting infrastructure.

Re:Not the way of doing it

[Slashdot Parent]

Don't forget other cosets: cooling, system administration, datacenter space, backups, racks, switches, KVMs, UPSs, network administration, maintenance, etc.

No question EC2 is expensive if you plan on fully-utilizing that hardware. But that's why it's called the Elastic Compute Cloud, not the Static Compute Cloud. If your computational needs are static, EC2 is most definitely the wrong tool for the job.

Re:Not the way of doing it

[Slashdot Parent]

EC2 is rather expensive for most applications. It really only pays off if you may need a lot of power on short notice (but usually need none). The article describes one of the very few general applications.

I think most people don't realize just how often they need a lot (or even a little) computing power on short notice. Once you get used to that way of thinking, it's a little addictive. By way of example:

I host one of my company's websites on Dreamhost. Am I insane? Dreamhost experiences an outage every few months or so. Incompatible with a business application, right?

Wrong. I have an EC2 bundle with a startup script that automatically configures the instance and fails the IP address over. If my company's website is ever down for more than 2 minutes, a failover is triggered. The website on EC2 takes about 2 minutes to come up, so my maximum downtime is 5 minutes or so. That's an acceptable amount of downtime for my application, a brochureware site that displays vacant apartments and accepts rental applications (several hours, naturally, would be unacceptable).

EC2 as a cold spare saves me money. If I had to use a reliable webhost, it would cost me, what, $50/mo? Dreamhost costs $5, and I probably use about $5-$10/yr in EC2 charges for the cost spare. Based on the above assumptions (I have no idea what a reliable webhost costs these days), EC2 saves me roughly $530/yr.

What another example? A client of mine has a deployment process where they first deploy to a staging environment before production. Because the production environment has a clustered DB and clustered app server, their staging environment has 2 DB nodes and 2 web nodes. That's 4 machines that see roughly 50 hours of use per year. Not efficient at all.

We considered VMware, but they didn't have the admin expertise in-house, and I forget what the license cost was, but that was an issue, too. In addition, they could not do load testing because they didn't have enough boxes to replicate the production system architecture. Enter EC2.

Now, they spin up as many EC2 instances as they need for whatever testing scenario they need. 4 instances for application staging, and 15 for load testing, at a cost of a fraction of one of their staging boxes that sat idle 99.9% of the time.

Like I said, the concept that you can have a virtual box whenever you need it and then throw it away when you're done is very addicting. I find it to be extremely convenient.

Re:Not the way of doing it

[b0bby]

it just isn't worth it, unless you only need the power short term

But as they said, they only needed it short term. It was more effective to just rent the 100 instances to get the cracking done reasonably quickly, since the client had no need for extra machines once the job was done.

Re:Not the way of doing it

[Peter Mork]

When building your own system, you need to purchase enough hardware to cover your peak load. As a result, you have to buy more hardware than you usually need. Since I'm on the road, I don't have my paper archives accessible, but I think that average utilization tends to run at around 10%. When you use EC2, you only need to pay for peak hardware when you need the peak hardware. Thus, in our studies, EC2 tends to be cheaper for small/medium organizations (unless your workload is extremely stable). (I think there are serious limitations with cloud computing, which you can read in our JBI article: "Cloud Computing: A New Business Paradigm for Biomedical Information Sharing," but cost is not the main issue.)

Re:Not the way of doing it

[gweihir]

Valid other examples. The lesson here is that you need to be aware that "the cloud" can be far more expensive. It is pretty cheap as spare infrastrucure, and for time-limited rare tasks. It is not the right thing for a reasonably loaded infrastructure.

Re:Not the way of doing it

[julesh]

If I had to use a reliable webhost, it would cost me, what, $50/mo?

There are plenty of reliable hosts that cost much less than that. Even here in the UK, where hosting is generally more expensive than in the US, I only pay £15/month (about $25) for a virtual machine with root access. If I was willing to live without root, I could get it for £10. I've had less than an hour of downtime over the last year. I don't know how reliable dreamhost is, but I'd say this system is certainly reliable enough for the application you describe.

We considered VMware, but they didn't have the admin expertise in-house, and I forget what the license cost was, but that was an issue, too.

The license cost of vmware server 2 is $0. Sure, the more advanced system (vmware infrastructure) can get expensive, but I doubt there'd be much point with such a small cluster.

Re:Not the way of doing it

[Slashdot Parent]

I've had less than an hour of downtime over the last year. I don't know how reliable dreamhost is, but I'd say this system is certainly reliable enough for the application you describe.

I'm very happy for you, but as we like to say in business, "Past Performance is No Guarantee of Future Results". Even bytemark will tell you this. Look at this from their SLA:

It is the customer’s responsibility to ensure that the consequences of any such failure are foreseen, and a suitable backup plan in place where there may be financial consequences of a failure. Bytemark will always advise the customer on contingencies to the best of our abilities.

What that says to me is that Bytemark will do their best to keep your services up and running, and by your review, they do a good job of it, but Bytemark does not have any failover procedure in place if their datacenter goes offline.

Think a datacenter can't go offline? A reasonably well-respected US host had a fire last year that brought their Houston datacenter offline for 2 days. Thousands of servers and god knows how many websites were brought down.

What would happen to your $25/mo VPS if Bytemark were to experience a similar situation? Do you really think you'd be back up and running in an hour? If I read their SLA correctly, the most you can expect from Bytemark if such an emergency happened would be 1 month's hosting fees. Would £15 be enough for you to cover the damage caused by 2 days' downtime?

For my application, I am perfectly fine with 5 minutes' downtime. 2 days, however, is not acceptable. I won't dispute that Bytemark is infinitely more reliable than Dreamhost. However, you should realize that you are at risk for a protracted outage and you don't appear to have a contingency plan.

If that is OK for your application, then the above shouldn't pose a problem for you. For my application, it is not acceptable, so I have a failover procedure in place.

Frist psOt?

[Anonymous Coward]

to download the with the number BSD fanatics? I'7e To this. For to stick something Join in especially ASSOCIATION OF Current core were everything else

Less geeky solution

[dazedNconfuzed]

A much less geeky/costly solution than using a GPS-integrated self-destruct mechanism is: ...have two passwords. One decrypts the data, the other erases it.

Actually, some ATMs have a similar ability: your PIN lets you access your bank account, while entering your PIN backwards does the same thing but calls the cops at the same time. If you're mugged at the ATM and forced to reveal your PIN, you give/use it backwards to notify police while the perp is busy emptying your savings.

Re:Less geeky solution

[Anonymous Coward]

Can we get a "-1 Wrong" moderation option?

Funny sig considering your post. Look, first thing; the authorities aren't stupid. The first thing they do is mirror your data, then test the passphrase you give them on the mirrored data. When your phassphrase deletes the data, they still have a copy backed up, and now you've bought yourself a prison sentence, or worse.

As to entering your ATM passphrase backward, that doesn't work anywhere. Some guy tried to make it a standard, but the authorities, noticing immediately all the problems with it, choose not to implement it anywhere. If you think you're right, and want to prove me wrong, go to Snopes and look it up.

Re:Less geeky solution

[Anonymous Coward]

According to snopes, the reverse pin alert was an idea, patented in the 90s, that was never implemented.

Re:Less geeky solution

[bluesatin]

My PIN is 2662, you insensitive clod!

Re:Less geeky solution

[Blapto]

Are you sure about this entering your PIN backwards trick? The only real reference I can find is a 6 year old article: http://www.msnbc.msn.com/id/4086277/ and they imply that it's possible but nobody has implemented it. Any other searching just throws up snopes like sites debunking it as a hoax.

Re:Less geeky solution

[Anonymous Coward]

Personally I've never heard of this, and you think if it's an anti-mugging/protection setup it would be more well known or published by your bank. Have you actually tried this, as it seems like an urban legend to me.

Re:Less geeky solution

[Anonymous Coward]

Actually, some ATMs have a similar ability: your PIN lets you access your bank account, while entering your PIN backwards does the same thing but calls the cops at the same time. If you're mugged at the ATM and forced to reveal your PIN, you give/use it backwards to notify police while the perp is busy emptying your savings.

What happens if your PIN is a palindromic number?

Re:Less geeky solution

[Anonymous Coward]

So, what happens if my pin number is 1331? Does it always call the cops?

Re:Less geeky solution

[jonwil]

Except that they cant GET at the pass phrase on the special USB stick until you give them the password.

DDR

[mac1235]

Sounds like someone was doing 'Difficult Data Retrieval'

But did it work

[Anonymous Coward]

FTA, they mention that Amazon didn't allow them to create more than 9 instances, so they couldn't crack the passwords in less than 122 days. (a request to get suitable amounts of computing power was made, but takes time, is not enabled by default, and wasn't available at the time of writing?)

Dear Sir,Thank you for submitting your request to increase your Amazon EC2 limit. It is our intention to meet your needs. We will review your case and contact you within 3 - 5 business days.

Re:But did it work

[Anonymous Coward]

Looks like the story was updated: [UPDATE 3 NOV 09: Amazon responded with a request for 'more information'. However, our friends at Sensepost demonstrated a creative way to bypass this limit using Python scripts at Blackhat 2009.]

That's no moon...

[Anonymous Coward]

what if we covered the moon with graphics cards?
i bet we could break any password then, huh guys

Wow, no imagination, huh?

[zippthorne]

You take one of each letter, put it them in a bag, jiggle the bag and pull out a single tile. Drop the tile back in the bag and repeat.

You can even get 52 characters out of it: if your thumb covers the letter when you draw it out, capital. If it covers the blank side, lowercase.

#IRC.TROLLTALK.COM

[Anonymous Coward]

base for FreeBSD

The article has no conclusion

[Anonymous Coward]

They never say that they actually found the password?

Or how long it took?

Are they still looking for it?

I read both pages and found no conclusion whatsoever.

CyberLocator and/or GeoCodex?

[Anonymous Coward]

There was a group called CyberLocator trying to do some authentication and geo/time stamping around GPS and a citadel model, though originally as an regional authentication scheme for online casinos, using raw GPS signal information and not calculated results, as part of the passphrase. They had some patents and stuff on it. Their authentication server had to have at least 3 of the same satellites in view to see the raw signal variances in the radio waves, which are apparently available on many but not all GPS chips. Because of time issues, it's substantially harder to fake your position information along with the regular secure passphrase transfer. I was able to track down one of the founders by following the casino related VC trail a few years ago when I was doing a project for work, but they probably went bust not long after and the patents got sold to the four winds. Good idea, I guess the marketing and associated costs weren't that hot.

There was a related thing called GeoCodex for doing location related encryption/geo-encryption, but that's either gone black or went bust. That too seemed to be a well executed idea, but things just didn't fall into place.