Let's imagine for a moment that you just saw a science fiction play back in 1835, set in the far-distant future of 2002. "167 years from now, with all the fancy technology and all sorts of cool gadgetry, they still use revolvers and handguns?"
Short answer: HELL YES.
(I'm also a shooter, too, so keep in mind my comments here are not purely theoretical.)
The simple idea of a chemically-launched projectile has a huge number of advantages.
Simple. Sometime ask a shooting friend to sit down with you and disassemble a pump-action shotgun. They're utter marvels of simplicity. They have very few moving parts, what moving parts they do have are very durable, and any part which is likely to break can either be repaired or replaced in a matter of hours by any competent metalworker.
By comparison, what do you do on a backwoods planet if your 31337 railgun pistol blows a capacitor? Whoops. Guess you're SOL.
Reliable. In two decades of shooting I have never suffered a failure of any sort from a pump-action shotgun. I've seen one failure from a Kalashnikov-style weapon (stovepipe jam on an SKS). My Windows 2000 box gives me a bluescreen every other month. Now imagine that you're in a fight with bandits who want to extract the gold from your teeth. Which would you rather have? A Winchester pump-action which is 100 years old but well-maintained and totally reliable even today, or a railgun running Windows 2000 which BSODs randomly?
Safety. Firearms are extremely safe devices. They don't go off unless you thumb off the safety, rack the slide and pull the trigger. Compare this to the power electronics on a railgun, laser pistol, or other high-tech energy weapon. Whoops. That railgun took a really sharp jolt? Oooh. Uncontrolled capacitor discharge. Are you electrically grounded? That might sting.
Stability. This may sound obvious, but we know how firearms work. We have a couple centuries of experience with them, and well over a century of experience with recognizably-modern firearms. We're not going to do away with that much collected information just because "heh, heh, this is a railgun, heh". No. Not going to happen.
Effectiveness. A #00 pellet from a 12-gauge shotgun is about.35 inches across. A 9mm bullet is.355 inches across. There are about ten 00 pellets in each 12-gauge 00 shotgun shell. Now think about this: as a rule of thumb (inaccurate, but roughly right), a shotgun's pattern spreads out one inch per linear yard of travel. That means at close ranges (under ten yards) hitting someone once with a shotgun is the rough equivalent of putting an Uzi in their belly and holding the trigger down for a full second. Think about that, okay? Now think about deer slug, and what that can do to a human being. It's sick. I've seen what happens to deer that get hit by a 12-g. It's not pretty. I don't know how you expect to improve on that sort of damage, because I really don't think you can. Not unless you want to go straight to full-body atomizing, which is a little beyond a shotgun's capability.
Versatility.Now think about the fact that a 12-gauge shotgun is really a kind of very convenient 18mm grenade launcher. There are tear gas shells for shotguns. There are incendiary shells. There are flares. There are nonlethal shells. If you only have room for a very limited number of weapons on your ship, doesn't it make sense to carry the most versatile weapons you can get?
Nonthreatening. I live in some great hunting area. That means there are a lot of hunters and a lot of people with hunter's weapons. I could go down to the 7-11 in a pickup truck loaded with enough shotguns to equip a Marine Corps fireteam, and nobody would bat an eye or even remember me after I left. But if I had an M-16A2 in the gun rack? Somebody would notice and call 911 before I'd even finished paying for my gas. If that's what it's like today, I expect the future is going to be much the same. Railguns, lasers, etc. will just scream military hardware. If the local authorities find you with a Gauss rifle, expect to spend a few days in the pokey while they check you out. If they find you with a shotgun? Bah, big deal, get out of here.
... So do I expect people to still be using chemically-propelled slugthrowers in five hundred years? I absolutely do. There will certainly be advances along the way--caseless ammo, bullpupped weapons, built-in nightvision optics, smartgun technology, etc.--but when you get right down to it, it's really damn hard to improve on the basic types of firearms we have today.
Anyway. This post has gone on long enough. It's now 9am on a Saturday and I need to go. I'm meeting my brother at the range at 10am to go through a box of clays.
I'm going to be taking along my 40-year-old Remington 878 autoloader.
I work in the information security field--or, rather, don't work since I'm unemployed in the tech downturn--and I'm looking at the Handbook of Applied Cryptography right now. It's a pale green tome, a little larger than Schneier's Applied Cryptography (which is standing behind it on the bookshelf). Here's how I would rate the two:
AC is by far more readable; HoAC is by far more correct and information-dense.
AC gives a very superficial coverage of the material; HoAC could be used as a textbook for a college math course. When I need a quick reminder of what some common RSA exponents are, I pull down AC. When I need in-depth information, I pull down HoAC.
AC is easier to navigate.
AC makes better leisure reading; HoAC is extremely dry and terse.
Short answer: if you think you know beans about crypto just because you've read through Applied Cryptography... well, you don't. Read through the Handbook until you can understand and follow all the math that they use, and then you can honestly call yourself a cryptonerd.:)
Is it just me, or is there an inherant insecurity in this?
It's just you. After the Dobbertin attack on MD5, pretty much everyone with a brain moved to SHA-1. This created some difficulties for apps which were hardcoded to only accept 128-bit hashes, but the accepted method of replacing MD5 in that case was, and remains, to use the first 128 bits of an SHA-1 hash. There is no inherent insecurity here for any well-designed hash function.
A well-designed hash function is one whose output is indistinguishable from random noise. To see what I mean, let's say I have a one-bit hash function. You put in your message and you get out either a 1 or a 0. You can't predict whether a certain message will result in a 1 or a 0, though, unless you actually go through the entire process of hashing.
Now let's say I take a SHA-1 hash of the same message and discard 159 bits. I'm left with... a 1 or a 0. And I can't predict whether a certain message will result in a 1 or a 0, though, unless I actually go through the entire process of SHA-1ing it.
Truncating a trusted hash to a shorter hash length is every bit as trusted as using a hash which was designed for that shorter length in the first place.
The converse is unequivocally not true. One way people like to create larger hashes is to first hash the data, then append the hash to the data and re-hash, then concatenate the two hashes together. It works, yes, but it's not an effective method. If you're using MD5, for instance, there are no more than 128 bits of entropy in your hash--even if you chain MD5 operations together to get a longer hash, you're still limited to 128 bits of entropy. If you want a longer hash size than the one you currently have, your choices are (a) chain your current hash, which will get you the size you need but at no additional security, or (b) use a different hash which is designed for the additional size.
The entire thing that got me started, was a downloaded Slackware ISO from an unofficial mirror, that had the correct checksum, but was hopelessly corrupt due to transmission errors close to my side.
If so, you're the luckiest person ever likely to walk the earth. The odds of any two messages hashing out to identical values are 1 in 3.4 * 10**38. The odds of this happening are 100,000,000,000,000,000,000,000,000,000 Schiffers to 1 against. That's steep.
(What's a Schiffer? Well, it's simple... out of the roughly 10**9 men on Earth, Claudia Schiffer is only sleeping with one of them--her husband. The likelihood that any given guy will be sleeping with Claudia Schiffer is roughly one in a billion. If you tell someone "the odds of this are one in 10**38", they'll just look at you blankly. If you tell them that it's 1<28-zeros>0 times more unlikely than them boffing Claudia Schiffer tonight... that, guys understand.)
Hate to be the bearer of bad news, but the book didn't work for me, either. But that's okay; you still get props in my book for writing the text that helped wrap my head around Pascal way back when. There, I'm done being a fanboy; the rest of this is all for Slashdotters without a clue.
Clue: when all is said and done, it doesn't matter if one particular book helped you or didn't help you. It doesn't matter if one particular kernel patch lets you use your FooBarBaz card, or if it just sets your mobo on fire.
What matters is what you do about it. If you read a great book on Assembly and then sit on your ass and don't do anything with that knowledge, then you might as well have not read the book in the first place. If you read a lousy book on Assembly and decide "dammit, there needs to be a better book," and then write that better book, then congratulations: you matter.
It's easy to say that the fellow who's actually doing the job could, should, be doing it better. (Hell, that sounds pretty much like John C. Dvorak's job description.) But it's a much harder thing, and better thing, to actually do the thing.
Really. It'll clarify things right up. Dollars to donuts there's a clause in there, probably called "Severability" or something to that effect, which states that "if any clause in this EULA is found to be in violation of the law, then it is null and void with all the other clauses still in effect."
Contracts aren't allowed to violate the law. A contract to kill someone isn't legally binding, because murder is illegal. If Microsoft wants to claim they get remote access at will to your boxes, then you get to say "neener neener neener, no you don't, under HIPAA I'm forbidden from allowing you that access".
The proper Microsoft response? "Oh. Well, we're sorry about that. All the other clauses of the EULA stick, though."
So go ahead, get Windows SP3, and then figure out some way to disable remote-root.
Oh, and one more thing--
FOR THE LOVE OF GOD, TALK TO LEGAL COUNSEL. WHY THE FSCK ARE YOU ASKING LEGAL QUESTIONS ON `ASK SLASHDOT', ANYWAY?! DO WE LOOK LIKE HARVARD LAW GRADS?!
(Sorry, just had to get that knee-jerk reaction out of my system.)
but from the day you get a virus, to the day you die, that virus potentially inhabits your body.
What's your point? Every human being is a colony of thousands of different unique bacteria. From the day you catch strep throat to the day you die, there are strep bacteria living somewhere on your skin. Just counting the number of different Escheria coli bacteria living in your gut would push me past Slashdot's space limitation. Just counting the number of different helpful, necessary bacteria would make me go on for paragraphs and paragraphs.
Sure, bacteria and viruses are with you for life. What's your point? That's why we acquire immunities.
This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.
No to the former; yes to the latter. The reason why this is a critical flaw in the Win32 API is because it means that in order for code to be secure it is essential that every existing piece of software be carefully checked to make sure it separates interface from back-end.
If you're talking about a large enterprise installation with lots of closed-source apps and a vendor turnaround time on security issues which runs into the months--and there are a lot of them out there, make no bones about it--then your boxes are at critical risk. In that case, you're essentially guaranteed to have at least one app an attacker can root the box through. Sure, it may be the app's fault for not separating interface and back-end sanely, like most of us who give a damn about good engineering learned (sometimes the hard way)... but it's also the Win32 API's fault for not requiring separation of interface and back-end [*], it's the Win32 API's fault for being so shoddily designed that an attack like this becomes possible in the first place.
A good analog in the UNIX world is sprintf(), which has been responsible for more stack-smash attacks than probably any other thing. Even though we have snprintf(), most people don't know snprintf() exists or why it should be used. Like the Win32 window exploit, our sprintf() vulnerabilities will continue for as long as people write stupid code. Like the Win32 window exploit, we can't fix the problem by removing sprintf() [**]. All we can do is provide snprintf() and hope and pray that people use it.
sprintf() is a flaw in the UNIX/C API which has led and continues to lead to attacks against the system, facilitated by stupidly-designed software which uses the call even when snprintf() is available. sprintf() can't be removed without breaking literally thousands of stupidly-written apps which depend upon it.
This Win32 attack is a flaw in the Win32 API which has led and continues to lead to attacks against the system, facilitated by stupidly-designed software which doesn't separate interface and back-end. This Win32 attack can't be removed without breaking literally thousands of programs.
Hey, guess what, world? We've found Win32's version of sprintf(). Oh, happy day.
My condolences go out to any security engineers working in Win2K land. You guys have got your work cut out for you minimizing this exploit.
[*] Not that I have any idea how they could do this. [**] sprintf() is defined in C89. Good luck getting rid of it.
I've just grepped through vg_scheduler.c looking for `bind', `sock', `11', `RAW', `raw', and several others. I've come up with absolutely nothing. Admittedly, I haven't checked out the entire source--at 3500 lines, it'd take me several days to do a proper audit--but so far I haven't found any references to socket calls anywhere.
Still, I would appreciate it if the maintainer could check out vg_scheduler.c and see if there's something amiss there. Thanks.:)
Bzzt--thanks for playing. Tritium is used to boost the initial fission yield; it's not used in the secondary stage.
A different set of compounds (lithium hydrides?) undergoes fusion, but this isn't the terminal stage of the nuke. The fusion is almost purely an incidental product--they're not looking to liberate energy from the fusion, they're looking to liberate neutrons. Specifically, real freakin' energetic neutrons which can induce fission in the U-238 shell surrounding the nuke. So essentially, there are three stages: a small fissile device at the core, then a small fusion stage, and then a really honkin' huge fissile stage which amounts for >90% of the liberated energy.
In fact, some of the early H-bombs used no hydrogen at all. If you get U-235 in the same shape as a softball, it'll spontaneously go supercritical; but if you get a cylinder of U-235 with a diameter slightly less than a softball, it can be arbitrarily long without going supercrit. To make it go supercrit, you use explosives to implode its shape, at which point it goes supercrit. The U.S. tested a 500kt "H-bomb" which was one of these purely fissile (i.e., "A-bomb") designs.... Why do nuke designers prefer fission reactions to fusion ones? When uranium splits, it does so by breaking into big and heavy atomic fragments (+46 charge). These atomic fragments carry away the majority of the reaction energy and dump it almost immediately as heat. By comparison, when hydrogen fuses to helium, the end product is a very light atomic nucleus and the majority of the energy of the reaction is liberated as neutrons, which can travel for quite some distance before giving up their energy.
Basically, fission has a lot more bang for the buck.
If you really want to know more of the physical details behind nukes, check out FAS (here) and the Bremsstrahlung Effect.
jEdit (available here) is available anywhere there's a reasonably recent Java2 runtime. On Windows with J2SDK1.4, I've noticed that it takes a fair bit of time to load up, but once loaded it's acceptably snappy--it's never going to win points for speed, but it manages to not be noticeably and/or annoyingly slow, which is good.
It has bindings for something like 50 different languages, from Ada to SQL and every-other-thing in between. I have been exceptionally pleased with jEdit so far, at least on Win32. On UNIX, jEdit is a little slower, to the point where it enters noticeably and annoyingly slow, but it's still a defensible choice.
If you do a lot of crossplatform work (I do) and want to keep your basic work environment the same in both environments, you can do an awful lot worse than jEdit.
... In the 70s, cops were beginning to discover that their service revolvers were generally pretty lousy pieces of kit. Most departments issued.38s, which are pretty anemic--many departments were still using.32 revolvers.
Some cops were complaining that they had pretty much no penetration. This caused some problems--well, hey. The inventor can say it better than I can.
Dr. Paul Kopsch, in a 1990 interview: "There were a couple gunfights, police versus criminal, here in Lorraine County[, Ohio]. The ordinary.38 Special service bullet would not get through the car door. And with any degree of obliquity, it bounced off the windshield. [Police] Lieutenant Turcus, Don Ward and I thought maybe we could design a bullet which would get through the car door, and get through the windshield and get the crook out of the car..."
Those three men--Kopsch, Turcus and Ward--invented an armor-piercing handgun cartridge, which they called the KTW (after their initials). The KTW was a bullet made of steel. When a normal lead bullet hits something, it'll deform and expend a lot of its energy as a result. Steel doesn't deform, and that lets it rip through cover easily.
Unfortunately, the bullet was so hard that firing it would destroy the barrel of the gun. Lead is soft enough to not damage the barrel; firing steel bullets will ruin a barrel. So in order to protect the barrel from damage, the KTW bullet was then clad in a light Teflon coating.
I've seen KTWs for sale at gun shows, but I think most of the KTWs on the market today are hoaxes. The KTW was never produced in large quantities and was only sold to military and law-enforcement arsenals--never to private citizens, nor was it ever sold directly to cops. The "KTWs" I've seen have been pretty shabby-looking things that the seller wanted $20 a round for, and promised that "of course it's real, don't you see the Teflon?"
In the military, "field expedient" is slang for "ugly hack that works surprisingly well". That said... during WW1 and WW2, the German armed forces didn't have anywhere near enough heavy machineguns to take on tanks. So the infantry made field expedient antitank rifles by taking 8mm ammunition (a very powerful round--at the turn of the century some people used them to hunt elephants), removing the bullet and then reseating the bullet, reversed, so that the blunt face would strike first. It gave the bullet the same effect as a metal die-punch; it punched neat, clean holes in steel.
Moral of the story: "pointiness" has never been a major issue with armor-piercing ammo. It's all about the sectional density.
Read Mark Bowden's Black Hawk Down for a good account of NATO SS109 ammunition (5.56mm semi-armor-piercing) used against human beings. At short ranges, such as the Rangers had in Mogadishu, the rounds punch very small, clean holes in targets--there were many incidents where an AK-wielding Somali had to be hit five or six times with SS109 before he was incapacitated, compared to the one-shot-anywhere-in-the-body that the Delta Force snipers enjoyed with their 7.62mm rifles.
The normal syntax everybody uses is not bounds checked and there is no way around that.
The syntax you use isn't. The syntax which I commonly use--and which is commonly used by professional C++ coders--is. Bounds-checking is one of the biggest wins of the vector; discarding it, just because you can't be bothered to learn how to use the STL properly, seems exceptionally rash to me.
But anyway I see no difference than somebody saying "C is safe, just use this special at(pointer,index) function instead of [] and you will be fine"
There is no difference, save for this: a bounds-checked vector is part of the C++ standard library (via the STL) and is available on every C++ platform that's worth coding for. Even MSVC++'s shoddy STL implementation supports it.
Bounds-checked array access is not part of the C89/C90 spec (dunno about C99), and thus, if you want it, you have to do what the original poster does--bleed for it, via many different vendors.
The original advice I gave is still the advice I'm giving now. Use a different language. If bounds-checking is what you need, then use a language with support for bounds-checking built into the language.
vector does do bounds checking, but since it results in a (minor) performance penalty, operator[] (the normal method of vector access) is unchecked. You want bounds checking, use at().
95% of the time, it is simply bad software engineering practice to use operator[] within a vector. The only time it's really acceptable practice is when (a) you're operating under severe performance limitations and (b) you have some other guarantee you won't hit an out-of-bounds condition.
I can still generally compile and run five year old (since last revision) C programs without too much trouble. Frankly, five year old C++ programs have a habit of failing compilation on the first file -- too much change in the compilers.
Hardly surprising given that five years ago there wasn't even an ANSI/ISO C++ standard. If you're using code that doesn't conform to the standard, it's not the language's fault if it fails to compile.
*snicker* Okay, find me a high performance Common LISP kernel.
I'm not a Common LISP hacker, sorry. But for non-C kernels, try BeOS (C++), try Oberon (Modula), try Plan 9... they vary from acceptable to excellent, and don't use C.
But if you really want a high-performance LISP kernel, I'd suggest looking at an (old) LISP Machine. Those babies were pretty sweet for the day.:)
Okay, you said Scheme was sexy, so I guess I won't flame you.:) (Hey, I warned you I'm a language zealot.) That said...
C has it's place. It's small and dark and should be avoided by most.
I don't know if I'd go this far. On one of my pages (here, or http://soli.inav.net/~rjhansen/c_relevance.html for the goatse.cx averse) I've got an essay--which I originally wrote intending it to be a response to a Web editorial I saw blasting every language that wasn't Java--which may be germane to the discussion here.
Short version: C has its place. Yeah, the place is small and dark and should be avoided whenever possible. But sometimes we don't get a choice of whether or not to avoid it, and when we're trapped in that small, dark place, C is your salvation. So I'm not going to knock C--but I will say that I generally avoid it whenever possible.:)
However, why not just use straight ANSI Common LISP
Didn't recommend it because I don't know Common LISP.:) I had a hard enough time wrapping my head around the C++ Standard; given the ANSI Common LISP standard is about the same size, I'm very reluctant to give it the focus that I'd need to in order to be a credible Common LISP programmer.
Scheme, on the other hand, has a very lightweight standard. It's easy to read, easy to understand. Sure, it probably misses out on some cool things that are in Common LISP, but I've yet to find an instance where Scheme has let me down.:)
Really--the only reason why I didn't recommend Common LISP was because I have a moral aversion to recommending languages I don't understand. If you like it, though, by all means, get down with your bad functional-programming self.:)
Warning: I'm a language zealot, so be warned that I'm utterly irrational and unamenable to the Sweet Voice of Reason. That said...:)
Use a different language. There are some things which C is appropriate for, but one of the things it's categorically not called for is when you have concerns about buffer-overflow conditions [*]. If this is a purely open-source, noncommercial project, do yourself and your career a favor: learn another language (one which doesn't have these sorts of problems) and write your app in that instead. You'll learn more, and you won't have to spend a dime on Purify or whatnot. If you go this route, I'd suggest Scheme; it's a beautiful LISP derivative.
If this is a commercial project, ask Management how married they are to C. In the overwhelming majority of cases, you can quietly substitute C++ without affecting the APIs one bit. Just wrap the external APIs in extern "C" and, inside the code, use C++'s beautiful vector instead of C-style arrays. Sure, you'll take a minor performance hit, but the increase in reliability will be well worth it.
Anyway, to try and give a (weak) answer to your question--instead of slapping a Band-Aid on the festering wound that is C memory management, you might want to think about doing away with the festering wound altogether. Use the right tool for the job--if C really is the right tool for the job, then fine, may God have mercy on your code. But if there are other, better, tools available... use them instead.
[*] OpenBSD manages to do pretty well with a C kernel, but that's because they're certifiably insane. It also impacts their dev cycle; they spend a great deal of time avoiding the pitfalls of C, so much so that it affects how much time they can devote to new development.
At one job, I was asked two questions--no more, no less--by one of my interviewers.
Why does Java suck?
Why is the answer you just gave wrong?
...Sounds counterintuitive, I know, but think about it for a moment. He wasn't asking me to give him facts; he was asking me what I thought, and then he asked me to think one hundred and eighty degrees opposite.
The job was pure C programming, incidentally.
I got the job--apparently, my second answer didn't suck as much as I was afraid it did--and I wound up working pretty closely with my interviewer. He told me later that mostly what he wanted to see was proof of life in my cerebral cortex. There are lots of people out there who can sling code, but there aren't many people out there who have given time and effort to applying their analytic and abstract reasoning skills.
Slashdot is a beautiful example of a community of coders who have great code-fu, but tend to seriously lack in the reasoning department.
It's absolutely clear that you're on crack. Sorry, but I don't have time to waste getting trolled. Look at my prior response. The answers you want are in there.
Barring that, you could do something daring (gasp!) like, oh, reading the published literature. Somehow, though, I don't expect you've done any of that.
If somebody comes up with a new encryption algorithm, they shouldn't have to write code to support Evolution, Eudora, Outlook Express, so forth and so on.
They don't. RFC2440 (plus RFC2015, 3156, etc.) are extensible; they support a broad variety of algorithms and are designed to support future algorithms. RTFFAQ.
Likewise, somebody should be able to write a front-end for a email application according to a specific API and expect to see every available encryption algorithm thus far implemented available from within that email application.
Microsoft CAPI provides just this. GPG Made Easy (GPGME) also makes it almost trivial to incorporate crypto support into your application. (ObDisclosure: I'm working on C++ bindings for GPGME, so I'm biased.)
gnupg is great, but it presumes a single algorithm, doesn't it?
RTFFAQ. OpenPGP supports more algorithms than you can shake a stick at. For instance:
IDEA
3DES
CAST5-128
Blowfish
Rijndael/AES-128, -192, -256
Twofish
RSA
El Gamal
DSA
Wouldn't it be much better to make it easier to introduce new algorithms into the mix?
No. In fact, I personally dislike the fact that most PGP implementations (including GnuPG) support so many algorithms. Every implementation must support 3DES, and y'know, 3DES has a twenty-five year track record of turning brilliant cryptanalysts into burned-out alcoholic wrecks. Anyone who wishes to use AES256 for "security" is missing the point--the most trusted algorithms aren't the latest sexy things. The most trusted algorithms are the ones which are older than God and uglier than a Soviet worker's housing bloc.
If he gets to *assume* that the encryption being used is pgp-style, his workload is modest, he just needs to feed the file to the program.
The analyst is already going to know what algorithms you're using. The way you plan these things is to assume the analyst has access to tens of thousands of times more computing power than exists in the world, tens of thousands of times more memory than exists in the world, knows you better than your wife does, and knows every last detail of your cryptosystem except what your key is.
Assuming anything else is absolute folly.
And yes, I am a cryptographer.
Especially if there are hundreds if not thousands of algorithms out there, each and every one available to the common man for his use.
There are three symmetric algorithms I would trust my deepest secrets to. IDEA, 3DES and Blowfish. AES isn't on that list (won't be for another couple of years while peer review shakes out). If I'm a professional in this field, and out of the literally thousands of different symmetric block ciphers proposed over the years I can only find three which I recommend without hesitation, and the other 997+ range somewhere between interesting-but-flawed and fatally stupid, I really doubt that you--a layman with no experience whatsoever--will be able to intelligently choose the three good ciphers out of a field which consists, mostly, of spectacularly bad ones.
Something as trivial as taking the output of gnupg and exclusive-or'ing with a Erica Rose Campbell jpeg would add another - if - statement to the NSA's decryption code
Please go read this book: Codebreaking, by Rudolf Kippenhahn. You have a critical misunderstanding of how cryptanalysis works. It doesn't work by a series of "try this, then try that, then try..." It works by looking for redundancies, patterns, in data and then creating a mathematical model which can recreate those same redundancies and patterns. If you're XORing with a JPEG, you're not going to be making it appreciably harder to break. There's a lot of mathematical order in a JPEG.
I would bother responding to your last comment about why PGP is "weak", but really, it's clear that you're talking through your hat. I can believe that you're utterly clueless, or I can believe that you're trolling. If the latter, then HAND, IABT. If the former, then please go off and read up on the subject.
I'd suggest starting with David Kahn's The Codebreakers, from there Rudolf Kippenhahn's Codebreaking, then Schneier's Secrets and Lies. Only then start to work on Applied Cryptography and the Handbook of Applied Cryptography.
First, please note what the subject says: Twofish, Serpent and AES/Rijndael aren't as trusted. That's not at all the same as saying they're not trusted.:)
They are all excellent ciphers as near as anyone in the field can tell, but they are all very new. Many people in the field (myself included) are deeply skeptical of all new algorithms. Blowfish, by comparison, is about ten years old and has no significant cryptanalytic attacks against it. This makes Blowfish preferred over AES in the eyes of many cryptographers. (This is also why so many of us drool over 3DES. While it's hideously slow and inefficient, 3DES has been turning brilliant cryptanalysts into alcoholic, burned-out wrecks for 25+ years. That's amazing.)
Second, I am not aware of any cryptographer who recommends Serpent or Twofish over AES. When Rijndael won the AES selection, every cryppie in the world who wanted to make a name for himself started to throw himself at it. Hence, Serpent and Twofish have been exposed to much less cryptanalysis than AES/Rijndael. Serpent and Twofish aren't bad ciphers, but given the existence of AES, every responsible cryptographer I know strongly recommends AES over Twofish and Serpent.
Third, if I recall correctly, the OpenBSD people like Blowfish because Blowfish is about as agile as a brick. Attempting to break Blowfish by brute force is a really painful thing to think about, because setting up a new key is computationally expensive. By comparison, AES is a very agile cipher.
Fourth, it's true that AES is a blazingly fast cipher. But Blowfish is no slouch in this department, either.
So what you wind up with is Blowfish (a) is key-clumsy, which OpenBSD wants, (b) has survived almost a decade of rigorous cryptanalysis, (c) is quite fast.
OpenBSD wouldn't get any real benefit from switching to Blowfish. Why should they change?
Slashdot Mirror
Short answer: HELL YES.
(I'm also a shooter, too, so keep in mind my comments here are not purely theoretical.)
The simple idea of a chemically-launched projectile has a huge number of advantages.
- Simple. Sometime ask a shooting friend to sit down with you and disassemble a pump-action shotgun. They're utter marvels of simplicity. They have very few moving parts, what moving parts they do have are very durable, and any part which is likely to break can either be repaired or replaced in a matter of hours by any competent metalworker.
- Reliable. In two decades of shooting I have never suffered a failure of any sort from a pump-action shotgun. I've seen one failure from a Kalashnikov-style weapon (stovepipe jam on an SKS). My Windows 2000 box gives me a bluescreen every other month. Now imagine that you're in a fight with bandits who want to extract the gold from your teeth. Which would you rather have? A Winchester pump-action which is 100 years old but well-maintained and totally reliable even today, or a railgun running Windows 2000 which BSODs randomly?
- Safety. Firearms are extremely safe devices. They don't go off unless you thumb off the safety, rack the slide and pull the trigger. Compare this to the power electronics on a railgun, laser pistol, or other high-tech energy weapon. Whoops. That railgun took a really sharp jolt? Oooh. Uncontrolled capacitor discharge. Are you electrically grounded? That might sting.
- Stability. This may sound obvious, but we know how firearms work. We have a couple centuries of experience with them, and well over a century of experience with recognizably-modern firearms. We're not going to do away with that much collected information just because "heh, heh, this is a railgun, heh". No. Not going to happen.
- Effectiveness. A #00 pellet from a 12-gauge shotgun is about
.35 inches across. A 9mm bullet is .355 inches across. There are about ten 00 pellets in each 12-gauge 00 shotgun shell. Now think about this: as a rule of thumb (inaccurate, but roughly right), a shotgun's pattern spreads out one inch per linear yard of travel. That means at close ranges (under ten yards) hitting someone once with a shotgun is the rough equivalent of putting an Uzi in their belly and holding the trigger down for a full second. Think about that, okay? Now think about deer slug, and what that can do to a human being. It's sick. I've seen what happens to deer that get hit by a 12-g. It's not pretty. I don't know how you expect to improve on that sort of damage, because I really don't think you can. Not unless you want to go straight to full-body atomizing, which is a little beyond a shotgun's capability. - Versatility.Now think about the fact that a 12-gauge shotgun is really a kind of very convenient 18mm grenade launcher. There are tear gas shells for shotguns. There are incendiary shells. There are flares. There are nonlethal shells. If you only have room for a very limited number of weapons on your ship, doesn't it make sense to carry the most versatile weapons you can get?
- Nonthreatening. I live in some great hunting area. That means there are a lot of hunters and a lot of people with hunter's weapons. I could go down to the 7-11 in a pickup truck loaded with enough shotguns to equip a Marine Corps fireteam, and nobody would bat an eye or even remember me after I left. But if I had an M-16A2 in the gun rack? Somebody would notice and call 911 before I'd even finished paying for my gas. If that's what it's like today, I expect the future is going to be much the same. Railguns, lasers, etc. will just scream military hardware. If the local authorities find you with a Gauss rifle, expect to spend a few days in the pokey while they check you out. If they find you with a shotgun? Bah, big deal, get out of here.
... So do I expect people to still be using chemically-propelled slugthrowers in five hundred years? I absolutely do. There will certainly be advances along the way--caseless ammo, bullpupped weapons, built-in nightvision optics, smartgun technology, etc.--but when you get right down to it, it's really damn hard to improve on the basic types of firearms we have today.By comparison, what do you do on a backwoods planet if your 31337 railgun pistol blows a capacitor? Whoops. Guess you're SOL.
Anyway. This post has gone on long enough. It's now 9am on a Saturday and I need to go. I'm meeting my brother at the range at 10am to go through a box of clays.
I'm going to be taking along my 40-year-old Remington 878 autoloader.
Let's hear it for the tried and true.
- AC is by far more readable; HoAC is by far more correct and information-dense.
- AC gives a very superficial coverage of the material; HoAC could be used as a textbook for a college math course. When I need a quick reminder of what some common RSA exponents are, I pull down AC. When I need in-depth information, I pull down HoAC.
- AC is easier to navigate.
- AC makes better leisure reading; HoAC is extremely dry and terse.
Short answer: if you think you know beans about crypto just because you've read through Applied Cryptography... well, you don't. Read through the Handbook until you can understand and follow all the math that they use, and then you can honestly call yourself a cryptonerd.Is it just me, or is there an inherant insecurity in this?
... a 1 or a 0. And I can't predict whether a certain message will result in a 1 or a 0, though, unless I actually go through the entire process of SHA-1ing it.
It's just you. After the Dobbertin attack on MD5, pretty much everyone with a brain moved to SHA-1. This created some difficulties for apps which were hardcoded to only accept 128-bit hashes, but the accepted method of replacing MD5 in that case was, and remains, to use the first 128 bits of an SHA-1 hash. There is no inherent insecurity here for any well-designed hash function.
A well-designed hash function is one whose output is indistinguishable from random noise. To see what I mean, let's say I have a one-bit hash function. You put in your message and you get out either a 1 or a 0. You can't predict whether a certain message will result in a 1 or a 0, though, unless you actually go through the entire process of hashing.
Now let's say I take a SHA-1 hash of the same message and discard 159 bits. I'm left with
Truncating a trusted hash to a shorter hash length is every bit as trusted as using a hash which was designed for that shorter length in the first place.
The converse is unequivocally not true. One way people like to create larger hashes is to first hash the data, then append the hash to the data and re-hash, then concatenate the two hashes together. It works, yes, but it's not an effective method. If you're using MD5, for instance, there are no more than 128 bits of entropy in your hash--even if you chain MD5 operations together to get a longer hash, you're still limited to 128 bits of entropy. If you want a longer hash size than the one you currently have, your choices are (a) chain your current hash, which will get you the size you need but at no additional security, or (b) use a different hash which is designed for the additional size.
The entire thing that got me started, was a downloaded Slackware ISO from an unofficial mirror, that had the correct checksum, but was hopelessly corrupt due to transmission errors close to my side.
If so, you're the luckiest person ever likely to walk the earth. The odds of any two messages hashing out to identical values are 1 in 3.4 * 10**38. The odds of this happening are 100,000,000,000,000,000,000,000,000,000 Schiffers to 1 against. That's steep.
(What's a Schiffer? Well, it's simple... out of the roughly 10**9 men on Earth, Claudia Schiffer is only sleeping with one of them--her husband. The likelihood that any given guy will be sleeping with Claudia Schiffer is roughly one in a billion. If you tell someone "the odds of this are one in 10**38", they'll just look at you blankly. If you tell them that it's 1<28-zeros>0 times more unlikely than them boffing Claudia Schiffer tonight... that, guys understand.)
Jeff--
Hate to be the bearer of bad news, but the book didn't work for me, either. But that's okay; you still get props in my book for writing the text that helped wrap my head around Pascal way back when. There, I'm done being a fanboy; the rest of this is all for Slashdotters without a clue.
Clue: when all is said and done, it doesn't matter if one particular book helped you or didn't help you. It doesn't matter if one particular kernel patch lets you use your FooBarBaz card, or if it just sets your mobo on fire.
What matters is what you do about it. If you read a great book on Assembly and then sit on your ass and don't do anything with that knowledge, then you might as well have not read the book in the first place. If you read a lousy book on Assembly and decide "dammit, there needs to be a better book," and then write that better book, then congratulations: you matter.
It's easy to say that the fellow who's actually doing the job could, should, be doing it better. (Hell, that sounds pretty much like John C. Dvorak's job description.) But it's a much harder thing, and better thing, to actually do the thing.
Like the old saw goes: shut up and code.
Really. It'll clarify things right up. Dollars to donuts there's a clause in there, probably called "Severability" or something to that effect, which states that "if any clause in this EULA is found to be in violation of the law, then it is null and void with all the other clauses still in effect."
Contracts aren't allowed to violate the law. A contract to kill someone isn't legally binding, because murder is illegal. If Microsoft wants to claim they get remote access at will to your boxes, then you get to say "neener neener neener, no you don't, under HIPAA I'm forbidden from allowing you that access".
The proper Microsoft response? "Oh. Well, we're sorry about that. All the other clauses of the EULA stick, though."
So go ahead, get Windows SP3, and then figure out some way to disable remote-root.
Oh, and one more thing--
FOR THE LOVE OF GOD, TALK TO LEGAL COUNSEL. WHY THE FSCK ARE YOU ASKING LEGAL QUESTIONS ON `ASK SLASHDOT', ANYWAY?! DO WE LOOK LIKE HARVARD LAW GRADS?!
(Sorry, just had to get that knee-jerk reaction out of my system.)
but from the day you get a virus, to the day you die, that virus potentially inhabits your body.
What's your point? Every human being is a colony of thousands of different unique bacteria. From the day you catch strep throat to the day you die, there are strep bacteria living somewhere on your skin. Just counting the number of different Escheria coli bacteria living in your gut would push me past Slashdot's space limitation. Just counting the number of different helpful, necessary bacteria would make me go on for paragraphs and paragraphs.
Sure, bacteria and viruses are with you for life. What's your point? That's why we acquire immunities.
... Look into Amantadine or its ilk, which are effective drugs for the treatment of influenza.
There aren't many antiviral drugs, and the ones we have are not especially effective, but it's incorrect to say antivirals don't exist.
This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.
No to the former; yes to the latter. The reason why this is a critical flaw in the Win32 API is because it means that in order for code to be secure it is essential that every existing piece of software be carefully checked to make sure it separates interface from back-end.
If you're talking about a large enterprise installation with lots of closed-source apps and a vendor turnaround time on security issues which runs into the months--and there are a lot of them out there, make no bones about it--then your boxes are at critical risk. In that case, you're essentially guaranteed to have at least one app an attacker can root the box through. Sure, it may be the app's fault for not separating interface and back-end sanely, like most of us who give a damn about good engineering learned (sometimes the hard way)... but it's also the Win32 API's fault for not requiring separation of interface and back-end [*], it's the Win32 API's fault for being so shoddily designed that an attack like this becomes possible in the first place.
A good analog in the UNIX world is sprintf(), which has been responsible for more stack-smash attacks than probably any other thing. Even though we have snprintf(), most people don't know snprintf() exists or why it should be used. Like the Win32 window exploit, our sprintf() vulnerabilities will continue for as long as people write stupid code. Like the Win32 window exploit, we can't fix the problem by removing sprintf() [**]. All we can do is provide snprintf() and hope and pray that people use it.
sprintf() is a flaw in the UNIX/C API which has led and continues to lead to attacks against the system, facilitated by stupidly-designed software which uses the call even when snprintf() is available. sprintf() can't be removed without breaking literally thousands of stupidly-written apps which depend upon it.
This Win32 attack is a flaw in the Win32 API which has led and continues to lead to attacks against the system, facilitated by stupidly-designed software which doesn't separate interface and back-end. This Win32 attack can't be removed without breaking literally thousands of programs.
Hey, guess what, world? We've found Win32's version of sprintf(). Oh, happy day.
My condolences go out to any security engineers working in Win2K land. You guys have got your work cut out for you minimizing this exploit.
[*] Not that I have any idea how they could do this.
[**] sprintf() is defined in C89. Good luck getting rid of it.
I've just grepped through vg_scheduler.c looking for `bind', `sock', `11', `RAW', `raw', and several others. I've come up with absolutely nothing. Admittedly, I haven't checked out the entire source--at 3500 lines, it'd take me several days to do a proper audit--but so far I haven't found any references to socket calls anywhere.
:)
Still, I would appreciate it if the maintainer could check out vg_scheduler.c and see if there's something amiss there. Thanks.
Bzzt--thanks for playing. Tritium is used to boost the initial fission yield; it's not used in the secondary stage.
... Why do nuke designers prefer fission reactions to fusion ones? When uranium splits, it does so by breaking into big and heavy atomic fragments (+46 charge). These atomic fragments carry away the majority of the reaction energy and dump it almost immediately as heat. By comparison, when hydrogen fuses to helium, the end product is a very light atomic nucleus and the majority of the energy of the reaction is liberated as neutrons, which can travel for quite some distance before giving up their energy.
A different set of compounds (lithium hydrides?) undergoes fusion, but this isn't the terminal stage of the nuke. The fusion is almost purely an incidental product--they're not looking to liberate energy from the fusion, they're looking to liberate neutrons. Specifically, real freakin' energetic neutrons which can induce fission in the U-238 shell surrounding the nuke. So essentially, there are three stages: a small fissile device at the core, then a small fusion stage, and then a really honkin' huge fissile stage which amounts for >90% of the liberated energy.
In fact, some of the early H-bombs used no hydrogen at all. If you get U-235 in the same shape as a softball, it'll spontaneously go supercritical; but if you get a cylinder of U-235 with a diameter slightly less than a softball, it can be arbitrarily long without going supercrit. To make it go supercrit, you use explosives to implode its shape, at which point it goes supercrit. The U.S. tested a 500kt "H-bomb" which was one of these purely fissile (i.e., "A-bomb") designs.
Basically, fission has a lot more bang for the buck.
If you really want to know more of the physical details behind nukes, check out FAS (here) and the Bremsstrahlung Effect.
jEdit (available here) is available anywhere there's a reasonably recent Java2 runtime. On Windows with J2SDK1.4, I've noticed that it takes a fair bit of time to load up, but once loaded it's acceptably snappy--it's never going to win points for speed, but it manages to not be noticeably and/or annoyingly slow, which is good.
It has bindings for something like 50 different languages, from Ada to SQL and every-other-thing in between. I have been exceptionally pleased with jEdit so far, at least on Win32. On UNIX, jEdit is a little slower, to the point where it enters noticeably and annoyingly slow, but it's still a defensible choice.
If you do a lot of crossplatform work (I do) and want to keep your basic work environment the same in both environments, you can do an awful lot worse than jEdit.
After graduating college I went to work at MCI, which was soon bought out by WorldCom. WorldCom is now in Chapter 11.
:)
After leaving WorldCom I went to work for McLeodUSA, which soon declared Chapter 11.
After leaving McLeodUSA I went to work for Yomu, which declared Chapter 7.
After leaving Yomu, I went to work for PGP Security, which doesn't even exist anymore.
Score: four for four.
Y'know, most people would be proud of batting 1.000. So why do I feel vaguely embarassed, foolish and ashamed?
... In the 70s, cops were beginning to discover that their service revolvers were generally pretty lousy pieces of kit. Most departments issued .38s, which are pretty anemic--many departments were still using .32 revolvers.
.38 Special service bullet would not get through the car door. And with any degree of obliquity, it bounced off the windshield. [Police] Lieutenant Turcus, Don Ward and I thought maybe we could design a bullet which would get through the car door, and get through the windshield and get the crook out of the car ..."
Some cops were complaining that they had pretty much no penetration. This caused some problems--well, hey. The inventor can say it better than I can.
Dr. Paul Kopsch, in a 1990 interview: "There were a couple gunfights, police versus criminal, here in Lorraine County[, Ohio]. The ordinary
Those three men--Kopsch, Turcus and Ward--invented an armor-piercing handgun cartridge, which they called the KTW (after their initials). The KTW was a bullet made of steel. When a normal lead bullet hits something, it'll deform and expend a lot of its energy as a result. Steel doesn't deform, and that lets it rip through cover easily.
Unfortunately, the bullet was so hard that firing it would destroy the barrel of the gun. Lead is soft enough to not damage the barrel; firing steel bullets will ruin a barrel. So in order to protect the barrel from damage, the KTW bullet was then clad in a light Teflon coating.
I've seen KTWs for sale at gun shows, but I think most of the KTWs on the market today are hoaxes. The KTW was never produced in large quantities and was only sold to military and law-enforcement arsenals--never to private citizens, nor was it ever sold directly to cops. The "KTWs" I've seen have been pretty shabby-looking things that the seller wanted $20 a round for, and promised that "of course it's real, don't you see the Teflon?"
In the military, "field expedient" is slang for "ugly hack that works surprisingly well". That said... during WW1 and WW2, the German armed forces didn't have anywhere near enough heavy machineguns to take on tanks. So the infantry made field expedient antitank rifles by taking 8mm ammunition (a very powerful round--at the turn of the century some people used them to hunt elephants), removing the bullet and then reseating the bullet, reversed, so that the blunt face would strike first. It gave the bullet the same effect as a metal die-punch; it punched neat, clean holes in steel.
Moral of the story: "pointiness" has never been a major issue with armor-piercing ammo. It's all about the sectional density.
Read Mark Bowden's Black Hawk Down for a good account of NATO SS109 ammunition (5.56mm semi-armor-piercing) used against human beings. At short ranges, such as the Rangers had in Mogadishu, the rounds punch very small, clean holes in targets--there were many incidents where an AK-wielding Somali had to be hit five or six times with SS109 before he was incapacitated, compared to the one-shot-anywhere-in-the-body that the Delta Force snipers enjoyed with their 7.62mm rifles.
The normal syntax everybody uses is not bounds checked and there is no way around that.
The syntax you use isn't. The syntax which I commonly use--and which is commonly used by professional C++ coders--is. Bounds-checking is one of the biggest wins of the vector ; discarding it, just because you can't be bothered to learn how to use the STL properly, seems exceptionally rash to me.
But anyway I see no difference than somebody saying "C is safe, just use this special at(pointer,index) function instead of [] and you will be fine"
There is no difference, save for this: a bounds-checked vector is part of the C++ standard library (via the STL) and is available on every C++ platform that's worth coding for. Even MSVC++'s shoddy STL implementation supports it.
Bounds-checked array access is not part of the C89/C90 spec (dunno about C99), and thus, if you want it, you have to do what the original poster does--bleed for it, via many different vendors.
The original advice I gave is still the advice I'm giving now. Use a different language. If bounds-checking is what you need, then use a language with support for bounds-checking built into the language.
C++ has this. C doesn't.
Oh? Look at the at() method.
.
vector does do bounds checking, but since it results in a (minor) performance penalty, operator[] (the normal method of vector access) is unchecked. You want bounds checking, use at()
95% of the time, it is simply bad software engineering practice to use operator[] within a vector . The only time it's really acceptable practice is when (a) you're operating under severe performance limitations and (b) you have some other guarantee you won't hit an out-of-bounds condition.
I can still generally compile and run five year old (since last revision) C programs without too much trouble. Frankly, five year old C++ programs have a habit of failing compilation on the first file -- too much change in the compilers.
:)
Hardly surprising given that five years ago there wasn't even an ANSI/ISO C++ standard. If you're using code that doesn't conform to the standard, it's not the language's fault if it fails to compile.
*snicker* Okay, find me a high performance Common LISP kernel.
I'm not a Common LISP hacker, sorry. But for non-C kernels, try BeOS (C++), try Oberon (Modula), try Plan 9... they vary from acceptable to excellent, and don't use C.
But if you really want a high-performance LISP kernel, I'd suggest looking at an (old) LISP Machine. Those babies were pretty sweet for the day.
Okay, you said Scheme was sexy, so I guess I won't flame you. :) (Hey, I warned you I'm a language zealot.) That said...
:)
:) I had a hard enough time wrapping my head around the C++ Standard; given the ANSI Common LISP standard is about the same size, I'm very reluctant to give it the focus that I'd need to in order to be a credible Common LISP programmer.
:)
:)
C has it's place. It's small and dark and should be avoided by most.
I don't know if I'd go this far. On one of my pages (here, or http://soli.inav.net/~rjhansen/c_relevance.html for the goatse.cx averse) I've got an essay--which I originally wrote intending it to be a response to a Web editorial I saw blasting every language that wasn't Java--which may be germane to the discussion here.
Short version: C has its place. Yeah, the place is small and dark and should be avoided whenever possible. But sometimes we don't get a choice of whether or not to avoid it, and when we're trapped in that small, dark place, C is your salvation. So I'm not going to knock C--but I will say that I generally avoid it whenever possible.
However, why not just use straight ANSI Common LISP
Didn't recommend it because I don't know Common LISP.
Scheme, on the other hand, has a very lightweight standard. It's easy to read, easy to understand. Sure, it probably misses out on some cool things that are in Common LISP, but I've yet to find an instance where Scheme has let me down.
Really--the only reason why I didn't recommend Common LISP was because I have a moral aversion to recommending languages I don't understand. If you like it, though, by all means, get down with your bad functional-programming self.
Warning: I'm a language zealot, so be warned that I'm utterly irrational and unamenable to the Sweet Voice of Reason. That said... :)
Use a different language. There are some things which C is appropriate for, but one of the things it's categorically not called for is when you have concerns about buffer-overflow conditions [*]. If this is a purely open-source, noncommercial project, do yourself and your career a favor: learn another language (one which doesn't have these sorts of problems) and write your app in that instead. You'll learn more, and you won't have to spend a dime on Purify or whatnot. If you go this route, I'd suggest Scheme; it's a beautiful LISP derivative.
If this is a commercial project, ask Management how married they are to C. In the overwhelming majority of cases, you can quietly substitute C++ without affecting the APIs one bit. Just wrap the external APIs in extern "C" and, inside the code, use C++'s beautiful vector instead of C-style arrays. Sure, you'll take a minor performance hit, but the increase in reliability will be well worth it.
Anyway, to try and give a (weak) answer to your question--instead of slapping a Band-Aid on the festering wound that is C memory management, you might want to think about doing away with the festering wound altogether. Use the right tool for the job--if C really is the right tool for the job, then fine, may God have mercy on your code. But if there are other, better, tools available... use them instead.
[*] OpenBSD manages to do pretty well with a C kernel, but that's because they're certifiably insane. It also impacts their dev cycle; they spend a great deal of time avoiding the pitfalls of C, so much so that it affects how much time they can devote to new development.
- Why does Java suck?
- Why is the answer you just gave wrong?
...Sounds counterintuitive, I know, but think about it for a moment. He wasn't asking me to give him facts; he was asking me what I thought, and then he asked me to think one hundred and eighty degrees opposite.The job was pure C programming, incidentally.
I got the job--apparently, my second answer didn't suck as much as I was afraid it did--and I wound up working pretty closely with my interviewer. He told me later that mostly what he wanted to see was proof of life in my cerebral cortex. There are lots of people out there who can sling code, but there aren't many people out there who have given time and effort to applying their analytic and abstract reasoning skills.
Slashdot is a beautiful example of a community of coders who have great code-fu, but tend to seriously lack in the reasoning department.
His name is Robert Hanssen.
Yours, very sincerely,
Robert Hansen
P.S.: Note that my last name is spelled with one S.
P.P.S.: Note that I'm not the infamous Alaskan serial killer, Robert Hansen, either.
:)
It's absolutely clear that you're on crack. Sorry, but I don't have time to waste getting trolled. Look at my prior response. The answers you want are in there.
Barring that, you could do something daring (gasp!) like, oh, reading the published literature. Somehow, though, I don't expect you've done any of that.
If somebody comes up with a new encryption algorithm, they shouldn't have to write code to support Evolution, Eudora, Outlook Express, so forth and so on.
They don't. RFC2440 (plus RFC2015, 3156, etc.) are extensible; they support a broad variety of algorithms and are designed to support future algorithms. RTFFAQ.
Likewise, somebody should be able to write a front-end for a email application according to a specific API and expect to see every available encryption algorithm thus far implemented available from within that email application.
Microsoft CAPI provides just this. GPG Made Easy (GPGME) also makes it almost trivial to incorporate crypto support into your application. (ObDisclosure: I'm working on C++ bindings for GPGME, so I'm biased.)
gnupg is great, but it presumes a single algorithm, doesn't it?
RTFFAQ. OpenPGP supports more algorithms than you can shake a stick at. For instance:
Wouldn't it be much better to make it easier to introduce new algorithms into the mix?
No. In fact, I personally dislike the fact that most PGP implementations (including GnuPG) support so many algorithms. Every implementation must support 3DES, and y'know, 3DES has a twenty-five year track record of turning brilliant cryptanalysts into burned-out alcoholic wrecks. Anyone who wishes to use AES256 for "security" is missing the point--the most trusted algorithms aren't the latest sexy things. The most trusted algorithms are the ones which are older than God and uglier than a Soviet worker's housing bloc.
If he gets to *assume* that the encryption being used is pgp-style, his workload is modest, he just needs to feed the file to the program.
The analyst is already going to know what algorithms you're using. The way you plan these things is to assume the analyst has access to tens of thousands of times more computing power than exists in the world, tens of thousands of times more memory than exists in the world, knows you better than your wife does, and knows every last detail of your cryptosystem except what your key is.
Assuming anything else is absolute folly.
And yes, I am a cryptographer.
Especially if there are hundreds if not thousands of algorithms out there, each and every one available to the common man for his use.
There are three symmetric algorithms I would trust my deepest secrets to. IDEA, 3DES and Blowfish. AES isn't on that list (won't be for another couple of years while peer review shakes out). If I'm a professional in this field, and out of the literally thousands of different symmetric block ciphers proposed over the years I can only find three which I recommend without hesitation, and the other 997+ range somewhere between interesting-but-flawed and fatally stupid, I really doubt that you--a layman with no experience whatsoever--will be able to intelligently choose the three good ciphers out of a field which consists, mostly, of spectacularly bad ones.
Something as trivial as taking the output of gnupg and exclusive-or'ing with a Erica Rose Campbell jpeg would add another - if - statement to the NSA's decryption code
Please go read this book: Codebreaking, by Rudolf Kippenhahn. You have a critical misunderstanding of how cryptanalysis works. It doesn't work by a series of "try this, then try that, then try..." It works by looking for redundancies, patterns, in data and then creating a mathematical model which can recreate those same redundancies and patterns. If you're XORing with a JPEG, you're not going to be making it appreciably harder to break. There's a lot of mathematical order in a JPEG.
I would bother responding to your last comment about why PGP is "weak", but really, it's clear that you're talking through your hat. I can believe that you're utterly clueless, or I can believe that you're trolling. If the latter, then HAND, IABT. If the former, then please go off and read up on the subject.
I'd suggest starting with David Kahn's The Codebreakers, from there Rudolf Kippenhahn's Codebreaking, then Schneier's Secrets and Lies. Only then start to work on Applied Cryptography and the Handbook of Applied Cryptography.
IAAC (I Am A Cryptographer).
:)
First, please note what the subject says: Twofish, Serpent and AES/Rijndael aren't as trusted. That's not at all the same as saying they're not trusted.
They are all excellent ciphers as near as anyone in the field can tell, but they are all very new. Many people in the field (myself included) are deeply skeptical of all new algorithms. Blowfish, by comparison, is about ten years old and has no significant cryptanalytic attacks against it. This makes Blowfish preferred over AES in the eyes of many cryptographers. (This is also why so many of us drool over 3DES. While it's hideously slow and inefficient, 3DES has been turning brilliant cryptanalysts into alcoholic, burned-out wrecks for 25+ years. That's amazing.)
Second, I am not aware of any cryptographer who recommends Serpent or Twofish over AES. When Rijndael won the AES selection, every cryppie in the world who wanted to make a name for himself started to throw himself at it. Hence, Serpent and Twofish have been exposed to much less cryptanalysis than AES/Rijndael. Serpent and Twofish aren't bad ciphers, but given the existence of AES, every responsible cryptographer I know strongly recommends AES over Twofish and Serpent.
Third, if I recall correctly, the OpenBSD people like Blowfish because Blowfish is about as agile as a brick. Attempting to break Blowfish by brute force is a really painful thing to think about, because setting up a new key is computationally expensive. By comparison, AES is a very agile cipher.
Fourth, it's true that AES is a blazingly fast cipher. But Blowfish is no slouch in this department, either.
So what you wind up with is Blowfish (a) is key-clumsy, which OpenBSD wants, (b) has survived almost a decade of rigorous cryptanalysis, (c) is quite fast.
OpenBSD wouldn't get any real benefit from switching to Blowfish. Why should they change?