Re:Would be 100 million as fast as hashcat claims
on
eBay Compromised
·
· Score: 1
Hmmm... I got my performance stats from a different web site. But the performance table on oclHashcat's fron page says 11231M c/s for SHA256. That's eleven billion a second, admittedly using 8 GPUs, but in the ballpark of my original post.
If crypt is iterating SHA256 110,000 times, that sounds fairly good. I've been looking at scrypt, which is explicitly designed to resist hardware based attacks.
Well, I would dispute those calculations a bit, but I accept that good long per-account salting forces each password to be cracked individually. I assume that the salt is compromised along with the password (or they won't be cracked at all).
Even randomly selected passwords from all alphanumeric characters only gives us about 6 bits of entropy per character. Most passwords are shorter than 10 characters, the average is more like 7. This only gives us 42 bits of entropy per password, assuming complete random selection from that space.
But - users don't randomly select from that space, and modern password crackers don't simply try all possible letter permutations, although they can successfully do this for passwords which are less than 7 characters. They exploit the patterns and techniques which users use to select passwords, using rules engines, password dictionaries, markov chains and all sorts of clever magic.
Run this on GPUs using hashcat, which for SHA256 can check about 3 billion hashes a second. A small cluster of 4 of these machines can then easily check over 10 billion hashes a second. You can now rent Amazon EC2 instances with GPUs. In a minute you can check 600 billion hashes, admittedly for a single password at a time.
Salted hashes are now crackable even for quite reasonable passwords, if the hash algorithm can be run on modern GPUs, and assuming the attacker has the salt as well.
Re:Hash algorithm? Static salt like eBay Japan?
on
eBay Compromised
·
· Score: 1
It's not particularly the strength of the hash that worries me, it's the speed of it. If they're using something like SHA256 - strong, but fast - then I'd be worried.
Good point. I checked out http://www.stroustrup.com/appl... and I can see they're mostly all quite demanding applications. I guess they deserve a demanding language:) But yes, fair enough. There are plenty of times getting the most out of what you have is going to be important.
I once worked on Java code which ran on the most ludicrously limited hardware. It was like treacle. I spent a lot of time tuning that code. Logging was the worst offendor, but some poor algorithms lurked in there too. Garbage collection was quite noticeable, even after rewriting to minimise it as much as possible.
Yes, I can see that sort of code would benefit a lot. Not an area I've done much work in, but I guess a lot of people are. I'm actually really interested in code that performs well - I spend quite a lot of time profiling and tuning. Some of the things Martin Thomson has done in Java land are pretty cool. Check out http://lmax-exchange.github.io... and http://mechanical-sympathy.blo...
Sure, resource handling in C++ is one of the examples I do give of the sheer power and beauty of what you can do with the language. I used it extensively even back then. I also remember some of the issues I encountered in passing them around safely were a big lesson in the complexities, pitfalls (and opportunities) that lurk in the language. It was enormous fun, but I think I've probably been more effective in less demanding languages.
I had the most fun ever with C++ back when the original story ran. But it was too complex, too big and yet lacking standard ways of doing really very common things. Every library took a different approach. No standard libraries to do pretty much anything you wanted to in the real world. And it was always possible to shoot both feet off at once while doing something you thought was obvious and/or designed to make your code safer. Incredibly slow to compile. Compilers never supported the full C++ spec, or supported different bits of it on different platforms.
The trouble is, I can't see any compelling reason to use it for anything much these days. Maybe the latest C++ is better - but given what I know of the language I suspect the main criticisms I have of it must be still valid.
Use cases where you need that insane low level of power and control while retaining a high level language syntax are not common at all.
Can anyone give an example of where C++ really shines these days over other languages?
Without the salts, the hashes are essentially uncrackable, if the salts aren't incredibly short. So don't waste your time trying to crack these.
Salts are not secrets. They are usually stored right alongside the account details in the password database.
If your solution is to make the salt secret, you're not using salts anymore. Per-account salts protect against pre-computation attacks and do not need to remain secret to provide this protection. They are a cheap and effective defense for this purpose.
If you want to keep your salts secret, they are technically called "keys", and are expensive and difficult to manage securely.
The software running on the POS is completely known and controlled. In a big organisation there are lots of them, so you want to be able to update over the network. Updates are tested and bundled with any whitelist updates required. It's the perfect environment for whitelisting.
I'm curious why think it won't work on a POS with remote updates?
I attended a conference on XML back in roughly 2004. A police technical architect was describing the ANPR system. He pointed out that the current deployments of the time were entirely local and not joined up nationally - but went on to say that it wasn't a very big step to do this, allowing the tracking of vehicle movements on a national scale. He looked embarrassed and uncomfortable as he said this.
I got the very strong impression at the time that he was trying to give a warning on where this technology was heading.
I'm no expert on id-based encryption, although I can just about understand how it works. It has some attractive properties as well as some serious downsides.
Pros:
* An encryptor can pick a public key at random for a recipient known to the decrypting authority.
* No prior arrangement is required except for knowledge of the public parameters of the authority, and a recipient to send a message to.
Cons:
* The private key of the recipient can be calculated at any time by the decrypting authority.
* The recipient must authenticate to the decrypting authority to receive the private key for the sender-chosen public key.
* All messages in the past and in the future can always be decrypted by the decrypting authority at any time.
* You have to trust this authority absolutely.
The fact that the private key can be calculated from the public key and the master secrets is actually a pro as well as a con. This is what lets the sender choose a public key of their choosing with no prior arrangement.
I've seen this work quite well in one setting - payment messages from secure pin entry devices to the payment processor. In this case, the payment processor can decrypt all payment messages at any time, but each message is sent using a different key for each transaction, chosen by the low power pin entry device, and requiring no interaction between them and the processor.
On reflection, it's probably not a good candidate for inclusion into a protocol that would replace TLS. I can't really see how it provides anything useful in that setting. Still, it was just an example of some of the cool ideas being realised in more modern cryptography:)
Well, I can't really make out what you're proposing here.
As far as I can see, the client side has three secrets to maintain - the GUID, master password and salt. If the GUID is unique to a computer, your accounts only work from a single machine, and if you lose the GUID then you lose access to all your accounts. Correct?
The nonce is a "number used once" - i.e. randomly generated for each session in a cryptographically sound way.... so how do the server and client negotiate the nonce for each session? Does one pick it and encrypt it to send to the other? Do they both participate in picking it? Do they use something like Diffie-Hellman to arrive at the value?
I really don't understand your point about changing the salt equals changing your logins without affecting your password. Do you mean if I wanted to lose access to all my accounts everywhere and begin again, I wouldn't have to change my password?
And... how do you know you're talking to the right server in the first place? I don't see any server authentication at all in your proposal.
That's enough for now. The one thing I've learned from studying protocols is that it's really, really hard to get right. Not because the people creating them are dumb or have malicious intent. It may well be time to start creating a new protocol to replace TLS eventually, using what we now know about trust, authenticated encryption, protecting the handshake and side channel attacks. And possibly using some new techniques in there, like identity-based encryption...
Don't worry - you won't get anywhere close, but I guarantee you will learn a lot.
Start by trying to define what you are protecting from whom, and how two arbitrary endpoints who have never met can know they are talking to each other and not a man in the middle.
A belief in GW is entirely compatible with having a beach front house. The problem is that it is slow moving but inexorable.
Personally, I'm with the vast, vast majority of scientists who claim it's real and extremely dangerous. From what I've seen of the human race, we won't do anything until we get badly burned.
I guess everyone will know for sure one way or the other in a few decades. I just hope we can live with it.
I thought we already covered this in the linux rdrand story. It's called unauditable because it whitens the raw entropy output using encryption on chip, making even quite non-random source data appear to be random. It is not called unauditable because it's a black box design. The paper states that the design is very well known.
The attack described in this paper is to modify both the entropy source output "c" and the post-processing encryption key "K", undetectably setting a fraction of them to constant bit values. This weakens the effective random number generation to some chosen n bits of entropy, instead of 128 bits. But because the AES encryption post-processing stage does a very good job of making its output appear random, it will still pass random number tests.
If we had access to the raw entropy source, we could see that it was not providing nearly enough entropy to the encryption post-processing stage.
Interesting. I once managed a very bright and young developer, whose coding was exceptional. He was very often (but not always) right. But he was also rude and completely lacking in any social graces. And it wasn't enough that he was right - he also made everyone else feel stupid and frustrated.
I had to find solo projects for him, as the rest of the team ended up flat out refusing to work with him - and I didn't blame them.
I believe one of the issues with this instruction as a source of random numbers is that the instruction whitens the output with no access to the raw entropy data. Any physical process that acts as an entropy source will have some (possibly small) biases - it won't necessarily appear to be completely random in particular ways.
This can be audited to see that the output conforms to the physical processes which are described.
If the instruction whitens the output through some algorithmic transform (e.g. hashing) to give apparently random numbers as output, there is no way to distinguish that from say encrypting a counter with a secret key - whose output will also appear to be random - but is trivially crackable if you know the secret key.
So it becomes an exercise in trust in Intel, rather than something which an be independently verified. There was a good comment on the cryptography mailing list about this - that it would be better to have hardware entropy sources, leaving the final steps of random number generation to software.
I guess the point the OP was making is that the remaining crime may become more violent. But I agree that a lot of opportunistic crime would essentially disappear.
If you want to cite human rights, your personal right to travel doesn't trump my right to be reasonably safe from hurtling lumps of metal driven by untrained morons.
It's bad enough as it is - so bring on the self driving cars...
Easy to confuse all this crypto stuff! I work with it regularly and still have to look quite basic stuff up if I haven't touched it for a while! Yes, I am that Matt Palmer, but no longer at the National Archives...I'm now doing contract security architecture for a consultancy.
The issues on IBE are kind of like trusting a CA, except there are no certificates and therefore no CA. There is a very powerful trusted party who can decrypt anyone's information. The way it works is, there are some all powerful master secrets, from which some public parameters are generated.
Anyone with the public parameters can generate a new public key for anyone (e.g. using your email address as the public key) and encrypt a message for you. The issue is that to decrypt the message, you have to ask the trusted party for a valid private key for that public key, which it can automatically generate for you given knowledge of the public key, using the master secrets.
One security issue of this system is how does the trusted party authenticate that you really are who you claim to be, and how does it distribute that private key to you. Another, possibly more serious objection, is that the trusted party can fundamentally generate private keys for anyone using their parameters, so they can decrypt everyone's data. You have to *really* trust that trusted party.
The only place I've seen IBE commercially used is by Voltage Security. One use case is to allow payment terminals to automatically generate a new public key for each payment. Since the payment provider is supposed to be able to decrypt all of these communications (they are the trusted party), then this works quite nicely.
The whole point of public key encryption is that you don't need to do a key exchange. You have the public key, which is, well, public. The problem then becomes trusting you have the correct public key. Signatures provided by some other trusted party are used for this, usually in certificates. There still needs to be some per-established trusted root or web of trust to enable this. Identity-based public key encryption even does away with the need for this, allowing the generation of arbitrary public keys for someone (although there are other security issues with this sort of encryption scheme which I won't go into here).
Diffie Hellman key exchange is unauthenticated and completely vulnerable to a man in the middle attack. It is used to create a shared secret between two parties, which becomes a shared key, usually for symmetric encryption. It's very old now but still amazingly cool - I love the somewhat counter-intuitive fact that two parties can create a shared secret amongst themselves using only public communications. As long as you accept that neither party has any idea at all who they are creating the shared secret with.
Slashdot Mirror
Hmmm... I got my performance stats from a different web site. But the performance table on oclHashcat's fron page says 11231M c/s for SHA256. That's eleven billion a second, admittedly using 8 GPUs, but in the ballpark of my original post.
If crypt is iterating SHA256 110,000 times, that sounds fairly good. I've been looking at scrypt, which is explicitly designed to resist hardware based attacks.
Well, I would dispute those calculations a bit, but I accept that good long per-account salting forces each password to be cracked individually. I assume that the salt is compromised along with the password (or they won't be cracked at all).
Even randomly selected passwords from all alphanumeric characters only gives us about 6 bits of entropy per character. Most passwords are shorter than 10 characters, the average is more like 7. This only gives us 42 bits of entropy per password, assuming complete random selection from that space.
But - users don't randomly select from that space, and modern password crackers don't simply try all possible letter permutations, although they can successfully do this for passwords which are less than 7 characters. They exploit the patterns and techniques which users use to select passwords, using rules engines, password dictionaries, markov chains and all sorts of clever magic.
Run this on GPUs using hashcat, which for SHA256 can check about 3 billion hashes a second. A small cluster of 4 of these machines can then easily check over 10 billion hashes a second. You can now rent Amazon EC2 instances with GPUs. In a minute you can check 600 billion hashes, admittedly for a single password at a time.
Salted hashes are now crackable even for quite reasonable passwords, if the hash algorithm can be run on modern GPUs, and assuming the attacker has the salt as well.
It's not particularly the strength of the hash that worries me, it's the speed of it. If they're using something like SHA256 - strong, but fast - then I'd be worried.
Good point. I checked out http://www.stroustrup.com/appl... and I can see they're mostly all quite demanding applications. I guess they deserve a demanding language :) But yes, fair enough. There are plenty of times getting the most out of what you have is going to be important.
I once worked on Java code which ran on the most ludicrously limited hardware. It was like treacle. I spent a lot of time tuning that code. Logging was the worst offendor, but some poor algorithms lurked in there too. Garbage collection was quite noticeable, even after rewriting to minimise it as much as possible.
Fair enough... I'm pretty ignorant on how CUDA or OpenCL is programmed. What is it about C++ that makes it a good fit?
Yes, I can see that sort of code would benefit a lot. Not an area I've done much work in, but I guess a lot of people are. I'm actually really interested in code that performs well - I spend quite a lot of time profiling and tuning. Some of the things Martin Thomson has done in Java land are pretty cool. Check out http://lmax-exchange.github.io... and http://mechanical-sympathy.blo...
Sure, resource handling in C++ is one of the examples I do give of the sheer power and beauty of what you can do with the language. I used it extensively even back then. I also remember some of the issues I encountered in passing them around safely were a big lesson in the complexities, pitfalls (and opportunities) that lurk in the language. It was enormous fun, but I think I've probably been more effective in less demanding languages.
I had the most fun ever with C++ back when the original story ran. But it was too complex, too big and yet lacking standard ways of doing really very common things. Every library took a different approach. No standard libraries to do pretty much anything you wanted to in the real world. And it was always possible to shoot both feet off at once while doing something you thought was obvious and/or designed to make your code safer. Incredibly slow to compile. Compilers never supported the full C++ spec, or supported different bits of it on different platforms.
The trouble is, I can't see any compelling reason to use it for anything much these days. Maybe the latest C++ is better - but given what I know of the language I suspect the main criticisms I have of it must be still valid.
Use cases where you need that insane low level of power and control while retaining a high level language syntax are not common at all.
Can anyone give an example of where C++ really shines these days over other languages?
It looks like a message authentication code, but it isn't. Hash(Key || data) is vulnerable to a length extension attack.
I think we need a "Misleading" category.
Without the salts, the hashes are essentially uncrackable, if the salts aren't incredibly short. So don't waste your time trying to crack these.
Salts are not secrets. They are usually stored right alongside the account details in the password database.
If your solution is to make the salt secret, you're not using salts anymore. Per-account salts protect against pre-computation attacks and do not need to remain secret to provide this protection. They are a cheap and effective defense for this purpose.
If you want to keep your salts secret, they are technically called "keys", and are expensive and difficult to manage securely.
The software running on the POS is completely known and controlled. In a big organisation there are lots of them, so you want to be able to update over the network. Updates are tested and bundled with any whitelist updates required. It's the perfect environment for whitelisting.
I'm curious why think it won't work on a POS with remote updates?
I attended a conference on XML back in roughly 2004. A police technical architect was describing the ANPR system. He pointed out that the current deployments of the time were entirely local and not joined up nationally - but went on to say that it wasn't a very big step to do this, allowing the tracking of vehicle movements on a national scale. He looked embarrassed and uncomfortable as he said this.
I got the very strong impression at the time that he was trying to give a warning on where this technology was heading.
I'm no expert on id-based encryption, although I can just about understand how it works. It has some attractive properties as well as some serious downsides.
Pros:
* An encryptor can pick a public key at random for a recipient known to the decrypting authority.
* No prior arrangement is required except for knowledge of the public parameters of the authority, and a recipient to send a message to.
Cons:
* The private key of the recipient can be calculated at any time by the decrypting authority.
* The recipient must authenticate to the decrypting authority to receive the private key for the sender-chosen public key.
* All messages in the past and in the future can always be decrypted by the decrypting authority at any time.
* You have to trust this authority absolutely.
The fact that the private key can be calculated from the public key and the master secrets is actually a pro as well as a con. This is what lets the sender choose a public key of their choosing with no prior arrangement.
I've seen this work quite well in one setting - payment messages from secure pin entry devices to the payment processor. In this case, the payment processor can decrypt all payment messages at any time, but each message is sent using a different key for each transaction, chosen by the low power pin entry device, and requiring no interaction between them and the processor.
On reflection, it's probably not a good candidate for inclusion into a protocol that would replace TLS. I can't really see how it provides anything useful in that setting. Still, it was just an example of some of the cool ideas being realised in more modern cryptography :)
Well, I can't really make out what you're proposing here.
As far as I can see, the client side has three secrets to maintain - the GUID, master password and salt. If the GUID is unique to a computer, your accounts only work from a single machine, and if you lose the GUID then you lose access to all your accounts. Correct?
The nonce is a "number used once" - i.e. randomly generated for each session in a cryptographically sound way.... so how do the server and client negotiate the nonce for each session? Does one pick it and encrypt it to send to the other? Do they both participate in picking it? Do they use something like Diffie-Hellman to arrive at the value?
I really don't understand your point about changing the salt equals changing your logins without affecting your password. Do you mean if I wanted to lose access to all my accounts everywhere and begin again, I wouldn't have to change my password?
And... how do you know you're talking to the right server in the first place? I don't see any server authentication at all in your proposal.
That's enough for now. The one thing I've learned from studying protocols is that it's really, really hard to get right. Not because the people creating them are dumb or have malicious intent. It may well be time to start creating a new protocol to replace TLS eventually, using what we now know about trust, authenticated encryption, protecting the handshake and side channel attacks. And possibly using some new techniques in there, like identity-based encryption...
Go for it.
Don't worry - you won't get anywhere close, but I guarantee you will learn a lot.
Start by trying to define what you are protecting from whom, and how two arbitrary endpoints who have never met can know they are talking to each other and not a man in the middle.
This is a really good point. The inefficiency of physical ballots requiring large numbers of people to participate is a security feature!
You rat!
A belief in GW is entirely compatible with having a beach front house. The problem is that it is slow moving but inexorable.
Personally, I'm with the vast, vast majority of scientists who claim it's real and extremely dangerous. From what I've seen of the human race, we won't do anything until we get badly burned.
I guess everyone will know for sure one way or the other in a few decades. I just hope we can live with it.
I thought we already covered this in the linux rdrand story. It's called unauditable because it whitens the raw entropy output using encryption on chip, making even quite non-random source data appear to be random. It is not called unauditable because it's a black box design. The paper states that the design is very well known.
The attack described in this paper is to modify both the entropy source output "c" and the post-processing encryption key "K", undetectably setting a fraction of them to constant bit values. This weakens the effective random number generation to some chosen n bits of entropy, instead of 128 bits. But because the AES encryption post-processing stage does a very good job of making its output appear random, it will still pass random number tests.
If we had access to the raw entropy source, we could see that it was not providing nearly enough entropy to the encryption post-processing stage.
Interesting. I once managed a very bright and young developer, whose coding was exceptional. He was very often (but not always) right. But he was also rude and completely lacking in any social graces. And it wasn't enough that he was right - he also made everyone else feel stupid and frustrated.
I had to find solo projects for him, as the rest of the team ended up flat out refusing to work with him - and I didn't blame them.
I believe one of the issues with this instruction as a source of random numbers is that the instruction whitens the output with no access to the raw entropy data. Any physical process that acts as an entropy source will have some (possibly small) biases - it won't necessarily appear to be completely random in particular ways.
This can be audited to see that the output conforms to the physical processes which are described.
If the instruction whitens the output through some algorithmic transform (e.g. hashing) to give apparently random numbers as output, there is no way to distinguish that from say encrypting a counter with a secret key - whose output will also appear to be random - but is trivially crackable if you know the secret key.
So it becomes an exercise in trust in Intel, rather than something which an be independently verified. There was a good comment on the cryptography mailing list about this - that it would be better to have hardware entropy sources, leaving the final steps of random number generation to software.
I guess the point the OP was making is that the remaining crime may become more violent. But I agree that a lot of opportunistic crime would essentially disappear.
If you want to cite human rights, your personal right to travel doesn't trump my right to be reasonably safe from hurtling lumps of metal driven by untrained morons.
It's bad enough as it is - so bring on the self driving cars...
Easy to confuse all this crypto stuff! I work with it regularly and still have to look quite basic stuff up if I haven't touched it for a while! Yes, I am that Matt Palmer, but no longer at the National Archives...I'm now doing contract security architecture for a consultancy.
The issues on IBE are kind of like trusting a CA, except there are no certificates and therefore no CA. There is a very powerful trusted party who can decrypt anyone's information. The way it works is, there are some all powerful master secrets, from which some public parameters are generated.
Anyone with the public parameters can generate a new public key for anyone (e.g. using your email address as the public key) and encrypt a message for you. The issue is that to decrypt the message, you have to ask the trusted party for a valid private key for that public key, which it can automatically generate for you given knowledge of the public key, using the master secrets.
One security issue of this system is how does the trusted party authenticate that you really are who you claim to be, and how does it distribute that private key to you. Another, possibly more serious objection, is that the trusted party can fundamentally generate private keys for anyone using their parameters, so they can decrypt everyone's data. You have to *really* trust that trusted party.
The only place I've seen IBE commercially used is by Voltage Security. One use case is to allow payment terminals to automatically generate a new public key for each payment. Since the payment provider is supposed to be able to decrypt all of these communications (they are the trusted party), then this works quite nicely.
Sorry, but this is just wrong.
The whole point of public key encryption is that you don't need to do a key exchange. You have the public key, which is, well, public. The problem then becomes trusting you have the correct public key. Signatures provided by some other trusted party are used for this, usually in certificates. There still needs to be some per-established trusted root or web of trust to enable this. Identity-based public key encryption even does away with the need for this, allowing the generation of arbitrary public keys for someone (although there are other security issues with this sort of encryption scheme which I won't go into here).
Diffie Hellman key exchange is unauthenticated and completely vulnerable to a man in the middle attack. It is used to create a shared secret between two parties, which becomes a shared key, usually for symmetric encryption. It's very old now but still amazingly cool - I love the somewhat counter-intuitive fact that two parties can create a shared secret amongst themselves using only public communications. As long as you accept that neither party has any idea at all who they are creating the shared secret with.