Slashdot Mirror

Weld Pond writes "The Digital Commerce Society of Boston is holding a fundraiser for the EFF legal efforts in the DeCSS case. @Stake (nee l0pht) is one of the sponsors making this event possible. Come join us and put your money where your mouth is. Suggested minimum donation is $35. The details are in the invitation. Geek warning: The Harvard Club of Boston requires jacket and tie. " One other note: I talked with some of the folks from OpenDVD last night, and there will be a fund setup within the week to help the legal defense fund. At the Beanie Awards, Alan Cox, who won the Unsung Hero Award, gave his $10,000 towards the defense fund - and we had a fundraiser later on in the evening.

Duke of URL writes "The gray hat hacker think tank L0pht Heavy Industries has provided a FAQ list on their recent merger with @Stake. It sounds like there will be a few more changes than I personally previously thought, (i.e. Web site changes, etc.) but the good news is that L0pht 'will continue to act as a Consumer Reports style organization in posting our general findings through analysis and evaluation as general customers reviewing software.' Also Hacker News Network will still be run by L0pht/@Stake and will receive more time and resources. "

Duke of URL writes "The gray hat hacker think tank L0pht Heavy Industries has provided a FAQ list on their recent merger with @Stake. It sounds like there will be a few more changes than I personally previously thought, (i.e. Web site changes, etc.) but the good news is that L0pht 'will continue to act as a Consumer Reports style organization in posting our general findings through analysis and evaluation as general customers reviewing software.' Also Hacker News Network will still be run by L0pht/@Stake and will receive more time and resources. "

This week's "main" interview guest is L0pht Heavy Industries as a group. (We hope to have answers from Linux International head Jon "maddog" Hall tomorrow). Many insightful questions for the L0pht guys were posted Monday. Today, lots of insightful answers on everything from political controls on the Internet to hardware hacking. (Click below to read.)

1) Which do you consider more dangerous
by Gleef
Which do you consider more dangerous to personal liberties on the Internet, national governments or multinational corporations, and why?

L0pht
While both Governments and multinational corporations are detrimental to personal liberties on the Internet, one must not overlook the greatest danger of them all. The uninformed citizen. In democracies, this is problematic, where governmental policy typically follows public opinion. In the case of the Internet, one will find that most citizens of the world are willing to give up personal liberties in exchange for perceived safety and piece-of-mind. For the safety of the children, is cited commonly.

Many people believe that anonymous access to the Internet is criminal behavior. Government would like you to think privacy is an "anti-social" behavior. You should have nothing to hide, should you? You wouldn't be reading up on the consecration of explosives, looking up security holes in various operating systems, or possibly downloading the latest crypto software, would you? Only terrorists do that.

Governments are lobbied by uninformed citizens, or citizens which are easily manipulated and swayed by various groups across the gambit of our modern civilization. Multinational corporations have their hand in the fray by funding these groups or by participation in Associations which provide counsel to government officials on technical matters. Often recommending legislation which will better the profit taking over the sanctity of "personal liberties."

Multinational corporations are problematic in that they operate in a proprietary world. Often outside parties will scrutinize the technological fabric of a communciations service being provided. Should a flaw be found, and published, the corporation claims that the flaw itself is detrimental to the service being provided and litigation is dispatched on the party disclosing the flaw. This has been the case in the Cellular communications venue. Cloning a cellular telephone was a real thorn in the side of the Cellular Industry. They took their gripes to the US Government. The CTIA and their ilk successfully swayed Washington to pass legislation to combat the cellular fraud. Result: A portion of the radio spectrum was made _forbidden_ to reception. Possession of an eprom programmer, a computer, and a cellular telephone became a crime. Meanwhile, the cellular network REMAINS open to eavsdropping. Money is power, and with power comes influence. However, in the end it was the Government, sucking up to industry, which passed the law.

Law Enforcement and Intelligence gathering communities dwell within the governmental domain. Both are lobbying lawmakers to pass laws to give them greater powers to combat crime in this high tech world. Surveillance is paramount. They will convince the lawmakers that without the keys to all communications, a bomb may be set outside Parliment or Congress or .

The government pursuades the people, the people pursuade the government. Who planted the seed first? Those who understand the technology are too busy working on the next cool widget. Meanwhile the technological world rushes toward a global dictatorship and the populace embraces it under the guise of security.

2) The net: strip mall or unlimted human potential?
by garagekubrick
The halcyon days of the net are gone. With ubiquity - the underground vanishes. Is it well on its way, with people like the CEO of Amazon being worshipped by the mainstream press, to becoming an enormous cyber strip mall, marketing tool, PR exercise in control of perception...

Or is there still an underground? Does it still have a potential to be the one true medium with liberation? Will governments and coroporations end up controlling it? Cause they are winning small, important victories relentlessly...

L0pht
The Internet has changed dramatically over the last year or two and with it the underground has also changed. Back in the good ole days (1995+6) every web site was underground, hell the entire internet was underground.

As the web increasingly encroaches onto the mainstream and large portal and corporate sites take over feeding you only the information they want you to see, the underground will evolve and change and morph to suit its surroundings.

There is definitely still an underground. In some aspects it is a lot larger than it used to be and in others it seems to be much much smaller. I think labeling the underground as 'the one true medium with liberation' is laying it on a little thick. The internet underground has been nothing but the exploration for knowledge, if you are looking to it to save mankind from itself your looking in the wrong place.

Governments are increasingly encroaching on personal liberties and freedoms of the average citizen, this is unfortunate. How much longer before the population as a hole realizes what is going on and says enough? Maybe they will never wake up. Will the governments eventually control the internet? Possibly. It is hard to tell but there will always be those who will resist that control and the underground will continue in one form or another.

While the web, as you put it, may become 'an enormous cyber strip mall' I can't help but think of the trash dumpsters behind that mall and what secrets they may hold.

3) Internet Worm II
by tilly
Several months ago I began predicting that someday someone would find a buffer overflow in the various Windows TCP-IP stacks and use it to write a worm that would bring down the Microsoft part of the Internet and cause so much traffic as to effectively shut down everything else. I further predict that until an event of this magnitude happens, the general public will not really learn the basic lessons about security that the *nix world was forced to learn from the first worm.

What are your thoughts on this prediction? (Timeline, reasonableness, etc.)

L0pht:
I believe your prediction is right on track. However, I don't feel that an Internet Worm II is necessary to teach Microsoft, its customers, or its vendors, about security. There are three ways to implement a security model, the slow way, the fast way, and the right way. The slow way involves making a bunch of little mistakes and fixing them over time as you find them, correcting your policies and implementations. The fast way involves having a major disaster occur, after which the faulty parts of the system are completely torn apart and reimplemented. In practice, the slow way often leads to the fast way.

Which brings us to the right way: To design software with a security policy in mind, and with extra caution, care, and expenditure during the implementation. OpenBSD's model of proactive security measures is a classic example of 'the job done right'. Retroactively applied security measures are a recipe for disaster.

Rant off.

As for when Microsoft is going to learn about these things, they'll first have to learn that 'bigger isn't necessarily better'. They need to stop believing their own FUD before they can actually make change over there. When I read things like the article at http://www.microsoft.com/ntserver/nts/news/msnw/LinuxMyths.asp, particularly the parts about Linux being less 'secure' than Windows NT, I'm appalled at the ridiculous 'facts' that are being used to back up their claims. For example, they claim that:

"Linux only provides access controls for files and directories. In contrast, every object in Windows NT, from files to operating system data structures, has an access control list and its use can be regulated as appropriate."

While this statement is true, they neglect to mention the fact that under a unix operating system, most things that correspond to Windows NT kernel objects, file, data structures, etc, are represented as files. Hence, the coverage of the security model for Linux is just as extensive, even more so, than Windows NT. This is a particularly bad statement, simply because it's not only incorrect, but the converse is true. Linux is more flexible in terms of permission management. Try setting the access controls on who can bind to a particular port under Windows NT, with the ease of chmod and portfs under Linux, and you'll fail miserably. And the list goes on.

(And as for 'access control lists', we've noticed that Windows can't seem to get the right default ACLs anyway, and that the complexity of managing them has outweighted the value of their 'flexibility'.)

As for your comments on the Windows NT TCP/IP stack being vulnerable to attack (possibly, who knows :P) and the possibility of a worm destroying Windows systems, the possibility is very real. And again, this possiblity is not unique to Windows. They're just a likely target at this point in time.

It would take a feat of dedication and great skill, but the possibility is there. My advice to anyone who's worried about this, is this: If you're going to use Windows NT, you should probably keep that firewall in place between those Windows service ports and the rest of the world. Microsoft loves to add services and open ports to your computer when you're not looking. And it's probably not going to be the IP stack, it'll probably be some goofy listening service, like anonymous share enumeration or something. Or maybe remote access to NetDDE. Or some authentication protocol that doesn't like large Netbios fields. Or possibly even some undocumented functionality in the named pipe filesystem used for RPC. Who knows. Personally, I'm not going to wait around to find out.

4)The Public's Perception of Hacking
by dmuth
First, I should probally preface this geek for several years, and love playing with technology, so I feel I am able to relate to the hacking community.

Anyway, my question is, how do you deal with the way the public (including the media) percieves "hackers"? I've seen some clueless people use the term to describe *anyone* who does anything with a computer that they find > objectionable. I've even heard the term applied to spammers!

Needless to say, the misue of the term makes my blood boil, because I feel a certain respect towards the real hackers, such as yourselves, because you guys do know what you're doing, unlike all of the script kiddies out that that either have the term applied by clueless reporters, or they use it on themselves.

So, I'd be interested in knowing how you cope with this sort of problem, as I've noticed this sort of perception of the hacking communtiy for some time.

L0pht:
The first thing you need to do is refer to yourself as a hacker and be prepared to educate the person you are talking to what you mean by that. It doesn't matter if you are talking to someone from the media, or the government, or the business world. People need to know the real meaning of hacking, its history, and what a positive thing it is.

A lot of the time we talk to the media just because we are afraid that if we don't there will be no one they talk to who will describe hacking in a positive light. No one to describe it as other than defacing web pages or breaking into .mil sites. This was one of the reasons we wanted to talk to MTV. We were afraid their story would be all about criminal hackers. If you saw the MTV show you saw that sometimes resistance against the media memes is futile. The show was 95% about illegal activity.

Yet the world of hackers is 95% non-criminal. Probably a better percentage of people behaving positively than most segments of society. It is a world of people exploring the edges of technology and building things. The crazy thing is the government is making more and more of that exploration illegal.

Reverse engineering security mechanisms is being considered a crime. Receiving digital radio signals is a crime. We can't let them wall off part of the world we inhabit from investigation.

Hackers have a positive role to play both as builders and critics of the digital world. Unless we speak up and refer to ourselves in that light we have only ourselves to blame. Everyone who can should educate. Its not easy changing perceptions. But sometimes a passionate personal explanation of what hacking means to you can make someone change their mind.

5)security of capability-based operating systems
by sethg
What do you think of capability-based systems, such as EROS? The folks who are working on these systems say they are fundamentally more secure (against both malicious code and heisenbugs) than Unix derivatives, Windows NT, and other ACL-based operating systems. Do you agree with this assessment? Do these systems have security weaknesses that Unix-like systems don't have?

L0pht:
It's nice to see work such as EROS comming out of DARPA funded projects. Capability-based systems are quite interesting. However, one must be quite careful when making statements such as the one that these systems are more fundamentally secure that others. One has to keep in mind that Windows NT made a similar claim. Was NT fundamentally more secure that Unix as was presented to the general public? Well, it did have a security model that Unix lacked and it's internals were much more akin to VMS which had various strengths that Unix lacked. Yet we all saw that the implementation is where it matters.

In reality the implementation is key. Things can look great on paper and be a real bear to implement (look at communism for example). Another key component that is often overlooked is the functionality. This is a double edged sword. If the system is not universal and generic enough in nature to exist in a plethora of environments then it is difficult, if not impossible, to gain wide scale acceptance and use. Of course, this notion is directly opposed to creating a secure operating system. If it has to work in a multitude of environments then it needs to be relatively open and flexible or else the skill set and support for integrating it into one specific environment is beyond most peoples abilities (ie it won't get used). Sun Microsystems ran in to this problem with older versions of SunOS (now retroactivly named Solaris 1.x) when they used to consistently ship with a '+' in /etc/hosts.equiv. After several years they received enough requests to take it out of the distribution for security reasons. Unfortunately, taking it out caused so many installations to not be "plug-n-play" that they promptly put it back in.

When I look at an operating system such as EROS the following pops out at me when thinking security (this should not be viewed as condemnation by any means).

. RTOS modeled.
Real Time Operating Systems can be very useful for directed applications but suffer in general use often times. In addition, certain security notions at extremely low levels of a system (ie hash signing memory blocks that are passed between processors or ASICS) incur overhead that is quite unwelcomed in most of the "general public's" acceptance in RTOS.

. Emulated POSIX and Unix environments
I love Unix. However, it's difficult for someone to maintain the claim that they are more secure than another operating system and then emulate it's behaviour. A good emulation is going to have the good and bad aspects on the security front or many things won't work.

. implementation from the ground up can be painful
Often times it is required. But heaven help the "vendor" that decides that in order to be their own maker they will do it from scratch without looking at the mistakes that others have made. We see it all too often that people decide to reinvent the wheel and foist square versions on people the first time around.

With all of that being said I believe that in the future, should people start to wake up and really appreciate the notion of security and privacy in a way that really influences the market... we will see more dedicated systems and fewer general purpose ones. In order to go that route projects such as EROS are invaluable.

6)Security Through...Unpredictability?
by Effugas
Would you agree that security and stability are but different sides of the same coin? In other words, a security exploit is truly nothing more than an expertly controlled failure?

If so, how much stock can we put into the "metadesign" of limiting the damage an exploit can create by attacking the ability of a failure to be controlled? Should operating systems incorporate such "unpredictability engines" when being run in a production, non-debugging manner? Or is such a design not worth pursuing, for various reasons?

L0pht:
You must be a kindred spirit :) We have been preaching the approach that most stability problems are security problems that have not been looked into enough for quite some time. By fixing security problems you enhance the stability.

Now, with that said, it is important to shoot for the pinultimate solution to problems and this ends up being a wonderful academic excercise (out of which great things come). Do we shun any notions that merely raise the bar instead of being the silver-bullet? No. Each elevation in design is a step in the right direction. It is apparent that we have many steps in front of us but this does not mean we should stop progressing until a magic cure is found.

Unpredictability in systems, such as loaders or interpreters that recurse random times to throw off "static" frame location and other mechanisms (ie canary values) etc. are some of the finer points that I see coming out of the security approach to implementations. Are they ready for production systems? It all depends upon what your production system must be capable of. In many cases the answer is yes. In some cases the answer is no.

7) Future of Hardware Hacking?
by Tackhead
Two questions (Well, three, really, but I'm a hardware geek, and I love trying to squeeze three things in the space of two):

A) Wireless.
Lots of folks have been asking today about the wireless network project. "Me too"; the page has been up for years, it's a fascinating and extremely powerful idea, but for those of us who aren't RF engineers...

> When do we get to see some hardware projects to build, or is it the case that -- due to regulatory restrictions on what can and cannot be transmitted on US airwaves -- work is being done independently on the notion of a secure wireless IP-based network but isn't being released so that those of us who aren't RF engineers can't gum up the works by screwing things up before it's ready? :-)

L0pht:
The Gnet project has been in progress for many years now. Mainly the problem had been lack of funds, but now time allocation and lack of dedicated participants hold back expansion.

There is a lot of interest, but no one seems to be willing to put up the nodes. There are 2 sites currently on the network. One at l0pht and one at a residence. This has been the state of the network for the past 2 years. Unfortunately no one with enough initiative in either state has been found to setup other nodes. There has been interest in other states but the long haul capability has yet to be worked out. Encrypted tunneling over the Internet may help span the network over long distances. Once the fabric of the network expands, landlines could be replaced with wireless links/nodes.

High-density, low-power networks sound great in theory, but until the interest level rises above its present state, the cellular structure will remain the dominant topology.

To get the network off the ground, we have been trying to go the Amateur radio route. Going this route does have its drawbacks. Encryption is forbidden, however compression is not. I have been running ssh in compression-only mode for years. The initial ssh authentication is allowed under FCC guidelines, as long as the communications is not encrypted, you are within the rules.

The move off the Amateur frequencies will be made once the cost of National Information Infrastructue (NII) part-15 devices drop under $500 dollars for a pair of nodes. These devices fall operate in the 5Ghz frequency range. The breakdown is as follows:

• 200 milliwatts EIRP (5.15-5.25 GHz) - indoor
• 1 watt EIRP (5.25-5.35 GHz) - inter-campus/neighborhood
• 4 watts EIRP (5.725-5.825 GHz) - Point-to-point, few miles, terrain permitting.

Other devices which are useable in the project are ISM band Part-15 devices which operate in the 900Mhz and 2.3Ghz frequency range, and dwell in the Wireless lan arena. Wavelan(Roamabout) http://www.wavelan.com, and rooftop networks (just purchased by Nokia) among others, players in the 900Mhz and 2.3Ghz arena. Older wavelan equipment can be found by searching auction sites and used equipment dealers. Early wavelan 2Mbps/sec ISA/PCMCIA cards can be found for ~$125.00 US Dollars. The problem with these cards is they don't conform to the IEEE 802.11 Wireless Ethernet specification. This is one inherent problem with building the network out of old equipment. It becomes costly to replace eqiupment once the entropy ball starts rolling.

The path to build custom equipment is equally as challenging. For example, the TAPR (Tucson Amateur Packet Radio) group has been in the forefront of Amateur packet radio for the past 15 years. While they have an established base of dedicated users, they continue to have problems developing new hardware. They have been prototyping a Frequency Hopping Spread Spectrum (FHSS) system for 3 years now, with still a protoype just passing a design review. Hopefully this project will come to fruition soon!

Some very talented folks over in Slovenia have developed some BPSK transceivers and a no IF SSB transceiver which will work on 1296, 2304 and 5760MHz. None are in kit form but the schematics, theory, construction notes, and equipment checkout is available in english. (schematics are not in english.). These radios are not for beginners or even intermediate kit builders. It would be nice if someone could kit these units. I started to convert the 23cm BPSK design to utilize a chipset family put out by RF Microdevices, but then my time got sucked into other projects. I may find the time to persue this once again, but I would like to get some semblence of a network greater than 2 nodes up and running first. *sigh*

B) The future of hardware hacking.
With the trend towards more and more functionality becoming embedded into ASICs and single-chip solutions, the golden age of "just desolder this", or "reverse-engineer the schematics and jumper that", or "replace [PROM| EPROM| EEPROM| PIC| FPGA] with one with the following special programming, and here's the [CPU| microcontroller]'s instruction set and a memory map of the embedded system" appears to be drawing to a close. Anyone can desolder a 24-pin DIP EPROM and hack it, but trying to desolder a 100-pin PQFP is a real bear without $500+ worth of specialized equipment, and knowing what to do with the chip after you've desoldered it is well-nigh impossible.

Do you see a time when "hardware hacking" (as we've traditionally known it) will have to fall by the wayside? If so - what, if anything, do you see as taking its place? (Perhaps users taking advantage of the vastly more-powerful gear out there today and building their own hackable hardware, eliminating the need to hack other people's hardware?)

I suppose that's tangentially related to the wireless.net question - for mass distribution of the tools needed to build such a network, for instance, it seems to me that re-purposing cheap, widely-available stuff that others have junked is a better path than having to build things from scratch. But if the cheap, widely-available stuff of the future isn't gonna be re-usable... where does one go from there?

L0pht:
It is true that the Electronics industry is moving toward much denser Multi-chip module like IC's. System-on-a-chip (SOC) is beginning to make inroads in communications equipment. Celluar/GSM/PCS phones are beginning to sport such technology. SOC will also revolutionize the security coprocessor industry.

What we see here is the bar being raised in the HW hacking arena. Remember cost still drives much of the industry and you will continue to see many devices still using microcontrollers. There are many, many internet appliances using standard Embedded Processors and peripheral IC's. The hackers are just going to have to bone up on thier FPGA hacking skillz. Monitoring the inputs of an FPGA and then the outputs, and hacking together an FPGA to drop inbetween isn't unheard of.

Hardware hacking today does require a bit more than the standard weller solding iron, a 50Mhz scope, and a multimeter. With processor speeds moving up into the 800Mhz range, you fall flat on your face with those stoneage tools. The trend in general is hardware which is becoming more and more abstracted and described by high-level programming languages such as verilog and VHDL. One must stay abreast of the latest tools in his trade. There are also relatively inexpensive "soft" tools, in that a spectrum analyzer, logic analyzer or a scope utilizes the modern PC as the guts of the device and an inexpensive physical interface module is purchased along with software for the host. The interface is typically a data acquisition pod for converting the sampled analog data into the host PC for processing and the presentation.

The security of FPGA's is definately going to become more of a target in the future. I can't think of anyone that doesn't set the security bit of FPGA before programming a device. Ummm.. Hmmm.. maybe I shouldn't say that. ;^) It does happen. There are also some not so well known ways around "securty bits" on FPGA's. Also, most FPGA's will allow you to reprogram them in circuit whether or not the security bit is blown. You just better be sure you can reproduce what you monitored before squirting in your own code.

Remember there are many more ways to fry an egg, such as voltage margining, or operating a circuit over/under current and temperature specifications. Hitting HW with various RF emissions (above and beyond what stantard emissions/immunities tests test for.) can also produce interesting results and insights.

And as you alluded to in your question, hackers will build their own hardware which will interface to the service/system under attack, which will allow for variable, marginable, modules to provide the flexibilty which the stock standard HW didn't provide. Study communications test equipment. Many secrets lie inside.

A lot of today's "hardware hacking" isn't strictly limited to hardware, due to the fact that most products are embedded systems - meaning there is a union of hardware and software. Those who are strictly "hardware guys" will fall by the wayside and those who are strictly "software guys" will also fall. You will need to have a decent knowledge of both the software and the hardware environment you are programming for. I have seen companies struggle because they hire CS folks to write firmware for a product. These particular folks could not grasp that they were writing for a platform other than a PC or desktop. They didn't understand how interrupts worked, how to write to a port, how to write low-level drivers to control external memory or other devices on an SPI, I2C or other inter-chip protocol. What ended up happening is the company called in the hardware engineer (me) to write all the low-level functionality. In order to properly design a product (and reverse engineer the product), you need to be able to grasp all facets...

The industry today is really in a sad state and I am fearful of the quality of the products that are due to come out on the market - the hardware and circuitry is sound and well-structured, but the software will have major fault and, because of this, many possibilities for vulnerabilities.

C) The future of l0pht.
(At least publicly), there's been a lot more activity on the software side of l0pht than on the hardware side.

To the extent that you can discuss it openly, do you see l0pht's main activities over the next 3-5 years as continuing to revolve around the "expose weaknesses in software" side or the "work on next-generation hardware projects" side?

L0pht:
Both. Hardware projects, since the beginning of time, are more costly, require more tools than software, and mroe often than not, more time consuming. Due to this, the amount of publicly-known activity appears to be less. As mentioned before, there will be more and more projects that require the knowledge of both hardware and software sides, where L0pht fits the bill perfectly. There are so many products and technologies to look at, there is no way we can limit ourselves by saying what activities we will and will not do. If something comes out, be it hardware or software, that we want to attack, we will.

8)What engines/sites do you use to scour the 'Net?
by Bacteriophage
Seriously, I would like to know. When you sometimes don't have all the answers (I assume that would be more than never), where do you guys go on the 'Net to find what you need concerning computer security, **/*acking, or even just news? Do you ever come to /.? This answer shouldn't take very long, and it'd be nice to get the seperate preferences of each crew member, as well as the general preferences of the group.

L0pht:

Generic search:

Altavista or NorthernLight for a spider based search Yahoo for a topic search.

Ask Jeeves when I don't really know what it is I am looking for.

security/hacking: altavista - word sequences work well. A recent example would be a search for the PCI specification by looking for "pci spec".

yahoo - when altavista doesn't help

Hacker search:

• The Hacker News Network Search Engine Page - Lots of undergound spiders http://www.hackernews.com/search.html
• attrition stats - http://www.attrition.org/mirror/attrition/stats.html
• eEye stats - http://www.eeye.com/html/Databases/Statistics/os.html
• NMRC - Good Novell NT and Unix info. www.nmrc.org
• counterpane - for books (through amazon) and lots of free information on crypto too.
• www.jya.com/crypto.htm - for the good cypherpunk info

------

Next week: Steve Wozniak (and a special pair of *surprise* guests Tuesday).

Yes, it's "year-end double-bonus interview week" on Slashdot. First, L0pht Heavy Industries. Yes, the world's most publicized infosec group, the one trotted out by TV and other mainstream media reporters whenever they want pithy (but authoritative) quotes about hacking and cracking and that sort of thing. The L0pht guys have heard all the (ho-hum) obvious questions already. They expect extra-smart ones from you, and we don't doubt for a second that you'll provide them. ;-) One question per post, please.

Most of the questions we got for crypto guru Bruce Schneier earlier this week were pretty deep, and so are his answers. But even if you're not a crypto expert, you'll find them easy to understand, and many of Bruce's thoughts (especially on privacy and the increasing lack thereof) make interesting reading even for those of you who have no interest in crypto because you believe you have "nothing to hide." This is a *long and strong* Q&A session. Click Below to read it all.

First Bruce says, by way of introduction...

"I'd like to start by thanking people for sending in questions. I enjoyed answering all of them.

"I've written on many of these topics before, and often I will point to existing writings on my Web site or in my Crypto-Gram newsletter. This isn't to be annoying; it just seems useful to point to things I have already written. I urge anyone interested to sign up for a free subscription to Crypto-Gram. I write it monthly, and I regularly answer questions such as these, or write about topics in the news (especially ones that have been reported on badly). To subscribe, visit my Web site at www.counterpane.com/."

ryanr asks:
I've heard you say many times that unless a particular crypto alg. has undergone lots of public review, it should not be considered safe. Unless possibly it's from the NSA. (Excluding, of course, the NSA stuff that is INTENTIONALLY backdoored.)

The implication there is that the NSA has applied some many resources to the crypto problems, that they are as good as the rest of the cryptographers put together.

My question is: Do you really think that a private process, no matter how many resources applied, can equal the public process?

ANSWER:
Yes. One way of looking at a public process is as a large and distributed private process. If the NSA collected all of the academic cryptographers, gave them a clearance, and locked them in a basement somewhere, it would become a private process. The real issue is whether or not the NSA has equivalent expertise to the public academic community, and whether it can apply that expertise in an effective manner.

The NSA has a lot more cryptographic experience in the narrow fields of making and breaking algorithms. They have been doing this, and nothing else, for decades. I don't believe that they have much expertise in weird digital signature schemes, or zero-knowledge protocols, or even more bizarre electronic commerce and voting schemes, because they aren't really of practical interest. But the NSA certainly has a very strong practical interest in algorithm design and analysis, to a much greater degree than we in the public community do. And they have seen a lot more ciphers: both designs that they have proposed internally and designs in production systems that they have tried to attack.

The NSA also has the ability to target its analysis resources. The public academic community is scattershot. We work on what interests us, and we are each interested by different things. A director at the NSA has the ability to take the top ten cryptanalysts in the building and say: "You. Go into that room and don't come out until you've broken RC4. I don't care if it takes two years." That ability to direct resources at particular problems gives them an edge that we don't have.

But how much of an edge? Until recently, I would have stated unquestionably that the NSA is a decade ahead of the state of the art in cipher design and analysis. Now, I'm not so sure.

Over the past five years, there has been a lot of open research in cryptography. We have discovered many different types of attacks, and have learned a lot about how to design ciphers. The best and brightest of the cryptographers are staying in the open academic community, and are not being swallowed up by the NSA (or by its counterparts in other countries). There is a vibrant academic community in cryptography; people can exchange ideas, share research, build on each other's work. We've seen attacks against the NSA-designed algorithm Skipjack that almost certainly were not known by the NSA. (See http://www.counterpane.com/crypto-gram-9807.html#skip for Skipjack information, and http://www.counterpane.com/crypto-gram-9809.html#impossible for information on impossible-differential cryptanalysis.) We've seen other attacks that, I believe, were not known by the NSA. (See http://www.counterpane.com/mod3.html for more information.) The public research community is now doing cutting-edge research in cryptography.

Now this doesn't mean we are better than they are. Certainly the NSA knows more about cryptography than the public community does. They read everything we publish, and we read nothing that they publish. Almost by definition, they know what we do. That imbalance alone will always give them an edge in knowledge. But I think that edge is closing rapidly.

And on a related topic, I don't think the recent press flap about the NSAKEY means that the NSA has a backdoor in Microsoft Windows. I wrote about this in HREF="http://www.counterpane.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI. But I do think that the NSA deliberately puts back doors in products; seehttp://www.counterpane.com/crypto-gram-9902.html#backdoors for some details.

Sajma asks:
Your book describes a slew of interesting applications for crypto protocols, including electronic money orders, digital time-stamping, and secure multi-party computation. What are the remaining crypto problems of interest to the general public which have not been solved? (secure distribution of digital media comes to mind -- can you sell someone a music file, allow them to use the file anywhere, but make sure no one else can use it?)

- SEE NEXT QUESTION -

randombit asks:
OK, hypothetical question. You rub a magic lamp, and a genie comes out. Specifically, a cryptographic protocol genie. He can come up with an efficient, secure protocol for any activity you want (assuming a protocol is possible, of course). What would you pick, and more importantly, why?

ANSWER:
Two questions; one answer. We actually have all the protocols we need. It's true that I described all sorts of interesting protocols in _Applied Cryptography_. The reality is that none of them is actually useful. What is useful are the few simple primitives -- signatures, encryption, authentication -- and the different ways to mirror real-life trust models using them. These protocols are simpler, easier to understand, and more useful.

The real problem with protocols, and the thing that is the hardest to deal with, is all the non-cryptographic dressing around the core protocols. This is where the real insecurities lie. Security's worst enemy is complexity.

This might seem an odd statement, especially in the light of the many simple systems that exhibit critical security failures. It is true nonetheless. Simple failures are simple to avoid, and often simple to fix. The problem in these cases is not a lack of knowledge of how to do it right, but a refusal (or inability) to apply this knowledge. Complexity, however, is a different beast; we do not really know how to handle it. Complex systems exhibit more failures as well as more complex failures. These failures are harder to fix because the systems are more complex, and before you know it the system has become unmanageable.

Designing any software system is always a matter of weighing and reconciling different requirements: functionality, efficiency, political acceptability, security, backward compatibility, deadlines, flexibility, ease of use, and many more. The unspoken requirement is often simplicity. If the system gets too complex, it becomes too difficult and too expensive to make and maintain. Because fulfilling more of the other requirements usually involves a more complex design, many systems end up with a design that is as complex as the designers and implementers can reasonably handle. (Other systems end up with a design that is too complex to handle, and the project fails accordingly.)

Virtually all software is developed using a try-and-fix methodology. Small pieces are implemented, tested, fixed, and tested again. Several of these small pieces are combined into a larger module, and this module is tested, fixed, and tested again. The end result is software that more or less functions as expected, although we are all familiar with the high frequency of functional failures of software systems.

This process of making fairly complex systems and implementing them with a try-and-fix methodology has a devastating effect on security. The central reason is that you cannot easily test for security; security is not a functional aspect of the system. Therefore, security bugs are not detected and fixed during the development process in the same way that functional bugs are. Suppose a reasonable-sized program is developed without any testing at all during development and quality control. We feel confident in stating that the result will be a completely useless program; most likely it will not perform any of the desired functions correctly. Yet this is exactly what we get from the try-and-fix methodology with respect to security.

The only reasonable way to "test" the security of a system is to perform security reviews on it. A security review is a manual process; it is very expensive in terms of time and effort. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure. The more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification, design, and implementation. We claim that the number of errors and difficulty of the evaluation are not linear functions of the complexity, but in fact grow much faster.

For the sake of simplicity, let us assume the system has n different options, each with two possible choices. Then, there are about n^2 different pairs of options that could interact in unexpected ways, and 2^n different configurations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that involve several options is huge. We therefore expect that the number of actual security weaknesses grows very rapidly with increasing complexity.

The increased number of possible interactions creates more work during the security evaluation. For a system with a moderate number of options, checking all the two-option interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses and a more difficult security analysis unavoidably results in insecure systems.

In actual systems, the situation is not quite so bad; there are often options that are "orthogonal" in that they have no relation or interaction with each other. This occurs, for example, if the options are on different layers in the communication system, and the layers are separated by a well-defined interface that does not "show" the options on either side. For this very reason, such a separation of a system into relatively independent modules with clearly defined interfaces is a hallmark of good design. Good modularization can dramatically reduce the effective complexity of a system without the need to eliminate important features. Options within a single module can of course still have interactions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actual systems still include cross-dependencies where options in different modules do affect each other.

A more complex system loses on all fronts. It contains more weaknesses to start with, it is much harder to analyze, and it is much harder to implement without introducing security-critical errors in the implementation.

This increase in the number of security weaknesses interacts destructively with the weakest-link property of security: the security of the overall system is limited by the security of its weakest link. Any single weakness can destroy the security of the entire system.

Complexity not only makes it virtually impossible to create a secure system, it also makes the system extremely hard to manage. The people running the actual system typically do not have a thorough understanding of the system and the security issues involved. Configuration options should therefore be kept to a minimum, and the options should provide a very simple model to the user. Complex combinations of options are very likely to be configured erroneously, resulting in a loss of security. There are many stories throughout history that illustrate how management of complex systems is often the weakest link.

I repeat: security's worst enemy is complexity. The most serious protocol problem is how to deal with complex protocols (or how to strip them down to the bone).

Get Behind the Mule asks:
Bruce, thanks very much for making cryptography so much more accessible to us all.

You wrote in Applied Cryptography that IDEA was your "favorite" symmetric cipher at the time. Is that still true today?

ANSWER:
It depends what you mean by "favorite." If I needed a secure symmetric algorithm for a design, and performance were not an issue, I would choose triple-DES. No other algorithm has been as well-studied, so nothing can compare in confidence.

The problem is that triple-DES is slow; on a 32-bit microprocessor it encrypts data at a rate of 108 clock cycles per byte. (You have to remember that DES was designed in the mid-1970s for discrete hardware. It is very slow on 32-bit microprocessors.) If I need a faster algorithm, I would use Blowfish. Blowfish encrypts data at a rate of 18 clock cycles per byte. Information on Blowfish is at http://www.counterpane.com/blowfish.html.

Neither is my favorite algorithm. Currently, my favorite algorithm is Twofish. Twofish is our submission to AES. It is still too new to use operationally, but I hope it will see wide use as people analyze it and as confidence grows in its security. Information on Twofish is at http://www.counterpane.com/twofish.html. It's even faster than Blowfish, and (I think) much better designed.

Faster algorithms are more problematic. I don't really like RC4. SEAL is better, but patented by IBM. I don't care for WAKE. I would probably use one of Belgian cryptographer Joan Daemen's designs.

I don't recommend IDEA anymore for several reasons. One, it isn't very fast; on a 32-bit microprocessor it encrypts data at a rate of 50 clock cycles per byte. Two, IDEA is patented, and the terms change regularly. Also, attacks against IDEA have steadily eaten away at the security margin. IDEA has eight rounds, and the current best attack breaks 4.5 rounds. There are still no attacks against the full eight-round cipher, and there is no reason to believe that any are possible. Still, since there are algorithms with much better performance, it seems improper to suggest IDEA.

Speed comparisons of other algorithms can be found at http://www.counterpane.com/speed.html. A detailed paper comparing performance of the AES candidates can be downloaded at http://www.counterpane.com/aes-performance.html. And for a current summary of attacks against various algorithms, see http://www.ii.uib.no/~larsr/bc.html.

Remember, though -- breaking the cryptographic algorithm is almost never the way to attack a security product. There is almost always an easier way to break the security. I've written about this extensively; see http://www.counterpane.com/whycrypto.html and http://www.counterpane.com/pitfalls.html in particular.

Tet asks:
Scott McNealy claims we've already fought and lost the war for personal privacy. Do you agree with him or not, and why?

ANSWER:
One hundred years ago, everyone could have personal privacy. You and a friend could walk into an empty field, look around to see that no one else was nearby, and have a level of privacy that has forever been lost to today's technology. The framers of the Constitution never explicitly put a right to privacy into the document; it never occurred to them that it could be withheld. The ability to have a private conversation, like the ability to keep your thoughts in your head and the ability to fall to the ground when pushed, was a natural consequence of the world. When the Supreme Court found a right to privacy in the Constitution, it's because the language of the Constitution assumed its existence.

Technology has demolished that worldview. Powerful directional microphones can pick up conversations hundreds of yards away. Pinhole cameras -- now being sold over the Internet -- can hide in the smallest cracks; satellite cameras can read the time on your watch from orbit. And the Defense Department is prototyping micro-air vehicles, the size of small birds or butterflies, that can scout out enemy snipers, locate hostages in occupied buildings, or spy on just about anybody.

In the aftermath of the terrorist takeover of the Japanese embassy in Peru, news reports described audio bugs being hidden in shirt buttons that allowed police to pinpoint everyone's location. Van Eck devices can read what's on your computer monitor from halfway down the street. (I heard that the CIA demonstrated this for Scott McNealy at Sun; they captured his password from a van in the company's parking lot.) Lasers bounced off windows can reveal the Doppler effect of compression and rarefaction of air by soundwaves, and eavesdrop on conversations happening on the other side. If an attacker can plug into your power line, it can read it from even further away. Purchase anything lately? Unless you use cash, what, where, and when is recorded in a database. And in many stores, a security camera has recorded your presence while the helpful sales clerk captures your name and personal information.

The ability to trail someone remotely has existed for a while, but it is only used in exceptional circumstances. In 1993, Colombian drug lord Pablo Escobar was found partly by tracking him through his cellular phone usage. Timothy McVeigh's truck was found because the FBI collected the tapes from every surveillance camera in the city, correlated them by time (presumably the explosion acted as a great synch pulse), and looked for it. During Desert Storm the U.S. dropped thousands of miniature robots -- millimeters in diameter -- on Iraq that looked for signs of biological warfare.

The technology to automatically search for drug negotiations in random telephone conversations, for suspicious behavior in satellite images, or for faces on a "wanted list" of criminals in on-street cameras isn't here yet, but it's just a matter of time. Face-recognition software can pick individual faces out of a crowd. Voice recognition will soon be able to scan millions of telephone calls, listening for a particular person; it can already scan for suspicious words or phrases. Moore's Law, which says the industry can double the computing power of a microchip every 18 months, affects surveillance computing just as it does everything else: the next generation will be smaller, faster, and a lot cheaper. As soon as the recognition technologies can find the people, the computers will be able to do the searching automatically.

At the same time, the fear of crime is facilitating a great deal of surveillance, not all of it instigated by the police. Some U.S. airports automatically record the license plates of anyone coming onto airport property, even if it is just to pick up someone. Some cities are installing directional microphones to pinpoint gunfire; others are setting video cameras on lampposts to deter crime. It's getting difficult to walk into a store without being videotaped. Timothy McVeigh couldn't drive a truck through downtown Oklahoma City without it showing up on an in-store surveillance camera, and these cameras were positioned to protect the store, not to track goings-on outside the windows.

The U.S. is initiating a program called "computer-assisted passenger screening," or CAPS. The idea is to match commercial air travelers against profiles of evildoers, using such items as the traveler's address, credit card number, destination, whether or not he is traveling alone, whether the ticket was paid in cash, when the ticket was purchased, whether it was one-way or round trip, and about three dozen other factors that are being kept secret. Needless to say, groups like the ACLU have objected to stopping and searching people based on stereotypes. Not to mention that the data is saved, just in case the government needs to peek into people's pasts. No warrant required, of course.

More is coming. Out of concern for public safety, the FCC has ruled that by 2001, cellular and PCS companies must be able to locate users who dial 911 to within a radius of 125 meters. Consumers will foot this bill through a user tax, and you can be sure that wireless operators will introduce a plethora of other services based on this technology. The companies are probably going to use the cellular technology to locate people, although if they can wait a couple of technological generations they can drop miniature GPS receivers in the phones and do even better. One way or another, people will end up carrying technology that allows them to be digitally tailed. And currently, no warrant is required.

The surveillance infrastructure is being installed in our country under the guise of "customer service." Some hotels track guest preferences in international databases, so that customers will feel at home even if it is their first stay in a particular city. Caterpillar Corporation is installing diagnostic chips into all new farm machinery. These chips alert the local dealer, via satellite, when a part is failing. The dealer can then drive to the farm with a replacement, often before the machine has even broken down. This is great; I'll bet farmers really like the prompt service and the reduction in downtime. But the same technology can be used for other, less benign, purposes.

Automobile surveillance is almost automatic. Rental cars, equipped with GPS navigational systems, can keep a complete record of exactly where that car has been. Mercedes Benz is planning on embedding a Web server into its cars, so that technicians can spot service problems remotely. At least two companies plan on marketing a smart car locator that uses a GPS receiver and a cellular phone to alert the authorities to your whereabouts in case of an emergency. It only takes a slight modification to allow the locator to work automatically when queried by the police. Lojack, the device that can track your car if it has been stolen, can also be used for surveillance. Will net-connected smart cars give police the ability to track everybody in the country simultaneously? Already systems like Lojack do this, as do car phones.

GPS is a dream technology for surveillance. One company is selling an automatic warehouse inventory system, using GPS and affixable transmitters on objects. The transmitters broadcast their location, and a central computer keeps track of where everything is. Spies have probably been able to use this kind of stuff for years, but it's now becoming a consumer item.

Individual privacy is being eroded from a variety of directions. Most of the time the erosions are small, and no one kicks up a fuss. But there is less and less privacy available, and most people are completely oblivious of it. It is very likely that we will soon be living in a world where there is no expectation of privacy, anywhere or at any time.

rise asks:
As one of the stronger voices behind the proposition that only peer reviewed, open, and thoroughly tested algorithms can be trusted you've widely disseminated several algorithms, Solitaire and Yarrow among them. What attacks or interesting analyses have surfaced since their release?

ANSWER:
For those who want to know what he is asking about, you can read about Solitaire at http://www.counterpane.com/solitaire.html, and about Yarrow at http://www.counterpane.com/yarrow.html. And you can read about my position on the importance of using a public, peer-reviewed algorithm at http://www.counterpane.com/crypto-gram-9904.html#different, my snide comments about proprietary cryptography at http://www.counterpane.com/crypto-gram-9902.html, and my dismissing of cracking contests at http://www.counterpane.com/crypto-gram-9812.html#contests.

There has been some excellent analysis of Solitaire by Paul Crowley. He has posted his results to the sci.crypt newsgroup, and you can look them up. Briefly, he found a bug in the code and a problem with the algorithm. I will fix the bug in the code as soon as I get around to it, but the problem with the algorithm is more disturbing. We hope to write a joint paper documenting the problem, and proposing a fix.

I don't think it is a problem operationally, though. Solitaire is a pencil-and-paper cipher designed for very short messages, and the attack will require a lot of ciphertext. Still, it is a problem and one that I should fix.

As to Yarrow, I don't know any outside cryptanalysis. I'd like to see some.

Thagg asks:
I bought your first edition of Applied Cryptography, and you say two things that bother me, with respect to your submission of Twofish as a Federal standard for encryption.

In the forward, you describe how you got interested in cryptography, and that you had no background or training in the field, but you thought it was interesting. Also, several times throughout the book you caution people not to trust cryptosystems from amateurs.

Clearly you have become well versed in the history and application of cryptography, your book makes all other descriptions of the state of the art invisible by comparison. Still, it appears to me that cryptosystem design and analysis requires fairly extreme mathematical proficiency, which I do not believe that you have.

Now, of course, Twofish is published in detail, and the best people in the world have attempted to crack it (and I think that the competitive process that the US Gov't has promoted is a spectacular way to get the best people to attack each other's ciphers). But, I remain somewhat worried that at the foundations of Twofish...is there something missing that a PhD in mathematics and number theory would have seen?

The winner of this competition will likely be the next DES, and will provide security for a fairly large percentage of the planet. The stakes are high. I'm sure that you have an answer to this criticism, and I'm eager to hear it.

ANSWER:
Certainly you should not trust cryptographic algorithms designed by people who have no experience designing and analyzing cryptographic algorithms. The question you ask is different. You are asking if a Ph.D. in mathematics and number theory gives someone any special insights that someone without the Ph.D. would miss. I believe that cryptographic experience is something that is learned through both training and through experience, and that someone with a Ph.D. is not automatically a better cryptographer.

Cryptography is interesting, because there are no absolute metrics. Anyone can design an algorithm that he himself cannot break. This means that anyone, from the best cryptographer to the sorriest man on the street, can design a cryptographic algorithm that works: that encrypts and decrypts data properly, and that the designer cannot break. The false reasoning that often follows is this: "I can't break it, therefore it is secure." The first question that anyone else should ask is: "You say you can't break it; well, who the hell are you?" More on this topic can be found at http://www.counterpane.com/crypto-gram-9810.html#cipherdesign.

The experience of the designers is something that I look at very carefully when I evaluate an algorithm. I can't devote the months and years necessary to convince myself that an algorithm is secure, so I want to know about the people who are convinced. And I don't look at their academic degrees; I look at what else they have broken.

The Twofish team has dozens of published cryptanalytic attacks, breaking all kinds of ciphers. (A list of Counterpane papers can be found at http://www.counterpane.com/publish.html, and David Wagner's published papers can be found at http://www.cs.berkeley.edu/~daw/.) These are impressive results: mod n cryptanalysis, boomerang attacks, slide attacks, side-channel cryptanalysis, related-key differential cryptanalysis, and attacks against Skipjack, Speed, Akelarre, RC5a, CMEA, ORYX, TwoPrime, etc., etc., etc. Interestingly enough, all five AES finalists have been designed by teams that have a similarly impressive list of published cryptanalytic attack. With a couple of exceptions, none of the non-finalists have any cryptanalysts on their teams.

Another thing to look at is the quality of the designer's analysis. I like designs that have long and detailed documents that discuss how the designers have attacked their own design. You can see this in the submissions for Twofish, and for Mars, RC6, and E2. I worry about a cipher like Serpent that does not come with any analysis. Either the designers didn't do any, which is bad -- or they did it and are hiding it, which is worse.

I think these things speak more to the strength of the design than academic degrees.

In fact, I have seen many systems designed by Ph.D. mathematicians with little cryptographic experience, that have been quickly broken. Experience in cryptography is much more important than experience in general mathematics.

It is certainly possible that there are attacks against an algorithm that the designers missed. This is why AES is a public process. Before AES is chosen, dozens of people with Ph.D.s in mathematics will be performing their own analyses on the submissions. If Twofish is chosen, it will because none of those Ph.D.s have found any weaknesses.

But if you want Ph.D.s on the Twofish team, co-designer Doug Whiting has a Ph.D. in computer science from CalTech. His dissertation was on building Reed-Solomon error-correcting codes in VLSI, so it had a heavy math content.

Enoch Root asks:
It was noted in your biography that you hold a degree in Physics in addition to your M.S. in Computer Science. This seems to be a developing trend in IT, as many Physics graduates turn to CS. Neal Stephenson undertook studies in Physics before becoming a writer. I am myself a physics graduate turned computer geek.

What impact do you think your science studies have on your current career? I suspect the high mathematical background of physics prepared you for cryptology, but what other aspects of a science degree come into play in your line of work? Would you call your B.S. in Physics an advantage or a disadvantage?

ANSWER:
The unfortunate answer is that it wasn't very relevant. It was neither an advantage nor a disadvantage, although it was harder to get a job out of college with a physics degree. Physics teaches mathematics, and that was helpful.

If you want to become a cryptographer, study mathematics and computer science. I wrote an essay on this very topic; see http://www.counterpane.com/crypto-gram-9910.html#SoYouWanttobeaCryptographer.

Hobbex asks:
One would think that cryptographers, who study the mathematical means for controlling information (not just secrecy, but also signatures, zero knowledge proofs etc) would be the least inclined to support the artificial limits to information set up by our legal system, and yet the field is littered with patents (probably more so than any other field of mathematics).

You, on the other hand, have been very generous with your algorithms and cryptos. Is there a political, ideological, or practical reason behind this?

ANSWER:
It is impossible to make money selling a cryptographic algorithm. It's difficult, but not impossible, to make money selling a cryptographic protocol.

Look at algorithms first. There are free encryption algorithms all over the place: triple-DES, Blowfish, CAST, most of the AES submissions. Look again at the URLs attached to question 6. It makes sense for a designer to use one of these public algorithms. If I patented Blowfish, no one would have used it. No one would have analyzed it. (Why would they do work for free, if I were making money off of it?) Only because Blowfish is free is it in over 100 products. (For a list, see A HREF="http://www.counterpane.com/products.html">http://www.counterpane.com/products.html.) If I patented it and charged for it, it would be much less widely used. IDEA is a good example of this. IDEA could have been everywhere; for a while it was the only trusted DES replacement. But it was patented, and there were licensing rules. As a result, IDEA is barely anywhere. SEAL is a great-looking stream cipher. But because IBM has a patent on it, no one uses it.

The early public-key patents are the only exception to this. Because the patents controlled the concept of public-key cryptography, there was no way to do public-key encryption, key exchange, or digital signatures without licensing the patents. This exception is over; the Diffie-Hellman patents have expired.

Regularly I hear from algorithm inventors who want to patent their new cool algorithm and then sell it. This business plan has absolutely zero percent chance of succeeding. I recommend that people give their cryptography away, and use the PR benefit to make a living. If the IDEA patent holders did that, they would be much better off.

Protocols are a little bit different. You can patent a protocol and turn it into a useful business. It's hard; most of the time a competitor can engineer around a protocol patent. But it is possible, and many companies are making a go at marketing patents in authentication, certificate revocation, digital content protection, etc. I'm not thrilled by this, but it's the reality of American business today.

aheitner asks:
As many know, your Twofish algorithm is one of the (many) submissions to become the AES standard. The goal for these algorithms is to be able to implement them extremely cheaply in hardware -- say on a 6800 with 256 bytes of RAM. In other words, cheaply enough to put on a smart card.

But IBM's team alleges that any algorithm that simple can be fairly easily cracked by doing a power usage analysis on the chip (by watching fluctuations in the electrical contacts with the reader) and that the necessary equipment to protect against power analysis would be equivalent to a much more complex processor -- so much so you might as well just implement a different and more complex (and hopefully power-random) algorithm. Of course IBM suggests their own implementation.

What do you think? Is there a way to build a simple smart card so that power analysis isn't a problem? Perhaps the whole question will become irrelevant since we'll be carrying around so much processing power in our PDAs that we'll just use them?

ANSWER:
Power analysis involves breaking a cryptographic algorithm by looking at the power trace from a chip executing that algorithm. This is a specific case of what I call "side-channel attacks." I wrote about side-channel attacks at http://www.counterpane.com/crypto-gram-9806.html#side, and some excellent information on power analysis can be found at http://www.cryptography.com/dpa/index.html.

I don't believe it is possible to create a cryptographic algorithm that, because of its mathematics, is immune from side-channel attacks.

Any cryptographic primitive, such as a block cipher or a digital signature algorithm, can be thought of in two very different ways. It can be viewed as a mathematical object; typically, a function taking an n-bit input and producing an m-bit output. Alternatively, it can be viewed as a concrete implementation of that mathematical object. Traditionally, cryptanalysis has been directed solely against the mathematical object, and the resultant attacks necessarily apply to any concrete implementation. The statistical attacks against block ciphers -- differential and linear cryptanalysis -- are example of this; these attacks will work against DES regardless of which implementation of DES is being attacked.

In the last few years, new kinds of cryptanalytic attacks have begun to appear in the literature: attacks that target specific implementation details. Both timing attacks and differential fault analysis make assumptions about the implementation, and use additional information garnered from attacking certain implementations. Failure analysis assumes a one-bit feedback from the implementation -- was the message successfully decrypted -- in order to break the underlying cryptographic primitive. Related-key cryptanalysis also makes assumptions about the implementation, in this case about related keys used to encrypt different texts. Side-channels attack are a generalization of this idea.

These attacks don't necessarily generalize -- a fault-analysis attack just isn't possible against an implementation that doesn't permit an attacker to create and exploit the required faults -- but can be much more powerful. For example, differential fault analysis of DES requires between 50 and 200 ciphertext blocks (no plaintext) to recover a key.

A side-channel attack occurs when an attacker is able to use some additional information leaked from the implementation of a cryptographic function to cryptanalyze the function. Clearly, given enough side-channel information, it is trivial to break a cipher. An attacker who can, for example, learn every input into every S-box in every one of DES's rounds can trivially calculate the key. What is surprising is how little side-channel information is necessary to break an algorithm. I have published a paper on side-channel attacks against block ciphers at http://www.counterpane.com/side_channel.html.

You can't design the math to solve this problem. You can try to design he hardware so that side-channel information does not leak; this seems to be far more difficult than it appears. Or you can design your cryptographic protocols so that side-channel attacks don't matter. This makes the most sense. Choosing AES based on side-channel resistance is short-sighted.

A long digression on AES, for those who haven't been following the process and for those who care about the outcome: AES is the Advanced Encryption Standard, the new encryption algorithm that will replace DES. NIST is in the process of defining a new encryption standard, which will have a longer key length (128-, 192-, and 256-bit), larger block size (128-bit), be faster than DES, be patent-free, and hopefully will remain strong for a long, long time.

The process is an interesting one. In 1997, NIST sent out a request for candidate algorithms. They received fifteen submissions by the June 1998 deadline, five from the U.S. and ten from other countries. In August, we (my own algorithm, Twofish, was one of the submissions) presented our algorithms to the world at the First AES Candidate Conference.

There was a Second AES Candidate Conference in Rome in March 1999, where people presented analyses of the algorithms. NIST chose five finalist algorithms this summer: Mars, RC6, Rijndael, Serpent, and Twofish. There will be a third AES Candidate Conference in New York in April 2000. NIST is also accepting public comments on the algorithms through 15 April 2000. Finally, NIST will choose an algorithm to become the standard (or perhaps more than one algorithm).

Cryptographers are busily analyzing the submissions for security. It's tempting to think of the process as a big demolition derby: everyone submits their algorithms and then attacks all the others...the last one standing wins. Really, it won't be like that. I strongly believe at the end of the process most of the candidates will be unbroken. The winner will be chosen based on other factors: performance, flexibility, suitability.

This means that we need your input into this process. I know you're not cryptographers, and you won't be able to comment on the mathematics of the various submissions. But you can comment on your encryption requirements, and whether the algorithms will suit your needs.

• AES will have to work in a variety of current and future applications, doing all sorts of different encryption tasks. Specifically:
• AES will have to be able to encrypt bulk data quickly on top-end 32-bit CPUs and 64-bit CPUs. The algorithm will be used to encrypt streaming video and audio to the desktop in real time.
• AES will have to be able to fit on small 8-bit CPUs in smart cards. To a first approximation, all encryption DES implementations in the world are on small CPUs with very little RAM. It's in burglar alarms, electricity meters, pay-TV devices, and smart cards. Sure, some of these applications will get 32-bit CPUs as those get cheaper, but that just means that there will be another set of even smaller 8-bit applications.
• AES will have to be efficient on the smaller, weaker, 32-bit CPUs. Smart cards won't be getting Pentium-class CPUs for a long time. The first 32-bit smart cards will have simple CPUs with a simple instruction set. 16-bit CPUs will be used in embedded systems that need more power than an 8-bit CPU, but can't afford a 32-bit CPU.
• AES will have to be efficient in hardware, in not very many gates. There are lots of encryption applications in dedicated hardware: contactless cards for fare payment, for example.
• AES will have to be key agile. There are many applications where small amounts of text are encrypted with each key, and the key changes frequently. This is a very different optimization problem than encrypting a lot of data with a single key.
• AES will have to be able to be parallelized. Sometimes you have a lot of gates in hardware, and raw speed is all you care about.
• AES will have to work on DSPs. Sooner or later, your cell phone will have proper encryption built in. So will your digital camera and your digital video recorder.
• AES will need to be secure as a hash function. There are many applications where DES is used both for encryption and authentication; there just isn't enough room for a second cryptographic primitive. AES will have to serve these same two roles.
• AES needs to be secure for a long time. Infrastructure is hard to update. Like DES, AES hardware is likely to be installed and used for decades. A radical new algorithm, with interesting and exciting ideas, just doesn't make sense. A conservative algorithm is what is needed.

Choosing a single algorithm (or even a pair of algorithms) for all these applications is not easy, but that's what we have to do. It might make more sense to have a family of algorithms, each tuned to a particular application, but there will be only one AES. And when AES becomes a standard, customers will want their encryption products to be "buzzword compliant." They'll demand it in hardware, in desktop computer software, on smart cards, in electronic-commerce terminals, and other places we never thought it would be used. Anything we pick for AES has to work in all those applications.

So how do you comment? NIST is accepting formal comments either on paper or by e-mail. See http://www.nist.gov/aes for instructions. Be sure to identify who you represent and what cryptography interests you have. And if you have any weird cryptography applications or environments, tell me. I'd like to know. Remember, the AES is going to be your cryptography standard for the 21st century. Tell NIST what you think.

Christopher B. Brown
Several announcements have been made lately about ciphers being assortedly vulnerable/invulnerable against Quantum cryptography.

Quantum physics seems to be the "magical" form of physics, and its application to cryptography even more magical. I don't think I properly understand "quantum cryptography," and I don't think that most of the people that have made public comment on it understand it terribly well either.

Could you comment on the present state of Quantum cryptography, and its probable relevance in public matters short term (which appears nonexistent), medium term (where the research of today may be in 5-10 years), and longer term?

ANSWER:
There are two separate applications of quantum mechanics to cryptography: quantum computing and quantum cryptography. I think you are conflating the two. Let me take them up in turn.

Quantum cryptography is a means of using quantum mechanics for key exchange. Basically, because it is impossible to measure the state of a quantum system without disturbing it, the physics of the key-exchange protocol allows you to detect eavesdroppers. It's a cool idea, and I spend a few pages in _Applied Cryptography_ explaining it in detail.

Quantum computing is newer. It turns out that it is theoretically possible to build a quantum computer. And, if you can build such a beast, it can factor large numbers and calculate discrete logarithms efficiently. Hence, it renders pretty much all of public-key cryptography insecure.

Both of these things are pretty far out. Quantum cryptography has been demonstrated in the lab; British Telcom researchers have exchanged keys over a 10km fiber-optic link. This is interesting, but I don't see it being used very much. The mathematics of cryptography, while not perfect by any means, is the one thing we can do well. There are so many easier ways of breaking into systems, it doesn't make any sense to replace mathematics with physics. And math is always cheaper.

Quantum computing is far out technologically. These computers are theoretically possible to build. We actually have no idea how to build them. Figure it will be ten or twenty or more years before this has a possibility of being a reality. An excellent article was published in a magazine called _The Sciences_. You can find it at http://cryptome.org/qc-grover.htm.

And when it becomes a reality, it does not destroy all cryptography. Quantum computing reduces the complexity of arbitrary calculations by a factor of a square root. This means that key lengths are effectively halved. 128-bit keys are more than secure enough today; 256-bit keys are more than secure enough against quantum computers.

Neville asks:
What's your response to the notion that the web's reliance on centralized Certificate Authorities for secure commerce is ultimately flawed? There are those, like the Meta Certificate Group, who feel that a hierarchical chain of certificates leading back to only a couple of elite organizations won't hold up in the distributed environment of the Internet. The entire framework of e-commerce seems to stand on the private keys of Verisign and Thawte. Do you feel this is a danger, and will there be viable alternatives?

ANSWER:
I agree with you 100%. The notion of a single global public-key infrastructure (PKI) makes no sense. Open your wallet, and you will see a variety of different authentication credentials: driver's license, credit cards, airline frequent flyer cards, library cards, a passport, and so forth. All of these are analog certificates, and will eventually have digital equivalents. There's no reason in the world why Visa can't use your driver's license number as a credit card number; it's just a pointer into a database, after all. But Visa never, ever will. They want control over issuance, update, and revocation. Similarly, digital credentials only make sense when the entity who cares about the credential controls the issuance, use, update, and revocation of that credential.

I have jointly written a paper with Carl Ellison called "Ten Risks of PIKI: What you aren't being told about Public Key Infrastructure." It will be published in the Winter 2000 issue of the _Computer Security Journal_. It's not on my Web site yet, but will be in by December. (Watch http://www.counterpane.com for details.) You can find a lot more good material on the problems with PKI at Carl Ellison's Web site: http://www.clark.net/pub/cme/html/spki.html.

jovlinger asks:

Bruce,

In a recent cryptogram, you write that most symmetric ciphers need more entropy than people can remember and hence supply. Even with bio-metrics adding more bits, it is not really worth the effort to construct ciphers with more than 128 bits of entropy in the key, because people won't give them more than that much entropy in the pass phrase.

However, social and technological pressures make longer and longer keys a necessity. What promising approaches do you see for making remembering and entering -- even though I have long passages of text memorized, I don't want to type them in for each e-mail I want to send -- usefully long passphrases?

I.e., to paraphrase, would you discuss the state of the art of cipher/human interaction, as it pertains to key management?

ANSWER:
For the rest of you, the Crypto-Gram article he mentions is at http://www.counterpane.com/crypto-gram-9910.html#KeyLengthandSecurity. In it, I argue that people just can't remember complicated enough keys and passwords to be immune from brute-force attacks (for example, L0phtcrack, see http://www.l0pht.com/l0phtcrack). Some of us can, but the masses that are using the Internet aren't able to, can't be bothered to, and won't be cajoled to.

The other way to carry around a large pool of random bits is on a data storage mechanism: a smart card, a Dallas Semiconductor iButton, a chip inside a physical key (like the device DataKey sells). These mechanisms are more annoying than passwords and passphrases, but they work. There's no real alternative; if something is too large to memorize, the only solution is to store it somewhere.

I don't believe that biometrics will ever become cryptographic keys. I wrote about this at http://www.counterpane.com/crypto-gram-9808.html#biometrics. Biometrics does have use as an authentication mechanism (note the difference), if it is engineered properly.

-----------------------

Next week: Mick Morgan, "the Queen of England's Webmaster," will answer questions about why not only the Royal Family's Web site but also the huge open.gov.uk site (and more than 80 other official UK Web sites) now run on Linux.

An anonymous reader has written in to say that l0pht has released a sniffer detector called AntiSniff. You can use it to determine if someone is sniffing around your network. There's already rumors of sniffer-sniffer-proof-sniffer already for those of you who already knew what I knew I thought you knew I knew.

If you're bored, there's a ton of strange links on the next page, selected by the warped minds of my slashdot co-authors ;-).

tom writes various stuffed Tux's (including a 1m high one), BSD Daemons and a TeX Lion at link (under "Un*x fan shop" and "ZU DEN ARTIKELN" - unfortunately the site's in German, but they speak English). Excellent quality, IMHO.

Robert Ennals writes A writer for the guardian/observer has a mention of one of their articles being linked from slashdot and considers this honour to be the "nearest I'll get to a Nobel prize" link

Kam writes Furniture Porn. Not much else to say... link

Louis Bertrand writes The December issue of DaemonNews, the monthly ezine devoted to the three open-source BSD operating systems (FreeBSD, NetBSD and OpenBSD) is available at link

SpaceDust writes No URL on this one, and not sure if it is really a /. thing. A friend who works at EA, tells me they are currently in Beta for Sim City 3000. Supported platforms will be Windows (mid Jan) and MacOS (in 6 months) I guess Linux gets squat (though, the /. effect may convince them otherwise) It's not too much different than "SC2k" except for a couple of new buildings, an improved interface, and now you have to manage garbage as well. They're in late Beta now, it's pretty stable and most of the major problems have been resolved but it still needs some tuning.

Josh Mast writes According to ,"> link A new opensource DOOM port has been started. "The Open Gaming Resource Engine project has been launched. This is a manifestation of the "Merger" project among members of leading DOOM source code projects, and will be an open source project. Looks nifty, maybe we'll finally have a decent port of DOOM for Linux now.

che guevara writes You bet it!!! I was surfing around on Camneerg- and saw this site that has an iMac that was hacked for a disk drive. You can get some info here, but don't try this if you don't want to void your warranty! Peace.

Brent Dearth writes ever since i got their demo tape at an underworld site, i've been searching for Market's webpage. well, i found it, and they have a couple mp3's full length for download. not really news, but i recall Hemos having good taste in music. link (sorry didn't paste)

Ben Smith writes The Onion has a silly little iMac joke in their new issue. In the left side column they have a neon blue stapler, and the caption says " New Stapler Makes All Other Staplers Look Like Worthless Shit". Good for a midday laugh.

Anonymous Coward writes Steven Hawking will appear on the Simpsons. Go figure. link

Anonymous Coward writes Kinda slow site.. (geocities) but well worth it :))))) link

Anonymous Coward writes More GNOME screenshots are available on the GNOME web site.

Weld Pond sent us a link to Hacker News Network, a new web mag that covers computer security and the computer underground. Joseph McDonald wrote in to inform us that someone has been registering typos of our Domain name. I'm flattered. I guess we're big now. An anonymous reader sent us a link to Da French Linux Page which looks strangely familiar. Contrary to what you may read elsewhere, it does not use any of my code, but the design is (ahem) borrowed (and uncredited). Lastly for the evening Star Wars news wrap up, derf wrote in to say that Entertainment Tonight will be showing the Prequel Trailer on TV in its entirety tomorrow evening for those who couldn't download the mpeg, were annoyed by the quality of the net version, don't live anywhere where they showed it in the theater yesterday, or just can't wait until friday. And ToiletDuk (who definitely wins Most Amusing Email of the Day) put together a wallpaper package (.Z) or a BMP. It's pretty good. I downloaded my copy of the trailer, watched the first few seconds, and as xanim chewed it to shreads, I decided to just abort and wait until friday. It'll be much inspiring on the big screen then on my piece of crap laptop. I can hold out for 48 hours (shake shake shake) really I can.

DilDog writes "Cult of the Dead Cow has released the source code to a *nix compatible client to Back Orifice. It can be downloaded Here." I'm getting the impression that this thing is going to be around for awhile.

DilDog sent us a link to the official cDc response to MSs rebuttal about Back Orifice. It's worth a read if you're at all interested in this thing.

The bad boys at l0pht have announced yet another massive IE security hole. This is a new way to download and execution of arbitrary code on both NT and 95 machines. Thanks to Christopher Blizzard for sending me this one.