Slashdot Mirror

In that case, FairPlay is also open: drms.c and DeDRMS.cs. MD5 and AES.

Here are a few more SI prefixes, including both "milli-" and "mega-". See if you can spot the subtle differences between them and be prepared to describe them to the rest of the class tomorrow.

I've bitched about this before, but why can't news sites provide links to their sources? This is the internet, after all; we have the technology. It would take seconds, and obviously the journalist already has the information. Yes, I know I can search it myself, but I shouldn't have to - the supporting documentation should be provided by the person writing the article. (And, yes, I'm aware of the irony of saying that without providing a link. :) But I'm stating an opinion, not a fact.)

--RJ

...the government will now enforce standards?

No, that's what we have the National Institute of Standards and Technology for.

/never mind the .gov

You may also want to take a look at:
http://math.nist.gov/jnt/
http://www.vni.com/products/imsl/jmsl.html
http://www.mathtools.net/Java/Libraries/

It is a great idea. There's just one problem with it.

You can send Online comments here by clicking on the "Submit Comments or Position Statements" link. Alternately you can e-mail your comments to vote@nist.gov.

I spoke to one of the committee members Allan Eustis. He stated that their mandate is to provide "Initial Recommendations of Voluntary Guidelines" this coming April. These guidelines will likely follow and overlap with the FEC2000 Guidelines and will apply to all parties in the "voting community" (States, Vendors, etc.). He stated that they would be unlikely to do a great deal before the election other than gather info as they have no budget until then.

While he was on the phone with me another individual in his office was complaining about the security challenges that they will have in dealing with some public comment (I am assuming this one). Apparently checking in guests at the gate ain't easy.

You can send Online comments here by clicking on the "Submit Comments or Position Statements" link. Alternately you can e-mail your comments to vote@nist.gov.

I spoke to one of the committee members Allan Eustis. He stated that their mandate is to provide "Initial Recommendations of Voluntary Guidelines" this coming April. These guidelines will likely follow and overlap with the FEC2000 Guidelines and will apply to all parties in the "voting community" (States, Vendors, etc.). He stated that they would be unlikely to do a great deal before the election other than gather info as they have no budget until then.

While he was on the phone with me another individual in his office was complaining about the security challenges that they will have in dealing with some public comment (I am assuming this one). Apparently checking in guests at the gate ain't easy.

Here's all the prior art you will ever need to fight a generic file hashing patent from 1997:

http://www.itl.nist.gov/fipspubs/fip180-1.htm Published 1995 April 17 (FIPS 180 was published 1993 May 11)

Explanation: This Standard specifies a Secure Hash Algorithm, SHA-1, for computing a condensed representation of a message or a data file

Game over.

That may seem like a reasonable request, but you should know that exploits, especially automated exploits couldn't care less about what version of a service you're claiming to run. They don't even care that it's the right platform.

The attacking system simply establishes a handshake, introduces the stimulus and waits for the response. If they get the desired response (shell, etc), great. If not, oh well, 1 down, 2^32-1 to go :).

Now for the flip side:
As an admin, if you knew you were not playing silly cat and mouse games with your banners, you'd be able to quickly determine which systems are still out of date.

And now for something completely different:
If you really want a secure user space application environment, you should build on a secure foundation. *BSD, UN*X (Solaris, AIX, HP-UX, etc), Linux, Windows, MacOSX, etc all employ a variation of Discretionary Access Control. DAC systems do not provide you the ability to actually enforce a security policy. Hardening an application on a DAC based foundation is akin to building a fortress on a foundation of sand.

If you require the ability to enforce your security policies, you need to start out with a sane and audited hardware base, and add on to it an OS equipped with mechanisms that provide for granular Mandatory Role Based Access Controls. You may consider the SE Linux project a good place to start.

That may seem like a reasonable request, but you should know that exploits, especially automated exploits couldn't care less about what version of a service you're claiming to run. They don't even care that it's the right platform.

The attacking system simply establishes a handshake, introduces the stimulus and waits for the response. If they get the desired response (shell, etc), great. If not, oh well, 1 down, 2^32-1 to go :).

Now for the flip side:
As an admin, if you knew you were not playing silly cat and mouse games with your banners, you'd be able to quickly determine which systems are still out of date.

And now for something completely different:
If you really want a secure user space application environment, you should build on a secure foundation. *BSD, UN*X (Solaris, AIX, HP-UX, etc), Linux, Windows, MacOSX, etc all employ a variation of Discretionary Access Control. DAC systems do not provide you the ability to actually enforce a security policy. Hardening an application on a DAC based foundation is akin to building a fortress on a foundation of sand.

If you require the ability to enforce your security policies, you need to start out with a sane and audited hardware base, and add on to it an OS equipped with mechanisms that provide for granular Mandatory Role Based Access Controls. You may consider the SE Linux project a good place to start.

NIST is funding a large scale effort to build a QC capable of factoring a 128 bit number in 30 seconds.
http://qubit.nist.gov/FoQuS/foqus.html

Quantum computers don't require any fundamental new breakthroughs, they are now almost an engineering problem. There is a real chance that the manhattan-style approach being taken by NIST will succeed in the next 20 years.

... for us to have the equivalet of today's computers (or better) in QC.

They're not equivalent. And they don't need to be.

In North America you can already get time from an atomic clock via radio. NIST Radio Station WWVB transmits time information on a 60KHz RF carrier at 1 bit per second.

• Currently, the GPS system provides time to the general public with uncertainties measured in nanoseconds.

GPS receivers are required to synchronize very closely to the atomic clocks in the GPS sattelites in order to calculate position... they have to measure how far RF signals (travelling at the speed of light) have gone. GPS receivers (and the article's atomic clock) are more than a million times more precise than "a few ms of lag".

The ESB uses a steel framework to carry the load. The rock facing you see is simply hung from this framework. See this link for a brief description.

The WTC had no such framework. There was a central core which was the main frame. From that central core the floor panels were attached on one end and on the other end were attached to an outside aluminum framework whose sole purpose was to supply rigidity. It was not designed to carry the building load. See this site for a very good description of the design.

When the planes slammed in to the WTC the outer rigidity was compromised as was the central core. The burning of the jet fuel softened (NOT MELTED) the steel supports under the floor panels which caused them to sag. Add in the extra weight of the plane sitting on the floor panels and the panels were eventually pulled loose from their attachments to the outer aluminum wall. The floor panels then began to fall in the now proverbial 'pancake' fashion.

Without the floor panels providing the necessary support the outer skin was not able to do its job. Thus, the floors above the impact point no longer had the stability they once had. When those floors began to collapse that was when the whole structure gave way.

The other key difference in the two hits is that the plane that hit the ESB was traveling at a much slower speed than were the planes that hit the WTC. Further, the two planes carried a much higher fuel load and were nearly full upon impact.

Here is the most current report and testing results. It was released on August 25th. While I read the NY Times version this is from the official tests. Lots of .pdf files.

Untits, people, units!

It is Petabyte and the 'pb' somebody further on uses would be a "pico bit", i.e. 1/1000000000000 of a bit.

Here is a reference for those without clue about SI prefixes: http://physics.nist.gov/cuu/Units/prefixes.html

Just because the media has no clue is no excuse to do it wrong.

NIST Net

Nistnet is another tool that simulates delay.

-jim

The NIST ATM simulator (public domain) might be useful. You need to provide some personal info to download it, but that isn't verified.

Indeed, there are infinitely many unique bit strings we may take the hash of, and yet only 2^160 hash values they can map to. By the pigeonhole principle, some hash value is mapped to by at least two unique bit strings.

(The pigeonhole principle says that if you shoot N pigeons with N+1 bullets, and don't miss, one pigeon has two holes... or something like that.)

Now hash functions can be classified as either weak collision resistant or strong collision resistant.

A hash function h is weak collision resistant if, given h and a bitstring x, it is impossible to find some other x' such that h(x) = h(x'). Note that x is specified.

A hash function h is strong collision resistant if it is infeasible to compute any collision (x, x') of h.

So, if a collision was found in MD5, it's no longer strong collision resistant (since the person found a pair x, x' such that h(x) = h(x')). Its when MD5 is no longer weak collision resistant that things start to get scary -- meaning, given any arbitrary bit vector, I can find another bit vector that generates the same hash value in a reasonable amount of time. This means that, after you download your favorite Linux ISO, just making sure the MD5 hash checks out does not garuantee the authenticity of the file.

But no worries. There's still SHA-1. And if that isn't good enough, there's its bigger cousins, SHA-256, SHA-384, and SHA-512.

- sm

Also, I forgot to cite a good password generation link. Check out the http://www.itl.nist.gov/fipspubs/fip181.htm APG system, fips 181, which will help you perform random walks (a combinator term, not a calisthenics term) to generate strong passwords.

Here's an example of a page I recently had to go into IE to get to print nicely -- Preview showed me that Firefox would have cropped off the right edge of the text. http://niap.nist.gov/cc-scheme/interps-process.htm l

Kind of a waste because it has exactly the same text as scienceblog. same text as the scienecblog.

Gov't studies effect of viruses, DDoS on grid computers

Posted on Sunday, August 01, 2004 @ 3:44 PM PDT by bjs

By connecting hundreds or even thousands of computers together to work on a single project, computer scientists are more frequently using a technique called grid computing to do previously intractable computations. Grid computing takes advantage of ''down time'' when computers are not using their full processing power to provide quick answers to problems in fields such as genomics, engineering design and financial services. While parallel processing typically involves tying together multiple computers at a single site--all using one piece of software--a computer grid may be much more geographically dispersed, composed of many heterogeneous computers whose availability may change over time.

From NIST:

NIST tackles tough problems with reliable computer grids

By connecting hundreds or even thousands of computers together to work on a single project, computer scientists are more frequently using a technique called grid computing to do previously intractable computations.

Grid computing takes advantage of ''down time'' when computers are not using their full processing power to provide quick answers to problems in fields such as genomics, engineering design and financial services. While parallel processing typically involves tying together multiple computers at a single site--all using one piece of software--a computer grid may be much more geographically dispersed, composed of many heterogeneous computers whose availability may change over time.

Computer scientists at the National Institute of Standards and Technology (NIST) recently launched a new project to improve understanding of how computer grids react to volatile conditions. A computer grid's strength--the teaming of many computers--also makes it more vulnerable to failures, viruses, sudden changes in workload and cyber attacks such as denial of service. NIST researchers are developing computerized models that will help establish how vulnerable grid networks are to failure. They hope to create ways to detect failure quickly and then fix the problem.

Originally developed as a way to connect supercomputers working on extremely complex problems like climate modeling, grid computing is rapidly finding commercial applications. Already some investment companies are using grid computers to analyze shifts in financial markets in real time. And pharmaceutical companies are beginning to use them to overcome the computational challenges of developing new drugs.

As commercial applications grow, protecting such networks and ensuring their reliability will become more critical. The NIST researchers hope to complete their models by early next year.

At my company, we have a small QA group that tests several enterprise client-server applications, including consumer-level applications on multiple platforms. To exhaustively test all of the permutations and platforms is literally impossible, so we turn to automation for many of the trivial tasks. We've developed several of our own automation harnesses for UI testing and for API and data verif. testing. The technologies that we've used :
- Seque's silktest
- WinRunner
- WebLoad
- Tcl/Expect

There are *many many* problems with large-scale automation, because once you develop scripts around a particular user interface, you've essentially tied that script to that version of your application. So this becomes a maintenance problem as you go forward.

One very useful paradigm we've employed in automation is to use it to *prep* the system under test. Many times its absolutely impossible to create 50,000 users, or 1,000 data elements without using automation in some form. We automate the creation of users, we automate the API calls that put the user into a particular state, then we use our brains to do the more "exotic" manual testing that stems from the more complex system states that we've created. If you are to embark on automating your software, this is a great place to start.

Hope this helps.

Microsoft Research China is where almost all of MSFT's multimedia researchers live. When competing in NIST's Video TREC, MSR China are the people who go. Granted, all the cool stuff comes from either IBM (New York), Berkerley, or CMU.

when you buy a new 1000baseT ethernet card it can potentialy hit 1,000,000,000 bits per second. The storage and networking worlds use the true meanings of Kilo = thousand, Mega = million, Giga = billion, Tera = trillion, Peta = Quadrillion ...

You don't see peaple bitching that they paid to travel a Kilometer in a taxi but they only went 1000 meters...

The problem is actually that WAY back in conputing history the term kilo was misappropriated because there was no verbal shorthand for 1024. Since then we have come up with the alternative terms of KiBi(KiloBinary) = 1024(2^10); MeBi = 1,048,576(2^20); GeBi = 1,073,741,824(2^30); TeBi = 1,099,511,627,776(2^40)...

Check out http://mathworld.wolfram.com/Byte.html
http://www.bipm.org/en/si/prefixes.html
http://physics.nist.gov/cuu/Units/binary.html
for more info.

I must admit that they sound a bit funny though...

More information about the Cryptographic Module Validation Program (the current standard for encryption is FIPS 140-2) can be found here: http://csrc.nist.gov/cryptval/140-2.htm

Also, here's a group which has both Windows and Linux versions of a FIPS 140-2 AES implementation, if you want to know what it looks like in action: http://www.standardnetworks.com/moveitcrypto

I always use Rijndael, since RijnDael is AES! And yes I use a 256bit key as my standard.

And as long as I've ever used AES I've been under the distinct impression that the AES (rijndael) algorithm uses three cipher key strengths: 128, 192, or 256-bit encryption key.

So feed me some links that show me I'm wrong here people.

I can write a new notation on a napkin or a webpage, that doesn't make it correct. Only widespread acceptance can do that. And outside of a few engaging in debates regarding the subject on slashdot, nobody has accepted it.

Look here for info...
To tell the truth, I think that in order for it to be "accepted," it has to be inducted into some French museum, and correlated in some way to a KG sized bar of silver, or something.

Being widespread doesn't make right. There is a widespread use of "your" in place of "you're" and "axe" in place of "ask." Neither of these usages is correct, but they have widespread acceptance.

I was looking through the authors citations and it seems that his quote concerning the number of vulnerabilities in Linux compared to those in Windows is pretty questionable. The database, as you can see here, has one selection for Linux and many for Windows. It seems that the U.S. National Institute of Standards and Technology considers components of Windows, such as Internet Explorer not to be a part of the operating system, thus listing vulnerabilities of the compenents separate from those of the OS. At the same time, Linux vulnerabilities include Sound Blaster driver issues and problems with third party software such as Symantec Antivirus.

Correction to Story:
"K" is the unit of temperature, the Kelvin.
"k" is the abbreviation for "kilo", 1,000.

Correction to Story:
"K" is the unit of temperature, the Kelvin.
"k" is the abbreviation for "kilo", 1,000.

According to the National Institute of Standards and Technology, you're ... right!

There's a link showing binary multiples here

unless/until somebody develops a SIP IM client for linux...

Does a java client cut it?

Should be:
CD&DVD Care and Handling Guide

Don't know how that got a space in it the first time.

It looks like this may supercede the NSA one. From the FAQ for the guide at http://csrc.nist.gov/itsec/guidance_WinXP.html:

How were the publication and security templates developed?
The publication was developed by NIST; however, NIST started with excellent material developed by the National Security Agency (NSA), DISA (Defense Information Systems Agency), Microsoft, and other members of the security community. NIST collaborated with NSA, DISA, the Center for Internet Security (CIS) and Microsoft to produce the publication's consensus baseline settings for various operational environments.

<a href="http://www.nist.gov/srd/index.htm">NIST databases</a>

Looks like those NIST folks forgot all about the DISA STIGs

... before it's too old for the front page. Probably a good idea to read before heading straight to the zip file.

guidance_WinXP.html

A fair bust. I remembered the number from my admittedly old Halliday and Resnick, 6.02252e23. Even wikipedia's quote of an authoritative source for 1998 has been updated a little as of 2002.

Exactly right: number of atoms in 12 grams of carbon-12, but it wasn't always that. More, with a pretty good introduction and brief history of the SI system, with interesting trivia (such as the fact that the metre is defined in terms of the speed of light as of 1983, rather than a wavelength of Krypton-86 radiation) here.

But technically the interesting point of the certification id that they managed to get the source code certified. There is at least one other open souce product Crypto++ that is also FIPS 140.2 validated (Certificate #343). But they only managed to get a compiled package validated, which does help me to trust the code but not really to "sell" the library to PHBs. The article doesn't really go into how they did get NIST to validate the source code. Anybody know more details?

But technically the interesting point of the certification id that they managed to get the source code certified. There is at least one other open souce product Crypto++ that is also FIPS 140.2 validated (Certificate #343). But they only managed to get a compiled package validated, which does help me to trust the code but not really to "sell" the library to PHBs. The article doesn't really go into how they did get NIST to validate the source code. Anybody know more details?

NIST have recently released a good guide on securing XP boxes here

I haven't had the time to read it yet, but from the high quality of their other documents it is probably well worth printing and reading.

(from a quick read of some web searching...) WPA (the precursor of 802.11i) used RC4 with a per-packet key transmorgifier called TKIP and authenticated both peers using either Extensible Authentication Protocol (EAP - useful in coprorate contexts with RADIUS or NT-Domain password servers) or Preshared Key (PSK - useful in home contexts where not password servers are available). 802.11i (seems to... quick read equivocation) add the option of replacing RC4-TKIP with AES-CCMP but the peer authentications (your choice of EAP or PSK) remain unchanged. This CCMP mode of AES keeps the temporal key and integrity features of RC4-TKIP but is (assumed to be) stronger encryption. Both encryption options, RC4-TKIP and AES-CCMP, require an intial key (same on both peers). Where this initial key comes from is an application layer decision and is beyond the scope of 802.11i.

Forgot the URL of the NIST overview: NIST overview

Pass a "law" and redefine reality. We tried it with pi, too.
Pi is a natural constant, defined as the ratio between a circle's circumference and its diameter.
A "meter" is an artificial definition. And, in particular, the "definition" of a meter has changed many times over the year, starting with the first adoption in 1791, being re-defined many times over the years, and only ending (for the moment) with the current definition in terms of c, the speed of light, in 1983. This article gives a history
Nobody was trying to legislate reality, just clarify definitions.

This is the second story from Timothy in just a bit more than a week where SI units are used incorrectly. See the previous story.

In this story 15-25 Mb/s is expressed two ways:

1) 15-25Mbps
2) 15-24mbps

Both of these are incorrect. Here's an reference on how to use SI correctly to back me up.

In short:

a) There's always a space between the number and the units.
b) "M" is mega and "m" is milli. There's nine orders of magnitude difference between to two.
c) "per" is expressed with a "/".

Another convention is that M=10e6, and m=10e-3.