Slashdot Mirror

The CPU in Llano is 2 generations back... with Athlon II. Beating the pants off Bulldozer is easy for Intel: just find a benchmark optimized for single threads, compiled with ICC, or weights the single threaded result. One of the major new features, the random number generator, wasn't even tested. Monte Carlo benchmarks, where are you?

If you can set up a public website so secure that no hacker can ever hack, why don't you set one up?

Formally verified web servers have been around for a while.

It is indeed the latter for the reason given above. The dose or ionizing damage is actually much smaller. The cross section or likelihood of interaction/damage decreases quickly with energy according to http://physics.nist.gov/PhysRefData/XrayMassCoef/ComTab/tissue.html

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Since this is about BIND, let me start the inevitable thread about the BIND alternatives.

BIND is the swiss army knife of DNS servers. It has a lot of features and can do pretty much everything. It's also a big binary and sometimes difficult to configure. CVE

Unbound and NSD are a suite of DNS servers from the same people. One (NSD) puts your web page on the Internet; the other (Unbound) looks for web pages on the Internet. NSD CVE Unbound CVE

PowerDNS (which like Unbound/NSD, is two separate programs) has a lot of flexibility with connecting to databases or what not to resolve a DNS name. Used by Wikimedia, among others. CVE

MaraDNS. I think it's the best one, but my opinion is a little biased. It was once a single program, now two separate programs (like Unbound/BSD and PowerDNS) Easy-to-configure; tiny binary suitable for embedded systems. CVE

DjbDNS. Great tiny two-program DNS suite. Hasn't been updated since 2001 and yes, it has security problems (I'm already taking bets that a follow-up to this post will pretend DjbDNS is magically perfectly secure). Zinq is a currently maintained unofficial fork.

There are many many other DNS servers, both open source and non-open source. Rick Moen has a great list of the open-source ones

Facial biometrics rely on a lot of data points, have a look at ANSI/NIST-ITL 1-2007 - a standard that defines how law enforcement agencies exchange data about tattoos, scars, fingerprints, faces... http://www.nist.gov/customcf/get_pdf.cfm?pub_id=51174 (free of charge, there are pictures :-)

Here's the specific excerpt you're interested in (public pic, no need to have a Facebook profile to view it):
https://www.facebook.com/photo.php?fbid=10150344785953020&set=a.129747423019.106694.739418019&type=3&theater

"Now that's a real ROFL!!!" - by mSparks43 (757109) on Wednesday December 28, @05:28AM (#38513254) Homepage

Facts are facts: Like here, I posted them earlier with backing proofs & documentations from reputable sources, & I do so again here now below... simple. No laughs, just facts!

Case-in-Point (to something I posted you said I did not):

I did post a kernel level error security issue problem that's ANDROID has here -> http://linux.slashdot.org/story/10/11/02/2238205/Serious-Security-Bugs-Found-In-Android-Kernel so, so much for your stating I did not. So yes, as you can see (or anyone else reading)? That's happened to ANDROID (& thus Linux too, since ANDROID's a Linux variant itself). I am up to 50++ security issues on ANDROID I posted (and can double it easily if you wish with more) also, & if those security issues, and they are? Then, clearly, they are occurring on ANDROID & are a problem there, no questions asked.

---

"You're the one who brought up Windows & desktop PC's, and hosts files, but still with no real explanation of wtf they have to do with Android" - by mSparks43 (757109) on Wednesday December 28, @05:28AM (#38513254) Homepage

You can use HOSTS files for ANDROID for better speed, security, anonymity to a degree, & even bypass of restrictions online...

(ANDROID, again, is a Linux & has a BSD based IP stack - most all OS do nowadays).

Custom HOSTS files data for use are free & so is HOSTS itself (you have one already). Custom HOSTS file also unquestionably can yield faster websurfing, faster access to sites, safer surfing, & to an extent, more "anonymous" surfing (vs. DNS request logs) & bypass of restrictions (DNSBL).

They're simple to install there using ADB (Android Debugging Bridge) as follows, in not too "broad" of strokes:

Load ADB
Tether your smartphone to your PC
logon with appropriate rights (read/write @ very least)
Use the push command to transfer over your existing hosts file on ANDROID with new custom HOSTS file imported from your PC.

* Done... 4 steps, only a few minutes time, if that.

---

"Going back to what I said earlier "Linux is as secure as you make it" - by mSparks43 (757109) on Wednesday December 28, @05:28AM (#38513254) Homepage

Same with Windows (or MacOS X too): You can "security-harden" them, & especially via "layered-security"/"defense-in-depth" procedures. An hour of time for decades of safer, faster, & better uptime.

---

"i.e. sure there are problems" - by mSparks43 (757109) on Wednesday December 28, @05:28AM (#38513254) Homepage

I list many below. Did you even KNOW that SeLinux (which gives MAC capabilities to Linux for security) is a COPY/IMITATION of Windows NT-based OS since 1992 & the ACL concept? It is... a copy, but a needed one. Windows NT-based OS have been "Orange Book" certified as C2 level secure. Linux has not been since 1992.

More on that shortly, with security detail from documented respectable sources.

---

"but nothing that has been seriously exploited that hadn't already been fixed." - by mSparks43 (757109) on Wednesday December 28, @05:28AM (#38513254) Homepage

WTF? If the Linux sourcecode repository isn't serious, & the 5 CA's that secure SSL for online banking/ecommerce/shopping & such aren't serious, then I don't KNOW what is. Both were breached this year 2011, running Linux....

Also, beg to differ:

Linux's still got issues -> http://web.nvd.nist.gov/view/vuln/search-results?query=Linux+kernel&search_type=all

How ironic that you only mention two of the buildings, considering the WTC report fails to mention (much less attempt to explain!) Building 7 as well!

Why do you say that? The NIST report certainly does.

http://www.nist.gov/el/disasterstudies/wtc/faqs_wtc7.cfm

Only one Slashdot do you need to be told that "metric tons" don't exist - they are tonnes, and require no prefix.

Authorities who disagree with you include:
The Encyclopedia Britannica
The Cambridge Advanced Learner's Dictionary & Thesaurus
The US National Institute of Standards and Technology
and about 16.5 million other hits on Google.

For some reason, having the homonyms ton/tonne variously refer to a short ton (907.18474 kg), a tonne (1000 kg), or long ton (1,016.0469088 kg a.k.a. English ton) vexes some people. They prefer to specify a "metric ton" rather than so overemphasize "tonne" that they sound as if they have a speech impediment.

The unit of measure exists by virtue of its pervasive use. The fact that you prefer an alternate equivalent does nothing to change that fact.

Only one of the holes -- CVE-2011-2444 -- is a hole in Flash. All of the other holes are things like use-after-free and what not in Chrome's code base.

Not according to the national vulnerability database. Here is the score for the last three months:

• Internet Explorer: 15 security holes
• Chrome: 76 security holes
• Firefox: 31 security holes

We can argue that it makes more sense to look at holes over the last year instead of over the last three months, but the evidence indicates that Chrome is the least secure and IE is the most secure. (Security holes by version doesn't make sense for Chrome, since it changes its version number so quickly. Ditto with Firefox).

Not according to the national vulnerability database. Here is the score for the last three months:

• Internet Explorer: 15 security holes
• Chrome: 76 security holes
• Firefox: 31 security holes

We can argue that it makes more sense to look at holes over the last year instead of over the last three months, but the evidence indicates that Chrome is the least secure and IE is the most secure. (Security holes by version doesn't make sense for Chrome, since it changes its version number so quickly. Ditto with Firefox).

Not according to the national vulnerability database. Here is the score for the last three months:

• Internet Explorer: 15 security holes
• Chrome: 76 security holes
• Firefox: 31 security holes

We can argue that it makes more sense to look at holes over the last year instead of over the last three months, but the evidence indicates that Chrome is the least secure and IE is the most secure. (Security holes by version doesn't make sense for Chrome, since it changes its version number so quickly. Ditto with Firefox).

"So, nothing even remotely related to the current article ?" - by Anonymous Coward on Thursday December 08, @04:09PM (#38307986)

The article's on CA's, security, & yes, even Linux (because the "hacked/cracked" servers RUN LINUX at GEMNET): THUS, as to what I posted (all fact based, deals in CA's that run LINUX and that were security breached... period) = VERY pertinent, on those very grounds, alone...

APK

P.S.=>

I disagree, you sound like those guys that scream "OMFG Windows was pwned ... again" because some guy didn't put an admin password on his Windows XP install or because IE has a flaw ..., except that here the component hacked (mysql database with no password + phpmyadmin accessible from the internet) is not even part of linux. And don't tell me IE is not part of Windows, they got sued and lost big because it is.

"Wrong. the Linux 2.6 kernel has more *KNOWN* and *PUBLICLY PUBLISHED* security vulnerabilities (although some linux fanboys might argue on the definition of "security vulnerabilities"). - by Anonymous Coward on Thursday December 08, @04:09PM (#38307986)

I agree on UNKNOWN security vulnerabilities, but I never mentioned those - I STATED KNOWN UNPATCHED SECURITY VULNERABILITIES LISTED @ SECUNIA.COM...

So, would you prefer I use the National Vulnerabilities Database here instead -> http://web.nvd.nist.gov/view/vuln/search-results?query=Linux+kernel&search_type=all&cves=on from NIST??

I could you know... however, later than "2.6 mainstream base code" versions of the Linux kernel patch the holes, but, that assuming that those that use it actually DID update their OS (that's largely a manual thing via rpm, yum, apt-get etc. on Linux usually).

Problem is, when you UPDATE a Linux kernel? It also BREAKS APPS ON IT, like mad too... I've had it happen!

---

"Microsoft keeps their hidden, deeply buried (the so-called "security" by obscurity)." - by Anonymous Coward on Thursday December 08, @04:09PM (#38307986)

Rightfully so - they're NOT an "Open 'SORES'" based company, & their sourcecode's their lifeblood... by way of comparison, regarding sourcecode of current OS source? Linux isn't doing well there, RECENTLY TOO, mind you, either:

---

KERNEL.ORG COMPROMISED:

http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised

---

"Proof's in the pudding", right there above, recently too mind you (again, per my usual, just facts)...

I'll also tell you, right now, for a FACT & from experience here (17++ yrs. professionally coding mostly)?

Sending "Open 'SORES'" code into a compiler & step-tracing it (because you have the actual sources) is far, Far, FAR EASIER to find "security bugs" in, than is disassembly of closed source code (or even fuzzing it sending it data it may not be able to handle)...

Closed source actually works BETTER for security, especially in that regard in fact, because it's "closed"... period!

... apk

Again I disagree, as Secunia themselves said (If I remember correctly, because some idiot used their figures as sound proof of Firefox being less secure than IE) : this is comparing oranges and apples. And the fact that you use trolling terms such as "Open Sores" doesn't help me to try to understand your argument. Flaws in closed source can be harder to find, but it also mean that we (user) cannot check for them either and that we don't know when they're patched or what is or is not patched. Security through obscurity is an illusion (just as much as blindly believing linux is perfectly secure).
Car analogy: if someone wants to steal A car, he will take easy one. If someone wants to steal YOUR car, he will steal it, period.

"So, nothing even remotely related to the current article ?" - by Anonymous Coward on Thursday December 08, @04:09PM (#38307986)

The article's on CA's, security, & yes, even Linux (because the "hacked/cracked" servers RUN LINUX at GEMNET): THUS, as to what I posted (all fact based, deals in CA's that run LINUX and that were security breached... period) = VERY pertinent, on those very grounds, alone...

APK

P.S.=>

"Wrong. the Linux 2.6 kernel has more *KNOWN* and *PUBLICLY PUBLISHED* security vulnerabilities (although some linux fanboys might argue on the definition of "security vulnerabilities"). - by Anonymous Coward on Thursday December 08, @04:09PM (#38307986)

I agree on UNKNOWN security vulnerabilities, but I never mentioned those - I STATED KNOWN UNPATCHED SECURITY VULNERABILITIES LISTED @ SECUNIA.COM...

So, would you prefer I use the National Vulnerabilities Database here instead -> http://web.nvd.nist.gov/view/vuln/search-results?query=Linux+kernel&search_type=all&cves=on from NIST??

I could you know... however, later than "2.6 mainstream base code" versions of the Linux kernel patch the holes, but, that assuming that those that use it actually DID update their OS (that's largely a manual thing via rpm, yum, apt-get etc. on Linux usually).

Problem is, when you UPDATE a Linux kernel? It also BREAKS APPS ON IT, like mad too... I've had it happen!

---

"Microsoft keeps their hidden, deeply buried (the so-called "security" by obscurity)." - by Anonymous Coward on Thursday December 08, @04:09PM (#38307986)

Rightfully so - they're NOT an "Open 'SORES'" based company, & their sourcecode's their lifeblood... by way of comparison, regarding sourcecode of current OS source? Linux isn't doing well there, RECENTLY TOO, mind you, either:

---

KERNEL.ORG COMPROMISED:

http://linux.slashdot.org/story/11/08/31/2321232/Kernelorg-Compromised

---

"Proof's in the pudding", right there above, recently too mind you (again, per my usual, just facts)...

I'll also tell you, right now, for a FACT & from experience here (17++ yrs. professionally coding mostly)?

Sending "Open 'SORES'" code into a compiler & step-tracing it (because you have the actual sources) is far, Far, FAR EASIER to find "security bugs" in, than is disassembly of closed source code (or even fuzzing it sending it data it may not be able to handle)...

Closed source actually works BETTER for security, especially in that regard in fact, because it's "closed"... period!

... apk

NIST published SP800-145 (PDF warning) in October with their definition of cloud computing:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

There is an expanded section covering an additional 1.5 pages describing:

• Essential characteristics
  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured service
• Service models
  • Software as a Service (SaaS)
  • Platform as a Service (PaaS)
  • Infrastructure as a Service (IaaS)
• Deployment models
  • Private cloud
  • Community cloud
  • Public cloud
  • Hybrid cloud

OK, so it's not the best-formatted list (I blame Slashdot), but it makes the point. The document is short and abstract, but it at least tries to give a coherent response.

Right, but you should be sure to use the proper units.

1GB equals exactly 1,000,000,000 bytes by definition.

1GiB (notice the 'i') is the one that equals 1,073,741,824 bytes.

It really depends on the terms of the contract. That's what controls. You can theorize and speculate and pontificate all you want, that contract is what they agreed to, and what the government agreed to pay for.

Now, the phrases "sent to an appropriately recognized facility" and "data remanence" make me suspect this is classified information, which would mean the contract is under NISP (National Industrial Security Program) jurisdiction. There are four possible CSAs (Cognizant Security Authorities) -- DoD, DoE, CIA, and NRC. I'm really only familiar with DoD, but I believe the rest follow suit on this. To wit:

Since Oct 2007, when ISL 2007-01 (Industrial Security Letter) was issued, overwrite methods are not acceptable for fixed disks. Degaussing or physical destruction are the only acceptable methods.

Degaussing has to be done using a deguasser which is on the NSA EPL (Evaluated Products List). This generally renders the hard disk inoperable. (Modern hard disks have their servo tracks encoded at the factory, and generally don't have field low-level format capability.)

Physical destruction has to cover the entire recording media. (e.g., "target practice" isn't acceptable.) They generally want the entire recording surface ground off, melted down, shredded to dust, and/or raised above the curie point. You can't just toss it in any old shredder.

You have to provide a certificate of destruction, saying you've done this. Failure to do so results in loss of Security Clearance, loss of contract, loss of future contract opportunities, fines, and/or jail. I wouldn't recommend it.

Now, submitter mentions they're going on to a new contract. If this is DoD, they should check the DD254 to see if it's the same classification derivation. If it is, they should be able to get approval to continue using the old systems. They should have a formal ATO (Approval To Operate) that identifies who to contact.

Now, if I'm way off base, and this isn't classified, then it's still up to what the contract says. There are various government standards that might be called out. NIST 800-88 is one; it allows for sanitization by overwrite, IIRC.

See here:

http://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_recovering_overwritten_data
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf

Zero-fill (full disk, including bad sectors) is good enough unless there's some top-secret spy tech that you need to protect against (SQUID transducers is one thing I heard?)

You are such a duplicitous idiot. I'm sorry to feed a troll. I'm especially sorry I went to so much trouble to feed a troll. Here goes anyway.
You say that:

NOT A SINGLE ONE IS FIXED HERE (& there's 18 OF THEM!) & I'll even QUOTE secunia on that now:

http://secunia.com/advisories/14295/

"Secunia is currently not aware of an updated kernel version addressing the vulnerabilities."

Once again, your reading comprehension and comprehension in general are simply broken. That is an advisory from nearly 6 years ago with incomplete information in the summary. If you bothered to dig deeper than the summary, the links to the CVE's on that page directly state that 9 of those 18 problems are fixed. The other 9 are also fixed, although the information directly on that Secunia page doesn't say so, but other sources do. Since you asked me to "KINDLY SHOW US PROOF THEY ARE FIXED (all 18 of them) as you stated..." (even though the responsibility is yours to prove that information that old is actually correct rather than mine to prove it wrong), here's some additional information:

#1 is covered by CVE-2005-0176, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0176/, which specifically says that it affects only kernel versions 2.6.9 and earlier.

#2 is covered by CVE-2005-0178, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0178/, which specifically says that it affects only kernel versions before 2.6.8.1.

#3 is covered by CVE-2005-0204, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0204/, which specifically says that it affects only kernel versions before 2.6.9

#4 is covered by CVE-2005-0177, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0177/, which specifically says that it affects only kernel versions before 2.6.8.1.

#5 is covered by CVE-2005-0209, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0209/, which specifically says that it affects only kernel version 2.6.8.1.

#6 is covered by CVE-2005-0210, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0210/, which specifically says that it affects only kernel version 2.6.8.1.

#7 is covered by CVE-2005-0449, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0449/, which specifically says that it affects only kernel versions before 2.6.8.1.

#8 is covered by CVE-2005-0839, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0839/, which specifically says that it affects only kernel versions before 2.6.11.

#9 is covered by CVE-2005-0937, which is addressed at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0937, updated 08/21/2010. It It lists affected kernel versions and they stop at 2.6.9.

#10 is covered by CVE-2005-0867, which is addressed at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0867 updated 08/21/2010. It lists affected kernel versions and the only version is 2.6.0. Confirmed fixed in 2.6.9.

#11 is covered by CVE-2005-0135, which is addressed at http://web.nvd.nist.gov/view/vuln/

You are such a duplicitous idiot. I'm sorry to feed a troll. I'm especially sorry I went to so much trouble to feed a troll. Here goes anyway.
You say that:

NOT A SINGLE ONE IS FIXED HERE (& there's 18 OF THEM!) & I'll even QUOTE secunia on that now:

http://secunia.com/advisories/14295/

"Secunia is currently not aware of an updated kernel version addressing the vulnerabilities."

Once again, your reading comprehension and comprehension in general are simply broken. That is an advisory from nearly 6 years ago with incomplete information in the summary. If you bothered to dig deeper than the summary, the links to the CVE's on that page directly state that 9 of those 18 problems are fixed. The other 9 are also fixed, although the information directly on that Secunia page doesn't say so, but other sources do. Since you asked me to "KINDLY SHOW US PROOF THEY ARE FIXED (all 18 of them) as you stated..." (even though the responsibility is yours to prove that information that old is actually correct rather than mine to prove it wrong), here's some additional information:

#1 is covered by CVE-2005-0176, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0176/, which specifically says that it affects only kernel versions 2.6.9 and earlier.

#2 is covered by CVE-2005-0178, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0178/, which specifically says that it affects only kernel versions before 2.6.8.1.

#3 is covered by CVE-2005-0204, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0204/, which specifically says that it affects only kernel versions before 2.6.9

#4 is covered by CVE-2005-0177, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0177/, which specifically says that it affects only kernel versions before 2.6.8.1.

#5 is covered by CVE-2005-0209, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0209/, which specifically says that it affects only kernel version 2.6.8.1.

#6 is covered by CVE-2005-0210, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0210/, which specifically says that it affects only kernel version 2.6.8.1.

#7 is covered by CVE-2005-0449, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0449/, which specifically says that it affects only kernel versions before 2.6.8.1.

#8 is covered by CVE-2005-0839, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0839/, which specifically says that it affects only kernel versions before 2.6.11.

#9 is covered by CVE-2005-0937, which is addressed at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0937, updated 08/21/2010. It It lists affected kernel versions and they stop at 2.6.9.

#10 is covered by CVE-2005-0867, which is addressed at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0867 updated 08/21/2010. It lists affected kernel versions and the only version is 2.6.0. Confirmed fixed in 2.6.9.

#11 is covered by CVE-2005-0135, which is addressed at http://web.nvd.nist.gov/view/vuln/

You are such a duplicitous idiot. I'm sorry to feed a troll. I'm especially sorry I went to so much trouble to feed a troll. Here goes anyway.
You say that:

NOT A SINGLE ONE IS FIXED HERE (& there's 18 OF THEM!) & I'll even QUOTE secunia on that now:

http://secunia.com/advisories/14295/

"Secunia is currently not aware of an updated kernel version addressing the vulnerabilities."

Once again, your reading comprehension and comprehension in general are simply broken. That is an advisory from nearly 6 years ago with incomplete information in the summary. If you bothered to dig deeper than the summary, the links to the CVE's on that page directly state that 9 of those 18 problems are fixed. The other 9 are also fixed, although the information directly on that Secunia page doesn't say so, but other sources do. Since you asked me to "KINDLY SHOW US PROOF THEY ARE FIXED (all 18 of them) as you stated..." (even though the responsibility is yours to prove that information that old is actually correct rather than mine to prove it wrong), here's some additional information:

#1 is covered by CVE-2005-0176, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0176/, which specifically says that it affects only kernel versions 2.6.9 and earlier.

#2 is covered by CVE-2005-0178, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0178/, which specifically says that it affects only kernel versions before 2.6.8.1.

#3 is covered by CVE-2005-0204, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0204/, which specifically says that it affects only kernel versions before 2.6.9

#4 is covered by CVE-2005-0177, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0177/, which specifically says that it affects only kernel versions before 2.6.8.1.

#5 is covered by CVE-2005-0209, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0209/, which specifically says that it affects only kernel version 2.6.8.1.

#6 is covered by CVE-2005-0210, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0210/, which specifically says that it affects only kernel version 2.6.8.1.

#7 is covered by CVE-2005-0449, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0449/, which specifically says that it affects only kernel versions before 2.6.8.1.

#8 is covered by CVE-2005-0839, which is addressed at http://secunia.com/advisories/cve_reference/CVE-2005-0839/, which specifically says that it affects only kernel versions before 2.6.11.

#9 is covered by CVE-2005-0937, which is addressed at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0937, updated 08/21/2010. It It lists affected kernel versions and they stop at 2.6.9.

#10 is covered by CVE-2005-0867, which is addressed at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0867 updated 08/21/2010. It lists affected kernel versions and the only version is 2.6.0. Confirmed fixed in 2.6.9.

#11 is covered by CVE-2005-0135, which is addressed at http://web.nvd.nist.gov/view/vuln/

I am a cryptographic security researcher. I will give some background on this before answering your specific questions. Information security is subject to the same pressures as other forms of conflict. Such pressures are otherwise known as an "escalation", "arms race" or even as "evolution". Cryptography is one such armament in the information security arsenal; and while cryptography is subject to constant pressure of Moore's Law as you quite rightly assert; more cataclysmic changes can occur through leaps in either or both knowledge or capability. I can think of no better example of these notions than the Enigma machine; first developed in the early 1900's but made extensive use of by Germany during the second world war.

The first countermeasure used against Enigma was reverse-engineering. This lead to identification of weaknesses that whittled down the key size from a massive 380 bits to only just 76 bits. A one in 75,557,863,725,914,323,419,136 chance of randomly guessing (brute forcing) the correct key was still well beyond the resources of brute force at the time. This lead to the construction of the Bombe machine (a precursor to the computer) that could perform rapid searches through the keyspace for given known plaintexts and keys. Enigma was eventually broken through a combination of reverse-engineering, improvements in cryptanalytic techniques, improvements to computational power leading to faster brute force and the exploitation of systemic and human factor weaknesses. As a result, countermeasures to such attacks were developed such as the foundational principles of modern cryptography, developed by Claude Shannon in 1948.

How fast are we going through these things and with the frankly insane amounts of hardware that keep coming down the pipe is this gonna end up some sort of "bit race" between the white and black hats?

I am guessing that the speed of innovation is partly driven by necessity. There will be periods of relatively steady improvements on both sides of the fence like there has been over recent years; then like with Enigma, there will be periods where there are giant leaps forward in technology and knowledge. There most assuredly is a "bit race" and it will continue so long as there is conflict.

so how long until 1024 and 2048 are as useless as the old 128 and 256 bit keys?

Giant leaps of technology aside, our industry generally accepts conclusions made about minimum key-length for each cipher by NIST : http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf. In short:

For AES, 128 bits is the minimum acceptable key size with no timeframe on when 256 bits will be required (everyone assumes this will occur around 2015)
For RSA, 1024 bit keys are the minimum acceptable key size until 2013 when the minimum will be increased to 2048 bit

How high of a number can we go to before the time to process it on an average machine makes it not worth the work? Is there a number high enough to be uncrackable? or is it all just a matter of letting Moore's Law catch up?

Just like mechanical computers in the time of Enigma, current silicon-based computers are quickly reaching practical limits and Moore's law is starting to show signs of fatigue. But if it were to be built, a quantum supercomputer could be so powerful as to render all current key sizes useless. But even the fastest quantum computer will have a speed limit; and so should every newer and faster generation of computer; because all such things are constrained by the Universe's ultimate speed limit. So long as it takes longer to break a cipher without knowing the key than it does to transmit encrypted information using knowing the key, there will always be secrecy in numbers.

With this problem, you'd do basically the same thing but you'd want slightly more data to handle the smaller size. (For handwriting, pressure and gradient would be the most obvious extensions to use. For original printed documents, you MAY be able to use any random fluctuations in toner or ink, since any fluctuations will be highly localized. For photocopies, the contrast of the copy might not be enough to show up extremely small variations - I'm really not sure what you could use there.)

However, you needn't get a unique solution.

Option 1: (Assumes some text is on the document.) You can use the methods used in cryptology to determine if the result of using a given key has produced a possible plaintext. A random arrangement of remains will never produce a sane text when OCRed, you'll always get a line where characters should be but can't be identified.

Option 2: An alternative second stage would be to treat every possible combination that meets the initial criteria as possible plaintexts for a cypher. The analysis at the end of the 2dem paper shows that basic encryption always expose some information even when the encrypted document is not considered readable. So it aught to be possible to look for information leakage to reduce the number of "keys" (ie: orderings that meet the criteria of stage 1) you need to brute-force look at.

If option 1 is sensitive enough and the document is of a type that permits simple analysis of the form rather than the content, then step 2 would never be needed. Step 2 is only needed if the form is not enough.

The problem here is that the above solution isn't guaranteed to reduce the number of possibilities to anything sensible. Stage 2 is a herustic that tries to make one segment correct in the hopes that this will make everything correct. Anyone who has solved one face of a Rubics cube knows this isn't a guaranteed approach. The best that can be said is that it will always reduce the problem space, but won't necessarily reduce it to the level that the problem can be considered essentially solved.

Yea, well, Keep this in mind.

This is like the 3rd or 4th SSL renegotation bug. The last one had only one fix: disable SSL renegotiation altogether. Firefox helped speed it along, but marking ssl servers that allowed renegotiation as insecure. And openssl released an updated version to drop support for it.

So pretty much every SSL server has renegotiation disabled.

IIRC it was this bug: CVE-2009-3555

You're currently on the Governing Board of the NIST Smart Grid Interoperability Panel. What is the state of standards development, and how big an impact does it have to move national infrastructure communications into the public IP arena so far as our ability to strengthen and expand our infrastructure? Conversely, how big are the threats in this new world?

"Obviously, in China, young people carry their old people like burdens while they're trying to manage their own families. That's not so great, either."

When people have six kids or so, it is not as much of a burden when the kids carry the elderly. Part of the problem is we are experiencing a "Peak Population" crisis.
http://p2pfoundation.net/backups/p2p_research-archives/2009-August/004174.html

But Japan aims to solve that with robotics...

Thanks for being part of making the 1980s happen!

My wife and our little "labor of love" venture in the 1990s:
    http://www.gardenwithinsight.com/

Sorry about your loss.

Health tips by me, the most important of which for most technology people is curing vitamin D deficiency (and which I could only learn about by hypertext-supporting networks and Google):
http://slashdot.org/comments.pl?sid=2478380&cid=37734208

There are plenty of resources to go around though, especially when you consider we could support quadrillions of people in space habitats in the solar system. But some causes for optimism:
http://cleantechnica.com/2011/05/29/ge-solar-power-cheaper-than-fossil-fuels-in-5-years/
http://www.remineralize.org/
http://www.nist.gov/el/msid/dpg/slim.cfm

And maybe even:
http://www.forbes.com/sites/markgibbs/2011/10/17/hello-cheap-energy-hello-brave-new-world/

If we had any real resource problems, why are so many people out of work? :-)

Real solutions:
http://www.youtube.com/watch?v=4vK-M_e0JoY
http://knol.google.com/k/beyond-a-jobless-recovery#

The human imagination is truly the "ultimate resource", so the more the merrier IMHO: :-)
http://www.juliansimon.com/writings/Ultimate_Resource/

You've of course read "True Names" no doubt about what an older woman is up to on the net: :-)
http://en.wikipedia.org/wiki/True_Names

Unblurring without having any additional information has been done by academic software before using a process called blind deconvolution, look it up for some interesting pictures and videos.

It's a rather "expensive" (cpu-intensive) operation, and indeed having sensor data about how the camera has shaken during exposure would significantly help in restoring the image. Interestingly, even cheap smart phones with crappy cameras will often already have movement sensor on-board, so there are some possibilities to improve image quality right after taking a picture; all it takes is a bit of software. How long until someone here whips up an improved Android camera app?

I'm probably under-informed, but I haven't heard of any cameras with full-blown movement sensor, although I know some of them can work out portrait vs landscape by now. Sounds like camera manufacturers have some catching up to do in the hardware department.

Make a cereal box spectrometer (I recommend using a piece cut from a sheet of plastic diffraction grating) and use it to look at the spectrum of a compact fluorescent lamp. Here's a table of mercury's spectrum. If you can see lines with wavelengths shorter than the 404.6 nm line then you can see UV. The 404.6nm line is on the far left. Seeing the 398.39 nm line might not count because it is so close to violet. If you can see the lines around 365 nm, then you can definitely see UV; however they may be too dim to see even if your eyes are able to detect those wavelengths.

The reason is they have metric shit-tons of money, enemies with access to bleeding-edge tech (and shit-tons of money) and would rather err on the side of caution. Media destruction is a formality, 1 overwrite makes data unrecoverable:

http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf

The ATA Secure Erase is a function built in to most drives to wipe them. NIST 800-88 (pdf warning) shows that apparently it's on par with degaussing in terms of recovery.

How to wipe in Linux
CMMR link from the PDF (Windows software)

CVE advisories include a list of affected versions... Am I missing something or are you?

Try this example advisory: Firefox "before 3.6.20" is reportedly affected, but in the listing there's no Firefox 3.0.19, because that version included a patch for that particular security hole.

You certainly CAN use GPS to synchronize clocks at the level of a few ns. While the GPS timing signals themselves are not accurate enough to form a stable timebase at this level, there are multiple methods which use GPS to implement time transfer between ground stations at much better than the 10ns level, when use in conjunction with an external high precision oscillator. See, for instance, http://tf.nist.gov/time/commonviewgps.htm or http://www.nist.gov/pml/div688/grp40/tmas.cfm and the references therein.

You certainly CAN use GPS to synchronize clocks at the level of a few ns. While the GPS timing signals themselves are not accurate enough to form a stable timebase at this level, there are multiple methods which use GPS to implement time transfer between ground stations at much better than the 10ns level, when use in conjunction with an external high precision oscillator. See, for instance, http://tf.nist.gov/time/commonviewgps.htm or http://www.nist.gov/pml/div688/grp40/tmas.cfm and the references therein.

On the slowest 32 bit processor tested (32 bit, ARM v4, 75 Mhz), NIST benchmarked Skein using portable C code at just under 1 megabyte / sec. That is about twice as slow as SHA-2 on the same processor, and certainly slow enough that you might notice in the case you mention. On modern 64 bit processor (Intel Q6600, x86_64, 2.4 Ghz), more like 286 MB / sec for Skein, about twice as fast as SHA-2. See here (pdf).

The striking difference between 32 bit and 64 bit implementations is much more than I would have guessed, but that may be merely a matter of optimization. For now it looks like a good excuse to use SHA-1 or SHA-2 when doing the sort of thing you describe on slow processors. For something like SSL or IPSEC, you aren't likely to notice the difference, because the bandwidth to a typical mobile device just isn't that high.

I've worked on/in a lot of big steel frame buildings over the last 20 years, and frankly the official explanation never made much sense to me either, but then again I'm not a metallurgical expert like some of the poeple on that site are.

If you're looking for facts I would try the sites below. Unlike the "truther" sites the people at the sites below aren't baffled by things that blacksmiths know - that steel loses its structural strength and bends long before it reaches its melting point.

Debunking the 9/11 Myths: Special Report

Questions and Answers about the NIST WTC 7 Investigation (Updated 09/17/2010)

Al Qaeda only had to keep about 30-40 people quiet for a year to pull off their attack. The movements of the people that did it, their pilot training, are all known. Al Qaeda took credit for it.

If you believe the conspiracy theorists called "truthers", you have to be willing to believe that probably several thousand people, at least, had to play a part in staging an attack on their fellow Americans that killed thousands and nothing has slipped out after 10 years - including the alleged missile attack on the Pentagon - and despite the fact that the government leaks like a sieve. Actually more than that since an attack that elaborate would have taken significant time to plan, prepare, and rehearse. (Sneak into buildings and place explosive charges to implode them, fire a missile at the Pentagon (by who? from where? What type? Why didn't it turn up missing?) as well as fake some aspects of the plane attacks (what about the family members? The recovered bodies?). Extraordinary claims require extraordinary evidence, something the 9-11 "truther" movement doesn't deliver. All they have are "questions" and crank theories.

the government does not say anything about the WTC-7 collapse

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=861610

And in the U.S., the charge (sorry...) of the Smart Grid Interoperability Panel is exactly this. Note that the SGIP is not an SDO. They are there to

coordinate standards development for the Smart Grid

The SGIP is a partnership between NIST and industry, academia, etc. Rick Scholer of Chrysler is on the governing board (as is Vint Cerf, incidentally).

And in the U.S., the charge (sorry...) of the Smart Grid Interoperability Panel is exactly this. Note that the SGIP is not an SDO. They are there to

coordinate standards development for the Smart Grid

The SGIP is a partnership between NIST and industry, academia, etc. Rick Scholer of Chrysler is on the governing board (as is Vint Cerf, incidentally).

Virtualization is a key enabler for Cloud Computing. It is not the same, but it becomes really difficult if not impossible to achieve the elasticity that Cloud requires without an underlying virtual infrastructure that can dynamically adapt to changes and fulfill SLAs.

You probably need to read the NIST definition of Cloud. Cloud has evolved from a pure buzz word to a very well defined set of layers that touches virtually every area of our interaction with computers, and it's more complex than just the simplistic explanation (or lack of thereof) that you try to convey in your comment.

Well said. This is just another article promoting the "Internet anonymity is bad" meme - probably scripted and promoted by The Chertoff Group. Yea, those guys. You know, the former Homeland Security Secretary who then started a security company and then sold its products to (surprise!) the DHS' TSA.

Chertoff was a major promoter of Real ID - the national ID card scheme passed purportedly to prevent terrorist attacks, even though it would actually do no such thing, but would provide a government a much better way to closely track its citizens and their activities, as well as massive profits for Chertoffs company. Note the security and online identity companies that they have now purchased or invested in. Getting some legislation mandating the ideas behind NSTIC will reap massive return for those investments.

Chertoff's group is quietly lobbying to bring back the Real ID (under a different name, of course) with new partners like the Center for Immigration Studies.

So, yea, when I see articles like this, I get REAL suspicious about who is behind it and what their real agenda might be.

http://physics.nist.gov/cuu/Units/prefixes.html
k is legal, K is ad hoc.

Not quite. But for once, the article isn't any more accurate than the Slashdot summary. The Federal Information Processing Standard (FIPS), which comes from the National Institute of Standards and Technology, is a test of the encryption module of a device or software. In this case, it is RIM's proprietary OS that runs on the PlayBook that has had its crypto module validated (PlayBook FIPS certificate). Yes, it is probably the first tablet to achieve this, since most computers leverage Window's validated crypto module (Go here, FIPS certificates, and search for Microsoft). However, meeting FIPS is only part of the process. Federal regulation also requires National Information Assurance Partnership (NIAP) certification and a test by an approved DoD test lab. After all of that, the device or software will probably be "certified for use in the U.S. government".

Not quite. But for once, the article isn't any more accurate than the Slashdot summary. The Federal Information Processing Standard (FIPS), which comes from the National Institute of Standards and Technology, is a test of the encryption module of a device or software. In this case, it is RIM's proprietary OS that runs on the PlayBook that has had its crypto module validated (PlayBook FIPS certificate). Yes, it is probably the first tablet to achieve this, since most computers leverage Window's validated crypto module (Go here, FIPS certificates, and search for Microsoft). However, meeting FIPS is only part of the process. Federal regulation also requires National Information Assurance Partnership (NIAP) certification and a test by an approved DoD test lab. After all of that, the device or software will probably be "certified for use in the U.S. government".

1 GB= 10^9 bytes (gigabyte)
1 GiB=2^30 bytes (gibibyte)

It changed in 1998