Losing Track of Nuclear Materials 160
As it so happens, I know a bit about accounting for nuclear materials at DOE facilities, since I've written a system to do just that (not the one in question, fortunately for me). There's a good basic description of the flawed inventory system available from a Russian site. It's a custom application built on Windows NT and SQL Server, and the application itself was almost certainly not written by Microsoft but by some consulting firm hired by the Department of Energy. (I don't know that it wasn't Microsoft who did the consulting, but it would surprise me.)
So rather than being a "risks of Microsoft software" story, this is a story in general about the risks of highly complex, closed-source code.
About ten minutes after Little Boy turned Hiroshima into an ex-city, the U.S. realized the importance of tracking the raw materials for nuclear weaponry. Enriched uranium and plutonium, primarily, but also many other materials that are fissionable or can be used in nuclear weapons. (Incidentally, you can possess uranium ore in its natural state without a Nuclear Regulatory Commission license - only if you try to enrich it do you run into problems. :)
Accounting of U.S. nuclear materials is handled through a system/organization called NMMSS, the Nuclear Materials Management and Safeguards System. This database was started in the Days of Yore, when men were men and computers were room-sized with lots of blinkenlights. This database was originally designed to accept 80-column punch-cards - lots and lots of punch-cards. Each punch-card could be part of an inventory received from some U.S. facility that handled nuclear materials, or part of a transaction indicating the transfer of nuclear materials from one facility to another, or any other data that needed to be entered into the database.
At the end of the day, the system would grind over the data entered, looking for problems. For instance, facility X says they sent 10 kilos of plutonium to facility Y, and facility Y says they received 9 kilos of plutonium from facility X - red flags go up, alarms ring, troops are dispatched.
The system has been modernized once or twice, and modified many, many times to take account of changing developments in nuclear science ("hey, this isotope can be used in making super-bombs - better track it too!"), changing regulations, and changing technology. But no one wants to screw it up, so modifications are always the minimum needed. So today, DOE facilities don't send punch-cards anymore - they can send their information via encrypted email or secure dial-up connections. But the data transmitted is still in 80-column formats, a legacy of the punch-cards. Each facility runs some sort of inventory system which tracks things at their facility, and submits various reports up the chain to NMMSS. It's all computerized - but there are massive legacies of the predecessor systems.
After the end of the Cold War and Soviet break-up, the U.S. DOE starting sweating about poor Russian control of nuclear materials. The U.S. has sent significant assistance to the former Soviet Union to aid them in accounting for and tracking materials that could be used in building nuclear weapons. The U.S. has also purchased a large amount of "excess" nuclear material from the former U.S.S.R., and the U.S. and Soviet inventory systems are at least partially merged now - at least some Soviet facilities submit inventory reports to NMMSS now, and so transactions of materials between U.S. and Russian facilities can be handled much the same way as transactions between two U.S. facilities. Naturally the U.S. donated their custom facility inventory software, which was probably developed at extraordinary expense, running on NT and SQL Server.... and now we're back to the original article.
At this point you know as much as I do. I don't know what flaw caused the loss in inventories that was described in the article, whether it was a flaw in SQL Server or the custom application written on top of it. I do know that any significant inventory loss would almost certainly be detected elsewhere in the chain -- NMMSS would note that the inventory was X kilograms one month, (X-Y) kilograms the next month, and wonder what happened, even if no one at the actual facility did. So my suggestion is to take the $1 billion estimate in the article with a grain of salt. Probably the flaw isn't that bad, probably it occurred in a repeatable manner and the data can be found or reconstructed (there are many checks and safeguards built-in to all of these systems to detect errors or attempted fraud). The most probable "attack" against the inventory system was a bad employee, attempting to divert nuclear material for financial gain. But the safeguards should suffice to detect systemic errors as well.
MUFs? (Score:1)
Re:Not too scary (Score:1)
Not really. Once you have the enriched uranium (for an ordinary fission device), all you really have to do is to merge it beyond critical mass in a short amount of time.
For instance, take two pieces of enriched uranium with a total mass over the critical limit, but each one below the limit. Then place them at separate ends in a steel cylinder 1 m apart. Attach some chemical explosive on both ends of the cylinder and weld the cylinder shut. Now, when you detonate the explosives (simultanously), the uranium pieces will crash into each other and instantly form a critical mass - Kaboooom...
Not exactly rocket science
Re:surprising? (Score:1)
Paper still runs the government/military. Everythign is checked and rechecked and entered into systems that probably don't talk to each other in any way. This story is being blown way out of proportion.
Government codes are "open source" (Score:1)
They may not be Free, and they might even cost you money, but no scientist would ever trust a closed source binary for important work.
-NuclearArchaologist posting as anonymous with broken cookies and without his password :(
Here's the largest nuke fuel thefts (Score:4)
http://www.arabmedia.com/jnucler.html
[snip]
The most notorious instance, fully uncovered by the American intelligence in 1967, involved the Israeli theft of several hundred pounds of enriched uranium from the U.S. Nuclear Material and Equipment Corporation (NUMEC) facility in Apollo, Pennsylvania with the alleged help of its American director, Zalman Shapiro.4 While the evidence was not sufficient to convict the principal involved, there was a "clear consensus" within the CIA that the nuclear materials in question had been diverted to Israel and used by the Israelis for nuclear weapons manufacture.5 Indeed, Shapiro was known to have maintained extraordinarily intimate relations with the Israeli government and its nuclear scientific community during his tenure at NUMEC. Other known instances of Israeli theft of nuclear materials include hit-and-run tear-gas attacks by the Israelis against uranium-laden trucks belonging to the government of France, their former nuclear benefactor.
British nuclear cargo was similarly hijacked by individuals suspected of working for Israeli intelligence. A fourth instance involves the temporary seizure of a ship registered to what was then West Germany, from which 200 tons of yellowcake (uranium used as nuclear fuel) subsequently disappeared, an instance the U.S. intelligence has also attributed to Israel.
[snip]
Correction (Score:5)
it was actually trackn~1.dll
Great. (Score:1)
--
Not so much closed-source as legacy code (Score:3)
Re:Nuclear Breeder Reactors and Bombs (Score:1)
#define X(x,y) x##y
Story submitters, please read what you submit! (Score:4)
Apparently, this has been going on for about 10 years.
From the actual story:
By [the Russians'] calculations, an enormous amount of Russia's nuclear material... would disappear from their accounting records if Russia were to use the flawed U.S. software program for 10 years.
Please, please, please read what you're writing about before you write about it!
Read the report (Score:2)
I'll reprogram it (Score:1)
And when I'm finished, I'll frag your brains out from that same machine!
Re:half-life (Score:2)
Right, but they use the hot isotope for a reason. If you use a slower-decaying isotope, you reduce the probability that the initiator will produce a neutron at the critical instant when it is needed.
You want the polonium to be spewing out alpha particles constantly, to maximize the probability that the system will produce that one critical neutron exactly when it is needed.
Re:half-life (Score:5)
However, inside each weapon is a small device called the initiator. The initiator is made of beryllium and polonium-210, and is inserted in the center of the plutonium sphere.
When the bomb is detonated, the plutonium sphere implodes, crushing together and mixing the beryllium and polonium. The polonium gives off alpha radiation, and beryllium emits neutrons when hit by alpha radiation. One reference says that the number of neutrons given off by the initiator is around five or six. All it takes is one neutron to start the fission chain reaction.
The initiator only has a few microseconds to emit the necessary neutrons. It's considered to be one of the most critical and difficult aspects of nuclear weapon design. A great deal of information has been published about nuclear weapon design, but information about initator design is never published.
Polonium has a half-life of only 138 days. So, even though the plutonium itself decays very slowly, it is the initators that must be regularly replaced.
Uh oh (Score:4)
Re:Not too scary (Score:2)
A plutonium bomb (implosion device) is a complex design. There are a lot of things that can go wrong.
A U-235 bomb (gun device) is considerably simpler, but inefficient in its use of fissionable material.
Someone who got their hands on a sizable quantity of highly enriched uranium could easily build a nuclear weapon.
Re:Not too scary (Score:2)
You are correct that an implosion device can use uranium or plutonium.
I'll have to check out Project Urchin.
Re:Risks of closed source software. (Score:2)
WE use a product called Novar for our traffic and billing here, and it's the worst written software on the planet. (Their 1.0 product was better than the 2.0) and every problem we have with the database can be linked back to the application and it's shoddy programming. (by my detective work, they wont admit it.)
I hate to support MS but in this case I highly doubt that MSSQL is causing any problems like this.
Re:Risks of closed source software. (Score:5)
I don't think that opening the code is automatically a bad thing, but in this case I don't think it would help too much. Open source code improves when people look at it, and people look at it when they use it and have problems with it. This was a custom system written for exactly one customer, and you can bet the DOE could have (and maybe did) get the source code if they wanted to. Making this system open source wouldn't have helped much since there really wouldn't be enough eyes looking at it to make the bugs shallow. In the worst case, the only people looking for flaws would be the people with something to gain from the flaws - black hats. You really only want something to be open source if you can be sure that there will be enough white hats contributing to balance out that risk, or if it's a program that has very minimal security implications, like gEdit or something like that.
That's assuming that the problem really was in the custom app and not in NT or MSSQL, but I assume any bugs where MSSQL quietly "disappears" certain information would be common knowledge by now...
Re:Is this really something to worry about? (Score:1)
Ah, the ActiveX method. Did that web page just nuke your hard disk? No problem, the code was signed. Your data is gone, but at least you know who to blame.
---
Apology (Score:3)
Thank you.
Re:Not so much closed-source as legacy code (Score:1)
Error: "There are who sorts of code."
Correction: "There are two sorts of code."
"Don't worry, it could happen to anyone. Have a nice day." --The GEICO Gecko
I used to work for a DOE sub-subcontractor (Score:1)
All of the DOE's software (at least, anything used by anybody with a normal security clearance) is written by a 3rd party -- which usually themselves subcontract. In fact, there are firms in the DC area with mulit-million dollar revenues that do nothing but "bottom feed" on DOE contracts -- that is, do less than 49% of the paid work (or whatever the margin is for that project).
Further, most of these are ENVIRONMENTAL companies, not IT shops, since they wouldn't know enough about, say, ground water remediation to make a front end database app anyway.
So am I surprised? Not really. Especially since we're dealing with a government agency.
Re:They need Gnuclear-Tracker (Score:1)
F.O.Dobbs
Re:how much the world has changed . . . (Score:2)
I remember when the US "invaded" Grenada. What a weird day (and day after) that was. Quite a view university folks were in fear of a nuclear exchange of some kind.
Oh, and my graduation was marred by a two hour commencement address by Herb Marcuse who told us how we had nothing to look forward too. There were no jobs because of Reagan. We would catch aids because of Reagan. We would have to wear gas masks because of Reagan's pollution. We would be arrested by Reagan's brownshirt thugs. Nuclear conflagration was inevitable. Gaagh!
"Microsoft software" (Score:2)
What they meant was, it's Microsoft software in spirit, if not in the flesh.
--
Re:They still make plutonium (Score:2)
i am fascinated.
Not a bug... (Score:5)
Yes is does. (Score:1)
Now if you mess up the triggers that control cascade updates/deletes and RI, then you get into the orphaned records situations.
Of course. (Score:5)
There's been a well known bug in TrackNuclearShit.DLL since Win 3.11, and MS has refused to patch it.
I think if you upgrade to IE 4.1 128 bit security, then disable javascript, but be sure to install MSN wallet software, then things work.
UNLESS, you're on SP 3 Win NT 4, at which point install the ATI drivers for the All in wonder card from a command line ONLY. Then remove the card with some BBQ tongs and put it in a shed. Do not look at the card for 3 weeks, then quickly put it back in wrapped in tinfoil. Turn the computer upside down. Leave it along for 8 minutes, then quickly apply mayonnaise to the front panel.
There, that should do it.
Re:half-life (Score:1)
Plutonium has a long half-life.
Nukes: A Lesson From Russia By Bruce G. Blair (Score:1)
By Bruce G. Blair
Although the United States spends nearly $1 billion every year to help
Russia protect its vast storehouse of nuclear weapons materials from
theft or sale on the black
market, few Americans know how this aid helps strengthen America's own
nuclear safeguards.
Russian experts at the Kurchatov Institute, the renowned nuclear
research center in Moscow, recently found what appears to be a critical
deficiency in the internal
U.S. system for keeping track of all bomb-grade nuclear materials held
by the Energy Department -- enough material for tens of thousands of
nuclear bombs.
Kurchatov scientists discovered a fatal flaw in the Microsoft software
donated to them by the Los Alamos National Laboratory. This same
software has been the
backbone of America's nuclear materials control system for years. The
Russians found that over time, as the computer program is used, some
files become invisible
and inaccessible to the nuclear accountants using the system, even
though the data still exist in netherworld of the database. Any insider
who understood the software
could exploit this flaw by tracking the "disappeared" files and then
physically diverting, for a profit, the materials themselves.
After investigating the problem for many months, the Russians came to
believe that it posed a grave danger and suspended further use of the
software in Russia's
accounting system. By their calculations, an enormous amount of Russia's
nuclear material -- the equivalent of many thousands of nuclear bombs --
would disappear
from their accounting records if Russia were to use the flawed U.S.
software program for 10 years.
Then, in early 2000, they did something they didn't have to do: They
warned the United States, believing that an analogous risk must exist in
the U.S. system.
Although neither Los Alamos nor the U.S. Department of Energy has
publicly acknowledged the possibility that innumerable files on American
nuclear materials might
have disappeared, the Russian warning caused shock waves at the highest
levels of the Energy Department.
Unlike the Russians, who did not throw away their manual records of
their nuclear stockpile -- the infamous shoe box and hand-receipt system
that U.S. assistance
was intended to supersede -- the United States has long since discarded
its old written records. To reconstruct a reliably accurate accounting
record, the Energy
Department may need to inspect all of America's nuclear materials -- a
huge task that could cost more than $1 billion and still might not
detect the diversion of some
material, should it have occurred.
The importance of the goodwill and trust that had grown up between
American and Russian nuclear experts over years of working together in
this area is clear. When
the Russian scientists first discovered the computer flaw, the initial
reaction in some high-level Moscow circles was to suspect an American
Trojan horse, a bug
planted deliberately to undermine Russian security. After complaints by
their Russian counterparts, scientists at Los Alamos suggested that the
Russian scientists
instead use a later version of the same program. Kurchatov then
discovered the upgraded program not only contained the same bug (though
much less virulent) but
also had a critical security flaw that would allow easy access to the
sensitive nuclear database by hackers or unauthorized personnel.
But trust overrode suspicion. The Russians concluded that the glitches
were innocent errors, not devious traps. Thus, they feared the U.S.
database, unbeknown to
Americans, was not only prone to lose track of nuclear materials but was
also accessible to unauthorized users. Russia reported both problems to
Los Alamos, which
Re:Not too scary (Score:1)
--
Re:Not so much closed-source as legacy code (Score:2)
"There are who sorts of code - code that is so complex that there are no obvious bugs and code that is so simple that there are obviously no bugs".
Wise words...
Re:half-life (Score:2)
Modern nuclear explosives use electronic neutron generators. They do not wear out.
do a search for mc4380
You might also want to check out the nuclear weapons databook by hansen & friends.
Accounting descrepancies (Score:1)
What was being missed (by the reporters, not the research organisation), was that this was entirely expected.
(a) Heavy metals weigh a lot, so a little missing sounds like a lot
(b) When you saw a preice of metal in half, thereis a small qunatitiy of metalic paticles, shavings if you like, that cannot be weighed and accounted for, caught in oil traps etc.
Over a period of years, this means that an establishment will receive more material than it sends out.
RG
Re:Here's the largest nuke fuel thefts (Score:2)
http://fas.org/nuke/hew/Israel/index.html
"Reports that Zalman Shapiro, the American owner of the nuclear fuel processing company NUMEC, supplied enriched uranium to Israel in the 1960s seems to have been authoritatively refuted by Hersh."
The cite apparently refers to:
AUTHOR: Hersh, Seymour M.
TITLE: The Samson option: Israel's nuclear arsenal and American foreign policy / Seymour M. Hersh. -- 1st ed.
ISBN/ISSN: 0394570065
IMPRINT: New York, Random House, c1991
PHYS DESC: 354 p., 24 cm.
The point of Drake's paper (which the parent post has [snip]ped) is really how the Arab states can approach disarmament, and not really a serious study of Israeli nuclear development, which she gets only from secondary sources.
The whole paper can be found at her web site [american.edu].
Re:I'll reprogram it (Score:1)
Re:Not too scary (Score:2)
Otherwise how do you explain Project Urchin?
Re:They need Gnuclear-Tracker (Score:1)
Re:how much the world has changed . . . (Score:1)
My commencement (last June) was by Bill Cosby. He didn't blame Reagan for anything.
"When I'm singing a ballad and a pair of underwear lands on my head, I hate that. It really kills the mood."
Instead of stealing it, enrich it yourself (Score:3)
http://www.findarticles.com/m1111/n1782_v297/21281 407/p1/article.jhtml [findarticles.com]
Just a fun article . . .
half-life (Score:5)
So does this mean that data about radioactive materials itself has a half-life? No wonder I can't remember my college physics classes! All my memories decayed!
I have zero tolerance for zero-tolerance policies.
Re:how much the world has changed . . . (Score:1)
My girlfriend went to a Catholic school, and in an attempt to not scare the children, they were told they were practicing fire drills instead of nuclear attack drills. So all these kids were being taught that in case of fire, crawl under your desk and hide...
US Nuclear Weapons Loss Accounting (Score:5)
That would explain it. (Score:1)
Userfriendly turns nasty ? (Score:1)
Suddenly I don't like the way the last week's userfriendly.org [userfriendly.org] is leading.
Re:Not too scary (Score:1)
Another one with a half-baked grasp of history 8-(
the plutonium bombs (Little Boy and Trinity) were implosion devices
I assume "Little Boy" was just a typo, and to nit-pick, "Trinity" was the name of a test of a device called "Gadget".
because they were initially afraid they couldn't scare up enough plutonium
Your logic escapes me. They were worried about Pu shortage, so chose implosion ?
There was no shortage of Pu, and there was no real concern over this past the very early days. Once a production reactor was on-line (i.e. not just the early Chicago pile), Pu was more readily available than HEU. After all, Pu extraction is relatively simple. Under war conditions, where operator safety goes out of the window, it's almost easy. There was continued concern over HEU production, and this led to the implosion designs being continued with
explain Project Urchin?
I can't. I've never heard of "Project Urchin". "Urchins" were developed in the Manhattan project, but not under a project of that name. Is Urchin something else ?
Why is an Urchin significant to a Pu shortage anyway ? You need an initiator as a neutron source, but they're not a specific component that's only required by one particular configuration. The Urchin concept isn't revolutionary (although making a workable one is hard). It's even too obvious to be patentable (although not by the USPTO's standards). India used them (called "Flower") in their early '70s tests [fas.org]. If you believe the kooks [visi.net] (I don't), even the German bomb design (sic) used a Po/Be urchin.
Re:Not too scary (Score:2)
Any nation [...] can build a breeder reactor to make weapons-grade uranium.
If you don't have the first clue [fas.org] what you're blathering about [bullatomsci.org], kindly shut the hell up.
Yes, Reagan was a great president (Score:1)
Count on an actor to deceive is all I have to say.
Re:Risks of closed source software. (Score:3)
Clue: Open Source does not mean that everyone has access to the source. GPL-style free software licenses mean that those who can get a binary can get the source for free, which in this case would've been a good idea. Then the facility in question could've found and fixed the bug long ago.
Or would you rather confidential government systems be running a closed-source solution like NT and not know who's getting what data from them?
(Well, there goes any chance of this getting up above -1 - criticizing Microsoft is a sure way to attract 'troll' and 'flamebait' ratings.)
-RickHunter
Sounds familiar (Score:1)
F-bacher
Re:huh? (Score:2)
F-bacher
Re:Is this really something to worry about? (Score:4)
I also fully agree that since no rogue nation has ever detonated a bomb in downtown Manhattan, it is obvious that it can never happen. History proves that it is completely impossible, so we should just stop sweating it.
So if somebody stole material that was recovered, it would be a one time deal.
Sure, I mean, why should we really care, since if they blew up Jerusalem once, they couldn't possibly do it twice. We'd track that software bug right down in that case. All those people killed in the blast and subsequent radiation posioning can rest easy in the knowledge that at least the same bug won't be exploited again. Probably.
Re:huh? (Score:1)
cut and paste? forget it
They did introduce backing it up later but it was already too late for my neighbour who spent Friday afternoon all Friday Night and into Saturday morning typing in the 200 ip addresses and Virtual Host Names his IIS was hosting.
You can't buy entertainemnt like that...
Oh SHIT! (Score:2)
Re:Not so much closed-source as legacy code (Score:1)
That your still using DOS. Arrgh run for the hills :-)
-----------------------------------------
Re:Uh oh (Score:1)
Peace,
Amit
ICQ 77863057
Re:Not a bug... (Score:2)
Dont Do That!!!!!
-= rei =-
Re:Not too scary (Score:2)
perl -e 'print "a nuclear bomb\n";'
Re:Why can't it be MS? App running under Windows? (Score:5)
It does when you're dealing with what is patently a piece of Safety-Critical software. I spent a little while working on railway signalling software, and the whole methodology is meant to eliminate this sort of vulerability.
Microsoft wrote a dodgy database server and a leaky OS. But they didn't make the decision to use those products as the basis for a piece of S-C software. They didn't write the software, design the SP's, build the data abstraction layers, create the failsafe routines.
What I find disturbing in particular is: where was the testing? Where was the useage simulation? How did a piece of software which turned out to have data integrity issues ever get a Safety Certificate?
For the Jubilee Line extension signalling, we didn't just limit development to ADA, there was a specified subset of permitted constructs, there were function point limits, a specified compiler, a specified runtime environment, there was rigorous analysis, code inspection, traceability, self-correcting feedback, three copies of everything which all had to match or the system stopped. There were no less than 3 teams of independent testers.
And even then it took a very long time to get the Safety Case signed off.
Microsoft shouldn't produce flaky tools, no question. But the very serious culpability here lies not with the creators of the shoddy toolset but with those who chose to implement a Safety-Critical application using these shoddy tools, and those who passed it for use.
Basic professional skill no. 1: know the right tools for the job in hand
TomV
how much the world has changed . . . (Score:5)
Now we're more concerned with the rogue state or terrorist nuclear weapon.
I wonder if someone even 10 years younger than I am can understand how much things have changed?
Is this really something to worry about? (Score:2)
Also, most nuclear materials can be tracked to their point of manufacture even after they've been assembled into a bomb and detonated. You find the core, you can analyze the left overs and know which plant, US or Russian or god knows who, manufactured the stuff. So if somebody stole material that was recovered, it would be a one time deal.
Finally, if theft and purchase of nuclear materials are so common, the plans so easy to attain, customs so easy to bypass, why hasn't some "rogue nation" detonated a bomb in downtown Cleveland? or Jerusalem? or Kennebunkport? Shipments have only been intercepted a few times, no terrorists have ever threatened to use nukes, and the only 2 countries that we (the US of Absolute Stupidity) have a major beef with, N. Korea and Iraq, that claim to be developing nukes haven't. What are we worrying about? Oh, and the greatest threat isn't theft, it's assembly. The response time on the guards at our main plant is fast enough to prevent escape, but not fast enough to stop someone from barricading themselves inside, dragging out some material and all the fixin's to a workshop and whipping up a Grade-A 100 megaton party popper. Who needs to escape? Turn the entire mid-west into a glass parking lot.
Re:how much the world has changed . . . (Score:2)
And some local paper -- probably the Daily News -- would dutifully do a report every May Day on the newest Soviet military equipment set to roll over Western Europe, with the little "One army man = 10,000 soldiers" and "one tank icon = 100 tanks" pictographs.
The same paper would, from time to time, in the Sunday supplement, publish a map of the NYC region with circles centered on the Empire State Building drawn for the different "death radii" of an airburst from a Soviet nuke.
And, as a teacher interacting with children of the 1990s, no, young people have no idea. Which is both frightening and, oddly, hopeful.
Re:how much the world has changed . . . (Score:2)
Their hair.
Re:Risks of closed source software. (Score:2)
--
Actually it was Superman, I believe (Score:2)
I'm confused (Score:2)
The editorial says: "Russia reported both problems to Los Alamos, which subsequently verified the defects, as did Microsoft."
So why was Microsoft involved in verifying the problems, if it has nothing to do with Microsoft software?
The software seems to be a custom app using MS Access 97 and Visual Basic running with Windows NT and Microsoft SQL Server. It may be a bug in the app itself, or a bug in the underlying software, or both. Nothing I saw really gives a clear indication.
Re:Not too scary (Score:2)
Getting the material is actually not as straightforward as you imply. Breeder reactors do not output weapons grade material. The stuff needs to be processed so that it contains the same fissionable isotope at a very high purity. Separating a substance which is chemically the same and differs only by weight is tricky. The weight difference is not that much (several neutrons in a nucleus with over 200 particles). It is very energy intensive and the machinery needed to do it needs to be very precise.
Also, as you state, making the bomb is not just two hemispheres of matter surrounded by a soccerball of explosives. Yet another case of the movies putting irrational fears into the public consciousness.
In conclusion, no part of making a nuclear weapon is "easy". It is an incredibly complex operation that would be difficult to hide.
Does "ArabMedia.com" sound unbiased to you? (Score:2)
Want to try reading some more reliable sources? According to this MIT "Nuclear Economics" course material [mit.edu]: See also Section III of this US Air Force paper [af.mil], which says:
Re:Close, but no cigar (Score:2)
Sensitive information in your company/government (my emphasis)
The key here is the information, which is secret, not the software that processes it.
Close, but no cigar (Score:5)
Actually, not even a cigarette. Knowing the source code doesn't compromise security per se, provided that the coders can distinguish their arse from a hole in the ground and didn't hard code database access information into the code.
Look at encryption. Software like GnuPG [gnupg.org] and to a lesser degree PGP are open source. The algorithms applied are well documented and accessible to anybody.
Can you crack a GPG encrypted message? Not likely and it doesn't matter at all. Because security is not in the algorithm, but depends entirely on the key, possibly the chosen algorithm and the precaution of the sender and receiver.
Security through obscurity is about as dumb as it comes.
Re:half-life (Score:2)
Tritium has a half-life of 12 years, so has to be changed from time to time.
About 12 1/3 years and it's swapped out every four years, max, usually about 40-45 months in practice.
1Alpha7
Re:half-life (Score:2)
Polonium has a half-life of only 138 days. So, even though the plutonium itself decays very slowly, it is the initators that must be regularly replaced.
None of the LLCs (limited life components) on a nuclear warhead are that short in the USA. We use neutron generators for that purpose, which are mounted to the side of the pit and are replaced about every 12 years.1Alpha7
They still make plutonium (Score:2)
Risks of closed source software. (Score:3)
I think open source is great, and something the government should be using for non-confidential or lower classified systems.
-
Re:Not too scary (Score:3)
This is exactly backwards. Bomb design is, though not exactly kindergarden stuff, actually fairly simple and easy if you know where to look to find the right info to work with. It's manufacturing the special materials in quantity which is hard and expensive.
Around 1970, the Department of Energy (and specificaly Edward Teller) did a threat analysis program called variously The Third-Country Experiment or The n-th Country Experiment. They took three brand new physics PhDs with no specific course work or training in nuclear physics and told them to design a bomb using only open source materials. This they did, designing a compact (1-ton), reliable (was analyzed by professionals and determined to have essentially full reliability / functionality, though one was not manufactured to test) weaponized plutonium implosion device, in 18 months time. So there's been a demonstration that it can take as little as less than 5 man-years effort.
See: The Nuclear Weapons FAQ [fas.org] by Carey Sublette and the newsgroup alt.war.nuclear [alt.war.nuclear]
Reports of nuclear weapons incidents: YAWN (Score:2)
I'm wondering if the lack of recent incidents is the result of reports still being classified or if we have increased our safeguards.
My experience aboard fast attack submarines has always left me with a good feeling about the degree of paranoia the military holds for these devices. They were treated with enormous respect and the security precautions surrounding them always impressed me. It sure was a pain in the butt. I felt the people whose job involved the care of these weapons understood the meaning of what they were doing and carried out the extreme work rules because, ultimately, they made sense.
Even looking over the history of the Naval nuclear power program you can see that, as our understanding of the dangers of radiation became more sophisticated we also became increasingly diligent in the handling of radioactive materials and in the reduction of radiation exposure. I looked at my old service records and I note that my total radiation exposure while in the service was under 50 mili-REM. Granted, I picked up the Parche in new construction, but I still did maintenance in the Reactor Compartment for years after criticality. We worked VERY hard to limit radiation exposure.
My feeling on the report cited is that the people who wrote it were fundamentally anti-nuclear and wanted to use existing reports to make things look bad/incompetent.
Accidents happen, even in zero-defects programs. (Maybe BECAUSE of the zero-defect program psychology). It's good to see that safeguards designed into the weapons worked.
Media Imitates Life (Score:2)
"The Russians found that over time, as the computer program is used, some files become invisible and inaccessible to the nuclear accountants using the system, even though the data still exist in netherworld of the database."
Oooh, next they'll tell us that there's no such thing as user or computer error, it's instead the magic pixies in the machine going on strike that brings down the software!
"Kurchatov scientists discovered a fatal flaw in the Microsoft software donated to them by the Los Alamos National Laboratory."
In a word, duh... However, Los Alamos (and a good deal of the military) doesn't *use* Microsoft products, except in the case of laptops, etc, non mission critical machines... Half of them are using Unix or whatnot, OS's that have been time tested as reliable and suited to mission critical applications...
And being that they use software that is essentially time tested, it *has* to be screwups on the part of the Russians, because if such a flaw exists in the software, they would not be a major risk for distribution of weapons grade nuclear fuel, *WE* would...
Whoever wrote that article for the Washington Post should go back to covering dog shows and the occasional visit of pandas to the Washington Zoo... Or perhaps he should take that up as a career revision...
Former Minuteman launch officer and president of the center for defense information? They don't program or use computers other than for entering launch trajectories and confirming launch codes, they just turn the little keys, right?
Were they using Office XP? (Score:2)
Re:half-life (Score:2)
When the warhead is armed, they are removed.
Initiators are always inside.
They need Gnuclear-Tracker (Score:5)
It's not very stable though, the core's it generates tend to glow in the dark.
This is an undocumented feature, not a bug (Score:2)
On another topic, why don't companies bombard radioactive waste with neutrons to make it break down?
--
Re:how much the world has changed . . . (Score:2)
Man, now you've got me feeling old. I clearly remember one particular project I did in Junior High; it was a poster detailing possible fallout clouds and "safe zones" in the US immediately following a nuclear strike. I remember researching weather patterns, attack scenarios and the like, only to come to the conclusion that there were a few strips of land in the upper Midwest where civilization could conceiveably continue.
The thing was, everybody in the class (teacher and myself included) took this thing seriously. We used to read books like Failsafe and spend entire class periods talking about not if such a thing could happen, but when it would happen and whether or not it would cause a full nuclear assault. Scary stuff for kids.
Footnote
It was some time later that I learned a) that there were enough targets (bunkers) in the upper Midwest to turn it into a perma-barbeque, and b) in order for civilization to survive somewhere, if must first exist in that place.
(Apologies to both North Dakotan Slashdot readers)
Re:Risks of closed source software. (Score:2)
> Clue: Open Source does not mean that everyone has access to the source. GPL-style free software licenses mean that those who can get a binary can get the source for free, which in this case would've been a good idea. Then the facility in question could've found and fixed the bug long ago.
This statement might actually be relevant if we were talking about a piece of commercial (or commercial-grade) software here. But we're not. This is about a piece of software written for a department of defense contract, and for which I would almost guarantee you the DoD got the source code. The military doesn't just go asking for bids for this kind of project and expect that in the end all they get is a 3.5" floppy disk with a binary on it. "Here you go, here's your nuclear materials inventory software. Now can we have our $10M?"
The GPL, or its absence, is completely irrelevant to the availability of the source code in this case. The purpose of the GPL is to stop people from distributing binaries without source code, or from modifying software without making the modifications available. This is a situation where a piece of software is written for a single customer, who then has the source code, and there is no incentive on anyone's part to try to distribute it, with or without source.
You are correct in that the GPL would not have given everyone on the planet (and their dog, and their neighbourhood terrorist, as some here are suggesting) access to the source code. But it's not the only method of making the code available.
> Or would you rather confidential government systems be running a closed-source solution like NT and not know who's getting what data from them?
Incidentally, I have heard reports of the US military getting access to source to MS windows when they've decided that it's important.
Open vs. closed source only makes sense in the consumer world of mass-market software, EULAs, shrink-wrap licenses and DMCA.
Shoulda used open source (Score:5)
You don't know adrenaline til you guide a nuclear missile with gnuke 0.913 (unstable).
Yeah, right. (Score:2)
Or, maybe I've watched too much X-files.
Re:US Should purchase inventory of Plutonium (Score:2)
Of course, you won't do that...
Re:huh? (Score:3)
I've seen plenty of bad apps written with the VB/SQL Server combination, and very few good ones, so it wouldn't suprise me that they did something dumb, like put the RI in the front-end code, or neglect to use tranactions.
I would suspect that a lack of proper RI has resulted in orphaned records, which could fit their (wierd) explanation of the problem.
Re:Shoulda used open source (Score:2)
[Distant sound of nuclear explosion. Mushroom cloud appears] Ooops. Fetch me an eraser; that town wasn't important anyways.
D - M - C - A
Re:huh? (Score:5)
I agree. It sounds like the database may have a flawed relational key structure. In such a case, certain data entry errors for a parent record can cause related child records to become "lost". The child records are likely still there, but are not related to the intended parent.
More broadly, there are likely to be 2 implied issues with this software:
1. If the software is 10 YO, it is likely that it was written with less than full attention to modern relational principles, such as database normalization [microsoft.com], application partitioning, etc.
2. It is certain that the database was changed, ported (*), etc. over its 10 year life. It is again certain that the changes were less than optimal. Some probably even introduced errors.
* - If the application is 10YO, it is certain that it was NOT written for NT/SQL Server, as SQL Server is not a 10YO application.
It probably will make sense for the database to be reviewed and rebuilt. In general, applications should be reviewed and re-engineered periodically.
Re:Not too scary (Score:2)
It's kind of like the DeCSS fiasco: once the technology gets out, there's nothing you can do to put it back in the bottle.
But at least you can't write a nuclear bomb in six lines of perl. Or can you?
Not too scary (Score:3)
Weapons-grade fissionable materials in themselves are relatively easy to make. Any nation that has the know-how to build a nuclear reactor can build a breeder reactor to make weapons-grade uranium. The technology required to make the actual bomb, though, is pretty difficult to figure out. It's kind of like the DeCSS fiasco: once the technology gets out, there's nothing you can do to put it back in the bottle. Thankfully, everyone (so far) who has the tech wants to keep it private. Hope the servers they store the info on aren't running Windows!
Nucular material is safe with me (Score:2)
If you can't rely on state workers like me, then who can you trust?
Re:That's not a bug ... (Score:2)
Just like the stuff it's supposed to track.
Re:how much the world has changed . . . (Score:2)
Now we're more concerned with the rogue state or terrorist nuclear weapon.
If you're that concerned with the rogue state and terrorist nuclear weapons then I suggest you put some pressure on your government to stop creating "ENEMIES" (justification for genocide) throughout the world and stop looking for commies in every closet. In other words --- stop getting your so-called information from the mass media propoganda machine.
I wonder if someone even 10 years younger than I am can understand how much things have changed?
The more things change, the more they remain the same. The only thing that has changed is the mindset (or lack thereof) of the masses who want and demand instant gratification and accept rote learning as the norm. What differs from your generation to mine is simple
Expecting absolute zero failure rates is absurd (Score:3)
What you are talking about is not reasonable. No matter how careful a programmer is, no matter how much testing the code goes through, no matter how many experts scan through the code, there is always the possiblity of a bug or design flaw. It cannot be expected that code written in the real world for use on real devices will be 100% fault tolerant. The same goes for anything else.
Why do you think there are so many problems with getting good, decently priced healthcare in the US? It is exactly because the doctors have to pay settlements in the millions if they make a very small mistake or a dying patient doesn't survive a very risky surgery (which the patient and family were informed of the risks). What is the result of this? Doctors/hospitals have to pay massive malpractice insurance premiums. HMOs were created, which makes getting serously ill worse, because your provider will hide possible treatments, refuse to pay for critical operations, use accountants to make decisions that only doctors should. And so on, and so on...
That is just for finacial liability. How would it be if an industry were criminally liable for not being 100.00000% perfect and 100.00000% successful at everything? I imagine it would end up like this: most of the people who are knowledgeable would run away screaming from their job, realizing they could not possibly live up to the standard and would end up in jail. Then you would only be left with clueless idiots, arrogant bastards, and con-artists. After a short time, the idiots and bastards would be in jail because they made some sort of mistake, and the con-artists would be in the Bahamas or somewhere with the millions of dollars they stole from desperate organizations trying to fill in the essential gaps in labor caused by this law. What does that leave us with? Nothing! Because we are talking about critcal industries, what would happen? I don't want to find out.
People or organizations should be punished if they hide problems or don't use resonable care, however saying that someone must be punished for everything that goes wrong is complete idiocy and shows total disregard for reality.
huh? (Score:2)
The Russians found that over time, as the
computer program is used, some files become
invisible and inaccessible to the nuclear
accountants using the system, even though the
data still exist in netherworld of the database.
If the data still exists in the "netherworld"
(!?) of the database, then why will they have
to go through a billion dollar physical re-
inventorying process?
Re:of course it's closed source (Score:2)
open source does not mean open data.
Software Manual (Score:2)