Slashdot Mirror

First of all, you can't flatly blame the scripting language for the deficiencies of the hosting environment.

• tables in Safari
• CSS in Firefox
• JPEGs in Opera
• gasp URLs in MSIE

Even lynx isn't safe .

I can only assume that you access Slashdot using nothing more than a telnet client and rendering the HTML with your mind, because those web browsers, well, like you said, they make surfing teh intarweb "like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link[...]. I don't like to play russian roulette."

First of all, you can't flatly blame the scripting language for the deficiencies of the hosting environment.

• tables in Safari
• CSS in Firefox
• JPEGs in Opera
• gasp URLs in MSIE

Even lynx isn't safe .

I can only assume that you access Slashdot using nothing more than a telnet client and rendering the HTML with your mind, because those web browsers, well, like you said, they make surfing teh intarweb "like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link[...]. I don't like to play russian roulette."

First of all, you can't flatly blame the scripting language for the deficiencies of the hosting environment.

• tables in Safari
• CSS in Firefox
• JPEGs in Opera
• gasp URLs in MSIE

Even lynx isn't safe .

I can only assume that you access Slashdot using nothing more than a telnet client and rendering the HTML with your mind, because those web browsers, well, like you said, they make surfing teh intarweb "like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link[...]. I don't like to play russian roulette."

First of all, you can't flatly blame the scripting language for the deficiencies of the hosting environment.

• tables in Safari
• CSS in Firefox
• JPEGs in Opera
• gasp URLs in MSIE

Even lynx isn't safe .

I can only assume that you access Slashdot using nothing more than a telnet client and rendering the HTML with your mind, because those web browsers, well, like you said, they make surfing teh intarweb "like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link[...]. I don't like to play russian roulette."

First of all, you can't flatly blame the scripting language for the deficiencies of the hosting environment.

• tables in Safari
• CSS in Firefox
• JPEGs in Opera
• gasp URLs in MSIE

Even lynx isn't safe .

I can only assume that you access Slashdot using nothing more than a telnet client and rendering the HTML with your mind, because those web browsers, well, like you said, they make surfing teh intarweb "like inviting a stranger from an L.A. street into your car or home. You never know what you're getting every time you click a link[...]. I don't like to play russian roulette."

• Keep the discs in the dark
• Low humidity
• Do not write on directly to the disc surface, write on the box
• Store them vertically
• Keep cool but above freezing

More details than CNN

"This report gives an overview of current forensic software, designed for acquisition, examination, and reporting of data discovered on cellular handheld devices, and an understanding of their capabilities and limitations."

http://csrc.nist.gov/publications/nistir/nistir-72 50.pdf

No doubt this is all false as it's a government body but why don't you read this and try to refute their claims: http://wtc.nist.gov/

I am not an engineer, nor am I a self-studied expert in the WTC clusterfuck. But it seems that someone else has already undertaken a critique of the NIST report: http://911research.wtc7.net/essays/nist/index.html .

No one's responded to my statements that it would've been nice to have had an analysis performed on the WTC steel. Maybe you can tell me why such an analysis was unnecessary.

I guess it just depends on who you'd rather believe: our loving, caring governmental overlords, or individuals who noticed discrepancies in the official fairy-tale, and have dedicated themselves to exposing massive tyranny & betrayal.

You also need to explain the collapse of WTC7. No planes, minor debris (it was some distance away). There were some fires and, hours later, *pop*, it liquified too. See www.wtc7.net.

Some fires? Would that "some" include the fire raging across several floors for several hours that was pretty much unattended as the resources were stretched so thin?

Remember that we're searching for truth here. No point in believing falsehoods

If you're searching for the truth why would you accept the claim that there were only "some" fires when there is plenty of documentary evidence to the contrary? Could it be because it doesn't fit in with your world view and you are unwilling to accept anything that isn't spoon fed to you by the Alex Joneses of this world, who make quite a good living out of regurgitating this shit.

No doubt this is all false as it's a government body but why don't you read this and try to refute their claims: http://wtc.nist.gov/

Another thing to note is that the file, enwiki8, isn't actually 100mb, it's 100,000,000 byte, ie 10^8 byte, not 100*2^20 byte. So not really 100mb. To me this is strange, I mean any real CS guy would have gone with binary, right? Only a real newbie would go with the exact decimal number that make very little sense in computer terms.

adding information [...] that I had solid 100% reliable information on, [...] deleted because [...] the information was only "hearsay". Well, months later, the information turned out 100% correct

Kilobyte has been 1024 bytes for over 50 years. It is a de facto standard.

TREC 2006 evaluations are now underway.

While it is reasonable to conjecture that spam has changed so as to defeat spam filtering techniques, or will change so as to defeat the PPM technique that did well at TREC, the historical evidence does not support this conjecture. In particular:

• The spam filters tested in 2004 give pretty well exactly the same performance on 2005 and 2006 data.
• New versions of the filters are a little bit better, but not by leaps and bounds, and also get about the same results over the last 2.5 years of data.
• There is no evidence that "Bayesian poisining" is a viable technique for defeating statistical spam filters in anything but a very artifical laboratory environment where the poisoner has access to the recipient's inbox

Andrej Bratko used PPM -- a well-known data compression technique to compress ham and spam separately. Well actually he didn't compress them but just build the statistical model necessary to compress them. Then he simply (tentatively) added the unknown message to each model and chose the one that compressed it best. The general technique of using compression has been mentioned here and elsewhere but Bratko used a much stronger compression scheme and was somewhat clever about it.

I later reproduced Bratko's results using DMC -- a compression schem that I invented 20 years ago -- and got some interesting results. We have a journal article in press describing it and also an evaluation paper at CEAS 2006.

Bratko A., Cormack G. V., Filipic B., Lynam T. R. and Zupan B., Spam Filtering Using Statistical Data Compression Models

That's a very limited look at what Google is doing... like their machine translation group scored first at NIST 2005 Machine Translation Evaluation Official Results.

The MT-05 evaluation consisted of two tasks. Each task required performing translation from a given source language into the target language. The source languages were Arabic and Chinese, and the target language was English.

And this is probably just a little fraction of their research. Same would probably go for Microsoft Research...

guys, There's a lot of conspiracy mongering and mininformation being spread around about Galileo and the GPS systems and how they work. Here's three links that should help address this: Here's the link to NIST's time and freq. group. http://tf.nist.gov/timefreq/index.html Here's the link to the United States Naval Observatory site, which oversee's the GPS system (with airspace commant). http://www.usno.navy.mil/ And here's the link to the link farm of the ESA, or rather to the EU's overall scientific administrative body. http://www.edpsciences.org/index.cfm?niv1=useful_l inks For specific information about the Galileo project, search "ESA" "Galileo" and Technical specifications... I posted more specific links on the difference between the Galileo and US GPS systems elsewhere on slashdot, in particular regarding the encryption schemes and hard science related to each systems operations. Galileo relies on the L1 carrier freq. used by the US GPS system, but this carrier freq. is "public", and "degraded" by definition (the C/A, or Coarse Acquisiton, signal). This is NOT proprietary to the EU's Galileo system, and it's dishonest for the EU to sell it as such commercially. The dual and multi-channel navcom services that the EU claims it wants to commercially exploit are not designed independently of the L1 carrier signal that the US system offers to everyone (conditionally). Please, just check the sites above. Thanks, Grouchy

No, the CMVP does not provide the information regarding the status or reason on the website that lists all the approved modules. It does however inform the certification lab that performs the testing on the module of the problem, and then the lab informs the OpenSSL folks. Then the vendor and lab work together to fix whatever it is that brought up the problem.
I don't know what the specific problem is with their module validation, but it's probably more of a paperwork issue than a technical problem. There are testing requirements that are described in the publically available Derived Test Requirements at http://csrc.nist.gov/cryptval/ as well as more information than you'll ever want to know about the FIPS 140-2 cert.

Each crypto module has a publically available Security Policy that describes how the module works in regards to each section of the FIPS 140-2 standard. Skim through http://csrc.nist.gov/cryptval/140-1/140sp/140sp642 .pdf to read the Security Policy for OpenSSL. It could be that information in that security policy doesn't jive with how the module actually works, or how CMVP thinks that it works. That's enough of a discrepency that CMVP would start this whole hub-bub.

So hopefully the OpenSSL people will be able to provide whatever other information that they have to and they'll be revalidated and all the noise will die down. Could the competition have gone through the source code and looked for any possible reason to make problems for the OSS institute? Absolutely. But that's not the guhb'ment.

But hey, it's a lot more fun to put on the tinfoil hats and speak of dark conspiracies and governmental corruption. :)

No, the CMVP does not provide the information regarding the status or reason on the website that lists all the approved modules. It does however inform the certification lab that performs the testing on the module of the problem, and then the lab informs the OpenSSL folks. Then the vendor and lab work together to fix whatever it is that brought up the problem.
I don't know what the specific problem is with their module validation, but it's probably more of a paperwork issue than a technical problem. There are testing requirements that are described in the publically available Derived Test Requirements at http://csrc.nist.gov/cryptval/ as well as more information than you'll ever want to know about the FIPS 140-2 cert.

Each crypto module has a publically available Security Policy that describes how the module works in regards to each section of the FIPS 140-2 standard. Skim through http://csrc.nist.gov/cryptval/140-1/140sp/140sp642 .pdf to read the Security Policy for OpenSSL. It could be that information in that security policy doesn't jive with how the module actually works, or how CMVP thinks that it works. That's enough of a discrepency that CMVP would start this whole hub-bub.

So hopefully the OpenSSL people will be able to provide whatever other information that they have to and they'll be revalidated and all the noise will die down. Could the competition have gone through the source code and looked for any possible reason to make problems for the OSS institute? Absolutely. But that's not the guhb'ment.

But hey, it's a lot more fun to put on the tinfoil hats and speak of dark conspiracies and governmental corruption. :)

3:00 pm -- Tuesday, July 18, 2006

http://oss-institute.org/index.php?option=content& task=view&id=166&Itemid=

OpenSSL Module Certification Number 642: back on again...

To: OSSI
From: DOMUS IT Labs
RE: Status of OpenSSL Module (Certification #642)

I received a call this afternoon (Tuesday, July 18, 2006) from the NIST side from the CMVP. They have indicated that certificate #642 had incorrectly been marked as "revoked" during the web site update on Friday 14-Jul-2006. The CMVP has returned the certificate to its "not available" status and posted the following explanation regarding the terminology:

If a validation certificate is marked not available, the module is no longer available for procurement, but may still be retained and used to demonstrate compliance to FIPS 140-1 or FIPS 140-2.

If a validation certificate is marked as revoked, the module validation is no longer valid and may not be referenced to demonstrate compliance to FIPS 140-1 or FIPS 140-2.

Refer to http://csrc.nist.gov/cryptval/140-1/1401val.htm

Updated and resubmission continues on previous schedule.

----
it's never boring, that I can promise you.
stay tuned.
jmw

--
John M. Weathersby, Jr.
Executive Director
Open Source Software Institute
www.oss-institute.org
tel: 601.427.0152

Ad maiorem dei gloriam (AMDG)
Audentes fortuna juvat

Here's a brief article (and a picture) of the US's current standard. There's also a graph showing that the US standard tends to be replaced roughly every 5-10 years.

This experiment may also have another use: a more precise measurement of the gravitational constant (G). The 2002 CODATA recommended value of G has a relative standard uncertainty (RSU) of 1.5e-4. Compared to other constants such as Planck's constant (RSU of 1.7e-7) or the mass of an electron (RSU of 1.7e-7), this is a very high relative uncertainty. (Source of numbers: http://physics.nist.gov/cuu/Constants/)

This experiment could almost certainly determine G to a higher precision than possible with Earth-bound experiments. On Earth, there is gravitational "noise" generated by things such as active geology. In interplanetary space, there are less noise sources and they are more predictable. The experiment is almost like a super Cavendish torsion balance experiment in that the gravitational attraction between non-astronomical (ie. not "very large") objects is what is being measured.

The high relative uncertainty of the gravitational constant makes things such as some astronomical measurements hard. Conversion of SI units to natural units (Planck units) involves high uncertainties due to G appearing as a factor in nearly all of the conversions. At the very least, determining G to a higher precision would allow astrophysicists to reduce uncertainties in cosmic gravitational "experiments" (eg. tests of general relativity).

...the very first thing they do when performing a cyberforensics analysis on any computer disk they get, is to make a clone copy themselves while employing a hardware write-blocker connected to the source drive, and then performing their examinations upon the copy, not the original.

I hope it goes more efficiently than our switch to the metric system.

Picture Password: A visual login technique for mobile devices

Such a standard would be openly published, for anybody to inspect. It would, in fact, be an open standard. That's why we have standards.

The Amazing Google has an online translator from Arabic (it's different than Farsi, of course): http://www.google.com/translate_t. It was pretty amazing to direct it
to Al-Jazeera arabic site and see the headlines in English. Google claims to have
submitted it to NIST translation tests, and beating competition to a punch:
http://www.nist.gov/speech/tests/mt/mt05eval_offic ial_results_release_20050801_v3.html

So again... Fact someone REPORTED THE NAME OF VALERIE PLAME TO NOVAK. Let me type it in english. Someone reported the name Valerie Plame to NOVAK. Since you dared... 1, 2, 3 (Department of Energy, If left alone, Freeh warned, unbreakable encryption poses a threat to fighting crime through wiretapping., Finally... Case Study of HR 695: The Security and Freedom Through Encryption (SAFE) Act... This is where the government decided to place controls on encryption leaving the US because (guess what...) the government cannot break ciphers as easily as you might think. So when I use the term "Unbreakable Crypto", let me make it clear what I mean... Without the keys its impossible... With the keys... Good luck. It would 1) take too long 2) require more space then there currently is ON THE PLANET 3) by the time they cracked it, it would likely mean nothing.

A fun fact I like to wow people with is where the hottest and coldest places in the known universe are; New Jersey and Colorado.

Well at least they were. Princeton's Tokamak is no longer running and lot's of people have BECs now.

Why not. That is cheerfull compared to the reality.

An example of a recent Nobel laureate comes to mind. The poor chap had to be pumped with antibiotics, have an arm chopped all the way up to a bit of a shoulder and put in a coma until his organism produced at least some antibodies http://www.nist.gov/public_affairs/newsfromnist_Co rnell_mediaevent.htm.

The necrosis toxins produced by cocci are as scary as anything can get. Thanks god noone has managed to make a biological weapon from them just yet.

The jet fuel, which ignited the fires, was mostly consumed within the first few minutes after impact. The fires that burned for almost the entire time that the buildings remained standing were due mainly to burning building contents and, to a lesser extent, aircraft contents, not jet fuel.

Nor was that building's steel members stripped of their heat resistent coatings by a jetliner impact.

As shown before, the jet fuel was incapable of raising the temperature of the steel enough to weaken it, even uninsulated sections.

NOR where there a FULL 20 floors of building above the floors that were burning.

The Madrid skyscraper was not overdesigned to 600% of specifications (2000% for the core), and yet it still managed to support a massive construction crane perched on its roof.

Pools of fuel that have vaporized in an area not yet connected to the fire, that suddenly catch fire.
Aerosols of dust. (grain elevator explosions)
Air in sealed spaces being heated until the sealed spaces b

And here I thought I was going to be all that and correct you. I was taught in school the 1960 definition (Krypton-86 wavelength), not the 1983 definition (yours, the correct one), and have blissfully unaware of the change. Thanks for enlightening me this morning!

For reference, here is what NIST has to say about the matter.

From the intro:

Measurement and control systems are widely used in traditional test and measurement, industrial automation, communication systems, electrical power systems and many other areas of modern technology. The timing requirements placed on these measurement and control systems are becoming increasingly stringent. Traditionally these measurement and control systems have been implemented in a centralized architecture in which the timing constraints are met by careful attention to programming combined with communication technologies with deterministic latency. In recent years an increasing number of such systems utilize a more distributed architecture and increasingly networking technologies having less stringent timing specifications than the older more specialized technologies. In particular Ethernet communications are becoming more common in measurement and control applications. This has led to alternate means for enforcing the timing requirements in such systems. One such technique is the use of system components that contain real-time clocks, all of which are synchronized to each other within the system. This is very common in the general computing industry. For example essentially all general purpose computers contain a clock. These clocks are used to manage distributed file systems, backup and recovery systems and many other similar activities. These computers typically interact via LANs and the Internet. In this environment the most widely used technique for synchronizing the clocks is the Network Time Protocol, NTP, or the related SNTP.

Measurement and control systems have a number of requirements that must be met by a clock synchronization technology. In particular:

• Timing accuracies are often in the sub-microsecond range,
• These technologies must be available on a range of networking technologies including Ethernet but also other technologies found in industrial automation and similar industries,
• A minimum of administration is highly desirable,
• The technology must be capable of implementation on low cost and low-end devices,
• The required network and computing resources should be minimal.

In contrast to the general computing environment of intranets or the Internet, measurement and control systems typically are more spatially localized.

IEEE 1588 addresses the clock synchronization requirements of measurement and control systems.

From the intro:

Measurement and control systems are widely used in traditional test and measurement, industrial automation, communication systems, electrical power systems and many other areas of modern technology. The timing requirements placed on these measurement and control systems are becoming increasingly stringent. Traditionally these measurement and control systems have been implemented in a centralized architecture in which the timing constraints are met by careful attention to programming combined with communication technologies with deterministic latency. In recent years an increasing number of such systems utilize a more distributed architecture and increasingly networking technologies having less stringent timing specifications than the older more specialized technologies. In particular Ethernet communications are becoming more common in measurement and control applications. This has led to alternate means for enforcing the timing requirements in such systems. One such technique is the use of system components that contain real-time clocks, all of which are synchronized to each other within the system. This is very common in the general computing industry. For example essentially all general purpose computers contain a clock. These clocks are used to manage distributed file systems, backup and recovery systems and many other similar activities. These computers typically interact via LANs and the Internet. In this environment the most widely used technique for synchronizing the clocks is the Network Time Protocol, NTP, or the related SNTP.

Measurement and control systems have a number of requirements that must be met by a clock synchronization technology. In particular:

• Timing accuracies are often in the sub-microsecond range,
• These technologies must be available on a range of networking technologies including Ethernet but also other technologies found in industrial automation and similar industries,
• A minimum of administration is highly desirable,
• The technology must be capable of implementation on low cost and low-end devices,
• The required network and computing resources should be minimal.

In contrast to the general computing environment of intranets or the Internet, measurement and control systems typically are more spatially localized.

IEEE 1588 addresses the clock synchronization requirements of measurement and control systems.

Then why does NIST offer its own public domain client?

Uh, then why does NIST have this page with step by step instructions on how to setup clients to use nist time servers including time.nist.gov and detailed troubleshooting instuctions for same?

What do they say that? - Sound like they go out of their way (advice about firewalls, etc) to let taxpayers "Set Your Computer Clock Via the Internet".

http://tf.nist.gov/stations/wwvb.htm

Devices could easily be designed to carry data such as percent oxygen, number of heartbeats present, nearest locator beacon, etc. Very low data rate, but still good enough to get this sort of quick-and-dirty textual stuff through...

The TREC tests involved tests on 350,000 email messages. A 92,000 message public corpus from this effort is available for free download.

John Graham-Cumming (no relation to TREC) has created SpamOrHam -- a community-based effort to adjudicate the judgements in the TREC corpus. This'll let us test in a big way Yerazunis' contention that spam filters are better than humans.

Any filter writer can participtate in TREC 2006 by submitting a letter of intent now and a filter in due course.

There's also an upcoming scientific spam conference this summer - CEAS.

The TREC tests involved tests on 350,000 email messages. A 92,000 message public corpus from this effort is available for free download.

John Graham-Cumming (no relation to TREC) has created SpamOrHam -- a community-based effort to adjudicate the judgements in the TREC corpus. This'll let us test in a big way Yerazunis' contention that spam filters are better than humans.

Any filter writer can participtate in TREC 2006 by submitting a letter of intent now and a filter in due course.

There's also an upcoming scientific spam conference this summer - CEAS.

http://physics.nist.gov/PhysRefData/PerTable/index .html

http://en.wikipedia.org/wiki/List_of_elements_by_n umber

Elements with atomic number less than the Mercury target will be formed.
Some of these are very expensive.The waste products from SNS
could be more valuable than the neutrons produced.

http://en.wikipedia.org/wiki/Spallation_Neutron_So urce/
http://physics.nist.gov/PhysRefData/PerTable/index .html/
It is a large machine for making Gold and other precious
metals that are lower in atomic mass. Thanks go out to U.S.taxpayers who are largely unaware that more efficient methods/equipment to produce high intensity neutron beams are available.

I have experience in HTML, C, C++, and Java.

Things will get better over time.

This is the first uyear that OpenSSL is certifed by the government cryptographers as usable. This allows, for the first time, official government use of openssl as a solution
in many, many government contract situations, where IPSEC or hardware would formerly have been required.

http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m

Let us check:

First trying Universal:

        There is proton/electron mass ratio.

Let us try to look for the dime not under the street lamp but where it belongs: in the gutter (
Atomic and nuclear constants): here it is, among 151 constants in total.

C'mon. 151 fundamental constants only in atomic-nuclear section?

Let us check:

First trying Universal:

        There is proton/electron mass ratio.

Let us try to look for the dime not under the street lamp but where it belongs: in the gutter (
Atomic and nuclear constants): here it is, among 151 constants in total.

C'mon. 151 fundamental constants only in atomic-nuclear section?

As defined in the TCSEC and commonly implemented, DAC is an access control mechanism that permits system users to allow or disallow other users access to objects under their control:
A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).

A role based access control (RBAC) policy bases access control decisions on the functions a user is allowed to perform within an organization. The users cannot pass access permissions on to other users at their discretion. This is a fundamental difference between RBAC and DAC.

OpenSSL is FIPS 140-2 validated:

http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m

Look for # 642

This was (is) the first case of open source software being validated, as opposed to a specific product.

OpenSSL is FIPS 140-2 validated:

http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m

Look for # 642

This was (is) the first case of open source software being validated, as opposed to a specific product.

OpenSSL is FIPS 140-2 validated:

http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m

Look for # 642

This was (is) the first case of open source software being validated, as opposed to a specific product.

A couple examples: It allows 56-bit DES. These days, DES can be broken by modest levels of brute force, so it can only secure your data against people who have a modest level of interest. Or another: It guarantees key handling is done right, but once it's given you the key, do YOU handle it right?

Personally, I'd get an abstract of FIPS, and then do a bit of legwork to make sure that the open source solution of your choice is protecting against relevant attacks that FIPS deals with. Make sure it's using a popular, well reviewed algorithm. Make sure it manages keys sanely. Make sure they're committed to a good review process to make sure future changes don't screw things up.

A couple examples: It allows 56-bit DES. These days, DES can be broken by modest levels of brute force, so it can only secure your data against people who have a modest level of interest. Or another: It guarantees key handling is done right, but once it's given you the key, do YOU handle it right?

Personally, I'd get an abstract of FIPS, and then do a bit of legwork to make sure that the open source solution of your choice is protecting against relevant attacks that FIPS deals with. Make sure it's using a popular, well reviewed algorithm. Make sure it manages keys sanely. Make sure they're committed to a good review process to make sure future changes don't screw things up.

Regardless of the system, the security is largely based on how it is used.

You could use a "bullet proof" cryptosystem but if used incorrectly it wont help anything.

Now for the question on FIPS versus OSS I would say it doesn't really matter from my understading of your situation. I know a little about encryption schemes.

FIPS 140-2, the main security publication for cryptographic modules, requires tested and PUBLICLY known cryptosystems that include Triple DES and AES. There is no reason in my mind to use OSS over FIPS just because the source code is available for OSS. Any cryptosystem used by a FIPS approved system is open and very well known. And you can easily read the FIPS publications for yourself to see what is being used since they are all public (although a good understanding of the subject is suggested since they are not easy reads). Also, the use of any FIPS approved system should describe what they are using, lots of documentation is required for approval.

As long as good cryptosystems are being used (like those suggest by FIPS) you should be fine. It doesn't matter if its FIPS compilant or not... in theory if the cryptosystem is implemented (correct) than you should be safe. However, as I mentioned earlier you have to use them correctly.

Also, for FIPS 140-2, other factors are included for the cryptographic modules that may add extra things that you don't really need to worry about. Things like roles, self-tests, and hardware requirements like the use of "opaque tamper-evident encapsulating material." I don't believe you need these requirements.

The only reason that I can see to use FIPS over OSS is if you need to work with the government in some secure way (like storing or transmitting sensitive material). From a marketing stand point, it might be nice to say you are using FIPS approved system, but as long as you say something like "We are using a AES symmetric key cryptosystem for disk encryption," it should be fine enough. Anyone that knows what you are talking about will understand and realize it is secure regardless of being FIPS approved.