×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Brute-Force Password Cracking With GPUs

Soulskill posted more than 2 years ago | from the add-a-character-every-six-months dept.

Encryption 128

An anonymous reader writes "We all know that brute-force attacks with a CPU are slow, but GPUs are another story. Tom's Hardware has an interesting article up on WinZip and WinRAR encryption strength, where they attempt to crack passwords with Nvidia and AMD graphic cards. Some of their results are really fast — in the billions of passwords per second — and that's only with two GTX 570s!"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

128 comments

Umm... (1)

taktoa (1995544) | more than 2 years ago | (#36503708)

Didn't we hear about this a week or two ago?

Re:Umm... (1)

Jawnn (445279) | more than 2 years ago | (#36503744)

Yes, though not sure it was the Tom's Hardware article. Whatever - that GPU's are fast at brute-force password cracking or... mining BitCoins (There, I said it!), is not exactly news today.

Re:Umm... (1)

lennier1 (264730) | more than 2 years ago | (#36503748)

It's been known for quite some time, but apparently the one who submitted it and the editor who greenlit it didn't get the memo.

Re:Umm... (1)

Sulphur (1548251) | more than 2 years ago | (#36504074)

It's been known for quite some time, but apparently the one who submitted it and the editor who greenlit it didn't get the memo.

Did they crack the memo?

Re:Umm... (3, Informative)

amicusNYCL (1538833) | more than 2 years ago | (#36503876)

Even though it's a dupe, why are GPUs so much faster than CPUs at this? It doesn't seem like they have any more power, is the architecture that different from CPUs? Is it an issue where you can basically dedicate all resources (GPUs plus VRAM) to the one task?

Re:Umm... (1)

jgtg32a (1173373) | more than 2 years ago | (#36503922)

GPUs are massively parallel, and doing something straight forward as running a hash a few billion times works much better in parallel than serial.

Re:Umm... (1)

toadlife (301863) | more than 2 years ago | (#36503946)

I read somewhere else that GPUs are better at raw number crunching that general purpose CPUs, which makes them more efficient at cracking passwords.

Re:Umm... (1)

toadlife (301863) | more than 2 years ago | (#36503974)

And based on the replies you've gotten, maybe I read wrong?

Re:Umm... (0)

Anonymous Coward | more than 2 years ago | (#36504758)

Second option, no one cares about your posts

Re:Umm... (1)

Man Eating Duck (534479) | more than 2 years ago | (#36505658)

And based on the replies you've gotten, maybe I read wrong?

Depends on what types of number crunching you're doing. If every step depends on the previous step then you won't be able to exploit the hundreds of cores that makes up even a cheap GPU these days by running them in parallel. If, on the other hand, your task consists of subtasks which can be easily done simultaneously like password hashing (just send a separate password to be hashed to all cores at once) or n-body calculations you will experience huge speedups. If you do a lot of matrix (vector) operations the GPU is also very well suited as it contains specialised hardware for such tasks.

Each GPU unit is also a lot simpler than a general purpose CPU, which means that you may have to implement your algorithms in a less efficient way. So, it depends on the task :)

Re:Umm... (1, Insightful)

Anonymous Coward | more than 2 years ago | (#36503978)

Does anyone else remember the days when slashdot readers were technical? This discussion is fucking painful.

Re:Umm... (1)

toadlife (301863) | more than 2 years ago | (#36504038)

Does anyone else remember the days when slashdot readers were technical?

Nope. Been around since ~1997 too. Perhaps technical discussions went on here some time before that?

Re:Umm... (2)

petit_robert (1220082) | more than 2 years ago | (#36505856)

>Been around since ~1997 too. Perhaps technical discussions went on here some time before that?

I have read comments to the same effect in other discussions (can't find one at the moment).

I'll admit I noticed a sort of dilution of the technical level of late, but it may be the price to pay for popularity. I followed some very interesting discussions here, and recently.

Besides, who could follow high level technical discussions about so many subjects? For instance, the posts below yours, that quickly explain why GPUs are good at password cracking, are _good_ information for me.

Re:Umm... (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36504102)

Does anyone remember when you could come on this website and have a discussion on this website and learn about new concepts and ideas? Don't be so bitter, even you were a noob at some point in your life.

Re:Umm... (0)

Anonymous Coward | more than 2 years ago | (#36505132)

People do say that a lot, but it's really not especially accurate. It's really the parallelization.

Re:Umm... (5, Informative)

adonoman (624929) | more than 2 years ago | (#36504024)

CPUs and GPUs have very different focuses. A CPU is designed to take a single piece of data, run an operation on it, then grab a different piece of data, and run another operation on it. (There's a whole bunch of optimizations for running the same operation on different bits of data, and different operations on the same bit of data, but those are largely optimizations, and only apply to relatively small scales). A GPU is designed to take a butt-load (technical term) of data, and perform the same operation on all that data, followed by another operation on that same butt-load of data.

When you are cracking passwords, you have a bunch of potential passwords you want to try. On a CPU, you are stuck with hashing between 1 and maybe a dozen simultaneously. On a GPU, you could potentially run a few million simultaneously. Each step on the GPU would be slower, but your total output of hashed passwords would be much higher.

Re:Umm... (1)

amicusNYCL (1538833) | more than 2 years ago | (#36505380)

Thanks. Would the GPU have a single, multi-stage pipeline (with apparently a lot more stages than a CPU), or does it actually have multple pipelines? Or maybe just a ton of small cores? I'm confused about where the parallelity (technical term) actually gets implemented in the hardware.

Re:Umm... (1)

Anonymous Coward | more than 2 years ago | (#36506214)

Recent GPUs have hundreds of relatively simple cores. As you can see here [nvidia.co.uk].

Re:Umm... (3, Informative)

Anonymous Coward | more than 2 years ago | (#36504114)

GPUs are much more specialized than CPUs. CPUs can only do a few things in parallel depending on the number of cores available in the CPU chip (ie 4). GPUs have a magnitude more processing paths than CPUs, the GTX 570 mentioned has 480 cores. That's what's being leveraged here, it's not the resources or power, it's the number of parallel processing paths.

Slashdot has no credibility on this topic (1)

Anonymous Coward | more than 2 years ago | (#36503914)

Didn't we hear about this a week or two ago?

It was a slightly different entry in /.'s series on "passwords are dead! oh noes!", except it was on brute forcing hashed passwords. It makes the same fundamental mistake that comments on that post pointed out _repeatedly_.

This is on brute forcing data encrypted with a symmetric cipher whose key is derived from a password. Yes, if you naively translate the password into a key, you go from a 128 or 256-bit keyspace to about the size of the dictionary.

Crypto 101: if you're deriving a crypto key from a password, you either need to do many rounds of encryption or use a stretchable hash function to derive the actual key.

Passwords aren't dead. If you force the attacker to take seconds of time for each password, moderately complex passwords are still not breakable.

What we really need are crypto libraries that also use the GPU so that we're not at a disadvantage compared to the attackers. In a nutshell, we need our stretchable functions to be implemented in OpenCL.

Re:Slashdot has no credibility on this topic (0)

Anonymous Coward | more than 2 years ago | (#36504082)

The "on this topic" was unnecessary in your title.

Re:Umm... (2)

wintertargeter (2012914) | more than 2 years ago | (#36504168)

No. Zdnet used ighashgpu. That's a hash cracker. WinZip and WinRAR encyption is different because it's based on precomputed password hashes. It looks like TH used AccentZip and AccentWinRAR to decrypt passwords.All three programs are created by Ivan Golubev. His blog is full of posts on cryptography performance.

Bridge jumper paralyzed after landing on boat (-1)

Anonymous Coward | more than 2 years ago | (#36503722)

Two people suffered serious injuries in a boating accident Friday at 4 p.m. in Crystal Cove of Hamilton Lake, Indiana Conservation Officers said. Officers said a 17-year-old boy jumped off the north side of the Lane 280 bridge over Crystal Cove, approximately 30 feet above the of the water. At the same time a northbound boat being driven at idle speed by Lisa Wulff, 38, of Hicksville, Ohio, exited from under the bridge.

Re:Bridge jumper paralyzed after landing on boat (0)

Anonymous Coward | more than 2 years ago | (#36505522)

Further examination tells us that over 3000 people in China were taking a shit at the exact same time.

Coincidence?

I wonder (5, Funny)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#36503730)

If we throw enough GPUs at it, if we could detect dupes on Slashdot?

Re:I wonder (0)

Anonymous Coward | more than 2 years ago | (#36503806)

Not a chance. Slashdot has become king of reposting articles and being 3 days late on news that everyone else has broken.

Re:I wonder (0)

Anonymous Coward | more than 2 years ago | (#36504194)

Full disclosure: I lolled.

Re:I wonder (1)

jovius (974690) | more than 2 years ago | (#36505004)

More likely with enough GPU's they'll come up with perfect summaries.

Password hacking process could be used to create completely new content - even data like images. If you can make billions of attacks per second the amount of coherent information must eventually be high enough.

old news (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36503772)

this has been known since 2009....

Irrelevant (1)

Hatta (162192) | more than 2 years ago | (#36503794)

Zip and RAR encryption has never been trustworthy. Let me know when they can crack GPG.

WinRar question... (1)

MobileTatsu-NJG (946591) | more than 2 years ago | (#36503816)

I've been told before that WinRar's encryption wasn't much to crow about, but this article says it's 128-AES. So.. which is it? Is it fairly secure (provided it is used properly...) or does it still have a major weakness that makes it easy to get into?

Re:WinRar question... (0)

Anonymous Coward | more than 2 years ago | (#36504080)

The AES key can have 128 bits of entropy but if the password that generates that key only has four bits of entropy then it doesn't matter how awesome AES is.

Re:WinRar question... (1)

MobileTatsu-NJG (946591) | more than 2 years ago | (#36504182)

Right, but that's not what I'm asking. I'll be more specific: Is using WinRar with a 8+ character password reasonably secure or does it have another vulnerability that weakens it? This article suggests that it's pretty darned secure. BUT... this is a benchmark article, not a strength of security exercise.

Re:WinRar question... (0)

Anonymous Coward | more than 2 years ago | (#36505264)

WinRAR is quite secure, given a secure password. You probably remember hearing about the old Zip 2.0 encryption scheme, which is incredibly weak. WinRAR can open it, but doesn't use it by default.

This is why you use encryption programs... (3, Interesting)

mlts (1038732) | more than 2 years ago | (#36503820)

WinZIP and WinRAR have effective encryption, but one needs to have an effective passphrase with it.

Ideally, the best way to encrypt stuff is with not just a passphrase, either with random keyfile for symmetric encryption, or use public key crypto (although PK crypto has its own caveats). This way, there is no brute-forcable passphrase to guess, so an attacker has to deal with the complete keyspace of an encryption algorithm, and not just what people type in.

Re:This is why you use encryption programs... (0)

Anonymous Coward | more than 2 years ago | (#36503898)

And how do you keep the keyfile secure?

Genuine question... I know people suggest SSH'ing using keys... is that more secure than having a 1 second delay between login attempts, or a firewall that only accepts local LAN connections?

Yes people misuse passwords... but imagine someone uses passwords *correctly*.

Re:This is why you use encryption programs... (0)

Anonymous Coward | more than 2 years ago | (#36504056)

Security is multi-layered. Asking if one method is better than another suggests you could not or should not do as much as your access requirements allow.

But to answer your question, keyfiles, at least the openssh ones, allow you to password protect them. The advantage to this being the password itself is not sent over the wire.

Re:This is why you use encryption programs... (1)

chemicaldave (1776600) | more than 2 years ago | (#36503950)

I was under the impression that brute forcing did exactly that. They're not using a dictionary. They're taking advantage of the GPU processing power.

Re:This is why you use encryption programs... (1)

mlts (1038732) | more than 2 years ago | (#36504258)

There are multiple ways to brute force. One is just finding the known subset of the keyspace (what people can type in), and running scans through that. Another is using dictionaries (ye old Crack). Of course, using dictionaries, then scanning the keyspace is useful too.

Dictionaries are still useful even though people's passwords tend to more than just a word these days. A lot of people use two words and a character, so that is far more gussable than trying to just brute force every single option in a 10-12 character keyspace.

Re:This is why you use encryption programs... (2)

pathological liar (659969) | more than 2 years ago | (#36504332)

Typically bruteforcing refers to exhaustively searching a reduced dictionary... bruteforcing 62^8 (alphanumeric, mixed case, a reasonable metric for a 'decent' password) might be easier with a GPU investment, bruteforcing 256^32 (let's assume a 256bit keyspace) is not.

Re:This is why you use encryption programs... (1)

Rich0 (548339) | more than 2 years ago | (#36505338)

I think you meant 2^256 in your second example. Technically, bruteforcing that probably is easier with a GPU, kind of like how you can get to Alpha Centauri faster in a galleon than by walking.

Re:This is why you use encryption programs... (1)

Caratted (806506) | more than 2 years ago | (#36504418)

You probably mis-read the parent.

Brute force is synonymous with checking the keyspace against a dictionary.

Architecture allows for the GPU do to this much more quickly, with the correct software. It is, however, still checking against a dictionary. Parent mentions encrypting what has already been encrypted (note the use of the word symmetrical), so that you must crack the whole keyspace, as opposed to the area of the encrypted file that you know contains the reversible hash (or, as opposed to just getting a prompt you're allowed to guess at a limitless number of times).

Re:This is why you use encryption programs... (5, Informative)

Jahava (946858) | more than 2 years ago | (#36504488)

I was under the impression that brute forcing did exactly that. They're not using a dictionary. They're taking advantage of the GPU processing power.

For this kind of encryption, the archive password is converted into a key. This is done because remembering a large key is hard, but remembering a password is not.

However, this kind of conversion is not remotely secure. With around 70 typable characters ("a-z", "A-Z", "0-9", a few symbols, etc.) the number of possible keys for keylength l is around 70^l . If we use a secure crypto algorithm, say, AES-256, then we would encrypt the archive with a 256-bit key. Something that uses a password for encryption does so by permuting the password into a key, typically through some combination of hashing, concatenation, and salting. This process deterministically maps the relatively-small ASCII password space to a 256-bit key space. So even though you're using a secure-sized 256-bit key, there are still only (at most) 70^l possible keys, since each key must be generated from a password.

Now, with AES-256, there are 2^256 possible keys. While brute-forcing the 256-bit keyspace is considered hard (that works out to about 1 * 10^77 possible keys), brute-forcing the possible plaintext passwords that could have generated the key is significantly easier (a 10-character password has only 2 * 10^18 possibilities).

So back to what the OP said, while the crypto and keysize of the underlying cryptography are secure (in this example, AES-256), the keyspace is inherently limited since it has to be derived from a much-smaller set of passwords. The OP is spot-on ... if you really want to encrypt something securely, you have to use a much larger keyspace, which, in this case, means generating a complete 256-bit key rather than deriving one from an ASCII password. This article shows that password-derived keys are not secure.

Re:This is why you use encryption programs... (0)

Anonymous Coward | more than 2 years ago | (#36505046)

I don't know where your delusion of 70 "typable" keys comes from. Maybe from being egocentric, and thinking ASCII-only.
PROTIP: http://www.neo-layout.org/ [neo-layout.org]

Good luck scanning through way more Unicode key combinations

Also: what stops a hacker from trying out passwords on the keyfile instead of the encrypted file?

Re:This is why you use encryption programs... (2)

Jahava (946858) | more than 2 years ago | (#36505256)

I don't know where your delusion of 70 "typable" keys comes from. Maybe from being egocentric, and thinking ASCII-only. PROTIP: http://www.neo-layout.org/ [neo-layout.org]

Good luck scanning through way more Unicode key combinations

Also: what stops a hacker from trying out passwords on the keyfile instead of the encrypted file?

It's an example to demonstrate how much more limited the typable keyspace is than an unconstrained binary keyspace, nothing more. I think you're quite out of line throwing words like "egocentric" around because an arbitrary example used QWERTY/ASCII.

However, say you did have 1024 typable characters. A random 10-character password with such a keyboard layout would yield only about (at most) 1024 ^ 10 = possible combinations, still well short of the example binary keyspace.

We're getting a bit off-topic, but if anyone's interested, more information on a method of deriving keys from passwords can be found here [wikipedia.org]. Notice how part of the process cycles over and over again to increase the computing time required to exhaust the keyspace. If you cycle 10,000 times, the decryptor only has to perform 10,000 operations, but a brute-force technique has to perform 10,000 operations for every password attempt, greatly increasing the CPU time required for each attempt. This is an attempt to compensate for the different in keyspace sizes by increasing CPU time outside of the cryptographic algorithm.

Re:This is why you use encryption programs... (1)

Jahava (946858) | more than 2 years ago | (#36505274)

However, say you did have 1024 typable characters. A random 10-character password with such a keyboard layout would yield only about (at most) 1024 ^ 10 = possible combinations, still well short of the example binary keyspace.

And I fail at HTML... 1024 ^ 10 ~= 1 * 10^31.

Re:This is why you use encryption programs... (2, Informative)

Anonymous Coward | more than 2 years ago | (#36505272)

I find it strange that you discount using a longer passphrase without bothering to calculate how long it would need to be. Assuming 70 typeable characters, getting 2^256 possible keys only requires 256*ln(2)/ln(70) ~ 42 characters assuming an equal distribution. (english text actually has much less entropy than an ideal even distribution of characters, but we'll ignore that for the time being)

As an example, "This is a fourty two character passphrase!" is a fourty two character passphrase. It's not unreasonable to blind-type something like that into a password field for someone with a reasonable amount of typing skill.

The main trouble is that people get the idea that passwords should be as compact as possible. This is partially due to using the term "password" instead of "passphrase", and partly due to stupid, stupid systems which impose a maximum length limit on passwords.

Re:This is why you use encryption programs... (1)

zzsmirkzz (974536) | more than 2 years ago | (#36507254)

So even though you're using a secure-sized 256-bit key, there are still only (at most) 70^l possible keys, since each key must be generated from a password.

Maybe I'm just not thinking hard enough about this but it seems very trivial to me to create a password/passphrase hashing algorithm that wouldn't be limited as you defined. Yes, there may be about 70 possible characters that can be typed - but their placement in the password (1st, 4th or 17th character) can also used to increase the possible keyspace.

Additionally, the length of the key (256-bits) and the length of the passwords do not have to be identical - the password can be much longer and thus can have a greater keyspace. Meaning using password/phrases (or limiting access to typable characters) doesn't necessary limit the keyspace - it only may be for passwords under a certain length using a particular mapping algorithm.

Re:This is why you use encryption programs... (1)

BisexualPuppy (914772) | more than 2 years ago | (#36504304)

The passphrase is hashed, and uses effectively the whole bit range. Your passphrase can be 8bits long, the hash will be what the algorithm needs. This hash will then be used as the actual key.

So.... (0)

Anonymous Coward | more than 2 years ago | (#36503890)

Someone worked out how to scan a billion entries in a rainbow table per second using a GPU?

Re:So.... (1)

wintertargeter (2012914) | more than 2 years ago | (#36504290)

rainbow tables only work on unsalted passwords. These were used by microsoft for 'lan' style passwords. IIRC, vista and win7 don't use these. And if you use a 14 character password or longer, even windows xp disables the lan encryption. Your rainbow tables are effectively useless against aes-128, aes-256, and even des. They simply precompute password hashes, and generating the tables takes quite a long time. Using rainbow tables has nothing to do with gpu acceleration.

Can someone explain (-1)

Anonymous Coward | more than 2 years ago | (#36503968)

Why are GPUs faster in this application than CPUs? Is it just because they don't have the overhead of running the system taking up clock cycles or is there some sort of fundamental hardware/architecture difference that makes them better suited to this task?

Re:Can someone explain (1)

icebraining (1313345) | more than 2 years ago | (#36504624)

is there some sort of fundamental hardware/architecture difference that makes them better suited to this task?

This. GPUs have dozens of cores optimized for parallel computation.

Commonsense PW Acceptance Limits? (0)

BoRegardless (721219) | more than 2 years ago | (#36503982)

So why don't more systems lock you out after 3 tries for another 10 minutes or an hour?

That would deny brute force attacks.

Re:Commonsense PW Acceptance Limits? (1)

jonbryce (703250) | more than 2 years ago | (#36504138)

Not much use if you have a password protected .zip or .doc file as you aren't using WinZip or MS Word to check the password.

Re:Commonsense PW Acceptance Limits? (1)

Dog-Cow (21281) | more than 2 years ago | (#36504164)

The article (or even the summary) is not talking about repeatedly attempting to log in to a system. It's talking about encrypted files.

Re:Commonsense PW Acceptance Limits? (1)

wintercolby (1117427) | more than 2 years ago | (#36504232)

If they're brute forcing against a hash, attempts/failures is irrelevant. If they're brute forcing file encryption, once again, system lockout attempts are irrelevant unless it's integrated into the operating system.

Re:Commonsense PW Acceptance Limits? (0)

Anonymous Coward | more than 2 years ago | (#36504240)

Seriously? This only works when the data and authentication software is external to your own PC because there's a layer of security between you and the data. If you have a raw piece of data on your own PC there's nothing that can stop you brute forcing the password.

Re:Commonsense PW Acceptance Limits? (1)

vlm (69642) | more than 2 years ago | (#36504338)

So why don't more systems lock you out after 3 tries for another 10 minutes or an hour?

That would deny brute force attacks.

Copy the file of passwords to your local machine, then hash against that file using software than intentionally does not implement such a delay.

Heck if you have access to backups, or vmware images, or backups of vmware images, just copy and NOP out the delay code...

Re:Commonsense PW Acceptance Limits? (1)

NevarMore (248971) | more than 2 years ago | (#36504512)

How am I going to enforce that on an encrypted file possessed by someone who is trying to decrypt it against my wishes?

Why none of this matters! (2)

SirAstral (1349985) | more than 2 years ago | (#36504068)

For most intents and purposes this is not that news worthy. In order to get processing performance like this you need a system that can also answer billions of password guesses per second. So keeping it simple, you need to get said database, make it function on/in a system/environment that can handle and that will allow this much activity for all those guesses.

ergo, someone has to jack yo shit before they can start guessing your password which may be more difficult than just trying to guess that password leaving you back to square one where you will most likely do something OTHER than a brute force/dictionary password attack!

Re:Why none of this matters! (1)

wintertargeter (2012914) | more than 2 years ago | (#36504520)

Right... except that anyone who has a desktop gaming system can do what TH did. It's not like they had a supercomputer.

Makes you wonder about Bitcoin (0)

GoodNewsJimDotCom (2244874) | more than 2 years ago | (#36504106)

Do you want to mine for Bitcoin, and get .0001 Bitcoin per hour? Or do you want to mine Bitcoin passwords and possibly get tons of Bitcoin per hour? Seems all you need is people's login name who has a lot of Bitcoin. Oh and you have to be a thief, which precludes anyone who has morals.

Re:Makes you wonder about Bitcoin (0)

martok (7123) | more than 2 years ago | (#36504352)

Bitcoin currently has no passwords. If you get their wallet.dat, it's all over.

Re:Makes you wonder about Bitcoin (1)

DanTheManMS (1039636) | more than 2 years ago | (#36504416)

Exactly what accounts do you think you're cracking the passwords to? What login name are you referring to?

Why are GPUs faster? (1)

erroneus (253617) | more than 2 years ago | (#36504160)

I gotta ask why GPUs are faster? And because they are faster, why aren't CPUs using methods and techniques similar to GPUs for getting certain things done? I remember the days of the "math coprocessor" that the math processor was used to help speed things up by performing math on-chip rather than by using subroutines in software.

I was always under the impression that GPU means graphics processor unit, not "Guessing Passwords Unit."

Re:Why are GPUs faster? (1)

FooBarWidget (556006) | more than 2 years ago | (#36504280)

These days there are GPGPUs with GP standing for "General Purpose". They're not only used for displaying graphics anymore but for general-purpose vector calculations. GPUs are faster *for vector calculations* because most of the chip consists of arithmetic units. In return, GPUs are much, much worse at pretty much everything else, such as branching. Don't try to run if-statements on GPUs.

Re:Why are GPUs faster? (1)

Stavr0 (35032) | more than 2 years ago | (#36504314)

My naive interpretation of this: http://www.nvidia.com/object/GPU_Computing.html [nvidia.com]

In effect, having a good,recent GPU is the equivalent of having hundreds of CPUs all in one single chip. Since password guessing is a task that can be divided easily, the GPU is 100x faster than a regular CPU, and it is very efficient at number-crunching.

Re:Why are GPUs faster? (0)

Anonymous Coward | more than 2 years ago | (#36504368)

GPUs are stream processors [wikimedia.org]. They are really good at doing the exact same operation on lots of values at once. If you actually only wanted to do the operation on one piece of data, they are at least an order of magnitude slower. They are really bad at any variations based on data. If your algorithm has any control flow in it, it will probably not work well in a GPU. Also, GPUs work well only with very specific memory access patterns. Doing an operation to all of memory is fast. Doing an operation that requires jumping around memory based on data is slow.

GPUs definitely do seem to be becoming the next-generation math-coprocessor. AMD and Intel have both been working on multi-core chips with both CPU and GPU cores. Back in the old days, math coprocessors added the ability to do floating point operations in hardware. Now GPUs support doing operations involving lots of floating point numbers in hardware.

Re:Why are GPUs faster? (2, Informative)

JamesP (688957) | more than 2 years ago | (#36504412)

In layman terms: The CPU is like a truck, the GPU like a Ferrari

One goes faster, but can't run on all kinds of terrain (data)

Re:Why are GPUs faster? (5, Insightful)

TerranFury (726743) | more than 2 years ago | (#36505010)

More like, a GPU is a freight train moving at 15 MPH, a CPU is a Ferarri doing 120MPH, and you need to transport a warehouse of boxes across country.

Re:Why are GPUs faster? (1)

JamesP (688957) | more than 2 years ago | (#36505354)

This analogy works (if you think the GPU is around 500MHz/1GHz and the CPU is at 3GHz)

But I prefer the other way because for example, GPUs would probably suck at SQL, or parsing XML, whereas the CPU can just 'deals with it'

Of course, analogies are never perfect

Re:Why are GPUs faster? (1)

nospam007 (722110) | more than 2 years ago | (#36505062)

But the important thing. Did they crack the Wikileaks insurance file or not?

Re:Why are GPUs faster? (1)

JamesP (688957) | more than 2 years ago | (#36505402)

Since you don't know the plaintext, it's impossible, even by bruteforce

In the case of Zip, you know some metadata (like zip headers) and I guess it uses known data from file formats or checksums

One is AES->Zip->Data, wikileaks is AES->??

Re:Why are GPUs faster? (0)

Anonymous Coward | more than 2 years ago | (#36505102)

I think you got that backwards:

CPU is the ferrari, it is fast, but has a tiny trunk.
GPU is an 18-wheeler, goes just fine, but carries a ton of stuff with it.

GPUs do the same operation on tons of data simultaneously, it is what they were designed for. So even though each step is slower than with a CPU, they are doing that step on many simultaneous guesses, thus the throughput is greater.

Re:Why are GPUs faster? (2)

140Mandak262Jamuna (970587) | more than 2 years ago | (#36504462)

GPUs are not really that much faster. GPUs are essentially tiny CPUs with very limited, I mean extremely limited cache/register/instruction sets. And they throw in hundreds or even thousands of these together in a card. Essentially GPUs are large number of weak processors. Some problems are "embarrassingly parallel", painting a 3D scene on a 2D screen or testing a guess passwords of an encrypted file. Some other problems are quite parallel but you need to aggregate the data at the end, like multiplying a matrix by a vector. Some problems are very difficult to parallelize. Decomposing a mesh/grid of a 3D domain into million small tetrahedrons and hexahedrons is extremely difficult to parallelize.

It just so happens, guessing a password can be done by a relatively weak CPU and one can pack thousands of such weak CPUs in one card and buy it cheaply. That is all. Don't hold your breath waiting for GPU to solve the Navier-Stokes equation for the Large Eddy simulation with particle combustion anytime soon.

Re:Why are GPUs faster? (1)

Solandri (704621) | more than 2 years ago | (#36504470)

Cryptography is one of just a handful of embarrassingly parallel computing problems (3D graphics is the most notable one). For the vast majority of things people use computers for, a not-so-parallel general purpose CPU is better.

Re:Why are GPUs faster? (0)

Anonymous Coward | more than 2 years ago | (#36504498)

Its simple.

Lets say you want to add two numbers. But lets say that is all you do.

You do not need to dedicate silicon to say subtracting numbers.

Now also instead of doing 1 add at a time lets say you need to do 1000 adds at a time (fairly common with linear algebra and 3d type programs). A general purpose cpu would line up each one and do each add sequentially.

Lets say it takes 1 tick to add.

With a GPU you line up all 1000 adds to go and 1 tick later you have 1000 numbers added. With a regular CPU it took 1000 ticks. That is excluding overhead such as setting up the memory space and checks.

Now lets say you want to branch. The GPU can not do that very well. But a regular CPU it is easy as that sort of thing is built in and helps make your code size small and cache rates better. Some of the newer GPUs have branching (in the form of shaders which are just small program fragments).

For example the x86 arch has a bunch of singleton commands which do some of this sort of thing. Like you want to add 8 numbers together there is a single command for that. GPU's on the other hand have silicon setup to 200+ adds at once.

GPU like things are going into the CPU (MMX, SSE, etc). But there just is not the real estate for it on the scale a GPU does it. GPU's on the other hand are trying to solve a fairly narrow problem and have the real estate for it but lack other functionality that general purpose CPU has.

So to answer your question yes they are starting to do it and have been for several years. It is called SIMD. http://en.wikipedia.org/wiki/SIMD

Yes, yes... (1)

danielpublic (1920630) | more than 2 years ago | (#36504228)

"Omg, what am I going to do about my eight char password I use half across the Internets?"

Well...
One could print out a passwordcard [passwordcard.org].
Then one might start using passwordmaker [passwordmaker.org], to whatever phone/OS one fancy. By which time one (sh/c)ould check if ones passwords are long enough [lockdown.co.uk] and while this "one" is at it, have a look at these tricks [passwordmaker.org] from an almost "tl;dr-ish" list. Now, apply elbow grease and a bit of go figure. "Problem solved? Moving on?"

Oh, who am I kidding? Then all those (fear) mongering polemics would have to starve and we cant have that now can we? *fancifying tinfoilhat*

Re:Yes, yes... (1)

Bengie (1121981) | more than 2 years ago | (#36504550)

A 15 char pass phrase is much more secure than an 8 char password. All it takes is a nonsensical pass-phrase and a light peppering of special chars and no one could break it without having a few dedicated power plants to supply electricity to their GPU cluster.

$5 wrench would work better.

Real encryption (1)

martok (7123) | more than 2 years ago | (#36504282)

With the recent MTGox compromise, I've been looking at a better password system. It looks like one way to go is to use a program like password safe or keesafe to generate unique passwords per website. However, I'm curious as to how resistant these master files are to GPU attacks. GPUs basically sliced through the MTGox MD5 hashes like butter. How long would it take a higher-end distributed cluster to break a Password Safe master file? It's blowfish encrypted I believe.

another slashvertisement (0)

Anonymous Coward | more than 2 years ago | (#36504308)

yes this is a dupe, but when GPU companies selling cards for $600 etc start throwing around payoffs many sites answer. solution? dont buy cards over 100 bucks

video cards used to cost 30 bucks, until a few companies decided to charge more.
a sure sign this is astroturf designed to drum up sales? just read the tag.

"Some of their results are really fast — in the billions of passwords per second — and that's only with two GTX 570s!"

ORDER YOURS TODAY WHILE SUPPLIES LAST!!!

Re:another slashvertisement (1)

PitaBred (632671) | more than 2 years ago | (#36505972)

...really? Some of us play games on the GPUs, too. Or *gasp* do actual work with them! And the more expensive ones are faster. Because that's how technology works. No, not everyone needs an F1 car. Most people would be fine with a Corolla. And the cheaper cards generally give you much more value for your money. But if you can't see where some people would be more concerned about absolute performance than pure economy, then you're stupid.

This is not a slashvertisement. This is simply tech journalism. Or is Car & Driver just a big advertisement? Is ANY special-interest magazine or site "just an advertisement"?

7z (1)

Anonymous Coward | more than 2 years ago | (#36504372)

Which tool can crack 7zip passwords?

Relevance?! Which client/server can handle that?! (1)

G3ckoG33k (647276) | more than 2 years ago | (#36504374)

Where is the practical relevance?!

If done over a network I guess it would generate a kind of traffic no server could handle.

In forensics, yes. But where otherwise?!

Re:Relevance?! Which client/server can handle that (0)

Anonymous Coward | more than 2 years ago | (#36505042)

Cracking archive passwords; although as best I can tell those are primarily used only by spammers releasing fake warez.

Re:Relevance?! Which client/server can handle that (0)

Anonymous Coward | more than 2 years ago | (#36506526)

True, this is a case of one metric tested on a closed system being projected into the rest of networking and the internet. If you were to try this over an external connection, even that of a closed network, you will see those numbers drop off drastically. Adding a simple fix like limiting the number of log-on attempts in a time period stops this measure cold. It doesn't matter if you can cycle through 10,000 combinations in a second if the server locks you out after ten.

Password length matters (3, Informative)

pugugly (152978) | more than 2 years ago | (#36504764)

Things to remember - password difficulty is based on x^y, where x is the number of possible characters and y is the password length. Increasing password length is *always* going to be more effective than increasing the mix of characters (indeed the point of a dictionary attack is to reduce can be thought of as reducing 96^8 8 character passwords to a mere 250,000^1).

Each additional alphanumeric character increases the search space by a factor of 62 - a two word password is still only 250,000^2, a password of ten random lowercase characters is 26^10, a *much* larger number.

Moores law says processing power doubles ~18 months. Every new lowercase character extends life of your password almost 12 years before new hardware can decrypt it as quickly as today's hardware. 23 1/2 if you use upper and lowercase.

Don't panic.

Re:Password length matters (0)

Anonymous Coward | more than 2 years ago | (#36507272)

x is the number of possible characters or number of characters used in the password ?

eg both "1121" and "1357" are numeric passwords with the same character space. one has repeats, does it make it less secure?
an upper and lowercase that uses only lowercase chars, is it less secure than one using both?

I mean... (0)

Anonymous Coward | more than 2 years ago | (#36505902)

I think everyone should panic, they're taking over... and we're selling them to you.

http://www.ccny.com/

When's it going to be useful for me? (0)

Anonymous Coward | more than 2 years ago | (#36507258)

I'd like it to speed compile times.
I like Gentoo and all but I'd really like it if building the thing got faster.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...