Slashdot Mirror

From 2011: http://it.slashdot.org/comments.pl?sid=2368162&threshold=0&commentsort=0&mode=thread&cid=37016386
"Twirlip: Towards a 21st Century Worldwide Public Intelligence Desktop Platform for Collaborative Sensemaking, Analysis, Risk Assessment, and Horizon Scanning"

Around them, I also put together another proposal to collect and organize stories about security issues as a modernized "Risks Digest" using software like my wife desiged my wife wrote called "Rakontu":
http://www.rakontu.org/

Another spin on that from this month:
https://www.newschallenge.org/open/open-government/submission/civic-sensemaking-by-working-with-stories-using-rakontu/

With some more code links and a video here:
http://twirlip.com/

See also:
http://www.phibetaiota.net/2011/09/paul-fernhout-open-letter-to-the-intelligence-advanced-programs-research-agency-iarpa/

From 1999 to NASA, some ideas about rethinking our manufacturing infrastructure systematically and in an open source way:
http://www.kurtz-fernhout.com/oscomak/

And also to DARPA in 1999:
"DARPA Progam Manager Position on Self-Replicating technology"
https://groups.google.com/forum/?hl=en&fromgroups=#!msg/virgle/feS-LaqnFyM/z0sqkvvCx2QJ
"We of course need to minimize military tensions around the world through arms control, international aid, and setting a good example. This delays the culmination of these other trend to war, but in my opinion will not prevent them because of ever-present potential for a small group of unstable people to use weapons of mass destruction. ... I also don't think we have a significant choice. Such self-replicating and self-repairing systems will be developed eventually anyway, if only from commercial competitive pressures. The only thing we can do is slow down their development. Yet that has its own risks of our current infrastructure being overwhelmed by current weapons of mass destruction or sophisticated terrorism. Also, should such self-replicating technology be developed first clandestinely by an oppressive regime, the consequences for the United States could be disastrous."

From 1987 for grad studies on improving security via self-replicating space habitats:
http://www.pdfernhout.net/princeton-graduate-school-plans.html

A long string of failed proposals. :-)

Well, at least I can still try to promote great ideas by others that have met with more success: :-)
"A Conceptual Framework for System Fault Tolerance"
http://hissa.nist.gov/chissa/SEI_Framework/framework_1.html

And I can keep on working towards those other ideas as very limited spare time permits.

I guess I am mostly just a creation of 1960s-1970s TV about our future in space -- to keep banging my head against the wall of space and security for decades? :-) Star Trek, The Starlost, Space 1999, Silent Running, Battlestar Galactica, Buck Rogers, Lost In Space, Thunderbirds, and so on... And way too many sci-fi novels. :-)

A lot of this conversation has been about remote security scans, but once you find a vulnerability, how do you remediate it? How do you maintain your security posture, and continue auditing your hosts on a regular bases? To what standard?

The National Institute of Standards & Technology provides a lot of help to those attempting to implement security standards.

First is the Security Content Automation Protocol (SCAP) - scap.nist.gov. This defines how you manage, measure and evaluate vulnerabilities.

Second would be SCAP content. You'll note on the NIST SCAP page the word "community" appears 5 times in the first paragraph. That's not on accident. SCAP content is generally community generated, and there are lots of great lists of people working on SCAP content for a variety of operating systems.

Red Hat maintains the gov-sec mailing list and fedora, for example has loads of content available for Red Hat Enterprise Linux based systems.

Our friends at NIST also publish what is called the US Gov't Configuration Baseline (USGCB for short). USGCB content is available in SCAP format for Windows & RHEL. These standards are certainly a good starting point.

If your standards come in the form of a STIG - that content is available as well from the Aqueduct project.

[Disclaimer - I work for Red Hat, I support the US Gov't, and I think making security easier is probably an important thing to do]

A lot of this conversation has been about remote security scans, but once you find a vulnerability, how do you remediate it? How do you maintain your security posture, and continue auditing your hosts on a regular bases? To what standard?

The National Institute of Standards & Technology provides a lot of help to those attempting to implement security standards.

First is the Security Content Automation Protocol (SCAP) - scap.nist.gov. This defines how you manage, measure and evaluate vulnerabilities.

Second would be SCAP content. You'll note on the NIST SCAP page the word "community" appears 5 times in the first paragraph. That's not on accident. SCAP content is generally community generated, and there are lots of great lists of people working on SCAP content for a variety of operating systems.

Red Hat maintains the gov-sec mailing list and fedora, for example has loads of content available for Red Hat Enterprise Linux based systems.

Our friends at NIST also publish what is called the US Gov't Configuration Baseline (USGCB for short). USGCB content is available in SCAP format for Windows & RHEL. These standards are certainly a good starting point.

If your standards come in the form of a STIG - that content is available as well from the Aqueduct project.

[Disclaimer - I work for Red Hat, I support the US Gov't, and I think making security easier is probably an important thing to do]

Tools for scanning a server:
http://nvd.nist.gov/scapproducts.cfm
If you pick a product and run the scan based upon all of the vulnerabilities in the NVD and come out completely clean, you are probably looking at a brick and not a computer.

A good password is defined here:
http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf
Based upon your description, you do not meet Level 1 requirements (the minimum). There are over 100 pages talking about secure authentication based upon various levels of security. You are probably most interested in "Appendix A: Estimating Entropy and Strength" in terms of that. Feel free to run password hashed against this John the Ripper:
http://en.wikipedia.org/wiki/John_the_Ripper

There are various other NIST guidelines for securing a system. It turns out that it is not easy, fun, or appreciated. For example, all passwords should be stored as salted hashes using SHA256 or SHA512.

Tools for scanning a server:
http://nvd.nist.gov/scapproducts.cfm
If you pick a product and run the scan based upon all of the vulnerabilities in the NVD and come out completely clean, you are probably looking at a brick and not a computer.

A good password is defined here:
http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf
Based upon your description, you do not meet Level 1 requirements (the minimum). There are over 100 pages talking about secure authentication based upon various levels of security. You are probably most interested in "Appendix A: Estimating Entropy and Strength" in terms of that. Feel free to run password hashed against this John the Ripper:
http://en.wikipedia.org/wiki/John_the_Ripper

There are various other NIST guidelines for securing a system. It turns out that it is not easy, fun, or appreciated. For example, all passwords should be stored as salted hashes using SHA256 or SHA512.

NIST's cloud definition is pretty spot on. They define cloud as having the following characteristics:

On-demand self-service
Broad network access
Resource pooling
Rapid elasticity
Measured service ...all working together to provide the following service models:

Software as a Service
Platform as a Service
Infrastructure as a Service ...hosted in one of the following deployment models:

Private cloud
Community cloud
Public cloud
Hybrid cloud

Anyway, that's the stripped down list without details. The short paper (with details!) I pulled that from is here:

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

Back then, there were two DNS servers out there:

1. BIND, which was horribly insecure and one of the more significant cause of remote root access security holes
2. DJBDNS, which was and by and large is secure, but had a weird maybe-not-open license and lots of quirks

LWN has a good article from that era to give people an idea how limited choices were with open-source DNS servers. Since then, we got Unbound and NSD, PowerDNS, and (shameless plug warning) MaraDNS (there are also a lot of DNS server projects which never were finished or were abandoned years ago, such as OakDNS, Dents, Posadis, etc.)

The idea behind DNSSEC is that is is, within a margin of error (I'm already awaiting a somewhat pedantic correction from a neckbeard), it is the HTTPS of DNS: It makes it impossible (cue neckbeard pedantic correction) to spoof a DNS reply. DNS without DNSSEC is like HTTP without HTTPS: There are security issues where an attacker can make someone go to the wrong web site.

(Yes, I am aware of DNScurve. I'm also aware that, like Esperanto, the best idea doesn't always win--or even get implemented in a mainstream DNS server)

(Slashdot: 2001 called and wants its lack of Unicode support back. Why can't I use use smart quotes or real em dashes in my replies?)

Chrome OS bug:
The CVE-2013-0913 hack was was a buffer overflow in the GPU for Chrome OS / Linux.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0913

Chrome browser bug:
Last year's PinkiePie hack chained multiple Chrome (browser) bugs together to be able to get to the GPU.
http://www.webpronews.com/google-chrome-cracked-by-six-bug-combo-2012-05

They didn't release details yet, but odds are since it's the same person he probably used a similar method to hack the browser and get access to the GPU of the OS.

A configurable, highly modifyable embedded microcontroller can be attached to other hardware to make that hardware configurable and highly modifyable! Imagine that! Its almost like that's what embedded microcontrollers were designed to do!

Ok, its true, I have a radio controlled clock, that syncs via shortwave and binary coded decimal to atomic clocks, and with a Raspberry PI attached, I could turn this into a cheap* stratum 1 NTP server. *($50 for Raspberry Pi, $20 for clock, so $70 for cheap stratum 1 NTP time server, which is less than the typical $550-$950 these units normally cost). There are a million other things you can do like this, and hack-a-day shows you how.

The standardization of the second took place 46 years ago. It is now the basis of SI, the international system of standards. The following is from NIST, the Federal Government agency in charge of standards:

"The unit of time, the second, was defined originally as the fraction 1/86 400 of the mean solar day. The exact definition of "mean solar day" was left to astronomical theories. However, measurement showed that irregularities in the rotation of the Earth could not be taken into account by the theory and have the effect that this definition does not allow the required accuracy to be achieved. ... Experimental work had, however, already shown that an atomic standard of time-interval, based on a transition between two energy levels of an atom or a molecule, could be realized and reproduced much more precisely. Considering that a very precise definition of the unit of time is indispensable for the International System, the 13th CGPM (1967) decided to replace the definition of the second by the following ...:

"The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom."

Not only that but, length is now defined in terms of the second:

"In turn, to further reduce the uncertainty, in 1983 the CGPM replaced this latter definition by the following definition:

"The meter is the length of the path travelled by light in vacuum during a time interval of 1/299 792 458 of a second.

"Note that the effect of this definition is to fix the speed of light in vacuum at exactly 299 792 458 mÂs-1. The original international prototype of the meter, which was sanctioned by the 1st CGPM in 1889, is still kept at the BIPM under the conditions specified in 1889."

Funny - there's no mention of Java 6 here, only Java 7.

Why are you only looking at one vulnerability?
As reported by Ars Technica, the 15th February, Facebook was victim of a watering hole attack, involving a “popular mobile developer Web forum“. The attack was using a Java 0day that has been urgently patched, in Oracle Java CPU of first February, by version 7 update 11 and version 6 update 39. http://eromang.zataz.com/2013/02/20/facebook-apple-twitter-watering-hole-attack-additional-informations/

I don't get why they blame Apple for this when clearly Oracle is at fault for letting Java stagnate this much.

The reason is because this flaw exists in Apple's implementation of Java 6 - which is still required by many people as not all apps work on Oracle's Java 7 (which was patched for this vulnerability some time ago).

Funny - there's no mention of Java 6 here, only Java 7.

You do realize that Apple has handed over Java support on OSX back to Oracle, right?

For Java 7, yes, Apple doesn't support that. For Java 6, they still do. The Apple version of Java still exists, was vulnerable to the Java 0-day, and missed the patches that fixed it that were first released a couple of weeks ago.

Now that's odd, are you claiming that the 0-day works in Apple's Java 6 despite only working under Java 7? http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0431

New? That went in a few Firefox versions back, I think at Firefox 16. I turned it off, since I use Sumatra PDF (which is dumb, but safe).

How do you know it's safe? From http://web.nvd.nist.gov/view/vuln/search-results?query=Sumatra&search_type=all&cves=on ?

That's nothing. Look[1] how long some Flash bugs have been around, or holes in MS Word, Active-X exploites, Windows exploits... it's all a matter of how much time you have to maintain the codebase, and what you prioritize.

Things with a 98% chance of never affecting anyone will go for a long time before getting the "half-line fix" just like any other software. Yes, including jQuery[2]

[1] - http://web.nvd.nist.gov/view/vuln/search
[2] - http://web.nvd.nist.gov/view/vuln/search-results?query=jquery&search_type=all&cves=on

That's nothing. Look[1] how long some Flash bugs have been around, or holes in MS Word, Active-X exploites, Windows exploits... it's all a matter of how much time you have to maintain the codebase, and what you prioritize.

Things with a 98% chance of never affecting anyone will go for a long time before getting the "half-line fix" just like any other software. Yes, including jQuery[2]

[1] - http://web.nvd.nist.gov/view/vuln/search
[2] - http://web.nvd.nist.gov/view/vuln/search-results?query=jquery&search_type=all&cves=on

Long ago, when manufacturers started making 1024 bit RAM chips, people found it easier to refer to them in common speech as "kilobit" chips. Every engineer knows that RAM chips come in powers of 2 and therefore what they really meant was 1.024 kilobit RAM. Later, some kiddies who didn't know any better started thinking that "kilo" actually meant 1024 but only for RAM chips, and then others thought that it meant 1024 for anything related to computers. Wrong. Kilo means 1000. Always has. If you want to talk in multiple powers of 2, the correct name for the prefix is kibi or mebi etc.

This National Standards Institute document explains the difference.
http://physics.nist.gov/cuu/Units/binary.html
Also Wikipedia: http://en.wikipedia.org/wiki/Mebibyte

In summary, 1GB (Gigabyte)=1000000000 bytes, 1GiB(Gibibyte)=1 073741824 bytes.

"official" on whose auth ?

The IEC. International Electrotechnical Commission (January 1999), IEC 60027-2 Amendment 2: Letter symbols to be used in electrical technology - Part 2: Telecommunications and electronics. * http://physics.nist.gov/cuu/Units/binary.html

Really quickly:

• DNScurve, as pointed out above, doesn't do nearly as much as DNSSEC does. In particular, DNScurve still allows "NXDOMAIN recirection" but DNSSEC doesn't. In addition, Bind, NSD, Unbound, and PowerDNS (non-recursive) have DNSSEC support, but there is not a mainstream DNS server out there with DNScurve support.
• djbdns hasn't been updated since 2001 and even the unofficial forks do not have patches for all three CVE security holes in DjbDNS. Since DjbDNS' goal was security, I consider it abandoned until someone makes a fork fixing all of the known security problems.
• There are ways to make blind DNS spoofing almost impossible without needing to add complex cryptography. Crypto, however, is needed when the attacker can watch the DNS packets that the victim sends.
• I would love to implement DNSSEC for MaraDNS, but I would need $50k US to pull it off. I would like make it a kickstarter project, but I think people would rather just use Unbound/NSD (which, unlike MaraDNS, was funded with a government grant) instead of throwing money my way.

Here is news for you too http://web.nvd.nist.gov/view/vuln/search-results?query=Foxit&search_type=all&cves=on SumatraPDF will be in this list too once it gains user base

No, here is why http://web.nvd.nist.gov/view/vuln/search-results?query=Adobe+PDF&search_type=all&cves=on

Actually, the US government has defined the imperial units as a converted value of metric units ever since the Mendenhall Order back in 1893.

In other words, the imperial values are pegged to the metric definition. The conversion values are not for "acceptable use" - they are the very definition.

NIST is where one of the copies of the standard kilogram is kept. NIST prefers SI standards.

http://www.nist.gov/pml/wmd/metric/metric-program.cfm

Office of Weights and Measures "ensures traceability of state weights and measures standards to the SI", so while there may be "standard pound" of sorts, it's measured back to SI standard (kg) to keep them in check.

http://www.nist.gov/pml/wmd/

Actually, the US government has defined the imperial units as a converted value of metric units ever since the Mendenhall Order back in 1893.

In other words, the imperial values are pegged to the metric definition. The conversion values are not for "acceptable use" - they are the very definition.

NIST is where one of the copies of the standard kilogram is kept. NIST prefers SI standards.

http://www.nist.gov/pml/wmd/metric/metric-program.cfm

Office of Weights and Measures "ensures traceability of state weights and measures standards to the SI", so while there may be "standard pound" of sorts, it's measured back to SI standard (kg) to keep them in check.

http://www.nist.gov/pml/wmd/

Perhaps you should read this document from NIST about the history of weights and measures in the US.

According to this document...
1827 a troy pound was obtained from London.
1828 a brass artifact (which was compared to this troy pound) declared standard for the US mint, not the avoirdupois pound
1866 the metric system was made lawful for commerce in the US. Legally defines avoirdupois pound as (1/2.2046) kg
1875 17 governments (incl the US) established the international bureau of weights and measures
1890 The US receives standard kilogram artifacts #4 and #20 for use as the national prototype
1894 The US tweaks the definition of the pound relative to this kilogram artifact to make it closer to the UK pound

The US makes various other tweaks over the years in the pound's definition relative to the standard kilogram artifact that the US government maintains.

The "troy" pound artifact is only used for Mint operation in the US and is not related to the avoirdupois pound used in commerce.

Also all NIST calibrations are done in metric units (as of 1959).

It is acceptable to use hours with SI units, whereas foot is not. Hours is "more" of a SI unit than foot is, if it makes sense to talk about degrees of SI'ness of units.

Can you point me to the part of HITECH that requires FIPS certification, because the NIST checklist still has the standard HIPAA style policy driven directives, not prescribed technical solutions. (section 164.312(a)(2)(iv))

FIPS 140-2 to be more specific

More specific, but not necessarily accurate. FIPS 140-2 is the requirement for data "in motion" (being transmitted via some communication channel.) The requirements for encryption to be sufficient to not leave the data covered by it "unsecured" under HIPAA are methods consistent with NIST Special Publication 800–111, Guide to Storage Encryption Technologies for End User Devices.

FIPS 140-2 to be more specific. There are plenty of free options.

Are there? Last time I looked into FIPS 140, it was the case that only certain software versions were validated by NIST, and none of the validated incarnations were either free-beer or free-libre.

Crypto++ is free and open Source and FIPS 140-2 validated

HIPAA *does* set in place specific specifications to comply. The beauty of HIPAA is that the Dept H&HS releases guidance to inform people how to comply on pretty much every aspect:

http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html

When it comes to technology, they always refer to NIST standards as being tested and compliant. Read NIST special publication 800-111 and its references to the FIPS 140-2 standard at http://csrc.nist.gov/ (Publications / Special Publications on the top menu) and you'll see they have very thorough information on how to implement encryption correctly.

FIPS 140-2 to be more specific. There are plenty of free options.

Are there? Last time I looked into FIPS 140, it was the case that only certain software versions were validated by NIST, and none of the validated incarnations were either free-beer or free-libre.

Even the folks behind Truecrypt "To our best knowledge, TrueCrypt complies with the following standards, specifications, and recommendations...", before failing to mention FIPS 140 at all.

Indeed, looking again at the list of validated FIPS 140 wares, it does seem to be lengthy, but it is mighty specific and I do not see a single instance of anything free-as-in-beer, let alone "plenty of free options."

The only thing that stands out is that Red Had has had some OSS software validated as being FIPS-140, but only when installed according to their posted Security Policy, which seems to require RHEL, which is not free.

So. [citation needed], and stuff: If you've got the goods, give 'em up. (And no, "To our best knowledge" is not a defense against a HIPPA violation: It either is validated to FIPS 140(-2), or it is not.)

The problem with this entire debate and the petition is that it assumes that the US has not adopted the metric system.

Let me start by quoting the National Institute of Standards and Technology [NIST a division of the US Department of Commerce]. Appendix B "Units and Systems of Measurement Their Origin, Development, and Present Status" to their publication Handbook 44 "Specifications, Tolerances, and Other Technical Requirements for Weighing and Measuring Devices" [pdf] states:

2.2.5. Status of the Metric System in the United States.

The use of the metric system in this country was legalized by Act of Congress in 1866, but was not made obligatory then or since.

* * *

Since 1970, actions have been taken to encourage the use of metric units of measurement in the United States. A brief summary of actions by Congress is provided below as reported in the Federal Register Notice dated July 28, 1998.

Section 403 of ... the Education Amendment of 1974, states that it is the policy of the United States to encourage educational agencies and institutions to prepare students to use the metric system of measurement as part of the regular education program. Under both this act and the Metric Conversion Act of 1975, the “metric system of measurement” is defined as the International System of Units ... interpreted or modified for the United States by ... the National Institute of Standards and Technology.

Section 5164 of ... the Omnibus Trade and Competitiveness Act of 1988, amends ... The Metric Conversion Act of 1975. ... read[s] as follows:

“Sec. 3. It is therefore the declared policy of the United States–

(1) to designate the metric system of measurement as the preferred system of weights and measures for United States trade and commerce;

(2) to require that each federal agency, by a date certain and to the extent economically feasible by the end of the fiscal year 1992, use the metric system of measurement in its procurements, grants, and other business-related activities, except to the extent that such use is impractical or is likely to cause significant inefficiencies or loss of markets to U.S. firms ... ;

(3) to seek ways to increase understanding of the metric system of measurement through educational information and guidance and in government publications; and

(4) to permit the continued use of traditional systems of weights and measures in nonbusiness activities.”

The Code of Federal Regulations makes the use of metric units mandatory for agencies of the federal government. (Federal Register, Vol. 56, No. 23, page 160, January 2, 1991.)

Perhaps the petitioners want non-metric units to be outlawed. That is not US policy (see above).

The title of the petition is also erroneous in that it refers to the "Imperial system".

The Imperial system was adopted by the UK in 1824. It was never used in the US. The differences between Imperial and US customary systems are described in Section 2.3 of Handbook 44. They chiefly relate to units of volume.

E.g., the UK Pint contains 20 ounces while the US Pint contains 16. The ounces are also different. 1 Imperial fluid ounce = 0.961 U.S. fluid ounce.

The problem with this entire debate and the petition is that it assumes that the US has not adopted the metric system.

Let me start by quoting the National Institute of Standards and Technology [NIST a division of the US Department of Commerce]. Appendix B "Units and Systems of Measurement Their Origin, Development, and Present Status" to their publication Handbook 44 "Specifications, Tolerances, and Other Technical Requirements for Weighing and Measuring Devices" [pdf] states:

2.2.5. Status of the Metric System in the United States.

The use of the metric system in this country was legalized by Act of Congress in 1866, but was not made obligatory then or since.

* * *

Since 1970, actions have been taken to encourage the use of metric units of measurement in the United States. A brief summary of actions by Congress is provided below as reported in the Federal Register Notice dated July 28, 1998.

Section 403 of ... the Education Amendment of 1974, states that it is the policy of the United States to encourage educational agencies and institutions to prepare students to use the metric system of measurement as part of the regular education program. Under both this act and the Metric Conversion Act of 1975, the “metric system of measurement” is defined as the International System of Units ... interpreted or modified for the United States by ... the National Institute of Standards and Technology.

Section 5164 of ... the Omnibus Trade and Competitiveness Act of 1988, amends ... The Metric Conversion Act of 1975. ... read[s] as follows:

“Sec. 3. It is therefore the declared policy of the United States–

(1) to designate the metric system of measurement as the preferred system of weights and measures for United States trade and commerce;

(2) to require that each federal agency, by a date certain and to the extent economically feasible by the end of the fiscal year 1992, use the metric system of measurement in its procurements, grants, and other business-related activities, except to the extent that such use is impractical or is likely to cause significant inefficiencies or loss of markets to U.S. firms ... ;

(3) to seek ways to increase understanding of the metric system of measurement through educational information and guidance and in government publications; and

(4) to permit the continued use of traditional systems of weights and measures in nonbusiness activities.”

The Code of Federal Regulations makes the use of metric units mandatory for agencies of the federal government. (Federal Register, Vol. 56, No. 23, page 160, January 2, 1991.)

Perhaps the petitioners want non-metric units to be outlawed. That is not US policy (see above).

The title of the petition is also erroneous in that it refers to the "Imperial system".

The Imperial system was adopted by the UK in 1824. It was never used in the US. The differences between Imperial and US customary systems are described in Section 2.3 of Handbook 44. They chiefly relate to units of volume.

E.g., the UK Pint contains 20 ounces while the US Pint contains 16. The ounces are also different. 1 Imperial fluid ounce = 0.961 U.S. fluid ounce.

It's caused plenty of issues.

http://www.nist.gov/pml/wmd/metric/eu.cfm

The problem with this entire debate and the petition is that it assumes that the US has not adopted the metric system.

Let me start by quoting the National Institute of Standards and Technology [NIST a division of the US Department of Commerce]. Appendix B "Units and Systems of Measurement Their Origin, Development, and Present Status" to their publication Handbook 44 "Specifications, Tolerances, and Other Technical Requirements for Weighing and Measuring Devices"[pdf] states:

2.2.5. Status of the Metric System in the United States.

The use of the metric system in this country was legalized by Act of Congress in 1866, but was not made obligatory then or since.

* * *

Since 1970, actions have been taken to encourage the use of metric units of measurement in the United States. A brief summary of actions by Congress is provided below as reported in the Federal Register Notice dated July 28, 1998.

Section 403 of ... the Education Amendment of 1974, states that it is the policy of the United States to encourage educational agencies and institutions to prepare students to use the metric system of measurement as part of the regular education program. Under both this act and the Metric Conversion Act of 1975, the “metric system of measurement” is defined as the International System of Units ... interpreted or modified for the United States by ... the National Institute of Standards and Technology.

Section 5164 of ... the Omnibus Trade and Competitiveness Act of 1988, amends ... The Metric Conversion Act of 1975. ... read[s] as follows:

“Sec. 3. It is therefore the declared policy of the United States–

(1) to designate the metric system of measurement as the preferred system of weights and measures for United States trade and commerce;

(2) to require that each federal agency, by a date certain and to the extent economically feasible by the end of the fiscal year 1992, use the metric system of measurement in its procurements, grants, and other business-related activities, except to the extent that such use is impractical or is likely to cause significant inefficiencies or loss of markets to U.S. firms ... ;

(3) to seek ways to increase understanding of the metric system of measurement through educational information and guidance and in government publications; and

(4) to permit the continued use of traditional systems of weights and measures in nonbusiness activities.”

The Code of Federal Regulations makes the use of metric units mandatory for agencies of the federal government. (Federal Register, Vol. 56, No. 23, page 160, January 2, 1991.)

Perhaps the petitioners want non-metric units to be outlawed. That is not US policy (see above).

The title of the petition is also erroneous in that it refers to the "Imperial system". The Imperial system was adopted by the UK in 1824. It was never used in the US. The differences between Imperial and US customary systems are described in Section 2.3 of Handbook 44. They chiefly relate to units of volume. E.g., the UK Pint contains 20 ounces while the US Pint contains 16. The ounces are also different. 1 Imperial fluid ounce = 0.961 U.S. fluid ounce.

The problem with this entire debate and the petition is that it assumes that the US has not adopted the metric system.

Let me start by quoting the National Institute of Standards and Technology [NIST a division of the US Department of Commerce]. Appendix B "Units and Systems of Measurement Their Origin, Development, and Present Status" to their publication Handbook 44 "Specifications, Tolerances, and Other Technical Requirements for Weighing and Measuring Devices"[pdf] states:

2.2.5. Status of the Metric System in the United States.

The use of the metric system in this country was legalized by Act of Congress in 1866, but was not made obligatory then or since.

* * *

Since 1970, actions have been taken to encourage the use of metric units of measurement in the United States. A brief summary of actions by Congress is provided below as reported in the Federal Register Notice dated July 28, 1998.

Section 403 of ... the Education Amendment of 1974, states that it is the policy of the United States to encourage educational agencies and institutions to prepare students to use the metric system of measurement as part of the regular education program. Under both this act and the Metric Conversion Act of 1975, the “metric system of measurement” is defined as the International System of Units ... interpreted or modified for the United States by ... the National Institute of Standards and Technology.

Section 5164 of ... the Omnibus Trade and Competitiveness Act of 1988, amends ... The Metric Conversion Act of 1975. ... read[s] as follows:

“Sec. 3. It is therefore the declared policy of the United States–

(1) to designate the metric system of measurement as the preferred system of weights and measures for United States trade and commerce;

(2) to require that each federal agency, by a date certain and to the extent economically feasible by the end of the fiscal year 1992, use the metric system of measurement in its procurements, grants, and other business-related activities, except to the extent that such use is impractical or is likely to cause significant inefficiencies or loss of markets to U.S. firms ... ;

(3) to seek ways to increase understanding of the metric system of measurement through educational information and guidance and in government publications; and

(4) to permit the continued use of traditional systems of weights and measures in nonbusiness activities.”

The Code of Federal Regulations makes the use of metric units mandatory for agencies of the federal government. (Federal Register, Vol. 56, No. 23, page 160, January 2, 1991.)

Perhaps the petitioners want non-metric units to be outlawed. That is not US policy (see above).

The title of the petition is also erroneous in that it refers to the "Imperial system". The Imperial system was adopted by the UK in 1824. It was never used in the US. The differences between Imperial and US customary systems are described in Section 2.3 of Handbook 44. They chiefly relate to units of volume. E.g., the UK Pint contains 20 ounces while the US Pint contains 16. The ounces are also different. 1 Imperial fluid ounce = 0.961 U.S. fluid ounce.

http://physics.nist.gov/cuu/Units/current.html

The official spelling is "meter" (I, and most on this American site speak American English). I'm not invoking a different concept, unless someone speaking a different dialect intrudes on a US site in a conversation between Americans and complains that everyone understands properly, so that's a problem. You obviously knew exactly what I meant, so it was, linguistically speaking, correct.

The US is in the process of metrication. Slow, but then again even France took a long time to convert.

For example all of US units are now defined in terms of metric units. The foot is 0.3048m.

http://www.nist.gov/pml/wmd/metric/metric-program.cfm

A decimal system of weights and measure based on the meter and gram

otherwise we'd have kilokilogram's and millikilograms

Wrong.

Technically, the units are metres and kilogrammes. It's not obvious from the Wikipedia article, but I don't think that adding a prefix (or removing one to get "grammes") counts as making a new unit.

It is obvious from NIST:

It is important to note that the kilogram is the only SI unit with a prefix as part of its name and symbol.

I liked your approach, but that said, qwak23 makes a good point in reply about how different people respond better or worse to different interactional styles. There is a book called "Motherstyles" about how the same applies for raising kids.
http://www.motherstyles.com/

Going with your approach here, one thing to do is step back and see the context (which I do not know about for the kernel list and that maintainer). If you were really commenting in a real situation, there would be more context. And so, beyond what you said, and depending on the relationship, something might be said like: "Bill, you've done a hundred excellent welds in a row here, and I know you've done great work on other projects. However, this weld is substandard and dangerous for these reasons. Is something going on in your life that led to this change? Lack of sleep? Overwork? Family problems? Are your tools damaged? Are the supplies substandard? Do you lack adequate training for this particular type of welding? Etc. The weld needs to be redone. You're generally a good performer and I want to keep you on the project. The deeper question is, how can we also keep this issue from happening again? What can I do as your manager to help you do your job better?"

A philosophy of "Total Quality Management" goes beyond detecting and correcting a specific defect. It includes looking at the context for a defect so that similar defects don't happen again in the future. Related:
http://en.wikipedia.org/wiki/Total_quality_management

For the software realm, consider how Linus could have reviewed multiple levels of the Linux Kernel's (and related application sphere's and test environment's) "fault tolerance":
"A Conceptual Framework for System Fault Tolerance"
http://hissa.nist.gov/chissa/SEI_Framework/framework_1.html
"A major problem in transitioning fault tolerance practices to the practitioner community is a lack of a common view of what fault tolerance is, and how it can help in the design of reliable computer systems. This document takes a step towards making fault tolerance more understandable by proposing a conceptual framework. The framework provides a consistent vocabulary for fault tolerance concepts, discusses how systems fail, describes commonly used mechanisms for making systems fault tolerant, and provides some rules for developing fault tolerant systems."

People make mistakes. People even make mistakes about making mistakes (not seeing them, denying them, deflecting blame, etc.). So a big issue is, what social and architectural systems do we build around that to ensure the systems work well, anyway? Things like redundancy, modularity, and testability are important in that context.

One thing of concern to me about this (not knowing the kernel communications culture or the previous interactions of Linus and this maintainer) is whether the Linux kernel (and development community) has maybe reached some point where old development methods are breaking down in trying to support an every growing monolithic kernel approach? I initially reswisted using Linux in the 1990s because I knew there were alternative architectures available, like from QNX, Erlang, Actor, or Smalltalk, and I had hoped those alternatives would prevail. I started using GNU/Linux only when it seemed like the social momentum there was unstoppable. Thus my previous comment on "message passing" as perhaps a better architecture for software in the 21st century because if can help address theses issues of redundancy, modularity, and testability as ways to manage risk from complexity. Related:
http://en.wikipedia.org/wiki/Message_passing
http://en.wikipedia.org/wiki/SIMPL

See point #8 here:

There's not enough information in the OP's question. Is this a home or business environment? What do you want to protect? What do you perceive as the most likely threats? As to your questions about snoopy corporations and government agencies, do you have a particularized reason to be paranoid about such things, or are you merely a concerned citizen? I would start with NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems. You could also watch "Privacy Is Dead, Get Over It."

The software speed of the SHA algorithms is somewhat moot in the medium terms because over the medium term, crypto primitives (encryption, hashing, RNGs etc) are moving to hardware and moving to an instruction model instead of a device+device_driver model.

So the hardware implementations available to software through instructions will be faster than software implementations and have much better security properties in terms of attack surface and side channels. Modern crypto tends to fall to side channels and implementation error before it falls to crypto attacks and hardware is the best place to solve these problems.

At the recent NIST RBG Workshop http://www.nist.gov/itl/csd/ct/rbg_workshop2012.cfm
I presented a short talk on where Intel is going. http://csrc.nist.gov/groups/ST/rbg_workshop_2012/johnston.pdf

Basically, we've started putting standards based crypto primitives in hardware, on the CPU die, presented through the instruction interface (E.G. AES-NI, RdRand, RdSeed) to provide for more secure crypto on PCs. This is our publicly stated intent going forward. So who cares how many cycles it takes when there's a constant time instruction available that is faster?

The software speed of the SHA algorithms is somewhat moot in the medium terms because over the medium term, crypto primitives (encryption, hashing, RNGs etc) are moving to hardware and moving to an instruction model instead of a device+device_driver model.

So the hardware implementations available to software through instructions will be faster than software implementations and have much better security properties in terms of attack surface and side channels. Modern crypto tends to fall to side channels and implementation error before it falls to crypto attacks and hardware is the best place to solve these problems.

At the recent NIST RBG Workshop http://www.nist.gov/itl/csd/ct/rbg_workshop2012.cfm
I presented a short talk on where Intel is going. http://csrc.nist.gov/groups/ST/rbg_workshop_2012/johnston.pdf

Basically, we've started putting standards based crypto primitives in hardware, on the CPU die, presented through the instruction interface (E.G. AES-NI, RdRand, RdSeed) to provide for more secure crypto on PCs. This is our publicly stated intent going forward. So who cares how many cycles it takes when there's a constant time instruction available that is faster?

NIST's comments on their selection of Keccak to be SHA-3: (PDF)

Additionally, KECCAK complements the existing SHA-2 family of hash algorithms well. NIST remains confident in the security of SHA-2 which is now widely implemented, and the SHA-2 hash algorithms will continue to be used for the foreseeable future, as indicated in the NIST hash policy statement. One benefit that KECCAK offers as the SHA-3 winner is its difference in design and implementation properties from that of SHA-2. It seems very unlikely that a single new cryptanalytic attack or approach could threaten both algorithms. Similarly, the very different implementation properties of the two algorithms will allow future application and protocol designers greater flexibility in finding one of the two hash algorithms that fits well with their requirements.

So, Keccak wasn't necessarily chosen because it was "superior" to the other finalists (note that it's slow when implemented in software, especially in comparison to the other finalists), but because it was different enough that, should SHA-2 be found to be fundamentally broken, SHA-3 should remain unaffected.

An optimized version of BLAKE would be useful because it can run faster than SHA-3 in software, while also being (theoretically) stronger than SHA-2 (or other older algorithms).

Mind you, I'm not an expert in cryptography; regardless, it probably wouldn't be the greatest choice to use BLAKE2 right away. It's still not been held up to the level of scrutiny that something like SHA-2 has. (Although I'm certain that being a finalist has helped it come under much closer scrutiny than if it hadn't been one.)

As for why a fast cryptographically secure hash function is desirable, others have already answered that question better than I can.

Yah dude, you're so totally spot on - noone at all documents this!

I learned under metric, for me those "customary" units of height are very hard to grasp.

In metric, everything is in tens, you add or subtract zeros, thats it.

A meter contains 10 decimeters (rarely used), a decimeter contains 10 centimeters, a centimeter contains 10 milliliters, etc.
http://physics.nist.gov/cuu/Units/prefixes.html

Customary/Imperial units are a mess, and to make matters worse, you don't use a single unit but TWO different ones for measuring things (feet AND inches?). What the hell is an inch? half a feet? quarter? decimal? no... its freaking 1/12. OF COURSE you don't fit 12 feet in a yard, that would be too easy, its 3... AND you also don't fit 12 pica in an inch, but 6...

To make sense of your nonsense, we have to convert to a single unit first (eg. inches), and THEN move to metric, that is not a trivial mental operation for many.

Another American annoyance is paper sheet sizes. But there are many more areas for frustration in those outdated customs.

Let them sink in their isolation, is what we say here.

Citing 9/11 is interesting in light of the NIST report:

Did fuel oil systems in WTC 7 contribute to its collapse?

No. The building had three separate emergency power systems, all of which ran on diesel fuel. The worst-case scenarios associated with fires being fed by ruptured fuel lines-or from fuel stored in day tanks on the lower floors-could not have been sustained long enough, could not have generated sufficient heat to weaken critical interior columns, and/or would have produced large amounts of visible smoke from the lower floors, which were not observed.

As background information, the three systems contained two 12,000 gallon fuel tanks, and two 6,000 gallon tanks beneath the building's loading docks, and a single 6,000 gallon tank on the 1st floor. In addition one system used a 275 gallon tank on the 5th floor, a 275 gallon tank on the 8th floor, and a 50 gallon tank on the 9th floor. Another system used a 275 gallon day tank on the 7th floor.

Several months after the WTC 7 collapse, a contractor recovered an estimated 23,000 gallons of fuel from these tanks. NIST estimated that the unaccounted fuel totaled 1,000 ±1,000 gallons of fuel (in other words, somewhere between 0 and 2,000 gallons, with 1,000 gallons the most likely figure). The fate of the fuel in the day tanks was unknown, so NIST assumed the worst-case scenario, namely that they were full on Sept. 11, 2001. The fate of the fuel of two 6,000 gallon tanks was also unknown. Therefore, NIST also assumed the worst-case scenario for these tanks, namely that all of the fuel would have been available to feed fires either at ground level or on the 5th floor.

... This meant, for example, that the legal definition of the inch in the US became 2.56 cm....

2.54 cm

http://www.nist.gov/pml/wmd/metric/length.cfm

Also, to clarify, this seems to not be over SSL itself, but rather over "using a shared seed value to generate pseudo-random key values at a transmitter and a receiver." RTFA on CipherLaw Blog.

Isn't CTR-mode use of a cipher block prior art? This was invented in 1979 by Dife and Hellman and in effect turns a key into a series of pseudo random values which are xored with the plain text.

"However, more analysis needs to be put into their plan; more requirements gathering and architecture is needed."

Something I tried to get NASA to support a dozen years ago: http://www.kurtz-fernhout.com/oscomak/

That said, the Factor e Farm people are really trying hard and making some progress in the general area. What is ridiculous is that this is not a top priority issue funded by NASA, NIST, and European counterparts with hundreds of thousands of reasonable paid engineers involved.

Another related idea I posted:
"Getting Greece and Iceland to be 99% self-sufficient by mass; international consortium"
https://groups.google.com/forum/?fromgroups=#!msg/openmanufacturing/YzbzBFjeBkg/HXC7-XHSGLkJ
"Now, does this [Greece running out of tear gas during riots about economics] make any sense if you understand the possibilities of open manufacturing or an open society? In Greece you have a warm climate, access to oceans, lots of sun and wind, an educated populace with a 2000+ year history of democracy (on and off :-), no obvious external enemies declaring war, and so on. And they are so worried about their future ability to make and use things (which is how I translate "fears for Greece's economic future") that they are running out of tear gas? This all makes no *physical* sense. The place should be a paradise. Instead it is in "self-destruct mode" according to one editor. It must be *ideology*. Or, more correctly, ideology *embodied* in a certain type of productive infrastructure. ..."

The closes I know of from the US government is from the Carter presidency: http://www.islandone.org/MMSG/aasm/

Here is something more recent from NIST which is great but not quite as self-replication focused and only had about 20 staff involved (last I heard):
http://www.nist.gov/el/msid/lifecycle/sm_smo.cfm
http://www.nist.gov/el/msid/lifecycle/

Frankly, it feels to me like the failure of engineering academia in the USA to comprehensively work to analyze our productive processes is perhaps a reflection of how much a certain form of capitalist ideology infests US academia. It seems like it is heresy to even consider that anything other than some mystical "market" would decide what would be manufactured or how it would be made or moved between users, even though a lot of companies are being weighed down by supply chains they don't really understand or control. So, in academia you can study one tiny part of how something is made, but you can't try to create an approach to comprehend the whole because that goes against mainstream economic dogma of willful blindness about lifecycle consequences and comprehensive design. Only in a thought experiment like NASA might do about a moon base or something like that is it permitted to discuss the idea of comprehensive planning about how to make *everything* and take it all through a full lifecycle. Meanwhile, we drown in our own e-waste because externalities like disposal are not priced in up-front. Modern computer-based manufacturing has the potential to be so flexible that we could have, if not Star Trek replicators, at least the next best thing of small production runs and mass customization coming out of very flexible manufacturing lines (seem James P. Hogan's "The Two Faces of Tomorrow" for some descriptions of what that would look like, set in a space habitat).

Still, there is the RepRap project and such as an exception in academia. So, I think change is happening, slowly. Maybe the rate of change on this meme is growing exponentially though?