Irony rears it's head on the day that patches for a Linux vulnerability are announced at the same time Microsoft ends its patching and update service for Windows XP.
How is a vulnerability in OpenSSL, which is a library that can be compiled for multiple platforms, a "Linux vulnerability"?
To put it in perspective, that $100K was for bypassing exploit mitigation features that cross all processes on the system, and would severely undermine Windows 8.1's security features. This one seems to require you to be standing in front of a specific console.
When posting screenshots containing secret keys, just remove a large part of it. Don't use blur or swirl like filters, these can be reversed quite well.
The blurred key posted by itnews is pretty much reversible with the naked eye.
According to the summary the blurred key, and others, are already available in plaintext on Github meaning countless people could have already captured them and possibly still can.
Because you don't understand immigration law? He could have a greencard, making him a permanent resident but Russian national, or he could have applied for one, in which case he can continue to extend his visa until a determination is made on his application.
Of course they ask ISPs to hand over stuff by email addresses, etc.
How do they select those email addresses? Because that's the bit we're actually talking about. The Snowden docs suggest it's by automatically inspecting everything and applying selectors to find the interesting stuff. IMO that's dragnet surveillance.
“This is the most transparent administration in history,” -- Barack Obama, February 2013
He must have been speaking about how obvious their stance with regarding releasing information was.
But to make a counter-point, much as I loathe to do so, it's also possible with all the NSA/Snowden stories that they have faced more requests for documents that are classified than typical. It would be nice to see the chart from TFA displayed as a 100% breakdown rather than a stacked breakdown.
That doesn't make a lot of sense to me. If you define some performance criteria and the processors on which those criteria must be met, what's the problem? The operations would be the same, the instructions underlying those operations could be different. For any particular processor it could even be slightly inefficient. But at least it would be secure to an agreed upon/openly vetted standard. As I said, if you just want a fast/insecure PRNG, make one separately, and give it a very clear API name indicating that it's insecure.
The only problem I see is where you draw your entropy from if you need to mix in something truly random.
Apple might prefer someone disclosed it to them first, whereas some of Apple's users might like to know straight away that they're vulnerable. In either case there is the chance someone less scrupulous has identified the same problem and may use for nefarious purposes.
Open disclosure is only irresponsible depending on your point of view, just like private disclosure might be irresonsible depending on your point of view. There are researchers who will argue for both sides. Open disclosure might disqualify you for being paid under some bounty programs, but then it's up to whoever runs those programs as to whether they would rather encourage at least open disclosure at a minimum based on the personal opinions and motivations of the person doing the research.
Crypto and security guys are an opinionated lot. Getting everyone to agree to some kind of standard is unlikely.
There are surely a set of criteria to be met in the design for a PRNG to be acceptable, a set of known attacks and weaknesses that the PRNG has to be resiliant to to some established degree, some minimum level of performance required (max ops per generation, average ops or ms per generation of n numbers on a certain CPU feature set), unencumbered by patents or full waiver provided. You put together some candidates, allow some window of time (e.g. a year) for everyone to poke holes in them provided all the known materials that would assist someone to make them fail the acceptance criteria. Whatever makes it through is your suite.
Why don't we decide on a handful of strong PRNGs, and make every major OS use them exclusively, and in the case you really need something fast/psuedo-random you have to use a source/API explicitly named "insecure_rng".
That's both Android and iOS fallen victim to poor PRNGs in the last year..
As much as people (including me) like to hate on banks, when was the last time you actually lost money? When was the last time you put money in a bank and they "lost" all or part of it? When was the last time you put money in a bank and lost all or part of it because the bank was robbed?
When was the last time the fed printed as much money as it wanted, devaluing the money you had put in the bank?
I think the idea is to create demand which will bring the pricing down over time. What will start out as a niche device could easily become the new standard.
Well, it has some other challenges in that regard too: * If MP3/AAC/AAC+ is "good enough" those devices will always have cheaper storage and will undercut the Pono, even if its price does come down. And my phone already supports all those formats out of the box, and can pull the content from the cloud with album art. * I wonder how the battery life is, becauseas an enthusiast I've used devices that support FLAC before, and without hardware support like most products have for MP3 I found that they tend to run hotter and battery life is shorter. * All major online stores deliver music in lossy formats. Most people have libraries of MP3s. Those libraries don't swallow their hard drive.
Again, don't get me wrong, a lossless world would be nice, but I think lossless has to at least arrive in the online stores first, and I doubt this device will be what drives that, given its initial price point and zero market share.
Also, Neil Young have never given a fuck about what other people think.
Well, he has to care about what his target market are actually willing to fork out for in sufficient numbers. I guess we'll see.
I read the other day that these units are going to go for about $400 a piece. While I myself am an audiophile at heart, I just can't see the use cases for this that makes it worth the money.
For a start, when I'm on the go, unless I'm in a plane (which I'm not very often), I can't use noise-cancelling headphones or I have little situational awareness, and the benefit of this higher fidelity is lost. If I'm sitting at my computer, I'd rather access my library through the computer via a nicer interface and still be able to hear the audio for videos I play etc., and I don't have to worry about plugging in or running down batteries.
So I'm left wondering where are the occasions when I'd really benefit from the higher quality on the go, how frequently do they arise, and is it worth the money for more pristine sound in just those cases?
Also, the damn thing is triangular. Where am I supposed to be putting this? It's not going in a pocket alongside my smartphone...
For me, it's nice that someone is trying to produce a product with a higher audio quality, but I don't see myself buying one.
Why do these smart, quantitatively trained engineers, who could help cure cancer or fix healthcare.gov, want to work for a sexting app?
Because as an employee in America, your CEO makes on average over 273x your pay, whereas if you join a startup early enough you stand a chance of actually benefiting from your companies success.
Not only that, but notice that the demo video conveniently has them moving a set of cups behind the screen, none of which are blue. The glaring omission here is what happens if something blue does get moved behind the display - like say when you're out driving and a blue car goes past, or you look at the sky? Does that get badly distorted/dimmed? And if so, and I want an RGB version of this, what happens?
It would be sweet if you could project e.g. IR light at it and have that come out with a frequency shift, but that doesn't seem to be what's happening.
I wouldn't be complaining, this is great! Diff all the common code. Hopefully you'll turn up the Chinese backdoors readily, and maybe they've also been smart enough to close some of the US ones, identifying those also.
Sounds great. Where's the guarantee of no NSA backdoor ?
Not only that, but what if I don't want AES? What if I want one of the other algorithms, or a chain? What about different modes of operation, like XTS, that are added over time? How do I test this hardware implementation does what it says it does?
I can look at the code for the pi easily. Firmware for a hardware device, if anyone even gets access to it?
Sure, assuming you want to share your mounted volumes, you don't mind your decrypted files traveling over the network via whatever protocol your desktop OS is compatible with and its associated security model, and it handled all the underlying file systems you wanted to mount volumes on, and all the code to support mounting all those base file systems was trusted and fully audited too, and the act of running a samba server or something and all of the auth code that might go along with supporting the stack etc. didn't concern you, and you didn't care if the volumes it was mounting from might contain exploits against the Pi, etc.
The more you support, the harder it is to audit, the harder it is to secure, the easier it gets to exploit.
TrueCrypt has to keep the keys somewhere so long as a volume is mounted. Whatever happens, so long as it's not currently on the CPU (and potentially even if it is), something that can read its data structures is always going to be able to find the keys in RAM if the structure is known. Maybe if TrueCrypt has some crazy polymorphic engine and corresponding polymorphic data structure that changed on every run it could get very difficult, but probably not impossible, to extract them.
Given that we're in an era of low-cost portable devices (Raspberry-Pi, BeagleBoard, etc.), it would be really nice if TrueCrypt could implement a driver that passed data off to an external, open-source device for processing that held the keys in its own memory, and provided no other service than to perform the cryptographic functions and hand back the data. It would be slower, but at least then you don't have the keys in memory on a general purpose computer running browsers, java, flash, adobe reader, etc. etc.
Take one of those devices and attach a small screen to them and you could enter your passphrase using a keyboard attached directly to them, and use a keyfile on a flash stick plugged into the USB port too. The distro powering all of this could be minimal and audited.
Or maybe it is because the exploits they were using were made specifically for Windows, and not Linux.
You miss the point entirely. Of course they were exploits made for Windows. They were targetting Windows-based devices. They didn't attack the devices because they ran Windows. They attacked them because they wanted the data. They would have attacked them if they had ran Linux, too.
If the entire system was Linux it may have been harder all around to get the data.
Why, because Linux is magic? They would need to find just one exploit that let's them get enough privileges to read the memory. That exploit could be in Linux, that exploit could be in the POS software that runs on Linux.
I'm no Windows CE fanboy, believe me, but Linux doesn't make this problem go away via voodoo. This should be a story about securing their POS network, IDS, systems monitoring, how payment devices and the code that runs on them is verified, etc.
Slashdot Mirror
Irony rears it's head on the day that patches for a Linux vulnerability are announced at the same time Microsoft ends its patching and update service for Windows XP.
How is a vulnerability in OpenSSL, which is a library that can be compiled for multiple platforms, a "Linux vulnerability"?
To put it in perspective, that $100K was for bypassing exploit mitigation features that cross all processes on the system, and would severely undermine Windows 8.1's security features. This one seems to require you to be standing in front of a specific console.
Still, what a stupid bug to have.
When posting screenshots containing secret keys, just remove a large part of it. Don't use blur or swirl like filters, these can be reversed quite well.
The blurred key posted by itnews is pretty much reversible with the naked eye.
According to the summary the blurred key, and others, are already available in plaintext on Github meaning countless people could have already captured them and possibly still can.
I wonder how he worked for MS for 7 years as H1-B Visas are supposed to be limited to 6 years.
Because you don't understand immigration law? He could have a greencard, making him a permanent resident but Russian national, or he could have applied for one, in which case he can continue to extend his visa until a determination is made on his application.
Of course they ask ISPs to hand over stuff by email addresses, etc.
How do they select those email addresses? Because that's the bit we're actually talking about. The Snowden docs suggest it's by automatically inspecting everything and applying selectors to find the interesting stuff. IMO that's dragnet surveillance.
“This is the most transparent administration in history,” -- Barack Obama, February 2013
He must have been speaking about how obvious their stance with regarding releasing information was.
But to make a counter-point, much as I loathe to do so, it's also possible with all the NSA/Snowden stories that they have faced more requests for documents that are classified than typical. It would be nice to see the chart from TFA displayed as a 100% breakdown rather than a stacked breakdown.
That doesn't make a lot of sense to me. If you define some performance criteria and the processors on which those criteria must be met, what's the problem? The operations would be the same, the instructions underlying those operations could be different. For any particular processor it could even be slightly inefficient. But at least it would be secure to an agreed upon/openly vetted standard. As I said, if you just want a fast/insecure PRNG, make one separately, and give it a very clear API name indicating that it's insecure.
The only problem I see is where you draw your entropy from if you need to mix in something truly random.
How is it irresponsible disclosure?
Apple might prefer someone disclosed it to them first, whereas some of Apple's users might like to know straight away that they're vulnerable. In either case there is the chance someone less scrupulous has identified the same problem and may use for nefarious purposes.
Open disclosure is only irresponsible depending on your point of view, just like private disclosure might be irresonsible depending on your point of view. There are researchers who will argue for both sides. Open disclosure might disqualify you for being paid under some bounty programs, but then it's up to whoever runs those programs as to whether they would rather encourage at least open disclosure at a minimum based on the personal opinions and motivations of the person doing the research.
Crypto and security guys are an opinionated lot. Getting everyone to agree to some kind of standard is unlikely.
There are surely a set of criteria to be met in the design for a PRNG to be acceptable, a set of known attacks and weaknesses that the PRNG has to be resiliant to to some established degree, some minimum level of performance required (max ops per generation, average ops or ms per generation of n numbers on a certain CPU feature set), unencumbered by patents or full waiver provided. You put together some candidates, allow some window of time (e.g. a year) for everyone to poke holes in them provided all the known materials that would assist someone to make them fail the acceptance criteria. Whatever makes it through is your suite.
Why don't we decide on a handful of strong PRNGs, and make every major OS use them exclusively, and in the case you really need something fast/psuedo-random you have to use a source/API explicitly named "insecure_rng".
That's both Android and iOS fallen victim to poor PRNGs in the last year..
As much as people (including me) like to hate on banks, when was the last time you actually lost money? When was the last time you put money in a bank and they "lost" all or part of it? When was the last time you put money in a bank and lost all or part of it because the bank was robbed?
When was the last time the fed printed as much money as it wanted, devaluing the money you had put in the bank?
Oh, I see, all the time.
I think the idea is to create demand which will bring the pricing down over time. What will start out as a niche device could easily become the new standard.
Well, it has some other challenges in that regard too:
* If MP3/AAC/AAC+ is "good enough" those devices will always have cheaper storage and will undercut the Pono, even if its price does come down. And my phone already supports all those formats out of the box, and can pull the content from the cloud with album art.
* I wonder how the battery life is, becauseas an enthusiast I've used devices that support FLAC before, and without hardware support like most products have for MP3 I found that they tend to run hotter and battery life is shorter.
* All major online stores deliver music in lossy formats. Most people have libraries of MP3s. Those libraries don't swallow their hard drive.
Again, don't get me wrong, a lossless world would be nice, but I think lossless has to at least arrive in the online stores first, and I doubt this device will be what drives that, given its initial price point and zero market share.
Also, Neil Young have never given a fuck about what other people think.
Well, he has to care about what his target market are actually willing to fork out for in sufficient numbers. I guess we'll see.
I read the other day that these units are going to go for about $400 a piece. While I myself am an audiophile at heart, I just can't see the use cases for this that makes it worth the money.
For a start, when I'm on the go, unless I'm in a plane (which I'm not very often), I can't use noise-cancelling headphones or I have little situational awareness, and the benefit of this higher fidelity is lost. If I'm sitting at my computer, I'd rather access my library through the computer via a nicer interface and still be able to hear the audio for videos I play etc., and I don't have to worry about plugging in or running down batteries.
So I'm left wondering where are the occasions when I'd really benefit from the higher quality on the go, how frequently do they arise, and is it worth the money for more pristine sound in just those cases?
Also, the damn thing is triangular. Where am I supposed to be putting this? It's not going in a pocket alongside my smartphone...
For me, it's nice that someone is trying to produce a product with a higher audio quality, but I don't see myself buying one.
Why do these smart, quantitatively trained engineers, who could help cure cancer or fix healthcare.gov, want to work for a sexting app?
Because as an employee in America, your CEO makes on average over 273x your pay, whereas if you join a startup early enough you stand a chance of actually benefiting from your companies success.
Next stupid question?
now can we encrypt all traffic by default?
Are we seriously discussing how to dedupe files based on a hash here?
News for nerds, stuff that matters, questions that belong in a forum where people answer things you couldn't be bothered to Google.
Not only that, but notice that the demo video conveniently has them moving a set of cups behind the screen, none of which are blue. The glaring omission here is what happens if something blue does get moved behind the display - like say when you're out driving and a blue car goes past, or you look at the sky? Does that get badly distorted/dimmed? And if so, and I want an RGB version of this, what happens?
It would be sweet if you could project e.g. IR light at it and have that come out with a frequency shift, but that doesn't seem to be what's happening.
I wouldn't be complaining, this is great! Diff all the common code. Hopefully you'll turn up the Chinese backdoors readily, and maybe they've also been smart enough to close some of the US ones, identifying those also.
To add to this, I explicitly *do not want* the device holding my keys attached to/addressable via the network. NAS is out.
Sounds great. Where's the guarantee of no NSA backdoor ?
Not only that, but what if I don't want AES? What if I want one of the other algorithms, or a chain? What about different modes of operation, like XTS, that are added over time? How do I test this hardware implementation does what it says it does?
I can look at the code for the pi easily. Firmware for a hardware device, if anyone even gets access to it?
Sure, assuming you want to share your mounted volumes, you don't mind your decrypted files traveling over the network via whatever protocol your desktop OS is compatible with and its associated security model, and it handled all the underlying file systems you wanted to mount volumes on, and all the code to support mounting all those base file systems was trusted and fully audited too, and the act of running a samba server or something and all of the auth code that might go along with supporting the stack etc. didn't concern you, and you didn't care if the volumes it was mounting from might contain exploits against the Pi, etc.
The more you support, the harder it is to audit, the harder it is to secure, the easier it gets to exploit.
There's already a market for Pi cases, I don't see why not..
TrueCrypt has to keep the keys somewhere so long as a volume is mounted. Whatever happens, so long as it's not currently on the CPU (and potentially even if it is), something that can read its data structures is always going to be able to find the keys in RAM if the structure is known. Maybe if TrueCrypt has some crazy polymorphic engine and corresponding polymorphic data structure that changed on every run it could get very difficult, but probably not impossible, to extract them.
Given that we're in an era of low-cost portable devices (Raspberry-Pi, BeagleBoard, etc.), it would be really nice if TrueCrypt could implement a driver that passed data off to an external, open-source device for processing that held the keys in its own memory, and provided no other service than to perform the cryptographic functions and hand back the data. It would be slower, but at least then you don't have the keys in memory on a general purpose computer running browsers, java, flash, adobe reader, etc. etc.
Take one of those devices and attach a small screen to them and you could enter your passphrase using a keyboard attached directly to them, and use a keyfile on a flash stick plugged into the USB port too. The distro powering all of this could be minimal and audited.
Or maybe it is because the exploits they were using were made specifically for Windows, and not Linux .
You miss the point entirely. Of course they were exploits made for Windows. They were targetting Windows-based devices. They didn't attack the devices because they ran Windows. They attacked them because they wanted the data. They would have attacked them if they had ran Linux, too.
If the entire system was Linux it may have been harder all around to get the data.
Why, because Linux is magic? They would need to find just one exploit that let's them get enough privileges to read the memory. That exploit could be in Linux, that exploit could be in the POS software that runs on Linux.
I'm no Windows CE fanboy, believe me, but Linux doesn't make this problem go away via voodoo. This should be a story about securing their POS network, IDS, systems monitoring, how payment devices and the code that runs on them is verified, etc.