Slashdot Mirror
On Choosing Encryption ...
A crafty owl hooted this query into my ear: "How do developers decide which encryption they are going to use? If you do a search for 'blowfish' on freshmeat.net it turns up 14 hits. Blowfish isn't even an AES candidate. Counterpane's submission to the AES contest -- Twofish -- turns up a meager five hits, only two of which are really applications. Serpent, another strong AES candidate isn't used by any applications listed on freshmeat. OpenBSD can use Blowfish passwords. Not Serpent or Twofish but Blowfish. Why? How do the developers decide which to use? Do they actually evaluate the different candidates? On what criteria are the decisions made? Security? Speed? Ease of implementation? Is it based simply on what everyone else is doing or which algorithm's author is more well known?"
First, I have to say that choosing Blowfish, Twofish, IDEA, 3DES, Serpent, Rijndael or something else, is not the first, nor the most important question, in a cryptograhpical product. There's *much* more to cryptography than choosing a symmetric cypher, and it's very easy to use a great algorithm in a broken way. As the saying goes, security is a process, not a product. And within a product, it's a protocol, not an algorithm. You need to design the entire way that the various clients and servers will talk, to be secure: how to choose and agree on the keys, how and when to rotate them or generate new ones, where to get your crypto-strong random seeds, using the right cyphering modes for the situation (ECB is not usually a good idea), whether to use a block or stream cypher, whether and how to interface to public key crypto, how to fend off replay attacks, and so on and so forth, the whole protocol. Only when you've figured out all this stuff, does it start to make sense to evaluate individual cyphers, for speed and perceived security. There, again, the general idea for safety is to go for something that has withstood serious analysis for a long time. I wouldn't count out Blowfish just because Twofish is its successor; Twofish looks very impressive, but has been around for a much shorter time. Right now I'd still trust Blowfish or 3DES better.
The people who make decisions on important things like this don't know enough about what's going on. Judges make laws that are completely stoooooopid because they think the laws of the real world still hold relevance on the internet. Many people believe that if a cipher has been around for 5-10 years without any major attacks, it's safe. This isn't true. If you look at the AES finalists, they all employ 3 fundamental properties: a) input/output XORing b) a linear operation in each round c) a differential operation (S-box) in each round Because of the 3 biggest attacks on ciphers: 1) key recovery (basically knowing the input and output to the first and last rounds without even knowing the key is not good, so we XOR the input and output) 2) linear cryptoanalysis (guess what kinds of operations this is useful against? :) ) 3) differential cryptoanalysis (guess what kinds of operations this is useful against? :) ) Many of the ciphers used in BSD/Linux aren't using this for two reasons: 1) Script Kiddies can't write the code to attack these ciphers nor employ the HW horsepower to do it. 2) The AES is coming. When the standard is announced (not barred IP problems overseas), you can bet freahmeat and replay will have C/ASM/Java source code for many platforms. I hope this answers a lot of your questions. BlowFish (or even flipping the bits of you data!) is enough to keep the lazy hacker from getting at your system. Anything beyond that and you're investing efforts to keep 'advanced' hackers/corps away. Please feel free to drop me line at work jean-luc.cooke@entrust.com. I'm a cryptographer who's implementing the AES here at Entrust Tech.
Right now, the primary criteria for AES candidates is security. After that, they are evaluated based on implematation issues (how scalable is it, will it run in a smart-card up to a mainframe, how easy is the code to implement, etc). But, those other issues are irrelevant if the algorithm has a hole, so that's what they are looking for first.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
The first telephone ever created was totally useless, and the second was only barely better.
The usefullness of any communication device, whether encryption or telephones, is proportional to the square of the use.
Serpent, another strong AES candidate isn't used by any applications listed on freshmeat.
Serpent is available in the internation version of the linux kernel, as is blowfish, IDEA and others.
Great for loopback encrypted filesystems.
Maybe the kernel isn't an app. but serpent is there at least.
Try kerneli.org.
Even a good crypto algorithm won't protect you from a number of possible mistakes (failure to wipe buffers, bad pseudo-RNG, bad method of selecting keys, etc.). Availability of the encryption method as a library under a license that will permit its use in a free software project would be an important factor. With some projects, reimplementation from scratch is an option. For others, it isn't all that desirable.
The net will not be what we demand, but what we make it. Build it well.
Well, not quite irrelevant. It should be one that has been bounced on for a few years by serious cryptanalysts with no serious (i.e. non-academic) weaknesses found.
Triple DES is *probably* strong and has stood years of abuse.
RC4 is also thought to be strong, and is in the public domain whether RSA like it or not. It has the advantage that it can be coded in about 15 lines.
Blowfish is also probably strong. So are *all* the AES candidates. I like Rijndael with 18 rounds and Twofish (I'm betting on Twofish becoming the standard). Serpent is also nice.
But all this is irrelevant. *All* the algorithms I have mentioned are strong against any meaningful attack, and unless you are encrypting gigabytes they all perform well enough on modern hardware.
None of this matters if your implementation sucks. What really matters are things like key generation, key management, ensuring keys are never stored anywhere inappropriate (like on a disk - how are you going to control swapping?), enforcing strong passphrases (this is very hard). Then there's system security. What if someone patches a binary to email them the key during encryption?
Basically, spend your time hardening the implementation. That's where you will be attacked.
Also, don't code them yourself (except for fun) - there are a number of free (usually public domain) implementations of these algorithms. These have been peer-reviewed and tested. The chance of blowing the strength of the algorithm with a stupid coding error is too high to risk.
There's two major points to make.
1) No one knows how to show that any useful block cipher is "strong." The best we can do is show that a cipher resists some of the attacks which worked on other ciphers. This doesn't say much about possible future attacks.
Two major responses to this. The first says to use only block ciphers which have received lots of analysis. The theory is that lots of eyes will pick out flaws. By this metric, DES is the best cipher out there, and 3DES is the way you should use it.
Beyond that it's a judgement call. For instance : Blowfish vs. the five AES candidates. Blowfish has been around longer, but nearly every block cipher expert in the world has been hammering on the AES candidates. Which do you pick?
(personally, I would go for the final AES)
The other major response, expounded by Terry Ritter, is that you should change ciphers often and use multiple "stacks" of ciphers. The theory is that if you use a lot of ciphers for a short time, you make it harder for an adversary to concentrate his efforts on any one of them. This seems to be a minority opinion (at least on sci.crypt), but it should be considered.
2) In real life, most systems die a horrible death NOT because they used a weak block cipher, but
because they took a very good block cipher and used it in a stupid way.
In my opinion, most of the concern over the strength of this or that block cipher is blown out of proportion. YES it is important, but even more important is analysis of the protocol in which you're going to use the cipher. Just because you use 3DES does not mean you're "secure" (can you even define "security" in your application, to start with?)
I should mention here that I'm not a block cipher expert, and I don't find them easy to think about. I prefer public-key crypto (but I'm not an expert there either
You can try to work with the first point by thinking about who your adversaries might be. Do they have access to secret research on cryptanalysis which is likely to be better than what's publically known? Do they know the public literature better than you do? How valuable is that data you're protecting, and what happens if your protocol fails? (do you know how it could fail?) The more valuable the data, the more paranoid you should be about your adversaries, and the more careful you need to be in your choice of primitives.
In any case, design your protocol with a generic "block cipher" in it, so you can swap out whatever you have and put in something else later. This may entail adding a negotiation step so both parties use the same cipher -- make **sure** that this is authenticated somehow! (or you'll end up like SSL 2.0)
and then start worrying about the bigger protocol issues...
Dilbert: "You mean it does nothing useful and isn't your fault?"
Vendor: "Is there someone less knowledgeable I can talk to?"
Open Source. Closed Minds. We are Slashdot.
There are several issues here: peer review, architecture, algorithm and implementation.
Peer Review: At each step in the process (architecture, algorithm, and implementation), you should publish your ideas for criticism by experts. slashdot, Advogato, the Cypherpunks mailing list, sci.crypt, and the Crypto++ mailing list might (or might not) be good places to find such people.
Architecture: You should do a public key architecture where every participant has a public/private key pair and the public keys are used to sign and encrypt symmetric keys that are then used for encryption and authentication of messages. There are three feasible architectures for public key distribution. You have to choose one based upon your threat model. Almost all realistic threat models should be handled using the first option: "opportunistic public key distribution". If you don't have a threat model in mind at all then you might as well use the first option. If you do have a threat model which precludes using the first option then I'd like to hear about it -- you must be doing something very interesting indeed.
Algorithm: You probably just want Triple-DES and RSA (after September of this year, when RSA becomes free of patents) or else Triple-DES and Diffie-Hellman. It should be easy to switch to a different symmetric cipher later after the new ones have been peer-reviewed and tried by fire, but for starters you want the old standbys that have already withstood the test of time. They will be fast enough for you at first and if you need more speed later you can switch.
Implementation: Your first choice should be to use an extant implementation. Don't try to implement it yourself no matter how simple it looks. Satan's Computer is deceptively subtle to people who are used to hacking Murphy's Computer.
I prefer Wei Dai's Crypto++ library, but that is because I'm doing complex non-standard crypto tricks. If you just want simple "encrypt/authenticate a stream" functionality then use a TLS implementation like OpenSSL. By the way, if anyone wants to make Python wrappers for Crypto++ (possibly with the aid of Swig) then I would love to hear about it!
Okay that's my advice. Specific pitfalls to avoid are: skipping peer-review, trying to design a generalized perfect public key architecture to handle all possible threat models, using a newfangled or non-standard algorithm ("In open source hackery, newfangled is good. In crypto, not."), and implementing it yourself instead of using a library.
Please direct all flames and accolades to: zooko@schowto.mad-scientist.com
Blowfish is used in a lot of software implementations because it's a well-designed, trusted algorithm. It's been out for a number of years, and the best minds in the field have tried to break it-- and come up with next to nothing.
It's also well-suited to software implementation: it uses operations on 8-bit bytes, which are easy to write in C and assembly. As well, it both offers a larger key size than DES and runs more quickly. OpenBSD probably uses Blowfish passwords for at least one of these reasons.
RC6, Serpent, Twofish, Rijndael, Mars-- they probably aren't bad algorithms, really (some academic attacks against Mars and RC6 aside). The problem is that they're all so new that programmers and cryptographers are somewhat wary. After all, Magenta and FROG were also candidate algorithms, and they were broken within weeks-- and not just as academic attacks, either.
Choosing an algorithm is not the cut-and-dry process many people would think. An ssh server serving thousands of simultaneous clients, for example, would NOT do well to use software implementations of Serpent, which is one of the slowest AES candidates in software. But if you're looking at using an algorithm in an FPGA design with limited space, Serpent may be a good choice-- it's small and FAST in hardware.
Basing one's choice of ciphers solely on the reputation of the author is not a good idea. Ever heard of MacGuffin? Schneier designed it, Rijmen and Preneel came up with an attack on it.
Really, a good software engineer will choose the cipher based upon the needs of the system (speed, security, size, and external conditions). If a cipher meets the proper criteria, it will be used. If not, it doesn't matter what claims to fame the cipher's designer has-- it shouldn't be used.
FEAL is in fact the ubiquitous whipping boy of cryptanalysis. I don't have the references in front of me, but Schneier describes a series of conferences in which people broke FEAL variants with more and more rounds in shorter and shorter times. I think FEAL is the cipher that Adi Shamir published a break of one variant of the day after it was presented.
Schneiers "Self-Study Course In Block-Cipher Cryptanalysis" mentions that any time a novel CA method is proposed, it should be tested by first trying it on FEAL.
Sure, you can laugh at the dumb saps who invented it--except that they were highly respected mathematicians with decades of total experience in cryptography. Sort of a reality check for those of us who look at cipher designs and say "Hey, I could do that."
spawn_of_yog_sothoth
Jeff beat me to it
OpenBSD can use Blowfish passwords. Not Serpent or Twofish but Blowfish. Why?
Password checking for user authentication is performed in software on a general-purpose computer. Brute-force password cracking can be carried out on specialized hardware. Algorithms that run much faster in hardware than in software are bad choices for password hashing.
The design of Blowfish makes it difficult to speed up in hardware. Twofish and Serpent, on the other hand, were designed for fast hardware implementation. Blowfish is also more scalable, which lets you keep up with Moore's Law.
A paper (PostScript format) on OpenBSD's rationale for choosing Blowfish can be found here. A short presentation is here.
------
------
You are in a twisty little maze of open source licenses, all different.
...you forgot "loses laptops holding classified nuclear weapons data."
Have a nice day.
--
Simon.
However, I beg to differ that no apps on Freshmeat use Serpent or other newer encryption techniques. The International Kernel Patches include Twofish, Serpent and many other newer algorithms.
(The source for some cool-looking Elliptic Curve algorithms is out and about, too, on many crypto sites.)
As for not having been battered "enough", the AES algorithms have gone through more than a little stress-testing. Sure, it's not the same as a million eyeballs and a million more skript-kiddies, but it's not feather-weight, either. Elliptic Curves have been moderately stress-tested, too, and have proved resiliant.
HOWEVER, stress-testing is NOT the same as mathematically proving. The rigors of proof don't depend on case-by-case study, but on the logic itself. Stress-testing is all fine and dandy, but it can only tell you about the exact case being looked at, under the exact conditions the looking was done. An algorithm that depends on such testing could ALWAYS be broken tomorrow, no matter how much prior testing it's had. As such, the testing has no credibility in the "formal" sense, but is merely indicitive of the real strength.
IMHO, the habits of the mainframe & Old IBM age MUST be kicked, if cryptography (as it exists) is to survive, when the Dinosaurs it is copying are either dying, dead or fossilised.
Survival, in a fast-paced industry, is not about "playing safe", or cloning the has-beens. It's about being new and creative. Scared to move too quickly with algorithms? Use dynamically-loaded encryption modules! Being cautious CAN include charging ahead, when the greatest enemy (Old Age) is cutting down everything behind you.
Given the choice of the Grim Reaper or a Skript Kiddie, I'd rather tackle the worst some pimply 16-yr-old can throw at my code. Dead Code, however good, is still dead, and isn't going anywhere.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
As for why Twofish is not yet widely used -- it's a new cipher. Only two years old. Most of the programs you cite as using Blowfish pre-date Twofish, and it is only recently that I would trust Twofish (after every reputable cipher designer in the world has had two years of trying to crack Twofish). I can't say the same about Serpent, BTW, various AES commentators have nasty things to say about it (mostly that it needs more rounds to ensure proper bit diffusion, which would erase its speed advantage). About all that's been said bad about Twofish is that it is rather klunky and ugly compared to the more elegant ciphers in the AES contest (but a secure, fast klunky!).
Disclaimer -- I did the Twofish module for Python... probably am biased :-).
-E
Send mail here if you want to reach me.
Of course, it's easy to do a stream cipher wrong, and you must change your key for each message transmitted in order to prevent known-plaintext attacks. (That is why most stream ciphers require an intitialization vector, which is basically a random part of the key used to ensure that the same key isn't used for two encipherments). You're much better off using something like RC4 where that kind of stuff has already been thought of and taken care of, or using a cipher feedback mode for a block cipher, which basically uses the block cipher as the bitstream generator. See Bruce Schneier's "Applied Cryptography" for more info.
_E
Send mail here if you want to reach me.
I'm surprised that more people aren't using Skipjack. The algorithm is relatively simple and doesn't need much memory. I've read that it has been approved for the protection of SECRET information in the Defense Messaging System (DMS) by the NSA. As far as I know, this is the only public algorithm that has received the NSA's approval for the protection of classified information.
Mea navis aericumbens anguillis abundat
Did you create that leisuretown.com thing? It is one of the most sarcastic things I've ever read. If you created it on company time, it's even better.
If anyone has 30-45 minutes to waste like I did, go read it.
-Barry
There are no magic bullets. Whether you pick a complete cryptosystem or build your own system from components, you're still going to have to exercise due dilligence.
-E
Send mail here if you want to reach me.
I'm an InfoSec consultant IRL, but this is not professional advice. (And soon I'll be a full-time paid PGP hacker. Yay. )
:)
:) I wouldn't use it in a production system, but when it comes to noodling around with novel crypto (to quote Enoch Root), GOST is my favorite.
There are literally dozens of perfectly good ciphers out there. Blowfish, 3DES, Twofish, IDEA, RC2, RC4, SEAL... the list goes on and on and on.
No two ciphers are exactly identical. Cipher selection is based on these minute tradeoffs between ciphers. For instance, 3DES is solid as a rock but is quite slow. I wouldn't use 3DES to encrypt a high-bandwidth realtime communications link, obviously, although I would readily use it to encrypt a 100k file on a disk.
Blowfish is very fast, but key setup is slow--so I wouldn't use it in an environment where keys would be changed frequently.
IDEA is strong and fast, and is well-suited in a whole range of endeavors. It's also encumbered by patent, though, and some of my clients don't want to shell out money to Ascom-Tech A.G..
... In the final analysis, cipher selection is dictated more by secondary factors than by cipher security. There are so many strong ciphers out there that we can engage in personal preference and pay attention to "other details", like performance. It's pretty simple stuff, really. I have a harder time selecting a mode for a cipher than I do selecting a cipher.
My own personal fave cipher is GOST, mainly because you get retro-cool points for using it.
Most applications are still using triple-DES (3DES) because it's been around so long and analyzed thouroghly. This doesn't mean it's the most secure or has the best performance, but lots of developers just want a "proven" technology.
Twofish looks like it's done pretty well against the competing ciphers, but my guess is a new cipher will only catch on if it's widely deployed. For example, if Netscape and IE both support Twofish for secure websites and Web Devlopers start using it, then it'll boom. But people need motivation -- right now consumers aren't complaining about the security or performance of 3DES, so it's sticking around...
Well, different encryption technologies are better suited to different applications. Some are designed for streaming media vs files on your HD for instance, or for file compression. However, I can see the point that you are making is quite different in nature from that. In my point of view, people should pic encryptions that fit the following criteria.
1) Usful. You want an encryption that is actually worth using. Not worth encrypting something if it can be cracked without any effort.
2) Suited to the application, as I stated above.
3) Available Internationally (nobody wants to be stuck with a product that gets you arrested on export).
4) Open spec (you want it to work with other products.
** This list is in order of importance.
On top of that, your implementation should take the encryption seriously. Putting in a security measure, and then allowing someone to circumvent that is about as dumb as it gets. One example of this is window's passwords. It's case sensitive in Windows NT, but not in 95, on the same network. This means that, if your computer at least claims to be running Windows 95, you can cut the number of keys you need to check in order to crack into the network exponentially.
Just my $.02
Eh...
On a product I worked on until recently, encryption selection was done using the following formula:
(sensitivity of data)+(ease of implementation) = (arbitrary decision about how we felt about securing stuff)
An example, we would use a form of blowfish encryption for a configuration file that's super easy to decrypt. Because of the nature of the product, the content would be sniffable when being sent upstream anyhow, so we made the encryption just strong enough to resist a notepad surfer.
On another product, however, we were sending up private data. Now, it was usual registration data during install, but we had real privacy concerns, so we looked at our options and chose SSL because it was easy on our part to implement, but unlikely to be easilly sniffed/decrypted.
Conclusion of ramble: Whatever's easiest to implement with some allowance for the dsecurity of the data.
Security through obfuscation is coming to a close, so this method won't work much longer.
I find a few things are important in choosing an algorithm. From a math point of view, the optimal solution is NOT to go with the latest-and-greatest algorithm. Serpent, Twofish, and other new algorithms might be all fancy and wonderful, but they simply do not have the history behind them. They don't have years of continual battering that others do. 3DES, for example, has been around for ages. It has been beaten to death by cryptanalysts the world over, and it's still holding up very well. THIS is what makes someone confident in their selection of crypto algorithm. Sure, 3DES may not have a bazillion bits, but there are most likely no bone-headed mistakes in it. Serpent and Twofish probably don't have any either, but there just isn't the history there to say for sure. Encryption algorithms are like wine... Over time, some sour, and some develop into mature, robust, beautiful works of art. In this light, Blowfish becomes attractive. Its advantage over Twofish et al. is age. Its advantage over 3DES is its freedom. This is part of the reason why Blowfish is ubiquitous in the real world.
In any field, find the strangest thing and then explore it. -John Archibald Wheeler
The entire world eats, sleeps, breathes, and shits in plaintext, yellow-stickies, credit card numbers on disposed reciepts, telnet, rsh, chatty cordless phones, unencrypted mail, chatty websites, open scripts, broken permissions, pages left on the xerox, unlocked files, and phone numbers given to nasty skanks at a dirty bar that has a scan of your driver's license.
The only real way to keep your information private is to be a boring ugly uninteresting fucking nobody with no life and piece-of-shit computers on crappy dialup lines with no money, bad credit, and massive personality flaws. I got those bases covered!
And if you're reading this, you probably do too.
DontBlow.com is an absolute good.
Twofish isn't all that more difficult to understand than Blowfish, because it's basically just Blowfish with a few improvements and a change in block size as per AES standards.
The key to the popularity of Blowfish over Twofish is merely that Blowfish has been around for many more years. That would normally mean that the cipher is more "proven" than Twofish and others, except that the AES candidates which are still in the running have defied more cryptanalytic attacks than most other ciphers because of the barrage of attacks engendered by the AES process. This leaves the fact that Blowfish has been around longer and therefore gotten into more stuff as its only advantage.
Blowfish and Twofish are both very, very fast on 32-bit microprocessors, which is why they're generally the best contenders for inclusion in crypto programs. Triple-DES, on the other hand, is ungodly slow anywhere but in specialized hardware--because it was meant only as a stop-gap measure for when the 56-bit key length of DES became too short. As for AES candidates with potential, MARS is slower than Twofish but has an extraordinary security margin. It's the only cipher which uses all forms of cryptological tranformations, and therefore should be resistant to most forms of attack if not all. MARS is the one AES contender I'd trust as much as Twofish.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
-E
Send mail here if you want to reach me.
This is not true. More mathematical cryptosystems can be proven to be as secure as some difficult math problem (factoring, discrete log, etc.). Why not use these provably secure cryptosystems (Rabin, Goldwasser/Micali, etc.)? Because most of them are significantly less efficient, and because many outside of the theoretical crypto community probably don't even know of their existence. (There seems to be a large lag between the powerful systems invented by theorists, and what is implemented by any software developers)
The more efficient ciphers actually used in software tend to be of the "scramble" variety involving specific S-boxes full of random looking numbers and lots of connecting XOR gates. It is hard to prove anything formally about these ciphers since they are not based on number theory or formal mathematics. In regard to these ciphers not based on pure math problems (*fish, Serpent, 3DES, et. al) public scrutiny is the best hardening factor.
I wouldn't necessarily say that Blowfish is more secure than Twofish or Serpent just because it is older though. The AES candidates have probably undergone a lot more scrutiny than the non-AES candidates since they would potentially replace DES as a standard. This makes the crypto community focus more intensely on them then some arbitrary cipher.
As far as the original question on choosing encryption: I think the biggest issue is quality of existing implementation in libraries. I am a software developer that works almost exclusively in a crypto/security setting, and the first thing I look for in an algorithm is for it to be part of a tested, well-documented crypto library with a reasonable license (like openSSL perhaps). This is for two aspects of the same reason: crypto algorithms are not what people break when they break security systems.
Without a good library, I am either using a broken library or rolling my own. Rolling my own is riskier than using one that has been extensively tested by others.
Whether I use 3DES, IDEA, RSA, etc. is probably less important than the other parts of my code when I am writing security-related tools. Better to focus more time/energy making sure that all of my bounds checks are in place, no dangerous races exist, etc. These are what attackers use to break into systems.
One final note on the importance of "well-documented" libraries. The reason I emphasize this is because inherently libraries, more than any other software, are code to be reused. Good documentation facilitates reuse, and it makes things safer. I had an unfortunate experience with a poorly documented C crypto library (an old CryptoLib) that called free on the pointers passed to it as arguments without any indication whatsoever of this in the doc. The result was a program that would crash suddenly/mysteriously because of later accesses to that freed memory. This kind of thing could have been prevented if the doc had included the salient fact that my arguments were being freed (since this is hardly an expected behavior).
I agree 100% that Triple DES is a good algorithm to go for unless you have some reason not to. The main reason not to, of course, is performance; it's also a big, complex algorithm, so you don't want to try and implement it yourself. But if you don't need blistering performance out of your crypto, and you don't plan to implement the crypto yourself (the wise choice) then go for 3DES.
Freedom is *not* an issue with 3DES: you have all the same freedoms with it as you do with Blowfish. Blowfish's advantage over 3DES is substantially better performance in software, and greater simplicity. It's probably a good second choice for this sort of thing; it's pretty much the oldest standing unencumbered strong block cipher designed for speed in software, and thus among the most trustworthy.
Once the AES winner has been around awhile, this questions will be moot; everyone will use the AES for most applications that don't require some special other choice. The concensus at the last AES conference seemed to be that none of the AES candidates would be properly broken short of an extraordinary revolution in cryptanalysis that might leave none of today's ciphers standing; caveats apply to Rijndael (which some wanted extended to 18 rounds) and to RC6 (which just doesn't leave a lot of people with warm fuzzies on the security front).
Of course, the question arises whether it's a block cipher you really need at all. If you're doing bulk encryption, you need a stream cipher, and a block cipher in a chaining mode is just one way to build a stream cipher. Try asking a much more specific question on sci.crypt and see what advice you get. Normally the answer is that there's already a standard for what you're trying to do, and you're best off using what it mandates.
Ask me a more specific question and I'll try and give a more specific answer...
--
Xenu loves you!
Someone in the audience with me actually pointed out that twofish would be faster, and the authors of the paper replied that that was precisely why they didn't use it.
It's an interesting paper, nonetheless.
-Jeff Evarts, who has forgotten his Slashdot password
One thing people can do is use a cryptosystem instead of a single algorithm. This makes implememtation much easier, since people don't need to become familiar with Applied Cryptography and the literature on crypto. This is why people like SSL--it is free outside of the US, and will become free in the US on September 20th, and is a complete system belived to be secure.
One of the nice things about crypto research is that most of the research papers out there are freely available on the internet.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.