Yeah, everybody that does not read the articles get itchy. I'm fine with that. And if this means there is a lot less swearing and name calling, I can live with that too.
Just supporting LLVM bitcodes does not seem to be enough. You need to have a full runtime system, not just a virtual instruction set. It goes a long way, mind you, but you'll have to have API support for any kind of multi-media. If you want to take more control, you'll need an access system etc. And these API's need to be consistent with many languages as well.
By the way, the SHA-512/224, SHA-512/256, SHA-384 and SHA-512 are only different in their initial hash value, so it is very easy to implement these algorithms. Just change the constant and cut the required number of output bits. Personally, I think it is at least two hash functions too many.
What I don't get is the focus on 64 bit x86 computers. They take the fastest personal computers and see how well they run a hash function. It's way more interesting to see what happens when using smaller chips. Personally I think that the reference platform for the latest hash method should have been a 32 bit ARM or something, not a little endian 64 bit Intel chip.
Nope. These drives contain more memory than their stated capability. Of course, with the drives getting cheaper the number of extra blocks used for wear leveling is being lowered each time. My Intel SSD contains oodles of extra memory. If you just zero the drive, you may be sure that there is a residue left. Next time try and read the article.
That would be possible, since it would be the device itself that does the erasing. It could just issue a single erase command for the flash blocks containing the key and it would be done (I presume that the key is stored in at least two locations, or the failure of a single block of memory would be disastrous). It might even be stored in writeable memory within the controller.
No, that would be highly unlikely (that it is encrypted by default). You do need to set some security parameters when erasing, but as far as I know, that's not because of how secure erase works. The results in the article for secure erase would not be possible if there was a single key (because partial erase would not be possible). It also would not explain the 20 second wait during secure erase of my Intel SSD. Fortunately, flash blocks can be erased in one go, so secure erase is *much much much* faster on an SSD compared to a HDD.
Really old school HD's. There are several articles on the internet that say that for newer drives, even specialised firms cannot retrieve any data that has been overwritten by random numbers. Of course, you've got things like replaced sectors on current drives, so you are still better off using the SATA ERASE commands that by now have become standard.
And they work perfectly on SSD's. Since flash is erased per block, they are plenty fast. Much *less than a minute* to fully erase my 80 GB G2 from Intel. Used hdparm. They only annoying thing is the that you need the right access (e.g. many USB devices won't support hdparm, or at least these SATA commands).
You cannot hack all of the day (at least not at my age). I can write meaningless stuff on the internet all day though. It takes a lot less concentration and you can consume alcohol while you are doing it. If I would start programming now, I would be debugging the applications for the next couple of weeks.
Almost all people I spoke to loved the LOTR movies (there was some discussion if they were actually better than the book). The only thing they really did not like that much was the ending - way too long, it seemed like there were three separate endings. Of course, this is not dissimilar to the book, but then again, maybe it wasn't that great in the book either.
You may leave that "likely" out. Most of these TPA modules are modified smart card chips, and they certainly provide security against DPA attacks. The problem is that most general purpose CPU's do not. This becomes more of a problem if this chip is a low frequency, highly mobile RISC chip, I suppose.
"I'm not sure I buy it. Sure you could detect signals eminating from a smart phone, but decifering them into something coherent? Really? That's pretty awesome if it can be done, but where are the details about what devices you used and what exactly you did?"
That is completely in line what I've seen done during side channel attacks on various kind of devices - for me it is not hard to believe at all. Besides that, I used to listen to radio tuned to my MSX computer. It wasn't long until you could find out by listening to the audio signal what your computer doing. This is basically the same thing, except that the frequency is a bit higher, and more dense information is extracted.
Besides all that, there is no way that a company like this is *ever* going to fake this kind of demo. The security crowd isn't well known for its humor regarding rigged demos.
PS quoted manually since the reply function does not seem to space the reply very well
They didn't, they listed the guessed number of actual attacks against (Windows) machines. Finding 2.6 million possible vulnerabilities in the JVM after running code analysis, now that *would* make an interesting Slashdot headline.
Yes, and if you dig any further you find out that it is a Java *deployment* issue which exploits features of the underlying operating system. Funny enough, only Windows is affected, who would have guessed? And since nobody in his right mind is going to use Design By Contract for deployers, you can safely ignore the buffer overflow argument used in the article. Pure FUD.
PKI was *never* foolproof. Handing out certificates or signing stuff can be useful, but as long as private keys can be stolen, and as long as they are used to sign more than one application, and as long as anybody cannot be trusted forever, and as long as certificate revocation is not on by default, they are far-far away from being foolproof. Of course, the malicious ActiveX software that got signed by a key that could not be disabled was already a good demonstration of the problems of PKI (and good key management in general).
Trying to let a cat do anything other than purr and eat is a waste of time. Until they are a few years old you can entice them to run after things, but that's about it.
If cats were ever created for any purpose, it's probably to show to people that you are not in control of everything. Doubly so when mackerel is involved.
You get these people. I once tried to explain to a guy that 1) yes, he could use the scanner for making copies but 2) no he still needed to buy a printer. Took me a half hour to no avail.
Slashdot Mirror
Yeah, everybody that does not read the articles get itchy. I'm fine with that. And if this means there is a lot less swearing and name calling, I can live with that too.
Mod parent up, good reasoning here.
Just supporting LLVM bitcodes does not seem to be enough. You need to have a full runtime system, not just a virtual instruction set. It goes a long way, mind you, but you'll have to have API support for any kind of multi-media. If you want to take more control, you'll need an access system etc. And these API's need to be consistent with many languages as well.
If anyone is interested in the source material, here it is:
http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.pdf
Fresh from the press, it seems.
By the way, the SHA-512/224, SHA-512/256, SHA-384 and SHA-512 are only different in their initial hash value, so it is very easy to implement these algorithms. Just change the constant and cut the required number of output bits. Personally, I think it is at least two hash functions too many.
What I don't get is the focus on 64 bit x86 computers. They take the fastest personal computers and see how well they run a hash function. It's way more interesting to see what happens when using smaller chips. Personally I think that the reference platform for the latest hash method should have been a 32 bit ARM or something, not a little endian 64 bit Intel chip.
(Disclaimer: I've used a MacBook Pro as my main computer for years, and I really like it. That may or may not have colored my opinion.)
Technically, black and white aren't colors.
Nope. These drives contain more memory than their stated capability. Of course, with the drives getting cheaper the number of extra blocks used for wear leveling is being lowered each time. My Intel SSD contains oodles of extra memory. If you just zero the drive, you may be sure that there is a residue left. Next time try and read the article.
That would be possible, since it would be the device itself that does the erasing. It could just issue a single erase command for the flash blocks containing the key and it would be done (I presume that the key is stored in at least two locations, or the failure of a single block of memory would be disastrous). It might even be stored in writeable memory within the controller.
No, that would be highly unlikely (that it is encrypted by default). You do need to set some security parameters when erasing, but as far as I know, that's not because of how secure erase works. The results in the article for secure erase would not be possible if there was a single key (because partial erase would not be possible). It also would not explain the 20 second wait during secure erase of my Intel SSD. Fortunately, flash blocks can be erased in one go, so secure erase is *much much much* faster on an SSD compared to a HDD.
Really old school HD's. There are several articles on the internet that say that for newer drives, even specialised firms cannot retrieve any data that has been overwritten by random numbers. Of course, you've got things like replaced sectors on current drives, so you are still better off using the SATA ERASE commands that by now have become standard.
And they work perfectly on SSD's. Since flash is erased per block, they are plenty fast. Much *less than a minute* to fully erase my 80 GB G2 from Intel. Used hdparm. They only annoying thing is the that you need the right access (e.g. many USB devices won't support hdparm, or at least these SATA commands).
You cannot hack all of the day (at least not at my age). I can write meaningless stuff on the internet all day though. It takes a lot less concentration and you can consume alcohol while you are doing it. If I would start programming now, I would be debugging the applications for the next couple of weeks.
Almost all people I spoke to loved the LOTR movies (there was some discussion if they were actually better than the book). The only thing they really did not like that much was the ending - way too long, it seemed like there were three separate endings. Of course, this is not dissimilar to the book, but then again, maybe it wasn't that great in the book either.
You may leave that "likely" out. Most of these TPA modules are modified smart card chips, and they certainly provide security against DPA attacks. The problem is that most general purpose CPU's do not. This becomes more of a problem if this chip is a low frequency, highly mobile RISC chip, I suppose.
"I'm not sure I buy it. Sure you could detect signals eminating from a smart phone, but decifering them into something coherent? Really? That's pretty awesome if it can be done, but where are the details about what devices you used and what exactly you did?"
That is completely in line what I've seen done during side channel attacks on various kind of devices - for me it is not hard to believe at all. Besides that, I used to listen to radio tuned to my MSX computer. It wasn't long until you could find out by listening to the audio signal what your computer doing. This is basically the same thing, except that the frequency is a bit higher, and more dense information is extracted.
Besides all that, there is no way that a company like this is *ever* going to fake this kind of demo. The security crowd isn't well known for its humor regarding rigged demos.
PS quoted manually since the reply function does not seem to space the reply very well
The Java standard libraries are *primarily* native code? WTF have you been smoking? You can tell the moderators are not very knowledgeable either.
If somebody could post the percentage of C/C++ code in the Java RE, please do because we need to get rid of FUD like this.
They didn't, they listed the guessed number of actual attacks against (Windows) machines. Finding 2.6 million possible vulnerabilities in the JVM after running code analysis, now that *would* make an interesting Slashdot headline.
Yes, and if you dig any further you find out that it is a Java *deployment* issue which exploits features of the underlying operating system. Funny enough, only Windows is affected, who would have guessed? And since nobody in his right mind is going to use Design By Contract for deployers, you can safely ignore the buffer overflow argument used in the article. Pure FUD.
Yeah, and I'm from Africa (and I lay claim to that land because it was inhabited by my fore-fathers).
PKI was *never* foolproof. Handing out certificates or signing stuff can be useful, but as long as private keys can be stolen, and as long as they are used to sign more than one application, and as long as anybody cannot be trusted forever, and as long as certificate revocation is not on by default, they are far-far away from being foolproof. Of course, the malicious ActiveX software that got signed by a key that could not be disabled was already a good demonstration of the problems of PKI (and good key management in general).
Those were the shark-lasers. The dragonfly lasers were actually much smaller.
Trying to let a cat do anything other than purr and eat is a waste of time. Until they are a few years old you can entice them to run after things, but that's about it.
If cats were ever created for any purpose, it's probably to show to people that you are not in control of everything. Doubly so when mackerel is involved.
That [illegible] should have been extended to the entire piece.
Yeah, I own an Android phone, and you won't believe what problems I had to put up with security wise! It's rather unusable!
You get these people. I once tried to explain to a guy that 1) yes, he could use the scanner for making copies but 2) no he still needed to buy a printer. Took me a half hour to no avail.