Sure. Briefly, Micheal sucks. The Michael MIC sucks so badly in ways we know about that the spec says you need to drop the connection for 1 minute if you detect any possible tampering. It was chosen in order to be able to be implemented on the hardware of the day without much performance loss, not for security. WPA with TKIP is still considered strong, though theoretically attackable for today, but I will be greatly surprised (as would the designer of the MIC) if it lasts much longer. Once the MIC falls, the scheme becomes open to similar attacks that killed WEP.
The plan espoused by most wlan security people is get the heck off WEP 5 years ago towards something stronger, and be planning all your new equipment purchases in order to get off of WPA-TKIP to WPA2-AES soon.
Here's a supporting blurb from the 802.11i standard that defines the basis for WPA and WPA2:
The TKIP MIC trades off security in favor of implementability on pre-RSNA devices. Michael provides only weak protection against active attacks. A failure of the MIC in a received MSDU indicates a probable active attack. A successful attack against the MIC would mean an attacker could inject forged data frames and perform further effective attacks against the encryption key itself. If TKIP implementation detects a probable active attack, TKIP shall take countermeasures as specified in this subclause. These countermeasures accomplish the following goals:
MIC failure events should be logged as a security-relevant matter. A MIC failure is an almost certain indication of an active attack and warrants a follow-up by the system administrator.
The rate of MIC failures must be kept below two per minute. This implies that STAs and APs detecting two MIC failure events within 60 s must disable all receptions using TKIP for a period of 60 s. The slowdown makes it difficult for an attacker to make a large number of forgery attempts in a short time.
As an additional security feature, the PTK and, in the case of the Authenticator, the GTK should be changed.
The confidentiality and integrity mechanisms of TKIP are not as robust as those of CCMP. TKIP is designed to operate within the hardware limitations of a broad class of pre-RSNA devices. TKIP is suitable for firmware-only, hardware-compatible upgrade of fielded equipment. RSNA devices should only use TKIP when communicating with devices that are unable or not configured to communicate using CCMP.
http://hacketyhack.net/ is a tool that makes it easy for students to make things relevant to today. It is a ruby based learning environment that makes web (producing and consuming http) and gui programming very simple, and lets non-programmers quickly make things that they consider useful and cool. Highly recommended for introductory programming.
WPA-TKIP was built as a "transitional" standard. It is good enough for today, but we expect that to not last for very long.
WEP=breakable by your grandma. WPA-TKIP = very little security margin, was designed for a 5 year "transitional" period to move to AES. Not recommended for long term or high security use. WPA2-AES = strong.
HTTP sucks too, but we use it because we all use it. Whatever we want to build gets a http implementation simply because everyone else uses it and understands it, and interoperability is king. In fact, a web service like http/SSL implementation is the only other real contender for a large scale PKI that has a snowball's chance in hell of being adopted. If DNSSEC fizzles out, I'll try that way.
DNSSEC is the best shot we have at world scale PKI because it's an incremental add-on to something we already have, and solves a real problem that exists in DNS at the same time. It is the most robust way to shore up DNS for the long term against all non-DOS attacks. (DNSSEC makes DOS easier, and fails horribly on that count. Elliptic Curve Crypto will help somewhat by shrinking key size vs RSA based keys)
Yes, it will be "just another CA infrastructure", but is the one shot we have in the near future at getting such a thing deployed globally.
Yes, DNS is not the ideal CA infrastructure, but it's the best one that has a chance at life. We want to secure DNS, and on the side we get global PKI almost for free. We're not going to get this kind of chance again for a long time.
I believe you missed what I said, or at least what I intended to say.
DNSSEC enables using DNS as the method of protection from MITM for other applications.
With DNSSEC you can distribute your SSH fingerprint in a signed DNS record. That would enable your application (SSH) to have a secure connection that can even withstand a MITM attack as long as you can verify the DNS signing keys, irregardless of whether or not you've ever connected to that server before.
The same sort of system can be used for email signing keys, IPSEC keys or anything else you want to distribute in an authenticated fashion.
I agree that DNSSEC to enable secure DNS alone is overkill. If we were only fixing what we have, I'd do it your way. What I believe what you are missing is the potential a secure, distributed, scalable database founded on a robust PKI could have on how we interact with each other.
DNSSEC is more then just a way to keep people from redirecting you from www.google.com to evilsite.com, it's a technology that can be used to enable authentication and trust on an Internet wide scale. It is a game changer, and gives us something we never have had before.
I agree that your plan would mostly shore up DNS, but we would miss the opportunity we have to create something so much larger then simply the internet phone book. DNSSEC has the potential to bring sweeping change to our industry, and much greater security to all of our lives.
I have not fully digested your draft, but I believe you are right. There are many proposed solutions that shore up DNS somewhat, as long as our random number generators are strong. That has traditionally proved difficult, and the random number generators have been the primary attack point time and time again. I also think that creating the solution by only looking at recent DNS attacks is short sighted. DNS has the possibility of becoming so much more then it currently is, if we can trust it.
We have leverage to push for a secure system now. After this crisis is adverted, we will have to live with whatever we create for a LONG time. I for one vote fixing it in the strongest way available. Why not push for the one that gives a true, auditable PKI that can be used to secure the worlds most distributed database?
The potential for a secure DNS goes way beyond just name lookups, it can enable stronger trust in SSH, opportunistic IPSEC, strong email encryption and spam fighting technologies, and many more things that have yet to be created.
If it's "almost secure" against "most threats" we don't get the benefits of a comprehensive PKI.
DNSSEC is a pain in the butt, I realize that. It also has the potential to revolutionize how we use and secure the Internet. For me that trade-off is worth it.
Ok, here's the rub. If your plane is built or programmed in such a way that small amounts of EMF is going to hurt or kill people, you need to either fix the plane or ban all electronics. If I can't take my water and knitting needles on the plane, I sure as heck shouldn't be able to bring on something that will cause it to crash.
Banning all electronics will keep people from flying, so really, we have no choice but to fix the airplane hardware and or software to deal with the EMF.
Note there are special cases, like landing purely by instruments, where it is impossible to deal with all EMF, but those exceptions should be the exceptions. In normal flight if 500mW can cause massive injuries, something is SERIOUSLY wrong.
It IS the same idea as opportunistic encryption, already supported in FreeS/WAN and OpenSWAN IPSEC . The FreeS/WAN project died out specifically because the creator was disappointed that no one started using the Opportunistic Encryption portion of the software. See the FreeS/WAN history page for details. It's great technology, but: 1)not secure until we have secure DNS. 2)somewhat computationally intensive 3)somewhat complex setup
We can fix the first part with DNSSEC. Unfortunately that standard is not getting uptake primarily due to the political issue of who will be in control of the signing key for the root servers.
The 2nd and 3rd issues are what this new project is trying to solve. Unfortunately, by not using already deployed and tested standards like IPSEC, they face an even harder uphill climb then FreeS/WAN did.
I'm of the cypherpunk persuasion, and am doing all I can to push DNSSEC to help enable cool technologies like this, but I realize the rest of the world quite honestly doesn't give a crap. Here's to keeping the dream alive though!
Strange, I spend most of my day finding security holes in applications written in Java and C#.
Certain classes of attack are made difficult by bounds checking in virtual machine run languages, but let me assure you they are still full of logic flaws and other security holes.
There is no language that can compensate for people who don't know and/or don't care about security. There are tools and frameworks that can help people who do know and care however.
Yeah, that part wasn't anywhere near as bad as it has been made out to be. It's a reasonable analogy for a non-technical audience. The rest of it IS really bad though:
"Ten movies streaming across that, that Internet, and what happens to your own personal Internet? I just the other day got... an Internet was sent by my staff at 10 o'clock in the morning on Friday. I got it yesterday [Tuesday]. Why? Why? Because it got tangled up in a big ball with all these things going on the Internet commercially. "
I tell you, all the Internets I get come faster then that.. I guess Thunderbird is a good Internet pipe.
This is also why gmail, Cloudmark, and other hosted spam filtering works so well. Spam filtering works better as the number of inputs grows, and it is the ideal candidate for outsourcing. On the other hand, email tends to have sensitive information in it, and outsourcing is a little scary. It's always a trade off..
Once again, the benefits of small companies shine through: If there's too much work, we either:
1) Roll in our piles of money, 2) Subcontract it, or 3) Turn down some jobs.
And we get to choose which option we want.
On the other hand, no matter what size company you are in, if you're working too much and/or not making enough money, you need to either improve your skills, change jobs, or change careers. If you are intelligent, motivated, and willing to learn there is a good fit for you out there somewhere. It usually takes some hard work and sacrifice to find it and get your foot in the door though.
Compensation should absolutely be based on performance, not seat warming. That's the idea behind why we pay more senior people more, because we assume they perform better. The problem is we suck at rating performance. This is why it often makes sense for people with extraordinary talent to start their own enterprises, as entrepreneurship does pay based on results. Unfortunately, I'm not sure I'm quite that good, and am happy to share the work, risk, and rewards with others at the moment.
There are 2 ways to be paid: Based on Effort, or based on Results. By and large, great employees want to be judged on results, and mediocre ones want to be judges based on effort. The problem is in many fields (including most IT jobs) it is difficult to turn results into a number you can be paid based on, so the industry by and large rewards effort instead. That's one of the main reasons I work for a small company: We value results over effort. If I can get my job done in 1/2 the time allotted, that's great. If it takes me 2x as long, sucks for me. So it puts positive pressure on my to improve and be more productive in less time, the exact opposite of the pressure at most companies.
Toyota, Honda, and Nissan make the most reliable cars, in that order. This also holds with their respective "high end" brands: Lexus, Acura, and Infinity. The Germans made the best cars in the 80s and earlier, but Japan has taken over. Now, BMW's have a nice ride, and are excellent cars for a while, but as they age they spend a lot more time in the shop. I keep my cars for 10-20 years(right now driving a 90 Corolla and a 2005 Scion Xb), so I guess I'm in the minority, but Toyotas for me are a much better value for their long term reliability. I agree with your idea though, McDonalds and Subway are pants.;-)
If that doesn't work, the Channel Master CM 4228 is the best UHF antenna out there, and also covers high VHF much better then other "DTV" antennas.
That antenna, plus a rotator and decent height will give you best possible reception in most areas.
Note that the receiver sensitivity plays a large part also. I have two different DTV receivers, one for my MythTV box and one analog converter. One of them gets a lot more stations then the other, and less dropouts on the marginal ones. The Zenith DTT901 is the analog converter, and highly recommended for it's reception. Also cost me $10 after the FCC coupon.
For DNSSEC to work, you need either: 1)Signed root 2)signed TLDs with out of band pre-verification 3)DLV.
1) is the future. 2) and 3) are what we are stuck with today, so I'll explain them.
DNSSEC can be rooted anywhere you like, but the lower down the tree you go from the root the more keys you have to manually verify. For.gov to be secure, for example, every recursive DNS server operator would have to manually verify and install the.gov key. And they'd have to update it periodically, probably about yearly. For 2) to work, every DNS op would have to be on top of key rotation, or an out of band verification tool could be written that would depend on GPG, SSL, or other established crypto for verification.
DLV is a solution where someone besides the actual DNS root is treated as the DNSSEC root for anyone who submits their key to the DLV. Right now ISC runs one of these, available here. Previously, VeriSign ran a pilot, but dropped it. Apparently they saw no good way to monetize the service.
Eventually the actual DNS root will be signed, and there is lots of talk about it at the moment, but little action. St the moment.org,.arpa(reverse lookup), and.gov are moving to deploy DNSSEC themselves.
Note that the root signing issue is more political (i.e. Who holds the keys?) then technical at this point.
Which is why I'm not too worried about every being without employment, even if joe average coder stops sucking so bad. So many security/risk management employees have never been involved in actually getting their hands dirty and building things. Most don't understand how it is their companies make money, so they don't really know how to value the risks against their organization. Those of us who have the security skills, business experience, and salesmanship to both design good policies and get buy-in are quite rare.
Security/risk management isn't going away, but it does have to grow up and learn its place in the world.
I work in security, and would love to be out of a job. Or at least be doing the last 5% of integration testing after everyone else has done their job well.
Security in a nutshell is just coming behind "software engineeers, database admins, sys admins, and network engineers" and making sure they did their jobs correctly.
The sad part is how little of what we test is actually designed with security in mind. Instead of just testing a few edge cases, we often end up finding problems just about everywhere it was possible to find problems.
There are organizations who do have a good software development life cycle that includes security at every step, but they are still the minority. Unfortunately the industry is still in a "build it quick, we'll worry about security/scalability/stability/quality later" mode and it shows.
Better then google in this case would be programming.reddit.com. There you will find that python programmers are whiny babies, and you should go use lisp or haskell like a real man. Or someone will helpfully comment that "IDE's are hard, lets go shopping!"
But in all seriousness, the MOST of the folks at programming.reddit.com are pretty helpful, and that is a better forum for programming related questions then slashdot at the moment.
Note that fuel economy still isn't too bad, if you shop around. I drive a 2006 Scion xB, which averages over 30 MPH and carries everything I want. Toyota no longer makes this model, and the 08 xB is much less fuel efficient, but plenty of the old xBs are still in the market. We're also shopping for a second car, which will probably be a Toyota Yaris or Honda Fit, both of which average in the mid 30s. The Smart ForTwo is interesting, but too expensive for what you get IMHO.
Until very recently, most automotive research went into lowering emissions, improving safety (both to comply with regulations), and adding more sex appeal to cars.
I had one of those old Honda Civics, and it was a fun and cheap car to drive, but it has really bad crash test ratings, had a lot of engine and environmental noise, probably much more polluting then a modern car, etc.
The late 90's to 00's have also been consumed with trying to make cars more masculine with the whole SUV craze. That part is reversible, but making a car that is safe, low polluting, and comfortable does impact gas mileage. It's not just that we don't want to make them, there are real trade offs.
For $10,000 in hardware you can crack 56 bit keys in less then a week. Soon it will be 3 days for equivalent money. 56 bit crypto is dead, dead, dead. See http://www.copacobana.org/ for one such project.
In this case, Microsoft is doing the right thing for it's customers. The fact that it destroys its largest competitors business model is just an unfortunate side effect. I'm conflicted on this one, I hate intrusive ads and tracking, and hate Microsoft's business practices.
The problem is that many programs store temporary working copies on the local disk no matter where you store the main file (Microsoft Office, I'm looking at you...). If you have data worth stealing, full disk + swapfile encryption is the only way to go.
Slashdot Mirror
Sure. Briefly, Micheal sucks.
The Michael MIC sucks so badly in ways we know about that the spec says you need to drop the connection for 1 minute if you detect any possible tampering. It was chosen in order to be able to be implemented on the hardware of the day without much performance loss, not for security.
WPA with TKIP is still considered strong, though theoretically attackable for today, but I will be greatly surprised (as would the designer of the MIC) if it lasts much longer.
Once the MIC falls, the scheme becomes open to similar attacks that killed WEP.
The plan espoused by most wlan security people is get the heck off WEP 5 years ago towards something stronger, and be planning all your new equipment purchases in order to get off of WPA-TKIP to WPA2-AES soon.
Here's a supporting blurb from the 802.11i standard that defines the basis for WPA and WPA2:
The TKIP MIC trades off security in favor of implementability on pre-RSNA devices. Michael provides only weak protection against active attacks. A failure of the MIC in a received MSDU indicates a probable active attack. A successful attack against the MIC would mean an attacker could inject forged data frames and perform further effective attacks against the encryption key itself. If TKIP implementation detects a
probable active attack, TKIP shall take countermeasures as specified in this subclause. These countermeasures accomplish the following goals:
MIC failure events should be logged as a security-relevant matter. A MIC failure is an almost certain indication of an active attack and warrants a follow-up by the system administrator.
The rate of MIC failures must be kept below two per minute. This implies that STAs and APs detecting two MIC failure events within 60 s must disable all receptions using TKIP for a period of 60 s. The slowdown makes it difficult for an attacker to make a large number of forgery attempts in a short time.
As an additional security feature, the PTK and, in the case of the Authenticator, the GTK should be changed.
From http://standards.ieee.org/getieee802/download/802.11i-2004.pdf section 8.3.2.4
Also:
The confidentiality and integrity mechanisms of TKIP are not as robust as those of CCMP. TKIP is designed to operate within the hardware limitations of a broad class of pre-RSNA devices. TKIP is suitable for firmware-only, hardware-compatible upgrade of fielded equipment. RSNA devices should only use TKIP when communicating with devices that are unable or not configured to communicate using CCMP.
Section 8.3.1 of 802.11i-2004, emphasis mine
Also see Security Analysis of Michael: the IEEE 802.11i Message Integrity Code
http://hacketyhack.net/ is a tool that makes it easy for students to make things relevant to today. It is a ruby based learning environment that makes web (producing and consuming http) and gui programming very simple, and lets non-programmers quickly make things that they consider useful and cool.
Highly recommended for introductory programming.
WPA-TKIP was built as a "transitional" standard. It is good enough for today, but we expect that to not last for very long.
WEP=breakable by your grandma.
WPA-TKIP = very little security margin, was designed for a 5 year "transitional" period to move to AES. Not recommended for long term or high security use.
WPA2-AES = strong.
HTTP sucks too, but we use it because we all use it. Whatever we want to build gets a http implementation simply because everyone else uses it and understands it, and interoperability is king. In fact, a web service like http/SSL implementation is the only other real contender for a large scale PKI that has a snowball's chance in hell of being adopted. If DNSSEC fizzles out, I'll try that way.
DNSSEC is the best shot we have at world scale PKI because it's an incremental add-on to something we already have, and solves a real problem that exists in DNS at the same time. It is the most robust way to shore up DNS for the long term against all non-DOS attacks. (DNSSEC makes DOS easier, and fails horribly on that count. Elliptic Curve Crypto will help somewhat by shrinking key size vs RSA based keys)
Yes, it will be "just another CA infrastructure", but is the one shot we have in the near future at getting such a thing deployed globally.
Yes, DNS is not the ideal CA infrastructure, but it's the best one that has a chance at life. We want to secure DNS, and on the side we get global PKI almost for free. We're not going to get this kind of chance again for a long time.
I believe you missed what I said, or at least what I intended to say.
DNSSEC enables using DNS as the method of protection from MITM for other applications.
With DNSSEC you can distribute your SSH fingerprint in a signed DNS record. That would enable your application (SSH) to have a secure connection that can even withstand a MITM attack as long as you can verify the DNS signing keys, irregardless of whether or not you've ever connected to that server before.
The same sort of system can be used for email signing keys, IPSEC keys or anything else you want to distribute in an authenticated fashion.
I agree that DNSSEC to enable secure DNS alone is overkill. If we were only fixing what we have, I'd do it your way. What I believe what you are missing is the potential a secure, distributed, scalable database founded on a robust PKI could have on how we interact with each other.
DNSSEC is more then just a way to keep people from redirecting you from www.google.com to evilsite.com, it's a technology that can be used to enable authentication and trust on an Internet wide scale. It is a game changer, and gives us something we never have had before.
I agree that your plan would mostly shore up DNS, but we would miss the opportunity we have to create something so much larger then simply the internet phone book. DNSSEC has the potential to bring sweeping change to our industry, and much greater security to all of our lives.
I have not fully digested your draft, but I believe you are right. There are many proposed solutions that shore up DNS somewhat, as long as our random number generators are strong. That has traditionally proved difficult, and the random number generators have been the primary attack point time and time again. I also think that creating the solution by only looking at recent DNS attacks is short sighted. DNS has the possibility of becoming so much more then it currently is, if we can trust it.
We have leverage to push for a secure system now. After this crisis is adverted, we will have to live with whatever we create for a LONG time. I for one vote fixing it in the strongest way available. Why not push for the one that gives a true, auditable PKI that can be used to secure the worlds most distributed database?
The potential for a secure DNS goes way beyond just name lookups, it can enable stronger trust in SSH, opportunistic IPSEC, strong email encryption and spam fighting technologies, and many more things that have yet to be created.
If it's "almost secure" against "most threats" we don't get the benefits of a comprehensive PKI.
DNSSEC is a pain in the butt, I realize that. It also has the potential to revolutionize how we use and secure the Internet. For me that trade-off is worth it.
Ok, here's the rub. If your plane is built or programmed in such a way that small amounts of EMF is going to hurt or kill people, you need to either fix the plane or ban all electronics. If I can't take my water and knitting needles on the plane, I sure as heck shouldn't be able to bring on something that will cause it to crash.
Banning all electronics will keep people from flying, so really, we have no choice but to fix the airplane hardware and or software to deal with the EMF.
Note there are special cases, like landing purely by instruments, where it is impossible to deal with all EMF, but those exceptions should be the exceptions. In normal flight if 500mW can cause massive injuries, something is SERIOUSLY wrong.
It IS the same idea as opportunistic encryption, already supported in FreeS/WAN and OpenSWAN IPSEC .
The FreeS/WAN project died out specifically because the creator was disappointed that no one started using the Opportunistic Encryption portion of the software. See the FreeS/WAN history page for details.
It's great technology, but:
1)not secure until we have secure DNS.
2)somewhat computationally intensive
3)somewhat complex setup
We can fix the first part with DNSSEC. Unfortunately that standard is not getting uptake primarily due to the political issue of who will be in control of the signing key for the root servers.
The 2nd and 3rd issues are what this new project is trying to solve. Unfortunately, by not using already deployed and tested standards like IPSEC, they face an even harder uphill climb then FreeS/WAN did.
I'm of the cypherpunk persuasion, and am doing all I can to push DNSSEC to help enable cool technologies like this, but I realize the rest of the world quite honestly doesn't give a crap. Here's to keeping the dream alive though!
Strange, I spend most of my day finding security holes in applications written in Java and C#.
Certain classes of attack are made difficult by bounds checking in virtual machine run languages, but let me assure you they are still full of logic flaws and other security holes.
There is no language that can compensate for people who don't know and/or don't care about security. There are tools and frameworks that can help people who do know and care however.
Yeah, that part wasn't anywhere near as bad as it has been made out to be. It's a reasonable analogy for a non-technical audience. The rest of it IS really bad though:
"Ten movies streaming across that, that Internet, and what happens to your own personal Internet? I just the other day got... an Internet was sent by my staff at 10 o'clock in the morning on Friday. I got it yesterday [Tuesday]. Why? Why? Because it got tangled up in a big ball with all these things going on the Internet commercially. "
I tell you, all the Internets I get come faster then that.. I guess Thunderbird is a good Internet pipe.
This is also why gmail, Cloudmark, and other hosted spam filtering works so well. Spam filtering works better as the number of inputs grows, and it is the ideal candidate for outsourcing.
On the other hand, email tends to have sensitive information in it, and outsourcing is a little scary.
It's always a trade off..
This comic nails the public's reaction to this:
http://www.sinfest.net/archive_page.php?comicID=2947
Once again, the benefits of small companies shine through: If there's too much work, we either:
1) Roll in our piles of money,
2) Subcontract it, or
3) Turn down some jobs.
And we get to choose which option we want.
On the other hand, no matter what size company you are in, if you're working too much and/or not making enough money, you need to either improve your skills, change jobs, or change careers.
If you are intelligent, motivated, and willing to learn there is a good fit for you out there somewhere. It usually takes some hard work and sacrifice to find it and get your foot in the door though.
Compensation should absolutely be based on performance, not seat warming. That's the idea behind why we pay more senior people more, because we assume they perform better. The problem is we suck at rating performance.
This is why it often makes sense for people with extraordinary talent to start their own enterprises, as entrepreneurship does pay based on results.
Unfortunately, I'm not sure I'm quite that good, and am happy to share the work, risk, and rewards with others at the moment.
There are 2 ways to be paid: Based on Effort, or based on Results.
By and large, great employees want to be judged on results, and mediocre ones want to be judges based on effort. The problem is in many fields (including most IT jobs) it is difficult to turn results into a number you can be paid based on, so the industry by and large rewards effort instead.
That's one of the main reasons I work for a small company: We value results over effort. If I can get my job done in 1/2 the time allotted, that's great. If it takes me 2x as long, sucks for me. So it puts positive pressure on my to improve and be more productive in less time, the exact opposite of the pressure at most companies.
Toyota, Honda, and Nissan make the most reliable cars, in that order. This also holds with their respective "high end" brands: Lexus, Acura, and Infinity.
The Germans made the best cars in the 80s and earlier, but Japan has taken over.
Now, BMW's have a nice ride, and are excellent cars for a while, but as they age they spend a lot more time in the shop.
I keep my cars for 10-20 years(right now driving a 90 Corolla and a 2005 Scion Xb), so I guess I'm in the minority, but Toyotas for me are a much better value for their long term reliability.
I agree with your idea though, McDonalds and Subway are pants.;-)
If that doesn't work, the Channel Master CM 4228 is the best UHF antenna out there, and also covers high VHF much better then other "DTV" antennas.
That antenna, plus a rotator and decent height will give you best possible reception in most areas.
Note that the receiver sensitivity plays a large part also. I have two different DTV receivers, one for my MythTV box and one analog converter. One of them gets a lot more stations then the other, and less dropouts on the marginal ones. The Zenith DTT901 is the analog converter, and highly recommended for it's reception. Also cost me $10 after the FCC coupon.
For DNSSEC to work, you need either:
1)Signed root
2)signed TLDs with out of band pre-verification
3)DLV.
1) is the future.
2) and 3) are what we are stuck with today, so I'll explain them.
DNSSEC can be rooted anywhere you like, but the lower down the tree you go from the root the more keys you have to manually verify. For .gov to be secure, for example, every recursive DNS server operator would have to manually verify and install the .gov key. And they'd have to update it periodically, probably about yearly. For 2) to work, every DNS op would have to be on top of key rotation, or an out of band verification tool could be written that would depend on GPG, SSL, or other established crypto for verification.
DLV is a solution where someone besides the actual DNS root is treated as the DNSSEC root for anyone who submits their key to the DLV. Right now ISC runs one of these, available here. Previously, VeriSign ran a pilot, but dropped it. Apparently they saw no good way to monetize the service.
Eventually the actual DNS root will be signed, and there is lots of talk about it at the moment, but little action. .org, .arpa(reverse lookup), and .gov are moving to deploy DNSSEC themselves.
St the moment
Note that the root signing issue is more political (i.e. Who holds the keys?) then technical at this point.
Which is why I'm not too worried about every being without employment, even if joe average coder stops sucking so bad.
So many security/risk management employees have never been involved in actually getting their hands dirty and building things. Most don't understand how it is their companies make money, so they don't really know how to value the risks against their organization.
Those of us who have the security skills, business experience, and salesmanship to both design good policies and get buy-in are quite rare.
Security/risk management isn't going away, but it does have to grow up and learn its place in the world.
I work in security, and would love to be out of a job. Or at least be doing the last 5% of integration testing after everyone else has done their job well.
Security in a nutshell is just coming behind "software engineeers, database admins, sys admins, and network engineers" and making sure they did their jobs correctly.
The sad part is how little of what we test is actually designed with security in mind. Instead of just testing a few edge cases, we often end up finding problems just about everywhere it was possible to find problems.
There are organizations who do have a good software development life cycle that includes security at every step, but they are still the minority.
Unfortunately the industry is still in a "build it quick, we'll worry about security/scalability/stability/quality later" mode and it shows.
Better then google in this case would be programming.reddit.com.
There you will find that python programmers are whiny babies, and you should go use lisp or haskell like a real man.
Or someone will helpfully comment that "IDE's are hard, lets go shopping!"
But in all seriousness, the MOST of the folks at programming.reddit.com are pretty helpful, and that is a better forum for programming related questions then slashdot at the moment.
Note that fuel economy still isn't too bad, if you shop around.
I drive a 2006 Scion xB, which averages over 30 MPH and carries everything I want. Toyota no longer makes this model, and the 08 xB is much less fuel efficient, but plenty of the old xBs are still in the market.
We're also shopping for a second car, which will probably be a Toyota Yaris or Honda Fit, both of which average in the mid 30s. The Smart ForTwo is interesting, but too expensive for what you get IMHO.
Until very recently, most automotive research went into lowering emissions, improving safety (both to comply with regulations), and adding more sex appeal to cars.
I had one of those old Honda Civics, and it was a fun and cheap car to drive, but it has really bad crash test ratings, had a lot of engine and environmental noise, probably much more polluting then a modern car, etc.
The late 90's to 00's have also been consumed with trying to make cars more masculine with the whole SUV craze. That part is reversible, but making a car that is safe, low polluting, and comfortable does impact gas mileage. It's not just that we don't want to make them, there are real trade offs.
For $10,000 in hardware you can crack 56 bit keys in less then a week. Soon it will be 3 days for equivalent money.
56 bit crypto is dead, dead, dead.
See http://www.copacobana.org/ for one such project.
In this case, Microsoft is doing the right thing for it's customers.
The fact that it destroys its largest competitors business model is just an unfortunate side effect.
I'm conflicted on this one, I hate intrusive ads and tracking, and hate Microsoft's business practices.
The problem is that many programs store temporary working copies on the local disk no matter where you store the main file (Microsoft Office, I'm looking at you...).
If you have data worth stealing, full disk + swapfile encryption is the only way to go.