Slashdot Mirror

A Kelvin is the unit of measurement, as well as the scale. q.v.

The whole purpose of OpenBSD is to be the most secure OS on the planet.

Network setup can also be a difference that is difficult to emulate in development/test setups. You have to emulate network latency, bandwidth, packet drop etc. NIST Net looks good, but it is a bit heavyweight for everyday use. I usually stick to suspending servers/clients with kill -STOP in order to test latencies, packet drop, and timeouts. In one case where latencies really mattered, I ended up being granted access to development servers on 2 different cities and also using my home computer as a remote server.

Another area which can be difficult to emulate is the data size. One thing just generating enough data to match production environments, say 3 million records, but another is generate the data in such a way that the database becomes fragmented in the same way it does in production environments. No real way emulate this properly, except possibly mishandling the database setup to the horror of your DBA :-)

Related to the data size is the difference in data, that being the variation in usernames, the fraction of invalid passwords, fraction of unused accounts, usage patterns, etc. You have to know your customer's environment. Your own customer support people are your friend here, as you can rarely get a complete data dump and traffic logs for the whole week - it is usually sensitive data. The most productive way to handle this is getting a very good grasp of the production environment and the usage patterns, and then spending the time it takes develop a test tool that emulates it closely.

Not too sure if the private sector has a standard, but it looks like the government (US) has one in place.

NIST SP 500-245

No, no, no, a Day is defined outside the International system of units, but is accepted within it as the defined quantity - 86,400 s.

Outside of scientific usage a day may have any number of definitions - rotational period of the earth, sunrise to sunset, etc.

However within scientific usage SI units (or a system compatible with SI) are generally used and a Day will mean exactly 86,400 s unless that definition is modified by the standards committee (which might be done if it gets sufficently different from an astronomical day).

Otherwise you would get annoying things when one person is refering to one measure of a day and someone else is refering to another and neither knows they are using different quantities.

Note a year is not an accepted outside unit to the SI system so feel free to define it however you wish, but please notate what definition or time system you are using in accepted SI units (although defined time systems will generally have these definitions available).

If you want to use UTC year the leap second is added to the year under UTC, or Coordinated Universal Time to make it agree with astronomical time. Other systems of time.

It's a term used in computational theory: Undecidable Problem

Also, I neglected to mention in my previous post...

One factor behind MS AntiSpyware's successful may be the use of quadratic probing in a secondary clustering to traverse file patterns, which are stored in an acylic graph.

Fleischer and Trippen elaborate further on this technique in a Java implementation, which of course Microsoft did not employ. The rationale, however, is the same.

2K = 2000. 2Ki = 2048.
National Institute of Standards and Technology

Flamebait aside, this has a good chance at increasing security, if done right. NIST is the right agency to handle this. It's not intended to be a centralized national ID, but a standard way of defining what IDs look and act like. Basically, a guard doesn't have to remember all the different agency and vendor ID cards no matter what door he gets transferred to.

Since every dorm has a kid that "can make it look real" verifying that ID is the key. Here's where the folks at NIST and the rest of the Feds really need to earn their pay. If you can't verify who issued the ID and how, it doesn't have much security. The Smart Card Alliance sponsored a good white paper on the "Chain of Trust" concept, http://www.smartcardalliance.org/alliance_activiti es/secure_id_systems_report.cfm These IDs can't be issued by one entity so unless the effort includes a easy, fast and secure method to verify both the identity and how it was issued, they are just setting up a beauty contest between the forgers.

If you're using OS X you can always use FileVault to encrypt your stuff with AES-128.

Or if you're paranoid just use Secure Empty Trash or format your disc using Disk Utility and have it write random data over the entire disk 8 times.

In fact the odds are close to 60% against.

Consider a set of size n (with n fairly large) and a random function f from that set back to itself. How many pairs (x,y) are there with f(x)=y and f(y)=x?

Well the number of pairs in the set is n*(n-1)/2 which is approximately n^2/2. Each pair has odds 1/n^2 of satisfying the condition. It turns out that pairs are not perfectly independent in satisfying/not satisfying (if (x,y) satisfies the condition then (x,z) cannot for any other z), but in a detailed analysis it is close enough to independent for what I'm going to say next to still be true.

The situation that we have here is that we are observing a large number of unlikely possible events, with a ratio between the number and the probability indicating that we expect to see a fixed amount on average (in our case 0.5 since the number of pairs is n^2/2 and the probability of a given pair satisfying our condition is 1/n^2). How many do we deserve? Assuming that the number is large, probability says that the distribution that we see is well-approximated by the Poisson Distribution, which says that the odds of seeing k occurances is exp(-lambda)*lambda^k/k! with lambda being the expected number of occurances.

Therefore the odds of our seeing 0 occurances are exp(-0.5)*0.5^0/0! = 0.60653065971263... - hence my claim that they are 60% against.

I would recommend you look at simple facets of cyber-security. While being well versed about http://nist.gov/ NIST and http://www.netip.com/links/nsa_guides.htm NSA and related guidance is helpful when speaking about cyber-security... you may want to consider more common security problems for your internship.

For example, many companies have identity management problems - particularly in industries with largescale mergers. Just documenting the variety of identities each employee has on different systems and blueprinting recommendations for consolidation can be a considerable task. Even on a small scale - lashing an identity scheme together for operators in a data center - this can be worthwhile and involved work that may get into topics like logging, auditing, provisioning, policy, identity consolidation, integration...

Likewise, most companies have security policy problems - either they implemented overly restrictive policies and have rapidly bypassed them (using local admin accounts or promoting people to domain admin levels of access), or they implemented piecemeal policies project by project resulting in no consistency and no centralized manner to audit and manage the policies in place.

You may also want to consider application integration security. E.g. web applications that authenticate locally but then redirect the internal user to an external site. The token handling and identity exposure of both the company and the user to the third party site (an outsourced customer service application for instance) is handled differently with each implementation - and consolidation would provide many benefits for businesses varying from retail to financial.

While doing core philosophical cyber-security work may be out of your reach due to the limit of your current credentials - documenting and/or implementing simpler aspects of cyber-security may be an avenue leading to greater opportunities.

...As for industries - well, I would strongly suggest banking, insurance, securities, and healthcare...

You're arguing vocabulary. "Hard" is usually short for "NP-hard".

Might look around at NIST.

A few years ago I saw a nice presentation from one of the NIST people about getting the best Java performance for scientific computational tasks.

I'm currently building a variety of petroleum engineering tools in Java. Here are the libraries I've found most useful:

JFreeChart - for all your plotting needs. Robust, quick, and fairly bug free. Not perfect, but hackable.

iText - a free Java PDF library. My preferred method for creating reports, especially since a lot of my output needs to be e-mailed or submitted to the government, not printed out.

JAMA - a Java Matrix package. The fact that this library has a working singular value decomposition has saved me bunches of time programming a boring and tricky algorithm. I guess it has other stuff, too.

Actually if you haven't read it yet, I would highly recommend you read the FIPSPUB112 since it is a federal policy guideline (and no it doesn't advocate using "password" or a 4 digit pin as your secret...)
The point is that you need to have the buy in from the top - which is what this policy describes. It sounds as though you were made a scapegoat (and I do sympathise) by someone who didn't know or do their job properly.

At least by having complex passwords that expire and must change, (Notice I did not say random charachters I preffer to have pass phrases, and instead of spaces, I reccomend special characters for example insecure-passwords&suck1) clean desk policy, security policies, and security trainning, for all my l-users my arse is now protected. Now someone has to try and bruteforce a password which would take an extremely long time, find a security exploit, or (IMHO the easiest way)social engineer the user.

While I do understand why you have this attitude, I reiterate that this is not actually improving your security - it's improving your cya (cover your a**).
I agree that social engineering is the easiest way to get the password, and ironically the 'draconian' approach to password management you advocate makes it easier to exploit this by fostering a culture in which people expect problems with their passwords. So in a sense you are making what most serious attackers would choose as the most effective 'hack' even more likely to succeed - ironic no?

I think I should also make myself a bit clearer, I'm not saying we need simple passwords that any cracker can break (which is obviously insecure), but I am saying that, for example, forcing people to change their passwords too regularly can cause problems (and it does depend on your users!). Most IT admin staff can happily cope with changing their passwords every month (and even then I expect many just increment the end of their password... anyway..), most non IT literate people can't cope. I'm not sure why, but passwords are scary things - on par with usernames I might add - which make the magic box allow them to do their work. They don't understand, or care, about why it's necessary for it to be hard to guess - only that it's a pain in the a**.
Educating the users (as opposed to only training them) is the only way of defeating this and one of the hardest problems to solve in computer security (IMHO). Educating bosses and management comes a close second...

Having IDs that are hard to counterfeit and hard to be used by other unauthorized persons is the idea of having IDs. So, all bullet points about the goals of this PIV in the official project narrative (MS-Word doc) are actually wanted.

However, the danger to exploit such PIVs as big brother equipement is given. Especially scaring is that the PIV shall hold fingerprints; this is scaring because those fingerprints will be registered centrally in a database. The effects are that even if your fingerprints show up somewhere remotely to a crime (e.g. same place but completely different time -- and they stick), you are will become a suspect or, at least, a potential witness. And possibly you will then be on the observation list without knowing it even remotely. And all this has nothing to do with a federal agency, in which you might work (or have worked several years ago, for that matter).

Fingerprints are only one example. So, the problem is the data -- and where else (than on the PIV) it gets stored, and how it can be accessed.

Reading the briefing I thought they might understand security, as the writeup mentions using a PIN along with the card, however it then concludes:

"Inclusion of biometric data: Biometric mechanism equivalent to a PIN from a security architecture point of view.
User can't give away, lose, or forget his/her biometric"

true, I would not give away a finger, but it is a lot easier to cut one off a high level exec than get the PIN out of them. On the bright side, the writeup acknowledged that the "features" of biometric is open to debate" and that

"Some experts feel a card + PIN provides the same assurance level as a card + biometric"

Opening the source of government written software is the right thing to do: taxpayer dollars spent, so taxpayers should get the software. On my short list, government software that is well-known/useful to me:

1. PubMed's e-utils
2. NIST software, which includes OCR, and handprint recognition software, and fingerprint imaging software.

I'm guessing you won't even want to KNOW about Yottabytes and Zeptometers. It's true, Dr Seuss has come back from the grave and taken over the ISO.

It was a spin-off from the Text REtrieval Convference The driving force of text retrieval.
TrecVID has a retrieval task, ie, "find shots of people walking up stairs", "find shots of Bill Clinton with an american flag in the background" And a semantic concept-detection task, ie, train on a test set, and try to detect sport videos, bicycles, buildings.

Video retrieval is still in its infancy. So, processing the text from the speech recognizer still provides the most information.

btw.. high correleation between image and text is a hard issue. Especially since computer vision is a very hard problem.

But! check the paper of the (um, ok, it's also my) University of Amsterdam, who "won" (not a compitition ;) this year's TrecVID benchmark, and learn about the Semantic Value Chain

note that Google hasn't participated in any of the TRECVID benchmarks. IBM seems to be the only big (well performing) commercial participant.

It was a spin-off from the Text REtrieval Convference The driving force of text retrieval.
TrecVID has a retrieval task, ie, "find shots of people walking up stairs", "find shots of Bill Clinton with an american flag in the background" And a semantic concept-detection task, ie, train on a test set, and try to detect sport videos, bicycles, buildings.

Video retrieval is still in its infancy. So, processing the text from the speech recognizer still provides the most information.

btw.. high correleation between image and text is a hard issue. Especially since computer vision is a very hard problem.

But! check the paper of the (um, ok, it's also my) University of Amsterdam, who "won" (not a compitition ;) this year's TrecVID benchmark, and learn about the Semantic Value Chain

note that Google hasn't participated in any of the TRECVID benchmarks. IBM seems to be the only big (well performing) commercial participant.

Since at least the 1970s, the US system has been defined off of the metric system. A foot is exactly 0.3048 meters. Everyone wins, as normal people keep the values they are used to (to at least an accuracy they would never care about), and scientists get the exact values that they need.

Suppose you wanted something that didn't expand or contract in certain temperature ranges

No supposition required. A physical metal rod was the official definition of the meter for a long time. Measurement stability requires such properties. And such rods are still used today in less critical areas.

Back on the original topic, any unusual property of materials is bound to find an application.

Erm, TCSEC (Orange Book) applies to stand-alone computers only. Once it's connected to a network, the rating no longer applies. The Red book covers networking. Both have been superceeded by the Common Critera, which can address a computer in a networked environment.

What if you were to do all the above, and then do a line-by-line full coding audit with formal validation? IBM has something like 10,000 Linux coders. There are 50,000,000 lines of code. Assuming you could do the audit at no more than 10 lines a day, it would take 100 days to audit the kernel to this degree. For a real bare-bones box, it would probably take about the same to do the user-space stuff.

Unfortunately, IBM is not a certified evaluation lab (CCTL), so the 10,000 Linux folks would not be able to conduct such a source code audit. The main reason that such reviews have not been done is the incredible cost of the undertaking. For commercial products like Solaris, there is a vendor with a stake who will pay for it. For Linux, no one had stepped up to do so.

Not a bad idea, though.

Well, in a way, you're absolutely right. The very first thing you have to realize before you even do a preliminary security screening/threat assement is that security is always a trade-off. That's the major point that most managers fail to understand.

Basically, there are three elements that you need to balance: security, usability and costs (there a re also lot of other relevant factors like existing infrastructre, resistance to change, scalability, etc. that make real security work, ie. more breaking out the pen test kit and print a report, so damn expensive).

There is no such thing as a 100% secure system. That's the common wisdom and that's true. But you can design a 98% secure system. The only problem is that this system will require a huge overhead and be so cumbersome that your employees will spend most of their time doing anything but actual work. That way they'll either avoid it and use something else (ie. something less secure and more usuable), if given the choice. Or they'll be largely unproductive, which in turn means you'll have to spend a lot of money to even keep things running. Which of course means you'll not be able to compete (that's one of the reasons a lot of secure systems are designed for government use only because they government doesn't really have to compete or be efficient).

Multics implemented usuable security exceptionally well. You could get the job done in a timely but relatively secure manner. For some more information about user centered security check out this paper or "Multics Security Evaluation: Vulnerability Analysis" by Karger & Schell (1974). The latter is available online too.

It's really a shame there's no "Open Multics". I wouldn't really run it in a secure production envionment but I'd sure like to have my own Multics machine.

I apologize if this is consider trolling, but I submitted this story a couple minutes ago and since it's relevant to this story I'll post it in here (since it probably won't get approved if this one is already up. If it does make it up just mod it offtopic):

Technical director Dr. Avi Rubin of the John Hopkins University Information Security Institute (ISI) has made a presentation regarding Diebold's voting machine source code (pdf) to the National Institute of Standards and Technology (NIST has been playing a key role in the improvement of voting systems since 2002.) Turns out, amongst other major security problems, Diebold was using NIST's Data Encryption Standard (DES) to encrypt votes and audit logs. DES was developed in 1976 was proven breakable by a "brute force" system in 1998. NIST proposed revoking DES's certification last July and recommends AES or at least 3DES.

Read from page 13. There are some hilarious comments ... or they would be if this weren't a freaking voting machine!

I apologize if this is consider trolling, but I submitted this story a couple minutes ago and since it's relevant to this story I'll post it in here (since it probably won't get approved if this one is already up. If it does make it up just mod it offtopic):

Technical director Dr. Avi Rubin of the John Hopkins University Information Security Institute (ISI) has made a presentation regarding Diebold's voting machine source code (pdf) to the National Institute of Standards and Technology (NIST has been playing a key role in the improvement of voting systems since 2002.) Turns out, amongst other major security problems, Diebold was using NIST's Data Encryption Standard (DES) to encrypt votes and audit logs. DES was developed in 1976 was proven breakable by a "brute force" system in 1998. NIST proposed revoking DES's certification last July and recommends AES or at least 3DES.

Read from page 13. There are some hilarious comments ... or they would be if this weren't a freaking voting machine!

I apologize if this is consider trolling, but I submitted this story a couple minutes ago and since it's relevant to this story I'll post it in here (since it probably won't get approved if this one is already up. If it does make it up just mod it offtopic):

Technical director Dr. Avi Rubin of the John Hopkins University Information Security Institute (ISI) has made a presentation regarding Diebold's voting machine source code (pdf) to the National Institute of Standards and Technology (NIST has been playing a key role in the improvement of voting systems since 2002.) Turns out, amongst other major security problems, Diebold was using NIST's Data Encryption Standard (DES) to encrypt votes and audit logs. DES was developed in 1976 was proven breakable by a "brute force" system in 1998. NIST proposed revoking DES's certification last July and recommends AES or at least 3DES.

Read from page 13. There are some hilarious comments ... or they would be if this weren't a freaking voting machine!

The State of the Art and Practice in Digital Preservation and
Research Challenges in Digital Archiving and Long-term Preservation

The State of the Art and Practice in Digital Preservation and
Research Challenges in Digital Archiving and Long-term Preservation

The State of the Art and Practice in Digital Preservation and
Research Challenges in Digital Archiving and Long-term Preservation

Take your time to study SI units

And now go back to your proprietary GNU/Debina system. That is, if you can even find your way out of a paper bag when it comes to writing code. Oh wait, you can't even write a Hello, World. program.

--
HawkinsOS: kicking Smorgrav in the ass since 2004.

You should know that the metal alloy film that contains the phase change layer is less stable than the dye used in the -R/+R discs.

NIST did a study of CD and DVD backup methodologies and that statement is part of one of their final reports.

Here's the NIST starting point.

Here's the part about RW vs R longevity.

As you say you are a security novice, I would suggest you take a look at the Common Criteria for information security evaluation.
This is what most security evaluations are assessed against. Threat Analysis/Risk Assessmeny (TARA) consultants are in high demand and can earn a lot of $$ these days.

That is untrue. Any hash can be reversed in the sense that you can generate an input that will result in a specific output.

That is NOT reversing the hash: this should be painfully bloody obvious since the process you describe runs the same hash in the same manner.

Reversing a hash - meaning you start w/ the hash and work backwards to recreate the original data - is impossible. Bits are lost during the hash process, and there is no data in the hash that will allow those bits to be reconstructed. Read _Applied_Cryptography_ by Bruce Schneier, or at least read any of the many crypto/hash FAQs available on the web. NIST has some good papers available.

the standards the feds will use to crack your hard drive if you are ever investigated: from my trove of rejected articles:
2004.10.11: "the standard for getting evidence from a computer"
Most of us love, or have at least grown highly dependent upon our computer[s] and PDAs, some of us keep very personal stuff in our computer. So here is a sobering little page on how your government plans to interrogate your hard drive if you ever fall afoul of the law. NIST is asking for comments by November 1 on a draft proposal of ways and standards to prove that a disk imaging tool is accurately dredging up your dirty little secrets. NIST also has a brief article about how it is looking into ways to recover forensic data from PDAs. The most interesting link there pointed to a PDF describing some tools you may not be aware of. The DOJ and Homeland Security put NIST up to this task.
"....Counsel for the defense my now cross examine the FAT."

the standards the feds will use to crack your hard drive if you are ever investigated: from my trove of rejected articles:
2004.10.11: "the standard for getting evidence from a computer"
Most of us love, or have at least grown highly dependent upon our computer[s] and PDAs, some of us keep very personal stuff in our computer. So here is a sobering little page on how your government plans to interrogate your hard drive if you ever fall afoul of the law. NIST is asking for comments by November 1 on a draft proposal of ways and standards to prove that a disk imaging tool is accurately dredging up your dirty little secrets. NIST also has a brief article about how it is looking into ways to recover forensic data from PDAs. The most interesting link there pointed to a PDF describing some tools you may not be aware of. The DOJ and Homeland Security put NIST up to this task.
"....Counsel for the defense my now cross examine the FAT."

the standards the feds will use to crack your hard drive if you are ever investigated: from my trove of rejected articles:
2004.10.11: "the standard for getting evidence from a computer"
Most of us love, or have at least grown highly dependent upon our computer[s] and PDAs, some of us keep very personal stuff in our computer. So here is a sobering little page on how your government plans to interrogate your hard drive if you ever fall afoul of the law. NIST is asking for comments by November 1 on a draft proposal of ways and standards to prove that a disk imaging tool is accurately dredging up your dirty little secrets. NIST also has a brief article about how it is looking into ways to recover forensic data from PDAs. The most interesting link there pointed to a PDF describing some tools you may not be aware of. The DOJ and Homeland Security put NIST up to this task.
"....Counsel for the defense my now cross examine the FAT."

the standards the feds will use to crack your hard drive if you are ever investigated: from my trove of rejected articles:
2004.10.11: "the standard for getting evidence from a computer"
Most of us love, or have at least grown highly dependent upon our computer[s] and PDAs, some of us keep very personal stuff in our computer. So here is a sobering little page on how your government plans to interrogate your hard drive if you ever fall afoul of the law. NIST is asking for comments by November 1 on a draft proposal of ways and standards to prove that a disk imaging tool is accurately dredging up your dirty little secrets. NIST also has a brief article about how it is looking into ways to recover forensic data from PDAs. The most interesting link there pointed to a PDF describing some tools you may not be aware of. The DOJ and Homeland Security put NIST up to this task.
"....Counsel for the defense my now cross examine the FAT."

the standards the feds will use to crack your hard drive if you are ever investigated: from my trove of rejected articles:
2004.10.11: "the standard for getting evidence from a computer"
Most of us love, or have at least grown highly dependent upon our computer[s] and PDAs, some of us keep very personal stuff in our computer. So here is a sobering little page on how your government plans to interrogate your hard drive if you ever fall afoul of the law. NIST is asking for comments by November 1 on a draft proposal of ways and standards to prove that a disk imaging tool is accurately dredging up your dirty little secrets. NIST also has a brief article about how it is looking into ways to recover forensic data from PDAs. The most interesting link there pointed to a PDF describing some tools you may not be aware of. The DOJ and Homeland Security put NIST up to this task.
"....Counsel for the defense my now cross examine the FAT."

Is it possible that the surface of Titan is basically a hydrocarbon mix that is basically like slush or jelly? With the cold temperature and higher atmospheric pressure wouldn't that turn all the ethane and methane into something not unlike diesel fuel when its really cold?

I'm a chemist, and you're off-base.

The intermolecular forces between methane and ethane molecules are very small. Even at high pressure/low temperature they will have low density and viscosity.

Look it up (then choose 'fluid properties' and play around with the settings.)

For methane, in the range of 0-300 MPa of pressure (0-300 atmospheres) and 100 Kelvin (-280 F) for instance, the viscosity ranges about 150-200 uPa*s. Contrast that to water at room temperature and pressure, it's about 1000 uPa*s.

So.. no way it's jelly. It's not slushy. It's not even watery. It's light and whispy.

Played around with liquid nitrogen? It has a very low viscosity. Think something in that direction.

I prefer MiB (mebibyte) to denote 2**20 bytes. Its easier to spot the difference between MiB and MB.

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

If you look through the file it has references to java files, pascal files, C++ files, and perl files. I don't get it. I understand that in this document just the hashes are listed to source code - but does this also imply that the source code is being distributed?
On an additional note, I see references to jpg, gif,and bmp files. I must be interpreting this files incorrectly. Why else would source code of 4+ high-level languages and 3+ image formats be in the same project?

They are slightly involved - with HAVA and with the software library. interesting idea about the competition, though.

They are slightly involved - with HAVA and with the software library. interesting idea about the competition, though.

So, 2^64 = 1.84467e19 bytes = 1.84467e16 KB = 1.84467e13 MB = 1.84467e10 GB = 18.4467e09 GB = 18 billion GB

Oh. and you can go back to setting your clocks by hand. Atomic clocks use those frequencies too.

Instead, they use the WWVB signal at 60 kHz, which presumably would not be affected by BPL. This link gives more information specifically related to radio clocks.

Clocks do exist that use the 5, 15, 20 etc. mHz signals, but they're rare and expensive, and generally only used by hams, astronomers, etc. The stuff you buy at Frys, Radio Shack and Wal Mart, that's 60 kHz.

And yes, I'm a ham. AD5RH.

Oh. and you can go back to setting your clocks by hand. Atomic clocks use those frequencies too.

Instead, they use the WWVB signal at 60 kHz, which presumably would not be affected by BPL. This link gives more information specifically related to radio clocks.

Clocks do exist that use the 5, 15, 20 etc. mHz signals, but they're rare and expensive, and generally only used by hams, astronomers, etc. The stuff you buy at Frys, Radio Shack and Wal Mart, that's 60 kHz.

And yes, I'm a ham. AD5RH.

The second, and to my mind more interesting point, is that the cat is, to a certain extent, out of the bag. Especially if the basic research is being done all around the world, and made freely available. There's going to be a point in time between when house-sized (but usable) quantum computers are available to governments, and when they become ubiquitous (I can't wait to get a graphics card with quantum ray-tracing). During that time, governments will have perfect encryption and decryption, and you and I will not. Of course, I absolutely trust the (insert name of government here) and its benevolent intentions, but for you conspiracy freaks out there...

On the other hand, it kind of reminds me of a (fairly well-known?) short story about a machine that allows users to view the past - and about the government's reasons (legitimate, you discover in the end) for trying to keep it under wraps. (Does anyone remember the name of this story?) I know it's heresy to say on /., but I worry about what happens when perfect encryption becomes ubiquitous.