Slashdot Mirror

The correct unit is GB. Save the GiB unit for the base ten approximations.

Actually, you have it backwards. The MB, GB and so on are normal SI prefixes, and are units in base 10. The KiB, MiB, GiB etc, however, are in base 2. See for yourself.

check my MD5 signatures

What's the point, indeed. We should have moved away from MD5 signatures years ago. It's only a matter of time before some maliciously inclined asshat starts forging MD5 signatures on FLOSS packages, just to prove a point.

MD5 is broken and should not be used. It's time the FLOSS world went to at least SHA-224, if not SHA-512 (for future proofing, lots of bits). And just for reference, there is an open call for a new secure hash.

For Natural Language Processing and Question Answering research activities, search for "AQUAINT (DTO OR ARDA OR IARPA)" and also the NIST TREC (Text Retrieval Conference) workshops and research competitions.

There is a lot of interesting work out there and some answers as to why more precise information finding through natural language input is useful.

I see no proof of this. Apple responds relatively quickly to security holes and releases regular patches and updates.

Well, yes and no. Apple *is* very good with many security issues, but here are a few counter-examples off the top of my head:

• CVE-2007-2788: Integer overflow in the embedded ICC profile image parser in the JDK. Unpatched for over a year.
• CVE-2007-0243: Buffer overflow in the Sun JDK GIF parser. Vulnerability was made public on January 17th, 2007, and was unpatched until December 13th, 2007.
• CVE-2007-5232: When Java applet caching is enabled, allows remote attackers to violate the security model for an applet's outbound connections. Released October 5th, 2007, unpatched until December 13th, 2007.

Apple is not operating at 100% all of the time. In the case of these Java updates, some potentially serious issues sat unpatched for a good long while.

I see no proof of this. Apple responds relatively quickly to security holes and releases regular patches and updates.

Well, yes and no. Apple *is* very good with many security issues, but here are a few counter-examples off the top of my head:

• CVE-2007-2788: Integer overflow in the embedded ICC profile image parser in the JDK. Unpatched for over a year.
• CVE-2007-0243: Buffer overflow in the Sun JDK GIF parser. Vulnerability was made public on January 17th, 2007, and was unpatched until December 13th, 2007.
• CVE-2007-5232: When Java applet caching is enabled, allows remote attackers to violate the security model for an applet's outbound connections. Released October 5th, 2007, unpatched until December 13th, 2007.

Apple is not operating at 100% all of the time. In the case of these Java updates, some potentially serious issues sat unpatched for a good long while.

I see no proof of this. Apple responds relatively quickly to security holes and releases regular patches and updates.

Well, yes and no. Apple *is* very good with many security issues, but here are a few counter-examples off the top of my head:

• CVE-2007-2788: Integer overflow in the embedded ICC profile image parser in the JDK. Unpatched for over a year.
• CVE-2007-0243: Buffer overflow in the Sun JDK GIF parser. Vulnerability was made public on January 17th, 2007, and was unpatched until December 13th, 2007.
• CVE-2007-5232: When Java applet caching is enabled, allows remote attackers to violate the security model for an applet's outbound connections. Released October 5th, 2007, unpatched until December 13th, 2007.

Apple is not operating at 100% all of the time. In the case of these Java updates, some potentially serious issues sat unpatched for a good long while.

TAI itself isn't known until after the fact, since it is an average of multiple national time standards. Even those standards aren't synchronized to within their inherent precision. Different clocks which contribute to TAI can differ from each other in the microsecond range.

Timing GPS receivers can sync to well under that. NIST has some information on tracability.

The short answer is that your question was in regard to NTP, and a time server locked to GPS time is considered to be Stratum 1.

Is this whole thing a joke, or do these clocks actually work for some people? I had another one several years ago that also did not work.

I have an Oregon Scientific clock which has traveled with me from the South Bay to Seattle to Vancouver, BC and now back to Seattle. It works great and has done its part to keep me on time. As long as you are inside WWVB's footprint and aren't doing wrong things which will mess with longwave propagation (i.e. living in a house which is running unshielded electric motors all day or having a wall of bare monitors), it should work fine.

I have a tangential story about a roommate with a piece of hardware that messed up all my RF, but it's Not Safe For Slashdot. ;-)

Sure. The answer, on any drive > 15GB, is 1-Pass.

Stunning eh? I'll challenge anyone to prove that it is possible to recover anything from a modern hard disk that has been overwritten once with anything other than a magnetic microscope. And even that is questionable.

Modern drives are so dense that drive makers have a hard enough time getting data back off of them after its been written.

But you asked for documentation:

NIST Guidelines for Media Sanitization
http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf

Storage Networking Discussion
http://storage-networking.org/Discussion/forum_posts.asp?TID=59&PN=1

Guttman's Revised Paper
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

"Spam detection has got to be something like 99.999% accurate"

Nonsense. 99.999% is one error in 100,000 emails. Have you even received 100,000 emails? Have you checked every one to see if the filter made at most one mistake? Have you repeated the measurement several dozen times, as would be necessary to make such a claim? Of course not.

I would be surprised if the filter you are using (including Gmail) is 99% accurate.

Here are some accuracy figures under ideal conditions. From side-by-side comparisons I can assure you that spam filters in the field do considerably worse. You just don't notice.

char assignment[7];

strcpy(assignment,"SUCCESS");

strcpy(assignment,"REJECTION");

char fn[32];

sprintf(fn, "experiments/%s/output%d.dat", generatorDir[option], counter/100);

X = (double*) calloc(n,sizeof(double))

for( i=0; i<n/2; i++ ) {
    m[i+1] = sqrt( pow(X[2*i+1],2) + pow(X[2*i+2],2) );
}

char assignment[7];

strcpy(assignment,"SUCCESS");

strcpy(assignment,"REJECTION");

char fn[32];

sprintf(fn, "experiments/%s/output%d.dat", generatorDir[option], counter/100);

X = (double*) calloc(n,sizeof(double))

for( i=0; i<n/2; i++ ) {
    m[i+1] = sqrt( pow(X[2*i+1],2) + pow(X[2*i+2],2) );
}

char assignment[7];

strcpy(assignment,"SUCCESS");

strcpy(assignment,"REJECTION");

char fn[32];

sprintf(fn, "experiments/%s/output%d.dat", generatorDir[option], counter/100);

X = (double*) calloc(n,sizeof(double))

for( i=0; i<n/2; i++ ) {
    m[i+1] = sqrt( pow(X[2*i+1],2) + pow(X[2*i+2],2) );
}

N.S.A. already owns the patent to DES and the whole point of that was have a backdoor when Clipper failed to pass.

You also know that N.I.S.T. is a front for N.S.A. too right? Of course there's a backdoor.

This and other stories are available in the latest issue of DUH!

I am willing to bet two things:
1) This does not affect current versions of Windows.
2) This only affects exported versions of Windows. (The PRNG may still be there but may not be default.)

The RC4 implementation screams of a bit-size issue. It also goes to reason since they are in a non-US country. Furthermore, I doubt this affects current versions based on the information available. If you want, go throw the CMVP RNG validation list and find the Microsoft certificates. All of the RNGs that are approved do not use RC4.

I believe there is a lot of hot-air and presumption and in the paper. They published findings and ASSUMED that nothing has been changed with relation to the PRNG. The algorithm certificates shown above clearly shows this is not the case. Furthermore, they do not state which cryptographic provider is used to perform the generation. I believe this PRNG might be from DSS_BASE, which has since been deprecated. This would mean the problem does not exist. They also ask for Microsoft's code, yet I see none of their own. Without their code, how can their paper be reasonably verified.

I say show me some more, before you cry that this is the way all PRNGs since W2K have been implemented.

Once upon a time, computer professionals noticed that 210 was very nearly equal to 1000 and started using the SI prefix "kilo" to mean 1024. That worked well enough for a decade or two because everybody who talked kilobytes knew that the term implied 1024 bytes. But, almost overnight a much more numerous "everybody" bought computers, and the trade computer professionals needed to talk to physicists and engineers and even to ordinary people, most of whom know that a kilometer is 1000 meters and a kilogram is 1000 grams.

Then data storage for gigabytes, and even terabytes, became practical, and the storage devices were not constructed on binary trees, which meant that, for many practical purposes, binary arithmetic was less convenient than decimal arithmetic. The result is that today "everybody" does not "know" what a megabyte is. When discussing computer memory, most manufacturers use megabyte to mean 2^20 = 1 048 576 bytes, but the manufacturers of computer storage devices usually use the term to mean 1 000 000 bytes. Some designers of local area networks have used megabit per second to mean 1 048 576 bit/s, but all telecommunications engineers use it to mean 106 bit/s. And if two definitions of the megabyte are not enough, a third megabyte of 1 024 000 bytes is the megabyte used to format the familiar 90 mm (3 1/2 inch), "1.44 MB" diskette. The confusion is real, as is the potential for incompatibility in standards and in implemented systems.

Faced with this reality, the IEEE Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body.

http://physics.nist.gov/cuu/Units/history.html
The name "SI" came about in 1960, but the units and prefixes existed long before that in standards and scientific usage.

Since your post is written with about as much intelligence as one'd expect from a tree stump, I doubt you are going to grasp anything at all, but to try and help you anyway: Read what the U.S. gov't has to say about it. If that's too dry for you, this wikipedia article might be interesting, too.

If a megabyte is counted as 1024 kilobytes how's your math working? Still 8 bits to a byte right? I mean I thought a byte was a byte, are you telling me a hard disk follows different conventions? Because last time I checked binary units were pretty stable, not a lot of 'wiggle room' in the interpretation.

However, the various SI prefixes -- kilo, mega, giga, exa, and others -- were overloaded by the computer industry to refer to powers of two ("kilo" = 2**10, "mega" = 2**20, "giga" = 2**30) which were "pretty close" to their SI counterparts.

This has actually caused some confusion as computer people speaking of "kilo" this and "mega" that have worked with scientists who have always used the traditional SI meanings. These differences in interpretation can mean your chemical process doesn't work, the patient dies, you miss Jupiter, etc.

To help redress this problem, a new set of prefixes have been coined to refer to powers of two. These new prefixes have seen uneven but increasing adoption in the industry (if you have a recent Ubuntu/Debian release, run the command ifconfig -- the byte counts have the new prefixes).

So, the hard drive makers have been using the SI meanings for "giga" and, in case there was any confusion, explicitly printed in their literature, "One gigabyte is equal to 1000000000 bytes."

So, at first reaction, I think Seagate got screwed here. This makes me wonder if there aren't other layers of nuance that came out in court, but are lost in these stories.

Schwab

The metric prefixes were always used for the powers of ten, not powers of two. This was made *abundantly* clear when IEC approved different names for the power of two 'equivalents' in 1998.

See http://physics.nist.gov/cuu/Units/binary.html

Ballots in the United States typically have 20 to 30 contests on them. The Chicago ballot in 2004 had 90 contests.

People keep saying how fast Canadian elections are. (I'm Canadian too.) But they're missing a huge difference.

In Canada you usually have one contest.

This is why hand-counting doesn't work in the United States. Chicago, November 2004: 10 pages, 15 elected offices, 74 judges, one referendum. That's 90 contests.

See more at NIST's ballot collection.

People keep saying how fast Canadian elections are. (I'm Canadian too.) But they're missing a huge difference.

In Canada you usually have one contest.

This is why hand-counting doesn't work in the United States. Chicago, November 2004: 10 pages, 15 elected offices, 74 judges, one referendum. That's 90 contests.

See more at NIST's ballot collection.

I wonder how come none ever made "Optical Tape Storage" (and I DON'T mean microfilm)?

Ballots in the United States are far longer than those in Canada. Have a look for yourself: NIST has a collection of ballots online.

Here's one example: Chicago, Illinois, November 2004. 10 pages of choices, with 15 elected offices, confirmations of 74 judges, and one referendum. We're talking about 1 or 2 orders of magnitude longer than a Canadian ballot.

I do not support unauditable voting computers. I just wanted to explain why the voting problem is much different in the U. S., and give you some idea why the desire for automation is so strong. (I'm Canadian as well.)

Ballots in the United States are far longer than those in Canada. Have a look for yourself: NIST has a collection of ballots online.

Here's one example: Chicago, Illinois, November 2004. 10 pages of choices, with 15 elected offices, confirmations of 74 judges, and one referendum. We're talking about 1 or 2 orders of magnitude longer than a Canadian ballot.

I do not support unauditable voting computers. I just wanted to explain why the voting problem is much different in the U. S., and give you some idea why the desire for automation is so strong. (I'm Canadian as well.)

In other news, the NSA is partnering with NIST and University of Maryland to form the Joint Quantum Institute.

Now Slashdot has been invaded! Is there nowhere I can go to escape these conspiracist nutbags? I will make a feeble attempt to counteract this inane review of an inane book, with a list of various debunking links:

September 11th
http://www.popularmechanics.com/blogs/911myths/
http://www.debunking911.com/index.html
http://www.911myths.com/
http://wtc.nist.gov/

Income Tax and the Federal Reserve
http://docs.law.gwu.edu/facweb/jsiegel/Personal/taxes/IncomeTax.htm
http://www.publiceye.org/conspire/flaherty/Federal_Reserve.html

Other
http://www.debunker.com/conspiracy.html
http://www.ejectejecteject.com/archives/000140.html

General
http://en.wikipedia.org/wiki/Conspiracy_theory
http://www.urban75.org/info/conspiraloons.html
http://www.csicop.org/si/9012/critical-thinking.html

The first submission lead people to believe that it was some kind of vulnerability in OpenBSD when its really a whole class of security problem affecting any kind of process that attempts to trap the system calls of another for the purposes policy verification.

It's not a new class, CVE-2006-0457 is in the same category, for instance.

"Also, this may be a stupid question, but I wonder how one measures the 'randomness' of a generator?" There are lots of places that talk about this. A simplistic explanation of what it means to be a good PRNG is simply to provide a sequence of numbers with no correlations that matches the desired distribution. (http://mathworld.wolfram.com/RandomNumber.html). Books on modeling and simulation often have good explanations of this. This page (http://csrc.nist.gov/rng/) has a good overview, including simple descriptions of 16 statistical tests of interest.

Sure, there are metrics to evaluate randomness. One of the most common methods is entropy (http://en.wikipedia.org/wiki/Information_entropy). It can be use to calculate the "randomness" of data. It works so well that forensics people use it to carve files on hard disk (used to find a continuous stream of non-random data among random data). http://www.korelogic.com/Resources/Presentations/ceic_2007_advanced_file_carving_with_ftimes_final.pdf

There are several mathmatical metrics to evaulate randomness. Hell, there is even a FIPS publication (Federal Information Processing Standards) that covers a set of test that are intended to show a data set is random. http://csrc.nist.gov/cryptval/140-1/1401test.pdf

All organizations interested in possibly hosting a NIST Internet Time Service server are invited to contact Time and Frequency Division Chief Thomas O'Brian for more information, including a description of the equipment that the organization must have available and a discussion of the other technical qualifications necessary to host a server: obrian@boulder.nist.gov .

It seems that NASA is implementing PIV-II. Those smart cards mentioned in TFA look like those mentioned in the FIPS-201 standard.

Basically, everyone getting a PIV card has to pass a background check. However, it seems that asking those scientists and engineers about all that data mentioned in TFA is a bit excessive. The standard has an informational appendix (appendix C) that specifies what sort of checks should be done. It even specifies two levels of checks for different security levels. Looks like someone got a little bit too anal when deciding what checks to do. The checks mentioned in FIPS-201 seem reasonable, though. Can anyone that knows about background checks explain what they are exactly?

The cards themselves seem pretty good. It is pretty clear that the designers of FIPS-201 cards do not trust the wireless interface, making all biometric/sensitive information available only on the wired interface, unlike those e-passports every government is promoting. Pretty interesting reading material.

Or for hours of non-stop time-listening fun, you can always take the shortwave option, at the frequencies listed on the WWV website: http://tf.nist.gov/stations/wwv.html.

Companies only care about their bottom line. Brand identity and other priorities are all directly related to their profitability and thus everything comes down to the bottom line.

Looking at an extreme example such as our children's welfare, the USCPSC (http://www.cpsc.gov/) deals with product safety but does have a focus on children. If it wasn't for this commission the toy industry would be in far worse shape with respect to safety than it already is. Mattel isn't the only company using cheap Chinese labor with little to no QA to keep their profit margins up. They, too, have a team of actuarial dorks showing them how their bottom line is dramatically improved using this model and risking the occasional big hit (http://www.cpsc.gov/cpscpub/prerel/prhtml07/07257 .html.) The USCPSC keeps them in check to ensure even cost-prohibitive measures are taken when it comes to protecting consumers. Then again, we are talking about injury, death and mitigating a $700 billion/year loss in the US attributed to defective products so I do recongnize it's an extreme example. However, it illustrates that even when the stakes are high companies still only care about the bottom line so don't expect software companies to be any better.

The NIST put together a report in 2002 outlining the cost of software errors to the US economy and recommending some next steps (http://www.nist.gov/public_affairs/releases/n02-1 0.htm.) They estimated a third could be elminated through improved QA. Companies compared the cost of improving QA to the anticipated reduction of product-defect related expenditures and when the numbers weren't there they passed.

Granted, a commission would only be a start and apply solely to US companies. However, you can bet that consumers will remain at least as ignorant about their software as they are about the chemical composition of the toys their kids are chewing on. You can also bet that software companies will remain at least as irresponsible as their toy industry counterparts. Seems to me a third-party is the only way however it has to be legitimate, centralized, credible and well communicated. I think the MoAB, MoKB and other LMH projects showed how these principles could work even if a number of fixes came from the community and not the companies themselves.

Until then I say responsible disclosure is the way to go with full disclosure after 30 days if it's not fixed or at least officially communicated to the public by the developers. If you drive over a failing bridge as part of your commute would you want the city to withold this information for fear terrorists will exploit it? Sure, you say "close it" but that's like saying a company should "recall the software" until it's fixed. You say "don't use the bridge" but that's like saying a company should stop using the software. Sometimes these are options... sometimes they're not... but if you're not for disclosure it's like saying the city should keep quiet until they're ready to fix it.

...while some may argue the merits of tebi versus tera...

The NIST FAQ on this addresses a number of these points directly: http://wtc.nist.gov/pubs/factsheets/faqs_8_2006.ht m

Well, hypothetically, IPv6 netblocks should become cheaper than their scarce IPv4 counterparts. Coupled with vastly simplified client requirements (such as not having to figure out how to connect two machines that are behind NATs), an IPv6 network could be quite a bit cheaper than an IPv4-only setup.

Remember what happened when Apple released the Airport Express with support for non-NAT'd IPv6? http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1338

So don't give me that crap about IPv6 meaning there will be a true end-to-end network. It's a nice dream, but it's not gonna happen.

For more security, have each app sign the stuff and THEN have each server encrypt the data according to their key.

You may also be able to use something from NIST's list of authenticated encryption modes to add extra security.

In a case like this, you might even want to get cryptographic hashes of the complete disk, say using Whirlpool and SHA-256, and place those on the next disk. As this becomes part of the content of the next disk, it alters that disk's hashes and is reflected on the disk after, and so on. So to change one disk requires changing ALL subsequent disks - an operation that rapidly becomes more expensive than it is worth.

Using these words, search engine style indices and techniques can be used to make searching -- by supplying an example image area which can have its words computed -- quite fast.

The key bottle neck here is the clustering stage: reducing the original input of typically hundreds of features per frame -- multiplied by 25 frames per second by minutes, or hours, of video -- to a much smaller set of clusters. It looks like the work in the linked article is using a modified clustering algorithm which does not require all of the data to be in memory at once.

The TRECVID project is a challenge style exercise where groups compete to provide the best search results for a given set of queries where the search material is hours of video.

Given that the claimed vulnerability is in mDNSResponder, whose source is available under the Apache-2 license, and that we have a hint of what the vulnerability is ("proof-of-concept worm was able to reliably deliver root and was based on a variation of mDNSResponder vulnerabilities that Apple had previously patched" - the only one that I could think of was CVE-2007-2386) someone far smarter than I could find and patch the vulnerability before InfoSec Sellout's work is complete. Isn't F(and/or)OSS great?

Um, OS X apps don't use the /tmp directory in the way most unix machines do. It's manly there as a compatibility thing for BSD apps...

My Mac has been up for 21 days, used every day for a variety of things (none of them illegal, but hey...) and there is precisely one "file" in /tmp, the X11 socket under my user-id directory:

[mac:~] simon% ls -laR /tmp/
total 0
drwxrwxrwt 4 root wheel 136 Jul 14 03:24 .
drwxr-xr-x 6 root wheel 204 Jun 22 17:40 ..
drwxrwxrwt 3 simon wheel 102 Jun 22 20:27 .X11-unix
drwxr-xr-x 2 simon wheel 68 Jul 12 18:57 501 /tmp//.X11-unix:
total 0
drwxrwxrwt 3 simon wheel 102 Jun 22 20:27 .
drwxrwxrwt 4 root wheel 136 Jul 14 03:24 ..
srwxrwxrwx 1 simon wheel 0 Jun 22 20:27 X0 /tmp//501:
total 0
drwxr-xr-x 2 simon wheel 68 Jul 12 18:57 .
drwxrwxrwt 4 root wheel 136 Jul 14 03:24 ..
[mac:~] simon% uptime
10:09 up 21 days, 16:48, 1 user, load averages: 0.20 0.08 0.02

[the extra slashes are there because /tmp is a link to /private/tmp, and you only get the contents when you append the /] ... and I have darwinports installed, use X rather than Terminal, use X editors etc. I'm far more unix-like than your average Mac user...

Oh yeah, and "all" you have to do is brute-force the DMG encryption ? *ALL* !!!? The NIST seem to think it would take 149 thousand billion years to crack the key, *if* you used specialised hardware...

Simon

The latest NIST work [...] confirms the institute's 1998 results using the same method while reducing the measurement uncertainty by about 40 percent, thanks mainly to improvements in the hardware used in the experiments.

The latest NIST work [...] confirms the institute's 1998 results using the same method while reducing the measurement uncertainty by about 40 percent, thanks mainly to improvements in the hardware used in the experiments.

The latest NIST work [...] confirms the institute's 1998 results using the same method while reducing the measurement uncertainty by about 40 percent, thanks mainly to improvements in the hardware used in the experiments.

More specifically, most counties have a County Auditor whose job it is to inspect that the pumps are properly calibrated, and it is reasonable to point your Auditor to an NIST report. Generally, there are stickers on the pump with information on how to contact the County Auditor. A friend of mine got billed for 16 gallons pumped into his 15 gallon tank a couple months ago and raised hell about it. I imagine this type of manipulation is more common than people notice.

Yeah, it's stored in pressurized, insulated tanks underground, which will buffer the gas from temperature fluctuations. For this reason, I think that the lawsuits won't get too far.

But, the recent Congressional testimony on this topic and the multiple lawsuits in many states (some of which are class action), makes me wonder if there's something more to the story.