Quantum encryption (as it is currently used) makes sure that the data is transmitted in a secure fashion alright (or at least the key, and if you use one time pads, this means the same). But you will still have to solve the problem of authentication. And this is what public key cryptography does. Quantum cryptography solves the same problem as symmetric key cryptography in a way. Current symmetric algorithms are pretty safe, so quantum encryption in its current form is wholly uninteresting for commercial applications.
Then again, quantum cryptography analysis is wholly uninteresting for commercial application as well:)
Normally we refer to keys used in symmetric encryption as secret keys, not as private keys. For asymmetric encryption, where two mutually dependent keys are used it's private and public keys.
Anywho, it is said that AES-256 should be strong enough to withstand attacks by quantum computing. Of course, by definition, one time pads are resistant against every attack, as long as the keys are really kept safe. The reason why they are not commonly used is the size of the keys (as long as the plain text) and key distribution & memory issues.
So symmetric encryption is still rather safe, and as long as they aren't able to build a rather large quantum computer, I presume that asymmetric encryption is still safe as well.
Of course there are robust Pascal/Delphi applications, but you suggested that these features are expected in a robust language (whatever that means). I know at least one user of Delphi that only lets experienced programmers write un-managed Delphi code (pointers and what more). The rest needs to write managed code. If it's there, it tends to get used, and robustness does not come from that.
"Pascal does pointers, Structures, file I/O with either typed or untyped files, Inline Coding, Inline Assembler, pretty much everything you would expect from a robust language."
Pointers, inline coding and inline assembler are features you expect from a "robust language"? Well, as long as you don't need robust applications I suppose.
This standard format should be a way to be able to handle documents within WYSIWYG text editors. Do you have any idea what WYSIWYG actually stands for, or are you just trolling? If K-Office and OO.o lay out ODF differently then there is a serious problem, unless not all layout is included on purpose. Line endings do not have to do anything with lay out. And, to top it off, although XML is a data processing format, the document that the OOXML standard describes certainly isn't.
Just for fun, count the number of functions in Word that have to do with layout and the number of functions that have to do with content. Yeah, right, not for layout eh? Good, now try and create a technical document 200 pages or longer. Great for content? I think not. If you are using this stuff for just content or data-processing, boy, do I not envy you.
"I suppose the police will argue that listing the items as police bugs on an auction site shows awareness that the bugs weren't his to sell."
I just bought some farmers yogurt, but somehow I don't think I'll be arrested for that. Neither for grandma's cookies. I might get arrested for eating ma's cookies. But I doubt it since they were getting stale otherwise.
Throughput is lower, but SSD's already provide faster startup times than HDD's. Latency, reliability, size, low power use, noise are all clear advantages for SSD's over hard drive technology. If prices come down a bit (or rather, a lot) for SSD's when they become more regular, HDD's will only have size and size per dollar left as advantages.
For my OS, flash seems a very logical choice. Price and some uncertainties about the flash currently on the market have withhold me from buying it so far, but this will probably end pretty soon. For my video and MP3 collection, well, HDD's and (original) DVD's are the only logical choice for me.
Does it matter that there was no control group? It seems that the cancer was *local* to the RFID chip. The chance of a cancer developing in the same spot under the skin seems astronomically low. Not a common place for a cancer to develop, I suppose.
Yeah, I had the same thing. I thought it was weird when I read the headline. Maybe some all-important weather or communications satellite? Somehow I feel suckered in, I probably wouldn't have read the summary if the headline included " of dollars" at the end. And the only reason I joined in the discussion was to say this. You just beat me to it though, and I'm freshly out of mod points:(
Don't forget that PKCS#5 v2.0 uses an iteration count and a salt. This means that the algorithm is not applied just once, but 1000 times (or more, 1000 is the minimum). This would mean a slowdown of 1000 on these kind of crackers *if* they implement the iteration count. A salt would make it hard to use a default configuration like this one found on internet as well.
As said, the hash algorithm itself does not matter too much. The problem with all these schemes is that the amount of entropy in the passwords is simply too small. Creating an SSL channel before authentication and sending a (hashed?) password would do for mail services I suppose. That way there is no way to do the off-line cracking; they'll have to attack the server directly.
Arg! Whoops, sorry about that. Read the post, but thought you were quoting the summary.
I've wondered about Cell performance myself for a while, but I haven't got the time to go out of the way to do some measurements. For SSE3/4: I would call it highly unlikely that we would see anything like the performance they are posting: 2 ^ 12 performance difference for MD5 alone is quite a lot. Maybe SSE5 might speedup SHA-2 as well. Anyway, you might want to add the T2 (Rock processor) from Sun to that list, it has 8 crypto hardware accelerators on board. My 1.2 GHz C7 with hardware accelerator is probably way to slow to get anything near the performance, but I'll test it anyway. MD5 is much faster than SHA-1, which in turn is much faster than SHA-2, so you would want to use SHA-2 anyway, as a stop-gap measure.
Like this "super-computer" it is which problem you want to solve I suppose. Tesla = vector based, this is general CPU instructions and a - for supercomputers - very slow interconnect. That would make this "super-computer" fit for testing purposes and small problems for which Grid computing is too slow. But even for those purposes, it does not really pass the lameness filter.
"NSA@home is a fast FPGA-based SHA-1 and MD5 bruteforce cracker. It is capable of searching the full 8-character keyspace (from a 64-character set) in about a day in the current configuration for 800 hashes concurrently."
So your 2200+ AMD is beaten to little pieces by this monster.
Source, well, you had to click a single link to their homepage. That'll learn you to post early. Or not, since I supplied you the answer anyway.
That's nice, his own SHA-1 cracker. But, even with advanced cryptographic attacks, SHA-1 is still in the order of 2^63. Not something you would like to try with just a few FPGA's. What is meant here is a cracker to find out which plain text, with limited entropy, is used to create a certain hash value. A SHA-1-based password cracker would therefore be a better name, I suppose.
It seems from here that it searches a 64 ^ 8 = (2 ^ 6) ^ 8 = 2 ^ 48 keyspace in 24 hours. No small feat, it should therefore do about 3,257,812,230 hashes in a second. It does 800 concurrently, which makes for 4 million a second per SHA-1 unit. Ouch, that's really fast.
Note that this could be done with any hash or symmetric algorithm, as long as it can be implemented on FPGA. So the moral of the story: use very long password (or even better, pass phrases), or make sure that they won't be able to acquire the hash.
"The same with Public Key crypto. I could lock it up with a time stamp, but what prevents me from faking the stamp that locks the file?"
Ehm, Public Key crypto? Look it up on Wikipedia if you are not sure about a mechanism. Relevant part of Wikipedia contents follow.
The TSA concatenates a timestamp to the hash and calculates the hash of this concatenation. This hash is in turn digitally signed with the private key of the TSA. This signed hash + the timestamp is sent back to the requester of the timestamp who stores these with the original data (see diagram).
Since the original data can not be calculated from the hash (because the hash function is a one way function), the TSA never gets to see the original data, which allows the use of this method for confidential data.
Simple solution used in previous times was to post sensitive data via official state post service to your own address, since post stamp is an official time-stamp recognized in court.
Re:Very nice toolkit with some problems
on
GWT in Action
·
· Score: 1
"GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml file in the root of the target webserver (to see whether access is allowed or not)."
Distributing a specific web client to make it possible to view (some) web applications? That's not a good idea. Maybe for intranet use, but people won't go for a specific web client just to view some GWT based websites. The idea of a crossdomain.xml for use within JavaScript is an interesting one though.
"Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM."
Weird. Just for my information; I assume there are some native parts involved? I could not find any info on that.
I don't even think that the author does not know this. I think he was deliberately limiting his view to web applications. And to state that there is less support for languages supported in the browser (JavaScript, some Visual Basic) against those supported by the server (all of 'm really). Well, that's true, isn't it? So that would make the statement true, at least in the - supposedly - domain he was targeting. The initial reply of the grandparent was a bit over the top, in my opinion.
Re:Just when you need mod points
on
GWT in Action
·
· Score: 1
"Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants."
Funny, that, I am using both as well, and I feel the same thing. The other way around. VS is way behind Eclipse on some features, and a lot more on others. VS 2005 now has acceptable support for operations on the abstract syntax tree, but nothing really powerful. Of course, VS has more functionality integrated. But Eclipse has its vast number of functional plug-ins, and it does the parsing and code completion exceptionally well. Anyway, I've to spend most of my time on Eclipse - and that's the one that *I* like - so it seems I got the better deal.
Slashdot Mirror
Wrong.
:)
Quantum encryption (as it is currently used) makes sure that the data is transmitted in a secure fashion alright (or at least the key, and if you use one time pads, this means the same). But you will still have to solve the problem of authentication. And this is what public key cryptography does. Quantum cryptography solves the same problem as symmetric key cryptography in a way. Current symmetric algorithms are pretty safe, so quantum encryption in its current form is wholly uninteresting for commercial applications.
Then again, quantum cryptography analysis is wholly uninteresting for commercial application as well
Normally we refer to keys used in symmetric encryption as secret keys, not as private keys. For asymmetric encryption, where two mutually dependent keys are used it's private and public keys.
Anywho, it is said that AES-256 should be strong enough to withstand attacks by quantum computing. Of course, by definition, one time pads are resistant against every attack, as long as the keys are really kept safe. The reason why they are not commonly used is the size of the keys (as long as the plain text) and key distribution & memory issues.
So symmetric encryption is still rather safe, and as long as they aren't able to build a rather large quantum computer, I presume that asymmetric encryption is still safe as well.
Of course there are robust Pascal/Delphi applications, but you suggested that these features are expected in a robust language (whatever that means). I know at least one user of Delphi that only lets experienced programmers write un-managed Delphi code (pointers and what more). The rest needs to write managed code. If it's there, it tends to get used, and robustness does not come from that.
"Pascal does pointers, Structures, file I/O with either typed or untyped files, Inline Coding, Inline Assembler, pretty much everything you would expect from a robust language."
Pointers, inline coding and inline assembler are features you expect from a "robust language"? Well, as long as you don't need robust applications I suppose.
This standard format should be a way to be able to handle documents within WYSIWYG text editors. Do you have any idea what WYSIWYG actually stands for, or are you just trolling? If K-Office and OO.o lay out ODF differently then there is a serious problem, unless not all layout is included on purpose. Line endings do not have to do anything with lay out. And, to top it off, although XML is a data processing format, the document that the OOXML standard describes certainly isn't.
Just for fun, count the number of functions in Word that have to do with layout and the number of functions that have to do with content. Yeah, right, not for layout eh? Good, now try and create a technical document 200 pages or longer. Great for content? I think not. If you are using this stuff for just content or data-processing, boy, do I not envy you.
That's "fascist Australia", you insensitive clod.
"I am not an advocate of mass murder but we really need to figure out a way to weed the gene pool."
It's slightly less difficult than getting nerds to replicate, I suppose.
"I suppose the police will argue that listing the items as police bugs on an auction site shows awareness that the bugs weren't his to sell."
I just bought some farmers yogurt, but somehow I don't think I'll be arrested for that. Neither for grandma's cookies. I might get arrested for eating ma's cookies. But I doubt it since they were getting stale otherwise.
I'm not a US citizen, but am I allowed to make some harsh statements about Celine Dion anyway?
Throughput is lower, but SSD's already provide faster startup times than HDD's. Latency, reliability, size, low power use, noise are all clear advantages for SSD's over hard drive technology. If prices come down a bit (or rather, a lot) for SSD's when they become more regular, HDD's will only have size and size per dollar left as advantages.
For my OS, flash seems a very logical choice. Price and some uncertainties about the flash currently on the market have withhold me from buying it so far, but this will probably end pretty soon. For my video and MP3 collection, well, HDD's and (original) DVD's are the only logical choice for me.
"The long-timers will get them first."
There must be a joke hidden in this sentence somewhere...
Does it matter that there was no control group? It seems that the cancer was *local* to the RFID chip. The chance of a cancer developing in the same spot under the skin seems astronomically low. Not a common place for a cancer to develop, I suppose.
Yeah, I had the same thing. I thought it was weird when I read the headline. Maybe some all-important weather or communications satellite? Somehow I feel suckered in, I probably wouldn't have read the summary if the headline included " of dollars" at the end. And the only reason I joined in the discussion was to say this. You just beat me to it though, and I'm freshly out of mod points :(
Sorry to nitpick, but it's not a Citarbria, it's a Citabria. It's "airbatic" spelt backwards, not "airbratic".
Should we tag this as "oops"? Might be a good way to show that this might be an (unintentional) mistake...
Don't forget that PKCS#5 v2.0 uses an iteration count and a salt. This means that the algorithm is not applied just once, but 1000 times (or more, 1000 is the minimum). This would mean a slowdown of 1000 on these kind of crackers *if* they implement the iteration count. A salt would make it hard to use a default configuration like this one found on internet as well.
As said, the hash algorithm itself does not matter too much. The problem with all these schemes is that the amount of entropy in the passwords is simply too small. Creating an SSL channel before authentication and sending a (hashed?) password would do for mail services I suppose. That way there is no way to do the off-line cracking; they'll have to attack the server directly.
I think you are confused, it's Rapid Eye Movement, not Random Eye Movement.
Arg! Whoops, sorry about that. Read the post, but thought you were quoting the summary.
I've wondered about Cell performance myself for a while, but I haven't got the time to go out of the way to do some measurements. For SSE3/4: I would call it highly unlikely that we would see anything like the performance they are posting: 2 ^ 12 performance difference for MD5 alone is quite a lot. Maybe SSE5 might speedup SHA-2 as well. Anyway, you might want to add the T2 (Rock processor) from Sun to that list, it has 8 crypto hardware accelerators on board. My 1.2 GHz C7 with hardware accelerator is probably way to slow to get anything near the performance, but I'll test it anyway. MD5 is much faster than SHA-1, which in turn is much faster than SHA-2, so you would want to use SHA-2 anyway, as a stop-gap measure.
Like this "super-computer" it is which problem you want to solve I suppose. Tesla = vector based, this is general CPU instructions and a - for supercomputers - very slow interconnect. That would make this "super-computer" fit for testing purposes and small problems for which Grid computing is too slow. But even for those purposes, it does not really pass the lameness filter.
"NSA@home is a fast FPGA-based SHA-1 and MD5 bruteforce cracker. It is capable of searching the full 8-character keyspace (from a 64-character set) in about a day in the current configuration for 800 hashes concurrently."
So your 2200+ AMD is beaten to little pieces by this monster.
Source, well, you had to click a single link to their homepage. That'll learn you to post early. Or not, since I supplied you the answer anyway.
That's nice, his own SHA-1 cracker. But, even with advanced cryptographic attacks, SHA-1 is still in the order of 2^63. Not something you would like to try with just a few FPGA's. What is meant here is a cracker to find out which plain text, with limited entropy, is used to create a certain hash value. A SHA-1-based password cracker would therefore be a better name, I suppose.
It seems from here that it searches a 64 ^ 8 = (2 ^ 6) ^ 8 = 2 ^ 48 keyspace in 24 hours. No small feat, it should therefore do about 3,257,812,230 hashes in a second. It does 800 concurrently, which makes for 4 million a second per SHA-1 unit. Ouch, that's really fast.
Note that this could be done with any hash or symmetric algorithm, as long as it can be implemented on FPGA. So the moral of the story: use very long password (or even better, pass phrases), or make sure that they won't be able to acquire the hash.
"The same with Public Key crypto. I could lock it up with a time stamp, but what prevents me from faking the stamp that locks the file?"
Ehm, Public Key crypto? Look it up on Wikipedia if you are not sure about a mechanism. Relevant part of Wikipedia contents follow.
The TSA concatenates a timestamp to the hash and calculates the hash of this concatenation. This hash is in turn digitally signed with the private key of the TSA. This signed hash + the timestamp is sent back to the requester of the timestamp who stores these with the original data (see diagram).
Since the original data can not be calculated from the hash (because the hash function is a one way function), the TSA never gets to see the original data, which allows the use of this method for confidential data.
Simple solution used in previous times was to post sensitive data via official state post service to your own address, since post stamp is an official time-stamp recognized in court.
"GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml file in the root of the target webserver (to see whether access is allowed or not)."
Distributing a specific web client to make it possible to view (some) web applications? That's not a good idea. Maybe for intranet use, but people won't go for a specific web client just to view some GWT based websites. The idea of a crossdomain.xml for use within JavaScript is an interesting one though.
"Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM."
Weird. Just for my information; I assume there are some native parts involved? I could not find any info on that.
I don't even think that the author does not know this. I think he was deliberately limiting his view to web applications. And to state that there is less support for languages supported in the browser (JavaScript, some Visual Basic) against those supported by the server (all of 'm really). Well, that's true, isn't it? So that would make the statement true, at least in the - supposedly - domain he was targeting. The initial reply of the grandparent was a bit over the top, in my opinion.
"Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants."
Funny, that, I am using both as well, and I feel the same thing. The other way around. VS is way behind Eclipse on some features, and a lot more on others. VS 2005 now has acceptable support for operations on the abstract syntax tree, but nothing really powerful. Of course, VS has more functionality integrated. But Eclipse has its vast number of functional plug-ins, and it does the parsing and code completion exceptionally well. Anyway, I've to spend most of my time on Eclipse - and that's the one that *I* like - so it seems I got the better deal.