Slashdot Mirror

spot on...specifically FIPS Pub 140-2 Annex C (draft) "Approved Random Number Generators" which can be found at http://csrc.nist.gov/publicati...

Nah - there's a process called a hazard analysis that should reveal the potential hazards of what somebody is doing. Why these aren't performed at an academic institution is a separate problem. The problem in academic institutions which doesn't exist in either corporate or government research labs is a lack of line management responsibility. The university culture generally allows for throwing a professor (or even a department) under the bus when something goes wrong and OSHA has allowed them to get away with it. In other areas it's been pretty clearly demonstrated that line management is responsible for safety.

For example look at NIST Boulder's plutonium incident - the director of the entire facility is who lost the job because it was his responsibility to have a lab safety program that was sufficient and effective. What is only just starting to wake up academic institutions is the fatal UCLA lab fire which the university was able to plead out of criminal charges, but the professor in charge has not. While the university had some pretty stiff penalties as part of the plea bargain - all of the accountability has come down on the professor and not the university management chain (i.e. with the criminal charges against the university, it should have landed at least at the VP level). I don't think universities will actually foster a safety culture until core administration accepts that the responsibility for doing so is theirs - and this is not likely to happen as long as a professor can be thrown under the bus (whether or not he or she deserves it) and administration escapes major personal (as opposed to institutional) penalties.

NIST 800-53 rev. 4 discusses this topic, so it seems like it's going to become more common. http://nvlpubs.nist.gov/nistpu...

You do know we're talking about Google, right? Why would Google not have those kinds of resources?

Nobody does, humanity lacks the tools necessary to accomplish this feat in general purpose software.

They scan the Internet every day, upload an hour of video every second, filter spam for hundreds of millions - better than anybody, and they made Android so they have the inside track on detecting undesirable code.

Then why has Google not used this mythical capability to plug all the security leaks in their own Android operating system? A quick search shows hundreds of documented failures.

http://web.nvd.nist.gov/

Even my Google search results - the core competency that makes google google still contain as much useless garbage spam as ever.

These two things are unrelated.

Try explaining this to victims of a premium SMS scam.

Now you seem to be saying you're complaining about Android security because others complain about the security of your preferred system.

I think all of the major mobile platforms profit from selling out and treating the user like shit. I dislike them all.

That is not relevant. Also, it's a confession that your argument lacks merit. Maybe not the direction you wanted to go.

Why is it not relevant? What part of my argument lacks merit?

Now we are talking about a totally different thing - apps which require excessive permissions. As in, the end user gets to decide how much access he is willing to give each application. This is not malware at all and off topic for the discussion, but let's cover it.

Since when is Malware only defined as malware as long as it executes as root? An app that uploads all of my contacts to a criminal organization or participates in a premium dialing/SMS scam WITHOUT any root privileges **IS** malware to me and anyone effected by it.

The distinction of TFA is what is irrelevant. All that matters is what is actually happening in the real world not technical distinctions which most users do not understand.

This is restraining applications that want to be more than the end user wants them to be, giving the end user full disclosure when an update seeks to do things it didn't do before. You make it sound like a bad thing,

It is a proven failure. You can "inform" users and feel well they were warned and it is out of your hands all you want. "Full disclosure" as a security model is the same thing as clicking "I Accept" on the EULA without reading it. Users don't have a real choice to control what an application does they have a binary decision .. an ultimatum either you let me do this or you don't get shit. This model in the real world is a failure.

when in fact it's an enhancement above the other methods of application security provided by the system that empowers the user to be more restrictive than any algorithm could appropriately be. You make it sound like a bad thing. It's not.

All that is needed are user controlled options when installing an app the OS should ask you to pick from a menu of permissions or create a custom profile for that app. It should NOT present the user with an ultimatum.

I install a flashlight app and it does not get any I/O access to any network, touch the filesystem, access my GPS location..etc. The operating system should go as far as having the capability to lie convincingly to the application if requested by the user.

The "bad thing" occurs when the OS vendor has a vested interest in the app environment and ad revenues. Protecting the user is subjugated to making App vendors happy.

Rather than publishing on proprietary data of uncertain characteristics, this will essentially force researchers to use common, known, and available data sets. A smattering of what's available and reputable:

http://www.itl.nist.gov/div898...
http://www.keypress.com/x2814....
http://lib.stat.cmu.edu/DASL/
http://www.statsci.org/dataset...
http://data.gc.ca/eng/facts-an...
http://library.med.cornell.edu...

well... this is puzzling. i tried converting the value reported to MeV and accidentally divided by the atomic units constant 9.109 382 91 x 10-31 instead. what i got shocked the hell out of me: 1000x avogadro's constant. according to reports here http://phys.org/news/2014-02-p... the value is 0.000548579909067 atomic mass units. if however you divide that by the atomic unit of mass reported here http://physics.nist.gov/cgi-bi...|search_for=atomic+mass+unit you get, to 6 decimal places, avogadro's constant times 1,000.

i am... very very startled! the implications are that there is some sort of link between the mass of the electron and (if you look up the definition of 1 mole on wikipedia) the number of atoms in 12 kg of carbon. which is.... incredibly odd.

i don't think it's a systemic error, because the original experiment's value agrees with that of other measurements that have been made of the electron's mass. what it would mean is that there appears to genuinely be a link between the mass of the electron and avogadro's constant.

Formulas? You want Formulas?
http://people.math.sfu.ca/~cbm/aands/toc.htm

This version has the naughty bits:
http://apps.nrbook.com/abramowitz_and_stegun/index.html

And here's the Revised Standard Version:
http://dlmf.nist.gov/

The NSA has been involved with NIST and industry to produce a series of NIST Special Publications ( http://csrc.nist.gov/publications/PubsSPs.html ) which include BIOS security. This includes 800-147, 800-147B, 800-155, 800-164 etc.

I have no idea how many manufacturers implement these -- but there are some really gnarly issues there. It isn't even clear what BIOS means in the context of a blade server with multiple processors, management engines etc.

The TL;DR for these specs is that a BIOS update should not be accepted by the system if it is not signed by the BIOS manufacturer. This is a step in the right direction. Of course, it doesn't protect you from someone with access to the BIOS signing keys for a particular BIOS vendor (and there aren't many BIOS vendors around). I don't think that if 800-147 is implemented that it makes anything easier for the NSA, except that it might engender a false sense of security.

That is exactly what we need to terraform Mars! We need to send few tonnes of this stuff to Mars....

A lot more than a "few tonnes", I'm afraid. I'll also point out that the formula for this is C12F27N-- it has a molecular mass of 671-- that's fifteen times more massive than carbon dioxide molecules. So, per unit MASS it's only 460 times more powerful an infrared absorber than carbon dioxide.

SF6 is a better infrared-trapping greenhouse gas for Mars.

Chemical info here, by the way: http://webbook.nist.gov/cgi/cbook.cgi?ID=C311897

http://www.sigmaaldrich.com/content/dam/sigma-aldrich/structure1/050/mfcd00000436.eps/_jcr_content/renditions/large.png

"Administrators must understand many important aspects of BGP as a protocol to assess where it may be susceptible to various forms of attack and where it must be protected .. administrators must mitigate the risk and potential impact of associated exploit attempts link

"This document introduces the Border Gateway Protocol (BGP), explains its importance to ... and provides a set of best practices that can help in protecting BGP." link

Back-of-the-envelope calculation using XCOM.

Assume server rack and contents are made of aluminum (what is the predominant material in a server rack?). Let's say the server rack is 2m in height, but it's not fair to make the whole thing metal. Let's say 20% of it is metal (aluminum for this calculation), the rest is air (or, for the sake of calculation, vacuum). Alumnium has a density of 2g / cm^3 (so a 1m x 1m x 0.4 m slab of alumnium would weigh 800 kg, which appears to be in the middling range for what a server rack can accomodate--again, keep in mind, this is a really rough calculation).

Okay, plugging in Aluminum into XCOM gives a total attenuation in the 100-1k MeV range of ~0.03 cm^2/g.

e^[-(0.03 cm^2/g) * (2g / cm^3) * 40 cm] = 0.09

In other words, that's 90% attenuation. Keep in mind that this was a ridiculously sloppy calculation, with my material assumptions (and possibly energetic ranges) being way off (also, neutron cross-sections could easily be different than photon cross-sections). The point is, it's certainly possible (nay, likely) that the material of the servers themselves are providing shielding from the servers on the bottom of the rack.

Recently, cryptanalysts have found collisions on the MD4, MD5, and SHA– 0 algorithms; moreover, a method for finding SHA–1 collisions with less than the expected amount of work has been published, although at this time SHA– 1 collisions have not yet been demonstrated. Although there is no specific reason to believe that a practical attack on any of the SHA–2 family of hash functions is imminent, a successful collision attack on an algorithm in the SHA–2 family could have catastrophic effects for digital signatures. NIST has decided that it is prudent to develop a new hash algorithm to augment and revise FIPS 180–2. The new hash algorithm will be referred to as ‘‘SHA–3’’

This was published in 2007. My joke was about the general uneasiness in the community about SHA-2, even if it hasn't been broken yet. Unfortunately, it seems that the members of \. who responded to me were too thick to understand this. You could have just pointed out that SHA-2 hasn't been broken yet. Instead you evinced your lack of ability to make clever insults.

...you dolt...You're clearly an ignorant fuck.

If you use the word "dolt" in conversation in a non-facetious manner it means that you're either a horribly self-conscious member of the middle class who is afraid of appearing "unprofessional", or a dummkopf who hasn't learned that using "dolt" is a shibboleth of immaturity. If you're going to call someone a motherfucker, as any other confident fellow with an iota of social intelligence would, please do it at the outset. Your prose will have a more even tone and you won't be downmodded for flaimbaiting.

It sounds like you saw my correction. I typed 3DES when I meant DES, so I'll reply to your comments DES.

> DES doesn't go back nearly as far as 1972. (nor does DES for that matter)

Below is the official NIST paper describing DES. You'll note that after a four year approval process, DES officially became a government standard in 1977. As described in the paper, IBM was using it by 1974 after it was developed in the years prior.

http://nvl.nist.gov/pub/nistpubs/sp958-lide/250-253.pdf

You could reasonably choose any year between 1972-1977 as the beginning of DES usage, so you're mistaken about "not nearly as far back as 1972, sorry.

> rather a large number of milliseconds

Try cracking a password database sometime. I do this stuff for a living. The larger the database, the faster you'll get working passwords, so we'll give you the benefit of the doubt and use a fairly small database of only 1,000 accounts as an example. We'll also be generous to you and not use a rainbow table. With a small (difficult) database like that, you can expect to get maybe 12 passwords in the first second or two. In the first ten minutes, probably 250 working accounts.

A 100X larger database will yield roughly 100X as many passwords per time - around 1,000 working accounts in the first few seconds, or 2-3ms per account at first.

If we want to go fast, we use a rainbow table. Standard DES password hashing ala crypt() collides at about 1:1000 since it uses only the first eight characters. On modern PCs with GBs of RAM, we can use in-memory tables and crack millions per second. No need for that, though, I don't mind waiting several milliseconds.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

Basically anythin calling itself a guidline or framework. Some of the 'security recommendations' are also mush.
There are plenty of clear documents, but there are a lot more that are mushy

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-161
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-162
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.nist.gov/publications/fips/fips190/fip190.txt
http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

I haven't touched the CC stuff, because it wouldn't be fair.

We don't need "software updates that improve the security of OpenSSL", we need a whole new protocol.

If you really want to be helpful, Google, provide support and coordinate a competition to create a new SSL protocol, à la AES and SHA-3. Then we could make progress towards truly better security.

There have been reports on 58 different remote code execution vulnerabilities in Internet Explorer 10 in 2013 alone. I would hardly call that "taped together quite well".

Seems wwvb is still up and running at this time according to the readability status report! http://tf.nist.gov/tf-cgi/wwvbmonitor_e.cgi So all we can do is keep our fingers crossed!

It would have to be based on a statistical analysis which means it isn't a proof, it is demonstrated to a confidence level. How confident do you need to be?

Secondly, to properly evaluate to greater number of bits of entropy is going to require a larger sampling and I expect this increases exponentially. How much time do you have to reach your confidence?

The testing would be balancing those two questions, but in no case could an absolute answer be found.

But, from the horses mouth:

The subject of statistical testing and its relation to cryptanalysis is also discussed, and some recommended statistical tests are provided. These tests may be useful as a first step in determining whether or not a generator is suitable for a particular cryptographic application. However, no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis. The design and cryptanalysis of generators is outside the scope of this paper.

Random Number Generation

In other words, NIST says their recommended tests are statistics based and insufficient.

If you search you will find the official list of software that is certified as FIPS 140-2.

Correct. That list is here:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1051

you will not find any open source encryption certified by the government as FIPS 140-2

Incorrect. OpenSSL has been on that list since 2008, here's the certificate:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1051.pdf

If you search you will find the official list of software that is certified as FIPS 140-2.

Correct. That list is here:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1051

you will not find any open source encryption certified by the government as FIPS 140-2

Incorrect. OpenSSL has been on that list since 2008, here's the certificate:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1051.pdf

Here's the list of software that is FIPS certified. Be aware that most are libraries that are used in other products, which can sometimes make it hard to tell which particular certified bit is being used by end-user software.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2012.htm

And what is the "official" response for why Building 7 magically collapsed again?

It wasn't magic, it was physics. I suppose to some people it might seem like magic. I threw in a few extra links - figured they might be useful to you.

NIST Releases Final WTC 7 Investigation Report
World Trade Center Disaster Study

The Theory vs. the Facts
Debunking the 9/11 Myths: Special Report

And what is the "official" response for why Building 7 magically collapsed again?

It wasn't magic, it was physics. I suppose to some people it might seem like magic. I threw in a few extra links - figured they might be useful to you.

NIST Releases Final WTC 7 Investigation Report
World Trade Center Disaster Study

The Theory vs. the Facts
Debunking the 9/11 Myths: Special Report

Writing "square mm" is perfectly correct.

It's not perfectly correct. It's acceptable.

Example: meter per second squared (m/s2) The modifiers “square” or “cubic” may, however, be placed before the unit name in the case of area or volume.

At least in the US, NIST, the official standard bearer for all things SI, says you're wrong. "Gigg-a" is simply the ignorant pronunciation, popularized by the same people who though it a good idea to incorrectly use SI prefixes for units based on powers of two (1024 = k, etc.).

Writing "square mm" is perfectly correct.

The data you gather to determine accuracy is tedious, thrilling, gob-smacking, humbling, and generally fun. Here's what we measured to determine the accuracy (uncertainty) of NIST-7. http://tf.boulder.nist.gov/general/pdf/1497.pdf

Yep. If you go to the source, they say "NIST scientists plan to measure the accuracy of the ytterbium clocks in the near future..."

There are also uses of random numbers outside cryptography.I came across this: http://en.wikipedia.org/wiki/Mersenne_twister [wikipedia.org] which is good for some uses, but bad for cryptography.

Pet peeve of mine, but people often casually use MT as an example of a "golden" PRNG when it is really the first (1997) "popular example" for generating extremely long period uniform distributions using a generalized LFSR-like technique. Unfortunatly with simplicity come certain flaws. The biggest flaw is that it takes many iterations for a seeded initial state to get to a state that is really random. For user that aren't simulating huge universe-sized things (or need an extremely large non repeating, but uniform distribution PRNG), this isn't really the best tradeoff. If you have to throw away the first million numbers to sample a few thousand, that isn't the best efficiency ratio.

Fortunatly, most things get improved over time. For example, the "WELL" PRNG (2004) claims to have a faster state randomization time and is probably suited more to the needs of people wanting a default off-the-shelf PRNG for medium sized simulation purposes (e.g, the average scientist that doesn't spend time researching the properties of PRNGs for their simulations). Sadly, WELL isn't more popular since it is a better default PRNG for nearly all uses.

If your needs are more cryptographic based, DRBGs (deterministic random bit generators) are designed to resist identification of the current state (I've heard that it only takes observing 624 iterations to identify MT19937's state vector) and to reasonably stretch any existing true-random sources. NIST has some reasonably good standardized examples of these EXCEPT for Dual_EC_DRBG which paranoid folks should probably avoid...

Linux malware is hard to write, although the SCTP vulnerability last year would have allowed a worm that ran in kernelspace and didn't depend on any installed software. Ubuntu malware, or Android malware, however, are quite easy. That 0.1% figure for Android malware in comparison to Windows malware is probably just about true if you're counting all malware written for both platforms since they were introduced, irrespective of whether it works on recent versions, but it's nowhere near close if you're counting new malware. Take a look at this list and tell me that a widely deployed Linux distribution is hard to write malware for. For example, the CURL CVE-2013-2174 allows a remote attacker with a crafted URL to run arbitrary code, and CVE-2013-1697 in Mozilla allows HTML emails displayed with Thunderbird or web pages displayed with FireFox to execute JavaScript with a privilege level that allows it to make calls to native libraries, effectively meaning arbitrary code execution with ambient privilege. CVE-2013-1052 would allow either of these attacks to upgrade privilege and then install a rootkit.

Formerly responsible for procuring laptops/desktops for a Federal Agency (and still with the agency so posting anon).

All US Federal agencies are required to adhere to Trade Agreement Act (TAA) and Federal Acquisition Regulations (FAR) for procuring any sort of hardware. The VA has a very nice, easy to digest list of the approved countries http://www.va.gov/oal/business/fss/taa.asp/ that Federal agencies can procure equipment from. Almost all the major desktop/laptop vendors (Dell, HP, Toshiba, Samsung and Lenovo!) all have distribution centers in TAA compliant countries like Ireland or Mexico that perform final assembly and then ship to the US (meeting TAA/FAR requirements). Never mind that almost all the component pieces are manufactured in China, once the device is assembled and shipped from a TAA country, its good.

Lenovo being singled out for exclusion as a predominately Chinese owned company is not surprising. While short listing potential vendors, Lenovo was excluded for the potential(!) to have compromising components surreptitiously included with the final product. Of course this came from our parent agency security folks who promptly told us "you're not cleared to know why" when we pushed them on the subject. Its a shame as the Lenovo product line was very competitive in meeting our performance/cost requirements. Shortly after that exchange, NIST published BIOS hardening guidance http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf [PDF Warning] which basically has you flash the BIOS with a known good before doing anything else with the machine, making many of the claims I heard irrelevant (backdoor in BIOS, on the chip, etc).

I own a clock that is tuned to one of those frequencies. I besides the broadcast signal that I can listen to on the shortwave radio, the clock receives and decodes the BCD encoded broadcast which means that the little AA battery is all I need; that and telling the clock the year, and my time zone. Everything else, the day, date, day of the week, the hour, minutes and seconds it sets itself, and keeps itself set accurately to less than a second. All I need is to attach a little arduino to it with an NTP encoder and I can have a stratum 1 NTP server. The clock cost me twenty bucks (very cheap!)

NIST changed the broadcast format to include some phase modulation.

Indeed they don't even claim anything close to worldwide coverage themselves. Here are their estimated coverage maps.

There's a huge list of test vectors for AES published by NIST (among others): http://csrc.nist.gov/archive/aes/rijndael/wsdindex.html

The chances of being able to write some code which reproduces those values but ISN'T AES are less than the reciprocal of the number of atoms in the universe.

Maybe. Assuming that NIST is completely independent (or even adversarial) to the NSA. Just because they've both agencies of the same government doesn't mean the spooks have any influence over NIST. The NSA would never do anything like that.

It's not so easy to make sure that a program is a correct implementation of a mathematical algorithm or of an open standard.

There's a huge list of test vectors for AES published by NIST (among others): http://csrc.nist.gov/archive/aes/rijndael/wsdindex.html

The chances of being able to write some code which reproduces those values but ISN'T AES are less than the reciprocal of the number of atoms in the universe.

Not sure where you got 1,000,000 from, it is 1,000 petaflops in an exaflop

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

For sure there are significant challanges, in programming methods as much as anything else. Cores are not getting much faster, what you get are more and more of them, which makes huge demands on the amount of parallelism you have. And means IO becomes comparatively very slow indeed.

You might look at "The NIST Definition of Cloud Computing": http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf - it's one-and-a-half pages once you skip the boilerplate.

For some people nothing says "appeal to emotion" like FBI arrest reports I guess.

Here are some great resources for anyone confused by information at "911truth.org" and would like more information.

'Debunking 9/11 Myths': Nano-thermite dust found near Ground Zero (Photos)
Debunking 9/11 Myths: conspiracy plots are sheer fantasy

NIST Releases Final WTC 7 Investigation Report
World Trade Center Disaster Study

Debunking 9/11 Myths: Why Conspiracy Theories Can't Stand Up to the Facts
Debunking the 9/11 Myths: Special Report
Debunking the 9/11 Myths: Special Report

Resources for debunking 9/11 Conspiracy Theories

Debunking 9/11 Bomb Theories

The Truthers Are Out There

9/11 Conspiracy Theories: The 9/11 Truth Movement in Perspective

Debunking Conspiracy Theories In 'Voodoo Histories'

For some people nothing says "appeal to emotion" like FBI arrest reports I guess.

Here are some great resources for anyone confused by information at "911truth.org" and would like more information.

'Debunking 9/11 Myths': Nano-thermite dust found near Ground Zero (Photos)
Debunking 9/11 Myths: conspiracy plots are sheer fantasy

NIST Releases Final WTC 7 Investigation Report
World Trade Center Disaster Study

Debunking 9/11 Myths: Why Conspiracy Theories Can't Stand Up to the Facts
Debunking the 9/11 Myths: Special Report
Debunking the 9/11 Myths: Special Report

Resources for debunking 9/11 Conspiracy Theories

Debunking 9/11 Bomb Theories

The Truthers Are Out There

9/11 Conspiracy Theories: The 9/11 Truth Movement in Perspective

Debunking Conspiracy Theories In 'Voodoo Histories'

Here you go:

NIST Releases Final WTC 7 Investigation Report

Ah, that's okay then, because FreeType is known to be a secure and well-written piece of software...

Another convention sometimes used is that, since 12 noon is by definition neither ante meridiem (before noon) nor post meridiem (after noon), then 12 a.m. refers to midnight at the start of the specified day (00:00) and 12 p.m. to midnight at the end of that day (24:00). Given this ambiguity, the terms 12 a.m. and 12 p.m. should be avoided.

This is what the NIST (USNO) have to say in regards to 'Are noon and midnight referred to as 12 a.m. or 12 p.m.?':

This is a tricky question because 12 a.m. and 12 p.m. are ambiguous and should not be used.

Another convention sometimes used is that, since 12 noon is by definition neither ante meridiem (before noon) nor post meridiem (after noon), then 12 a.m. refers to midnight at the start of the specified day (00:00) and 12 p.m. to midnight at the end of that day (24:00). Given this ambiguity, the terms 12 a.m. and 12 p.m. should be avoided.

This is what the NIST (USNO) have to say in regards to 'Are noon and midnight referred to as 12 a.m. or 12 p.m.?':

This is a tricky question because 12 a.m. and 12 p.m. are ambiguous and should not be used.