Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Privacy

On Choosing Encryption ... 147

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?"
This discussion has been archived. No new comments can be posted.

On Choosing Encryption...

Comments Filter:
  • 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.
  • In short, people choose their encryption based on what they know. Or what they think they know.

    Encryption is hard to understand. You can't judge how strong an encryption is by its keyspace: a newspaper-style cryptogram has a larger keyspace than DES. The only way to find out how good an encryption system really is, is by trying to break it.

    Therefore, we go by what experts in the field say. Or people that sound like experts. (I know one very charismatic person who has been making over $200K/year, calling himself an encryption expert, who has done little more than read Schneier's book. But he has the charisma and the high self-confidence to pull it off.)

    As programmers, what should we do? It sounds like you're doing the right thing: researching. I recommend that you search not only the Internet, but also your local college library for magazines such as "Cryptologia" and "The Journal of Cryptology". (If you want information on-line, I recommend DMoz's site [dmoz.org] for links to more information.)

  • The first telephone ever created was totally useless, and the second was only barely better.

    However, at the same moment when the second telephone was made, the first one magically became useful. The same goes here too.


    --
  • Hey,

    That's an interesting question. My mersonal favourite algorithm is IDEA, because it's reasonably fast, secure and it has a good acronym. If you're writing your own program, I suggest a look at the Scramdisk [clara.net] webpage. They have a nice bit about algorithms and choosing between them.

    If you're presenting the question as an irrelevent question, like one might ask 'What does the scroll lock button do?' I'd say most programmers center thier choices on

    1) If it's ever been broken.
    2) What algorithms they know.
    3) Key Length.
    4) Speed.
    5) Anything else.

    Angorithm, however, is irrelevent in the big picture. The majority of effective attacks use things like buffer overflows and reverse engineering, not brute-force attacks, just like the easiest way of hacking is bribing employees. Well, that or threatening them [pointlesswasteoftime.com].

    Just my $0.02

    Michael Tandy



  • by Anonymous Coward
    It's also patented by the NSA, isn't it?

    Besides, the government's full backing of an algorithm is not always such a good sign. If they don't use it themselves, it's flawed. If they do use it themselves (like with Skipjack), remember that their process is closed and that the government doesn't exactly have a brilliant track record when it comes to doing smart things.

    Barring that, take a look at the facts:

    * Attacks only get better with time.
    * Skipjack has been public for about two years, and we've already broken 31 out of 32 rounds.
    * Cryptographers don't trust new algorithms or algorithms with good attacks. Skipjack fits both those categories.

    It should be secure for most people. But like the post above said-- "warm fuzzies" are important, and using an NSA algorithm doesn't give people warm fuzzies, even if the NSA *does* use it for the DMS.
  • This just isn't any kind of an advantage. All the gains that you list for having a slow key schedule can be gained with a few extra key bits. If you really can't get a few extra key bits for some reason, it's no problem to artifically slow the key schedule; just hash the key a few thousand times. With a construction like abreast Davis-Meyer, you can even use the block cipher to do the hashing. Fast keyschedules are a Good Thing and there's nothing to be said for deliberately slowing them down.

    There may be resasons for choosing Blowfish rather than Twofish, but this isn't one of them. Actually, I think there are only three:

    * you don't trust any cipher less than five years old

    * you have to have a 64-bit block, despite the advantages of a 128-bit block

    * you want something easier to code
    --
  • The type of encryption used should be app specific.

    Why choose one encryption algorithm over another?
    Well, its usually for the same reson an API is used over another.

    Evaluate your needs, ordering them from highest to lowest -- then figure out which algorithm is the best for your project.

    For example, it would be stupid to choose an algorithm with a crazy/lengthy interactive protocol for an end user who's computer savviness equates to clicking on his the Netscape window on an iMac. All they want to see is the nice padlock.

    If speed it the biggest concern, then sure, speed is important...but it completely depends on the app, and the developer.

    Speed, security, export status, length of time data must be secure, implementation, ease of use/transparency, reputation, etc are all factors an engineer must consider.

    Customer specification is an overriding factor as well...and sure, some Pointy Haired Boss' out there will tell you to implement something they read about in Newsweek.

    You mention Counterpane -- I'm not sure weather or not you're familiar with Bruce Schneier's book, Applied Cryptography. Perhaps there's an updated edition with Twofish info. In any case, this is all discussed (in great detail).

    I highly recommend reading this book if you're al all interested in cryptography. Good read, he explains everything in a very simple manner that even I could understand and use to write some pretty cool stuff.

    Good luck!
  • None of the AES "top five" have fallen to an attack, even a wholly impractical attack, that breaks all rounds of the cipher. All of them break if you reduce them to few enough rounds. I don't know why you name MARS as subject to these attacks in particular, though "MARS attacks!" is a great title for a paper; the two that look shakiest at the moment are RC6 and Rijndael (though note that all of the designers are still happy with their current designs).

    Oh, and fast implementations of Serpent take up more FPGA area than you might expect - in fact, more than RC6, despite the multiply in RC6. This is because it makes sense to unroll the loops eight times to hit the "sweet spot". However, it's perfectly fast in software - not quite as blinding as the other AES candidates, but plenty fast enough, especially on architectures other than the register-poor x86.

    MacGuffin was proposed by Matt Blaze and Bruce Schneier; it was never meant for serious use, but to encourage analysis of a new structure, the GUFN (generalised unbalanced Feistel network).
    --
  • by Anonymous Coward
    Somehow, Warm Fuzzies became a measure of how confident a given security/crypto specialist feels about a particular algorithm. You'll see it in the PGP source, you'll see it in Schneier's Applied Cryptography, and in various other online sources: "Although this algorithm is relatively new, it gives me warm fuzzies." "This extra layer of checking isn't strictly necessary, but it gives people warm fuzzies to do it."

    The bottom line is that for low security, it doesn't matter, for medium security, there's plenty of easy solutions, and for high security, noone* really knows what the opposition is capable of. (* except perhaps a certain employer of large quantities of mathematicians)

    As long as it passes the obvious tests -- which most algorithms in use do -- there's nothing much to differentiate crypto algorithms in terms of security except for Warm Fuzzies. There are other criteria, of course, speed, simplicity, patent issues, etc, but otherwise it comes down to your gut feelings.

    Personally, things that give me warm fuzzies include: Being straightforward, resistant to both older and newer forms of cryptanalysis (linear, differential, etc), decent keyspace (ie not DES), a certain amount of age (I don't trust brand-new algorithms), no known reduced-round attacks, ease of implementation, lack of patent encumbrance, and also the opinions of People Who Really Really Know Their Stuff.

    For me, CAST and ElGamal met the criteria. TwoFish passes on everything except age, I will probably dabble with it if it survives awhile with no cracks or flaws.

  • I believe that all of the AES candidates have to provide C implementations as part of their submission package. I think they also have to be IP issue free. Twofish and Serpent are every bit as "free" as Blowfish.
  • by Anonymous Coward
    I always use Babelfish [altavista.com]. Just translate your English to German, then back to English, then to French, then back again, then to Spanish and back, ditto with Italian and Portugese and BLAMO!!!(tm), you have text that NOBODY can read. True, you can never get the original text back, but that just makes it that much more secure.
  • Dungeon Dweller (in another post) made a nice list of important criteria for picking encryption algorithms. According to DD, the algorithm should be: 1) Useful. 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 Not only should the specs be open, but also the source code. It helps to know that NSA Skipjack is an 80-bit stream cipher, but it would be more productive for crypto experts to be able to critically examine the source code. With source code, we could see how hash functions operate, how many rounds of encryption occur, and so on. In my opionion, opening the source code to algorithms would provide a better way for us to evaluate their strengths and weaknesses.
  • I don't think this issue is entirely relevant, although I agree it is important.

    For many applications they simply don't have to interoperate with others. For instance, one of the Blowfish apps is a GNOME password manager. They could pick anything they wanted to. But they picked Blowfish over Twofish and Serpent. Why? Same deal with OpenBSD's choice of Blowfish. They don't "interoperate" with anyone in that scenario.

    If anything, your argument makes the widespread use of Blowfish even stranger, since it isn't even under consideration as an AES candidate its widespread adoption is unlikely.
  • by Anonymous Coward
    What kind of bastard encrypts configuration files?
  • by jlcooke ( 50413 ) on Thursday June 15, 2000 @08:11AM (#999774) Homepage
    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 [mailto]. I'm a cryptographer who's implementing the AES here at Entrust Tech.
  • I consider Blowfish fairly insecure compaired to other encryption utilities. It's an opinion. I brought up PGP because the algorithms it uses are more secure. Blowfish is safe to trust with you data, but I just don't like to.
  • And that helps how? (in an ideal world)

    Assuming you're not an idiot, the only copies of the information are strongly encrypted. Your swap space is encrypted (or you never allow your keys near it - which is hard to do, I grant)

    So, the attacker has to go after your encrypted keys, which means (effectively) brute-forcing your pass phrases. Before you notice your box has been rooted, because as soon as you do notice, you lock the attacker out, revoke your keys, and change your pass phrases.

    Of course, in a non-ideal world, the attacker patches your binaries, and learns a lot about you from reading *every* unencrypted file on the box. They grab your trivial (login etc) passwords by brute force, thereby reducing the keyspace for their next attack enormously, because they know the sort of passwords you choose. But by now, you're up against serious opposition. It's cheaper to go and see the person you want to talk to than to protect against this mess.

    I'm depressed now. Time to grab the latest OpenBSD release.
  • by phil reed ( 626 ) on Thursday June 15, 2000 @07:34AM (#999777) Homepage
    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
  • by SamIIs ( 65268 ) <SamIAm AT math DOT gatech DOT edu> on Thursday June 15, 2000 @07:36AM (#999778)
    On communication issues, being the "Best" isn't all that matters. If you're trying to talk to other people, it's important that they have the same protocols and languages, etc.

    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.

  • by LegacyMan ( 193804 ) on Thursday June 15, 2000 @07:37AM (#999779)
    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.
  • Happily the gap between practice and proofs seems to be closing. At least, OAEP has made its way into the PKCS #1 standard, and maybe from there it will be implemented. OAEP is pretty efficient - two hashes and two XORs on top of yer basic
    RSA operation.

    In fact, if you are willing to treat hash functions as "random oracles" (a big if which could be a thread in itself), then it seems that you can get quite efficient, provably secure methods to do lots of crypto. It's just a question of knowing about it. Something which having OAEP in a widely-used standard might help.

    Of course, what drove its adoption as part of the standard was the fact that the old standard was broken by Bleichenbacher at Crypto '98. Sad as it may seem, no one in the "wider" community seems to pay attention until someone comes up with a spectacular attack which the provably secure systems seem to resist. I'm sure there are some people of people busy fixing their old ISO-9796 signature compliant implementations, too...

    With luck, though, the IEEE 1363 standard for public-key crypto will start moving that segment of crypto towards provably secure methods. (see page at http://www.manta.ieee.org/groups/1363/ ). No clue when this is going to hit symmetric crypto -- anyone have a guess?
  • by dsplat ( 73054 ) on Thursday June 15, 2000 @07:42AM (#999781)
    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.
  • A factor for me would be could I use it to create a new ssh that would allow a person nammed: Linda Null with the user name null to access a machine via ssh.
  • It's worth pointing out that given today's hardware, and today's encryption algorithms, 3DES and Blowfish are both fast enough and secure enough for just about any application. Neither one is likely to be cracked by brute force within the next couple of decades, except possibly by d.net (unless quantum computers suddenly become cheap, in which case, all mathematical encryption schemes will be rendered useless and we'll have to use quantum tunneling encryption).

    They're both pretty fast already, and improving hardware technology can only make them faster. Why improve on a good thing, particularly when you're opening yourself up to the potential for errors in an untested algorithm?

  • by chazR ( 41002 ) on Thursday June 15, 2000 @08:12AM (#999784) Homepage
    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.
  • In the deep past, it was DES. Everyone knew it, the code was readily available, the algorithm very heavily analyzed, and it was a near universal standard. In the future, it will be the AES winner, as the code will be readily available, the algorithm very heavily analyzed, and a near universal standard.

    Currently, it has been more difficult. There was no clear standard when it became clear that DES's useful lifetime was over. People tended to use algorithms that were generally available and out for a while (therefore heavily analyzed), or which they have IP rights for. IDEA, 3DES, Blowfish, RC4, RC5, etc. 3DES and Blowfish being the most popular for open source and free projects, as they are both free of IP entanglements.

    The AES process [nist.gov] is relatively new. The five finalists have only been out there for a couple of years, and only been finalists for about a year and a half. Fortunatly, with the third AES conference behind us, and the winner due to be selected and announced within a couple of months, we will be returning to the days of DES, a common standard which everyone is free to use, with lots of implementations available.

    Also, with the AES finalists, the IP entanglements weren't entirely clear. TwoFish and Rijndael were unentangled from the start, but Serpent had an initial patent filed, but then let the process lapse (so it is now unentangled). MARS and RC6 still have significant entanglements. The winner, of course, will become entanglement free (barring the IP attack scenario), but until then, chosing an AES candidate wasn't any better or worse then picking an older, available algorithm from an IP viewpoint or even from a security viewpoint (as they weren't very heavily analyzed by those other than the developers during the first round, as there were some 30 odd first round candidates).

    Fortunatly, the AES winner will probably return us to the DES world: A trusted, entanglement free, well understood, secure algorithm.




    Nicholas C Weaver
    nweaver@cs.berkeley.edu
  • Why does FreeS/WAN want to use Blowfish rather than Twofish or Serpent?
  • 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.
    Try this one:
    for(i = 0; < length; i++)
    bytes[i] ^= 0xff;
    It is ultra-fast, symetric, and patent-free (but we might have to check with Amazon about that).
  • by Anonymous Coward on Thursday June 15, 2000 @08:20AM (#999788)

    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...
  • But when they were published means nothing. The only thing that matters is how much scrutiny they've received. How much cryptanalysis has Blowfish received compared to the AES candidates? Counterpane's own page admits "there are few published results" of Blowfish cryptanalysis.
  • That is an appeal to the masses and the worst fallacy that Aristottle ever catalogued. Get a Life.
  • by Robert S Gormley ( 24559 ) <robert@seabreeze.asn.au> on Thursday June 15, 2000 @02:02PM (#999791) Homepage
    Vendor: "Our device conforms to all known standards for communications protocols."

    Dilbert: "You mean it does nothing useful and isn't your fault?"

    Vendor: "Is there someone less knowledgeable I can talk to?"

    :-)

  • 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.

    Oh, like OpenSSL [openssl.org]? (-:

  • 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.

    And if you claim to be an old LANMAN client, that limits them to 8 letters long and reduces the character set even further. Also, if you're no good at writing sniffers, there's always a convenient .pwl file lying around somewhere to help you out.

    No point in locking the gate if you haven't strung the fence properly. Might as well go and kiss the horse goodbye now. (-:
  • Twofish is not an asymmetric algorithm! RSA and ElGamal are. Otherwise you're correct, asymmetric algorithms use a key pair where one key can be used to encrypt and the other decrypt. RSA can use either the public or private key to encrypt and the opposite one decrypts, whereas ElGamal can only do one-way encryption. ElGamal is a bit faster than RSA and has been proven to be at least as strong as RSA (and perhaps a bit stronger) but suffers from a couple major drawbacks, the first being that the ciphertext is twice the size of the plaintext, the second being that because it is one way you need two keypairs, one for signing messages and another for decrypting incoming messages...
  • Answers (I am not a professional cryptographer):

    Triple DES is used because affordable machines can brute-force DES in seconds to minutes. Triple DES effectively has twice the keylength of DES, 112 bits instead of 56 bits. This means triple DES is about 65 quadrillion times more expensive than DES to build a brute-force machine for, putting it beyond the budget of any known earthly agency such as the NSA. The only reason to go further is if you are trying to defend against the galactic government or something. :) Basically, the chances are very good that anything which cracks 3DES will crack 10DES too, to the extra compute effort isn't buying you anything obvious.

    Triple encryption isn't altogether silly if done right -- it is insurance against some disastrous hole being found in any single one of the algorithms used. But disastrous holes in codes like DES which have had decades of attack are seen as rare. Basically, other attacks are much more likely to be your undoing, and triple encryption won't address them, so the win isn't seen as great.

    Linux distros tend not to include much crypto because Uncle Sam has been insisting for a long time that national security requires that the national network be insecure: Distributing crypto from the US could get you jailed. Debian has offshore sites which distribute the crypto part of their distribution. (non-us.debian.org)

    Crypt shouldn't be hard to find. There used to be a 'crypt user's workbench' or some such with tuned implementations &tc. Very good attacks on it are now known, so there's not much interest in it.

    The 'fish' doesn't mean anything in particular, it has just become a habit to name crypto algorithms after animals -- pike, serpent, &tc.

  • A large keyspace is necessary but not sufficient to ensure security. It is easy to design a weak cipher with an arbitrarily large keyspace. Think of a simple polyalphabetic substitution cipher with N alphabets. Increasing the number of alphabets adds to the size of the keyspace but it is still vulnerable to pencil and paper attacks by decomposing it back into N simple substitution ciphers.
  • ...after three tries at getting it right, and SMB is even more broken after what is probably best described as "many" tries.

    Microsoft relied on security via obscurity and self-important code monkeys rather than careful and open design and community consultation. They almost certainly did it due to the combination of being paranoid (about anything "not invented here") and being a legend in their own mind.

    If you're prepared to run a 2000-only MS network, many of SMB's known holes (some large enough to run an oil tanker through) will vanish - but even the 2000-specific stuff is slightly broken and so new that the cracks aren't showing through the paint yet.

    There's good reasons that OpenSSH [openssh.com] has had more downloads than there are bits in the package recently. And they're not recording things like Mandrake's RPMed version, either. The whole system is peer reviewed and runs on proven, solid technology. And because it's Unix, you can make a secure VPN like this (just add routing to taste):
    pppd pty 'ssh -t user@host pppd notty'
    As Vinod Valopililli said in the Halloween emails, there are no one-week drivers for NT - and no ten-second securely crypted VPNs for Windows.
  • It's also well-suited to software implementation: it uses operations on 8-bit bytes, which are easy to write in C and assembly.

    My friend's DECsystem 10 is happier with 9-bit bytes. Of course, 36 bits at a time is easier still.

    I think sending something SixBit packed or Rad50 packed would be secure enough today. (-:
  • All of the algorithms you should even think about using have key lengths long enough to prevent brute force attacks within the lifetime of your threat model, and in general there's seldom a good reason to use something that can be brute forced within the expected lifetime of the planet. The real concerns are the expected time until either a mathematical breakthrough that changes the fundamental difficulties of the algorithms, or until somebody notices a bug in the algorithm design that can be exploited in some way much more effective than brute force, or until someone discovers a mistake in the way you're using the algorithm that violates the requirements for using it strongly. For instance, RC4 with 128-bit keys is just as fast as RC4 with 40-bit keys, but takes 2**88 times as long to crack, which is basically forever. But you have to never use the same key twice, so Microsoft's PPTP implementation that uses the same key for both directions of the conversation is instant toast.

    A more serious example is the MD5 hashing algorithm. Hans Dobbertin's work from the last couple of years looks like it's possible to generate hash collisions, at least under some conditions that can be realistic, so everybody's having to move to SHA-1 hashes for anything new. It's unfortunate - MD5 was fast, and the 128-bit output was a useful size for use as 128-bit keys. On the other hand, there are applications where a birthday-attack collision means you only need to try about 2**64 attempts instead of 2**128, so for those applications, MD5's 128 bits wasn't enough, because it's becoming possible to brute-force things of that size, while a similar attack on SHA1 would require 2**80 tries, which is a significantly larger number - and that's more important than the relative speed differences between SHA1 and MD5.

  • by Zooko ( 2210 ) on Thursday June 15, 2000 @08:38AM (#999800) Homepage

    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 [slashdot.org], Advogato [advogato.org], the Cypherpunks mailing list, sci.crypt, and the Crypto++ mailing list [escribe.com] 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.

    • Option one: "opportunistic public key distribution". The first time any pair of people talk to one another, they exchange public keys in an un-authenticated exchange. (Also: you could just do Diffie-Hellman key generation here.) After that, they remember each other's public keys for future use. This is susceptible to an active attack (a "Man In The Middle Attack"), during the first step (though not afterwards). However the cost to the attacker of executing a MITM attack is probably far more than the payoff. This depends on your threat model.
    • Option two: make it the user's problem; Each user decides whether to use a given key to talk to another user or not. This is the user interface nightmare that single-handedly prevented strong crypto from becoming standard in e-mail, but for a few applications it might be the right thing.
    • Option three: hardcoded; Generate key pairs yourself and include them in the application. For example if you are going to have a single central server in your system which you operate then you can generate a key pair for it, put the secret key on the server, and put a copy of the public key into each copy of the client (e.g. include the public key hardcoded into the client source code). This doesn't work as well if you want to distribute copies of your server for other people to operate, but refer to "Option one"...

    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 [eskimo.com]'s Crypto++ library [eskimo.com], 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 [openssl.org]. By the way, if anyone wants to make Python [python.org] wrappers for Crypto++ (possibly with the aid of Swig [swig.org]) 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

  • by Anonymous Coward on Thursday June 15, 2000 @08:41AM (#999801)
    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.
  • Nononono. rot-13 is still the best! I use double rot-13 for extra security. Twice as good!
  • by Anonymous Coward
    I would like to add the following questions to this: 1) Are there any _good_ encryption standards that can be exported/imported within most/all countries? 2) Which are the best open-source encryption libraries? (=not programs, but lib's you can use in your own programs) Breace
  • I've got an even better Idea! Let's use just a plain substitution cipher. oh wait, that was cracked 1500 years ago!
  • by HP LoveJet ( 8592 ) on Thursday June 15, 2000 @08:46AM (#999805)
    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."
  • by YASD ( 199639 ) on Thursday June 15, 2000 @08:46AM (#999806)

    Jeff beat me to it :-p

    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 [counterpane.com] makes it difficult to speed up in hardware. Twofish [counterpane.com] and Serpent [cam.ac.uk], 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 [openbsd.org]. A short presentation is here [openbsd.org].

    ------

  • by Simon ( 815 ) <`moc.enoznomis' `ta' `nomis'> on Thursday June 15, 2000 @02:57PM (#999807) Homepage
    ...you forgot "loses laptops holding classified nuclear weapons data."

    Have a nice day.
    --
    Simon.
  • >If triple DES is more secure than DES, then is 10x DES more secure than 3DES, assuming you use different keys at each iteration?

    Sure, but probably not by as much as one might imagine, as cryptographic algorithms can have unexpected algebraic properties that can act so as to confound security. We know that DES has just such a propertly - doubleDES (which should have a complexity of keylength112) is much weaker than expected, which is why triple-des is used instead.

    Cryptographers tend to view even small defects in crypto-algorithms as real problems, as those defects might be manifestations of larger, as yet undiscovered, flaws. So, dectuple-DES is quite a bit more secure than single or triple-DES, but it might well not be worth the trouble.

    Multiplying-up DES in particular is a (time) expensive business. DES was designed to be implemented in hardware, so even a single software DEScrypt is expensive, and thus compounding DES with itself makes for a very very slow cipher when implemented in software.

    >Does the above extent to any crypto alg? Triple blowfish? Quintuple IDEA?

    Yes, theoretically, and so does the suspiction/expectation of unforeen algebraic properties that make doing so suboptimal.

    >What about plaintext -> 3DES -> blowfish -> serpent? Do I gain a lot/anything by doing this?

    Complicated 'though this is, it has the advantage that there's lower liklihood of the weirdo-algebra problem described above. It is, however, severe overkill.

    Still, using multi-cyphers or multi-iterations is a poor substitute for having a decent cipher to begin with. If you're concerned that your chosen cipher has too small a key, use a cipher with a bigger key. If you're concerned that your chosen cipher is algorithmically flawed, use a cipher over which you have more confidence, rather than simply combining it with itself or others.

  • I recommend the very standard Applied Cryptography by Bruce Schneider. It tells you why protocols are good and bad and it tells you why encryption algorithms are strong or weak. By the way, people dont just choose encryption schemes because they are popular, unless they are fools. They are chosen for protocol strength and the difficulty in cryptanalysis of CIPHER-text. or in laymans terms: "how much it doesnt suck".
  • by Anonymous Coward
    Same kind of bastards that lease the program instead of selling it, give it backdoors so they can disable it, and generally have the attitude that their customers should feel honored to have the opportunity to sniff their shit.

    The same bastards what will be first against the wall when the SysAdmins rise...
  • Many people evaluate the algorithms for various implementations. One person, Brian Gladman (www.seven77.demon.co.uk) has C implementations of all the algorithms on his page, his implementations in my opinion are very good and efficient.

    I worked for a while with my school while I was stuck doing my thesis implementing these algorithms in hardware. Our goal was to see which had the most efficient implementation.

    Other people attempt to break the algorithms in the time honored (but highly dubious) tradition we all see in spy vs. spy movies. Others still evaluate the algorithms for resilliance to known attacks (such as mathematical, power based, electrical based etc). Everyone submits papers, theoretically those papers are read and conclusions are reached.

    In actuality, no one is quite sure how secure any of them are. Many have suggested using more than one AES candidate as our new standard, in the case that one is broken.

    As far as developers are concerned, I suggest checking brian gladman's page, however note the license agreements. Also note that in certain countries (like the US) you may never redistribute that code outside the US boundaries (stupidist *#*#$ I've ever heard).
  • As somebody who's spent some time over the last 2 years creating Java implementations of a number of the popular algorithms with BouncyCastle [bouncycastle.org] being the latest version. (Open Source and all that).

    The choice for what algorithm to use depends on a number of factors%2C and in my experience, it certainly helps to understand where it is going to be deployed (in hardware, small device like a Palm or a general purpose computer) and what is going to be protected (passwords, documents, streaming media).

    As a great example, Blowfish is a mighty fine algorithm, but the key schedule setup takes the equivalent time of encrypting about 5k of data. If you're going to be encrypting lots of small things with different keys then Blowfish probably isn't all that suitable. Blowfish's key schedule arrays are quite large, so in devices with limited memory (like the Palm) it isn't suitable.

    Twofish on the other hand has been designed to overcome a number of those limitations (pretty much because of the AES requirements).

    So, understand what problems the alrithms were designed to solve, and find one that matches yours.

    As has been stated many times, encrypting the data is only one link in the chain. If your key generation or exchange is weak, then you may as well not bother encrypting at all.

  • There are two big libraries out and they are related: SSLeay [uq.edu.au] and OpenSSL [openssl.org]. OpenSSL is based on the SSLeay libraies, both are open source. SSLeay has been around for a number of years and I have heard glowing reviews. This was also the first Open Source encryption library ever to obtain Verisign certificates.

    The fellow who made SSLeay (Eric Young) also has some stand-along libraries for encrypting buffers. I saw a Blowfish one for example.

    One note: encryption is easy to do, hard to do right. For example, Word Perfect had an encryption feature broken awhile back. It was broken because a section of the data was always the same. To crack the file all the person had to do was do the math:

    encrypted data - known data = key.

    This is a number of years ago but that will happen over and over again if the programmer doesn't understand the concepts behind data encryption.

    Just a plug: you might find Blowfish to be considerably faster than other algorithms. This is not because of simplicity but because the algorithm can take advantage of 32bit processors. It also does not have known weaknesses like DES nor patent restrictions like IDEA. Elliptical Curve is another worth looking into if you can't wait for the RSA patent to expire.

    Ozwald
  • Actually, blowfish is more secure then DES, since it allows a key to have up to 448 bits! (compare this with 48bit key for DES)
    The reason why blowfish is not so well accepted is that there hasn't been much studies performed and published about its weaknesses..
    One study has shown that a family of keys can be detected but not broken for blowfish implementations of 14 rounds or less. Another showed that a particular 4 round implementation can not be extended to more rounds, when using a second-order differential attack.
    These studies do not account for the standard implementation of blowfish, which consists of 16 rounds.
    Blowfish is also very fast! The speed comparison will show you that it takes 108 clock cycles to encrypt a byte using 3DES, meanwhile only 18 clock cycles per byte for blowfish! http://www.counterpane.com/speed.html

  • by jd ( 1658 ) <imipak AT yahoo DOT com> on Thursday June 15, 2000 @08:47AM (#999815) Homepage Journal
    "Won't go first" is a common attitude in crypto stuff. Sometimes, for good reasons. Usually, it has much more to do with inertia, legacy code, a "Not Invented Here" syndrome, and other such goodies. (Yes, Open Source has it's share of idiots, too!)

    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.

  • Well, the AES candidates are receiving a LOT more scrutiny than any other algorithms... The top minds from a lot of companies, governments, and univeristies are all at work trying to figure out which one stands up the best for it's purpose of replacing DES. Once one is decided upon, I'd bet/hope that people use it, unless they're qualified enough to explain WHY they'ed choose another that hadn't gone through the AES review process.
  • It helps to know that NSA Skipjack is an 80-bit stream cipher

    Skipjack is actually a 64-bit block cipher (with an 80-bit key).

    The algorithm has been declassified. You can get the specification from NIST's Skipjack and KEA [nist.gov] webpage.

  • by PD ( 9577 )
    Apparently you are using ROT26, which I haven't seen before either. It doesn't really stop me from understanding it though.
  • Can you expand on your 3DES-slowness-complaint.
    If its slower, then (all other things being equal)
    its harder to brute force right? If all other things aren't equal it seems like you have to include these things when you compare algorithms.

    I don't know a damn thing about blowfish or twofish. So educate me here if my reasoning is off.
  • Provided that the bits that you are XORing it with are random enough (low order bits of radio static is, from what I've heard, especially when stuffing them through a randomizing algorithm) and they are known only by you and your recipient, XORing is the only algorithm proven secure. Of course it's common name is a 1 time pad, but who's going to quibble over names.
  • > I would suggest Rot13.

    Actually, this is a bit outdated. All the standards today use something called "Triple-Rot13", which can be used in both the EDE (encrypt-decrypt-encrypt) and EEE (encrypt-encrypt-encrypt) mode. This provides twice the key length that Rot13 provides.

    (Note that Double-Rot13 can be broken in about the same time as Rot13 using a meet-in-the-middle attack if you have enough memory)

    Donny
  • A 40-bit keyspace is MUCH larger than any of the cryptograms that just use letter substitutions.

    Wrong. A simple substitution cipher has a keyspace equal to 26!, or about 88 bits.

  • by Eric Green ( 627 ) on Thursday June 15, 2000 @09:48AM (#999824) Homepage
    Well, Blowfish is also significantly faster than 3DES. In reality, I would say use 3DES unless speed matters, because 3DES has stood the test of time -- if it has not been cracked in almost 20 years, it probably won't be cracked within the near future. If you're going to do something that needs speed, on the other hand, Twofish and Blowfish are both much faster than 3DES. While neither has the history of 3DES, both have received significant cryptanalysis, and Twofish is faster and has a larger block size than Blowfish (should be more secure for many types of cipher feedback modes).

    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

  • by JHod ( 23510 )

    I do hope you know that while blowfish is an encryption algorithm, SSL is a protocol that negotiates end-to-end encryption? Perhaps even using blowfish as the algorithm? Please compare apples to apples. Blowfish files sent over http are not generally more or less secure than that same file sent via SSL (for example, https). The difference comes in key exchange, control and lifetime, which changes the effort needed to attack the ciphertext.

    The hard part of crypto is not choosing or even inplementing the algorithm, its setting up the security boundaries, deploying the algorithm correctly, and proper key management. The most secure algorithm can be destroyed by wonky random number generators, insecure key storage, improper key lifetimes, swap files or temp files that keep plaintext copies, etc... Choosing the algorithm should be almost an afterthought, as the system design is vastly more important.

    I should note that I am not a professional cryptographer, just an interested amateur who has deployed a few simple cryptosystems.

  • There may be a misunderstanding in terminology. A monoalphabetic substitution cipher, assuming a 26 letter alphabet with a randomly chosen 26 letter key, has a keyspace equal to log2(26!) bits, or about 88 bits. A Caesar cipher (c = (p + k) modulo 26) has a much smaller keyspace, log2(26) bits, or about 4.7 bits. See the lecture notes [cornell.edu] from Prof. Schneider's Introduction to Cryptography for a longer explanation.
  • by Eric Green ( 627 ) on Thursday June 15, 2000 @09:55AM (#999838) Homepage
    XOR is the basis of stream ciphers. The only real secret is that you must be XOR'ing against a key-generated bit stream. A common way of doing this is to use the key to seed the stream generator (basically a PRNG) on both ends, and the pseudo-random bit stream generated by the stream generator is then XOR'ed with the bits you're transmitting.

    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

  • by Detritus ( 11846 ) on Thursday June 15, 2000 @09:58AM (#999840) Homepage
    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.
  • A one time pad uses a very large random keypad which must be shared on both ends (i.e. must be transmitted some other way, such as, e.g., by diplomats with attache cases). As such, it is impractical.

    A stream cipher could be considered a "pseudo one-time pad", in that a shorter shared key, instead of being the keypad itself, is used to produce a pseudo-random keypad on both ends (which will be identical if the seeds are identical). The key is basically the seed to a cryptographic-quality PRNG in this case. This is a very tricky thing to get right, and most "pseudo one-time pads" are cracked within minutes of being released. Use RC4 or a block cipher feedback mode if you need a stream cipher, don't try to do this yourself at home.

    -E

  • by Ralph Wiggam ( 22354 ) on Thursday June 15, 2000 @10:04AM (#999843) Homepage
    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
  • by Eric Green ( 627 ) on Thursday June 15, 2000 @10:04AM (#999844) Homepage
    The problem with picking a complete cryptoSYSTEM is that often they are seriously broken. Both SSL and IPsec have been compromised multiple times over the years by things as stupid as a poor pseudo-random-number generator.

    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

  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Thursday June 15, 2000 @10:05AM (#999845)
    I'm an InfoSec consultant IRL, but this is not professional advice. (And soon I'll be a full-time paid PGP hacker. Yay. )

    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. :) 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.
  • by Sajma ( 78337 ) on Thursday June 15, 2000 @07:42AM (#999846) Homepage
    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...
  • by Dungeon Dweller ( 134014 ) on Thursday June 15, 2000 @07:42AM (#999847)
    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
  • by Chairboy ( 88841 ) on Thursday June 15, 2000 @07:42AM (#999848) Homepage
    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.
  • by Garin ( 26873 ) on Thursday June 15, 2000 @07:43AM (#999849)
    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.
  • by Scott McGuire ( 4080 ) on Thursday June 15, 2000 @07:43AM (#999850)
    It may be too early to use the AES candidates. Aside from their still just being candidates, some (all?) of them are relatively new and thus unproven. Blowfish's having been around longer is probably one of the reasons you can find more examples of it on freshmeat. To learn what to do I recommend:
    • Read "Applied Cryptography" by Bruce Schneier
    • Hang out on sci.crypt
    • Subscribe to the cryptography mailing list at c2.net (send something like "subscribe cryptography" to majordomo@c2.net)
  • by Semuta ( 193948 ) on Thursday June 15, 2000 @07:44AM (#999851) Homepage
    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.

  • Nope. One-time pads can't be broken. That's easy to prove. The problem with those is that you then have to transmit the pad securely, which brings you back to square one.

    Now, it's always possible to use an external source of randomness, which would allow both parties to create the one-time pad but would make it much more difficult for a third-party to, as the randomness would be time-sensitive. An example of that would be to use radio telescopes, pointed to a variable star, and using the readings as the random numbers. Sure, Dr Cracker of the Institute of Higher Snooping could break the message saying which star you were going to use, but unless he did so BEFORE the readings were to be taken, the information would be useless.

    Another form of "uncrackable" cypher would be one which used variable-length keys with a large upper limit to the key length, where there were few or no synonyms, and no short-cuts can be taken. Unlike the previous case, where the cypher's key exists only for an instant and is secured by time rather than artificial means, this system relies on the potential keyspace being very large. By using variable-length keys, not only do you increase the number of keys the user must look through, you also make it much harder to determine if a given "solution" is correct.

    (Variable-length keys are MUCH more difficult to program, precicely because of the synonym problem. The more keys that exist that produce the same output, the smaller the key-space. This means that you have to use (n+1)-state logic, rather than n-state, to include the case of null entries. Demonstrating a lack of synonyms for, say, 3-state encryption (if you're using binary) is going to be much more complex than if your key and data existed in the same base.

  • I'm not too familiar with FreeS/WAN, but I can comment on why Blowfish might be more popular vs. it's successor TwoFish.

    Blowfish is very very simple to code and understand. The core loop is only a few lines long and is used to prepare the key and encrypt. The hardest part is getting the digits of Pi correct.

    Twofish OTOH, is heavily beefed up to support the AES requirements such as 128-bit block sizes and is significantly more complex than Blowfish to understand, implement and optimize. Thus, people still prefer good old Blowfish.

    As for other AES algorithms, some of them may still be under license restrictions (at least until they win the contest).

  • I'm not trying to start anything, but as far as _standards_ go, it's gonna be important to choose something that is available on multiple platforms.

    Much as I dislike it, many of my friends use Windows, so if I am gonna encrypt something to send to them, I've got to use something that they can decrypt, right?

    Many of my other friends (whom I tend to hold in higher esteem), use one form of Un*x. The same applies to them.

    Then there are thoses people who use Macs (I tend to like them right off.)

    Anyway, my point is that it's all about communication. If the person I'm sending something to can't decrypt what I'm sending, why send it encrypted?

  • by Admiral Burrito ( 11807 ) on Thursday June 15, 2000 @09:24AM (#999863)

    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.

    It is also the most likely to be used in a broken manner.

    Countless are the programs that used the RC4 keystream for encryping more than one plaintext. This is highly breakable.

    Really, RC4 is the NSA's dream. It is such a simple little algorithm that it leads people to think that they can create a secure system with just a few lines of code.

    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.

    I would go a step further.

    Ignore the algorithms and pick a complete cryptosystem. If you're worried about packet sniffers, use SSL or IPsec.

    (Am I the only one who gets "invalid form key" messages when trying to post? It's really starting to bug me.)

  • OpenBSD chose Blowfish for their password file long before Twofish was invented. Remember, Twofish is only two years old, and only within the past few months could anybody safely say (without lying out of both faces) that it is secure. Only after the best cryptographers in the world have spent two years trying to break it can you really say that it even has a CHANCE of being secure...

    -E

  • by Anonymous Coward
    While it may be harder to brute force a slower algorithm, it is hardly a good thing to base your security on.

    When cryptographers talk about "brute force" they mean searching a key space of 2^256 keys. If another "strong" algorithm is say 100 times faster than 3DES, then 2^256 / 100 is still a very huge number. Once you get beyond a few million years of computation, dinky multiplicative factors of a couple 1000 really don't make much of a significant dent.

    OTOH, a faster "strong" algorithm has immediate implications to bandwidth, throughput, etc.... That factors in much more heavily than a theoretical 1000 years less brute-force attacking.

  • 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.
  • According to Bob Baldwin, one reason we see a lot of Blowfish and not much of Twofish and other AES candidates is that Blowfish (like DES and 3DES) works on 8-byte blocks, where the AES candidates work on 16-byte blocks.

    Crypto infrastructure is designed to allow different ciphers to be plugged in, but changing block size is more work. If you want to just drop in a cipher without changing anything else, you generally have to pick one that operates on the same size blocks.

  • by Anonymous Coward
    I can't believe the parent comment was actually moderated up. Christ, that's sad...

    Allow me to insert a little bit of clue into the mix:

    Both Blowfish and Twofish require sub-keys (generated from the larger key) for each of the rounds. They're all related, but it's difficult to generate the original key from the sub-keys.

    For both Blowfish and Twofish, it is possible to spend a good deal of time generating each of these sub-keys, before the encryption process begins. Store them in memory before you start encrypting, and simply look them up while encrypting.

    Alternatively, if the amount of memory available is limited, the sub-keys can be generated on-the-fly. This certainly makes for a slower algorithm, but it decreases the memory requirements. Either way, it's still faster than DES...

    And, yes, both ways will slow down an attacker, however slightly. But when you're looking at a 256-bit key, you have to remember that it's likely that the universe will collapse in upon itself before a brute-force key search finds the key.

    And, if you want to implement something along these lines anyway, a better method for doing this is Rivest's "Package Transform" (paper at http://theory.lcs.mit.edu/~rivest/fusion.ps ). With the Package Transform, you can achieve much of the same effect, but longer messages make for greater difficulty. So, if the Blowfish/Twofish margin isn't enough, you can simply pad out your message.
  • 3DES is an excellent choice where speed does not matter. Where speed does matter, however, it's not so great.

    Software implementations of 3DES can't keep up with 100mbit Ethernets, for example. So if I want to encrypt high speed networks, either I use a (very expensive) hardware implementation of 3DES, or I use another algorithm (like Blowfish or Twofish).

    Hammer. screw. Screwdriver. Nail. Pick the appropriate (tool,problem) pair from the list. There's no such thing as a magic bullet that solves all problems.

    -E

  • Sorry if I seam completely stupid, but what is the point? Why encrypt an mp3 just for it to be decrypted in the player? If the player has the key, and the user has the player, then the user has the key! I really don't understand how these mp3 encryption things are supposed to stop copying. If you can listen to it, then you can copy it. It only makes it more difficult to use, and loses customers, while not actually stopping people who are determined to copy music.
  • by Eric Green ( 627 ) on Thursday June 15, 2000 @10:26AM (#999875) Homepage
    The problem with a slow key schedule is that it slows down the cipher when you're using it for non-encryption things like, e.g., generating pseudo-random numbers or creating a message digest. The reason Twofish has a fast key schedule is not because it has to be implementable in hardware but, rather, because it has to be re-usable for things like creating message digests and pseudo-random numbers, since smart cards do not have enough memory on them to put lots of different algorithms.

    -E

  • To, partially, answer your question about the number of hits for Twofish and Blowfish, here we go:

    There are two types of encryption techniques. There is symmetric (Blowfish, DES, etc.) and asymmetric (Twofish, RSA, etc.). Symmetric algorithms use only one key to encrypt and decrypt information. Asymmetric algorithms, sometimes called public key algorithms use two keys. One public and one private. The public key is used to encrypt while the private key is used to decrypt. Asymmetric algorithms are also usually designed to work in some way as digital signatures or identifiers.

    So, first you need to figure out whether you need symmetric or asymmetric encryption. This eliminates an entire catagory. The reason you probably found so many Blowfish hits compared to Twofish is a.: Blowfish is older, and b.: symmetric algorithms tend to be simpler (mathematically) and easier to program.

    You can probably find a more thorough explaination of the two algorithms at Schneier's web-page: www.counterpane.com [counterpane.com]


    Ethan Jewett
    E-mail: Now what spa I mean e-mail site does Microsoft run again?

  • by Anonymous Coward
    Picking encryption is like picking your nose -- it's an intuitive process, and you know you've got the right "one" when you put your finger on it.

  • I would suggest Rot13. It is fast, real fast. Easy to implement, widly avaiable on all platforms. Free Public Domain License, don't have to pay RSCA (whatever there name is) mega bucks for licensing. It is importable and exportable to the United States (and probably to any other states).

    It does have a few security flaws, but unless your are the NCSA you will have a difficult time cracking it. I heard there is a "seti@home"-like project, to distrub a brute force against Rot13, but I haven't heard anything else about it. They have probably give up since todays computer *could* takes years to firgure it out...

  • The reason that you do not see many implementations of the AES cyphers is that they have not been around for very long. The industry has not had a whole lot of time to beat on them. 3DES, on the other hand, has had a number of people hammering on it for a decade or two and it known to be quite secure. FEAL has had people hammering on it for years and is known to be much weaker. (IDEA is secure, but has serious patent problems.)

    The reason you see so many implementations of Blowfish is that it has been hammered on for a while. The few problems with it have been fixed. It is fast. Most of all, it is FREE. It does not have the nasty little patent problems that many of the other algorithms have. Twofish will have the same status after it withstands the blows of cryptographers for a few more years.

    I also suspect that another reason for the lack of adoption of AES canidates is that people are waiting to see which one comes out on top. Never underesitmate the power of buzzword complience in the minds of management.
  • by brank ( 167549 ) on Thursday June 15, 2000 @07:53AM (#999880)
    It's nice to see that there are some people who haven't forgotten the reality of security technology: it's only secure until somebody beats its. Triple-DES (3DES) has been around long enough that I can trust it to keep my data safe. When I have to change, I will, but not before, and not to a new, untested algorithm.

    It's also important to remember than algoritms avalible for peer review are typically stronger because more brains have tried and failed to find holes in them.

  • by nestler ( 201193 ) on Thursday June 15, 2000 @10:56AM (#999899)
    ahto writes: an algorithm cannot be proven secure

    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.

    1. They break bad cipher implementations

    2. 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.
    3. They break other pieces of the system
      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).

  • by Paul Crowley ( 837 ) on Thursday June 15, 2000 @11:02AM (#999900) Homepage Journal
    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...
    --
  • by Anonymous Coward on Thursday June 15, 2000 @07:59AM (#999902)
    A very interesting paper [openbsd.org] was presented at USENIX [usenix.org] in 1999 that explains why blowfish was chosen as the encryption scheme for OpenBSD [openbsd.org] passwords.

    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 [csuchico.edu], who has forgotten his Slashdot password

  • by Kiwi ( 5214 ) on Thursday June 15, 2000 @08:00AM (#999903) Homepage Journal
    When choosing a crypto system to use, I make the following considerations:
    • The algorithm has to be free and unencumbered by patents. The ElGamal public key algorithm is an example of an unencumbered algorithm, but it did not become unencumbered until the DH patent expired in 1997. The symmetric key algorithm Blowfish is the first unencumbered post-DES algorithm that people believe is secure, which is why it is so popular.
    • The algorithm has to feel secure. This is way people stull use 3DES, even though it is far slower than Blowfish and most of the other new SK algorithms at the block cipher lounge [ii.uib.no] and the AES candidates [nist.gov].
    • The algorithm has to, once it meets the above two criteria, be efficient. Blowfish has an inefficient key generation cycle, but is otherwise efficient. Rijndael [kuleuven.ac.be] is the most efficient of the AES candidates.

    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 [apache-ssl.org]--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

  • Bruce Schneier has written the excellent book "Applied Cryprography". Many a programmer has their knowledge about cryptography from that book.

    Since he is also the person behind Blowfish, and that algorithm is described nicely in his book, it becomes a natural choice for many people who has read the book. It is also know to be unencumbered with patent problems.

    I would say the main reason for choosing a algorithm is that it is secure (have no known attacks against it) and is well know to the programmer. Because of "Applied Cryptography" Blowfish then becomes a natural choice. For other it would be 3DES.

This is now. Later is later.

Working...