[pocketmoon66]

cool!


http://technology.newscientist.com/a...ine-news_rss20

[Davros]

yes but does it work in sli

[Simon F]

Originally Posted by pocketmoon66

cool!


http://technology.newscientist.com/a...ine-news_rss20

The solution to this is the make the password=>hash algorithm at least 25x slower, by putting in, say, 25 more iterations. It'd make no perceivable difference to the login procedure but make brute forcing less attractive.

[snowwhite]

Originally Posted by Simon F

The solution to this is the make the password=>hash algorithm at least 25x slower, by putting in, say, 25 more iterations. It'd make no perceivable difference to the login procedure but make brute forcing less attractive.

Usually in secure corporate environment, you can attempt to login limited number of times before your account gets locked (permanently or for certan perioid of time) For example in Active Directory based environment, login procedure goes as following:
-> Server sends random challenge key to client
-> Client sends user name and password hashed with the challenge to server
-> If hash matches, server sends auhtentication token to client
-> Client uses the token to authenticate itself when using shared resources

1) Password isn't stored on local computer
2) Hash changes per login attempt, so it can not be trivially calculated (hash as is, is usually considered as 'random')

Because hash is always random, chance to bruteforce password is next to nill -> social engineering works better.

Ordinary users who do not use server based authentication AND/OR store material on their local computer, are vulnerable no matter what kind of login check is performed, if hacker has access to the computer and is not intterrupted.

=> On secure environment, password strength does not effect on overall security that much (unless password is considered really weak). On vulnerable environment, higher password strength increases the system security, but overall security is still much less than on properly set environment.

[Simon F]

I presumed what we have here is an example where a password file (consisting of a list of the salt and hash of password+salt) has been acquired and "Mallory" is attempting to brute force the original passwords.

[DemoCoder]

Originally Posted by Simon F

The solution to this is the make the password=>hash algorithm at least 25x slower, by putting in, say, 25 more iterations. It'd make no perceivable difference to the login procedure but make brute forcing less attractive.

Adding more rounds doesn't neccessarily increase security. It depends on the attack. If they are brute forcing the entire keyspace (say, DES) then an infinite number of rounds won't do squat. (e.g. Unix crypt). If they are attacking a cryptographic hash function, there are attacks which reduce the search space for a collision regardless of the number of rounds, especially with MD5 which allows rainbow attacks using prefixes.

The way the hash function is used in large part also determines vulnerability. MD5 alone has been broken. But MD5 is usually used for HMAC, and HMAC-MD5 is still secure. In much the same way that DES with Salt is much more secure than DES.

[Mintmaster]

Originally Posted by Simon F

The solution to this is the make the password=>hash algorithm at least 25x slower, by putting in, say, 25 more iterations. It'd make no perceivable difference to the login procedure but make brute forcing less attractive.

Funny how cryptography is the complete opposite of real-world physical security. Here, a tiny change can increase the burden of breaking in by orders of magnitude.

[Simon F]

Originally Posted by DemoCoder

Adding more rounds doesn't neccessarily increase security. It depends on the attack. If they are brute forcing the entire keyspace (say, DES) then an infinite number of rounds won't do squat. (e.g. Unix crypt).

I beg to differ.

[DemoCoder]

Originally Posted by Simon F

I beg to differ.

In Feistel ciphers, the state operated on at each round is a fixed and a function of the previous rounds. For example, each round, DES operates on a 32-bit half-block plus 48-bit subkey. Therefore, even if you ran a nigh infinite number of rounds (say, 1 billion), all I have to do is start is search of a space of 2^(32+48) of all inputs and emulate the final round.

That is, you can't increase the security of DES past 2^80 by increasing the number of rounds. Thus, once I have computer power able to search that space in a reasonable time, increasing rounds does nothing. Practically speaking, even this search space can be slashed in many block ciphers. (Birthday attacks work pretty well, e.g. cut this down to ~2^40 for hash collisions)

Remember, I don't need to recover the plaintext password if my goal is to decrypt all of your ciphertexts, I can reduce any N round block cipher to a 1 round cipher in this way. Granted, 2^80 is pretty large, but my point is, there have been historical cases of algorithms where increasing key size or # of rounds led to no increase is resistance to attack.

Now for hash collision attacks, it doesn't work that way (final round brute force), but there have been some surprising tricks developed in recent years in this field. Practically everything but SHA-1 has been busted. If you want to defend against birthday attacks, you have to increase the search space, not the number of rounds. Making a hash 25x more expensive to computer practically speaking, isn't very secure, since it's not intractable to rent or buy 25x the computing power.

[Simon F]

Originally Posted by DemoCoder

In Feistel ciphers, the state operated on at each round is a fixed and a function of the previous rounds. For example, each round, DES operates on a 32-bit half-block plus 48-bit subkey.

Each of those 48-bit subkeys doesn't have to be a "linear" combination of the password+salt.

Remember, I don't need to recover the plaintext password if my goal is to decrypt all of your ciphertexts,

But if you are trying to obtain passwords from a stolen password file, then you aren't any better off.

[DemoCoder]

Originally Posted by Simon F

But if you are trying to obtain passwords from a stolen password file, then you aren't any better off.

Ahh, but in many cases, you have private keys stored in files which are encrypted with a block cipher (i.e. keyring files), wherein a ciphertext recovery yields all the keys.

Practically speaking, Unix password files just get you access to the computer in most cases, the data is usually left unencrypted (few people use file encryption) Therefore, if I was able to steal the unix shadow password file, I probably could already rootkit the system anyway.

There is far more practically in trying to unlock an encrypted PDF, ZIP, or DRM'ed file. So from a practical standpoint, making the login hash slower will do little for total system security. This was tried in the past with Unix, but most people didn't use stolen passwords, they simply used exploits to bypass authentication and go right to authorization.

[Simon F]

I don't think we are talking about the same things

[Novum]

Originally Posted by Davros

yes but does it work in sli

You can scale CUDA to any number of devices by just splitting the workload which should be no problem here. You can even use different GPUs in the same system. It doesn't depend on SLI.

[mhouston]

It's not quite that easy. CUDA doesn't split the load for you, you have to do that. And, if you code relies on synchronization across blocks, then you will have a harder time using multi-GPU. But, if you write straight data parallel code and you aren't scattering to memory needed by other GPUs, getting multiple GPUs working is generally not that hard.

[Novum]

Originally Posted by mhouston

It's not quite that easy. CUDA doesn't split the load for you, you have to do that.

I know (isn't that what I said?). But I don't see a problem here. Just divide the keyspace. No problem.