November 15, 1999
by Bruce Schneier
A free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.
Back issues are available at http://www.schneier.com. To subscribe or unsubscribe, see below.
Copyright (c) 1999 by Bruce Schneier
Crypto-Gram now has over 25,000 readers!
In this issue:
Why Computers are Insecure
Almost every week the computer press covers another security flaw: a virus that exploits Microsoft Office, a vulnerability in Windows or UNIX, a Java problem, a security hole in a major Web site, an attack against a popular firewall. Why can't vendors get this right, we wonder? When will it get better?
I don't believe it ever will. Here's why:
Security engineering is different from any other type of engineering. Most products, such as word processors or cellular phones, are useful for what they do. Security products, or security features within products, are useful precisely because of what they don't allow to be done. Most engineering involves making things work. Think of the original definition of a hacker: someone who figured things out and made something cool happen. Security engineering involves making things not happen. It involves figuring out how things fail, and then preventing those failures.
In many ways this is similar to safety engineering. Safety is another engineering requirement that isn't simply a "feature." But safety engineering involves making sure things do not fail in the presence of random faults: it's about programming Murphy's computer, if you will. Security engineering involves making sure things do not fail in the presence of an intelligent and malicious adversary who forces faults at precisely the worst time and in precisely the worst way. Security engineering involves programming Satan's computer.
And Satan's computer is hard to test.
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 module, and this module is then tested, fixed, and tested again. Small modules are then combined into larger modules, and so on. The end result is software that more or less functions as expected, although in complex systems bugs always slip through.
This try-and-fix methodology just doesn't work for testing security. No amount of functional testing can ever uncover a security flaw, so the testing process won't catch anything. Remember that security has nothing to do with functionality. If you have an encrypted phone, you can test it. You can make and receive calls. You can try, and fail, to eavesdrop. But you have no idea if the phone is secure or not.
The only reasonable way to "test" security is to perform security reviews. This is an expensive, time-consuming, manual process. It's not enough to look at the security protocols and the encryption algorithms. A review must cover specification, design, implementation, source code, operations, and so forth. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure.
It gets worse. A security review of version 1.0 says little about the security of version 1.1. A security review of a software product in isolation does not necessarily apply to the same product in an operational environment. And the more complex the system is, the harder a security evaluation becomes and the more security bugs there will be.
Suppose a software product is developed without any functional testing at all. No alpha or beta testing. Write the code, compile it, and ship. The odds of this program working at all -- let alone being bug-free -- are zero. As the complexity of the product increases, so will the number of bugs. Everyone knows testing is essential.
Unfortunately, this is the current state of practice in security. Products are being shipped without any, or with minimal, security testing. I am not surprised that security bugs show up again and again. I can't believe anyone expects otherwise.
Even worse, products are getting more complex every year: larger operating systems, more features, more interactions between different programs on the Internet. Windows NT has been around for a few years, and security bugs are still being discovered. Expect many times more bugs in Windows 2000; the code is significantly larger. Expect the same thing to hold true for every other piece of software.
This won't change. Computer usage, the Internet, convergence, are all happening at an ever-increasing pace. Systems are getting more complex, and necessarily more insecure, faster than we can fix them -- and faster than we can learn how to fix them.
Acknowledgements: The phrase "programming Satan's computer" was originally Ross Anderson's. It's just too good not to use, though. A shortened version of this essay originally appeared in the November 15 issue of _Computerworld_.
Counterpane -- Featured Research
"Authenticating Secure Tokens Using Slow Memory Access"
John Kelsey and Bruce Schneier, First USENIX Symposium on Smart Cards, USENIX Press, to appear.
A company has developed an e-mail encryption package that allows the sender to choose how long the decryption key will be available, making all copies of the encrypted e-mail unreadable after a chosen date. This is a good system to prevent people from accidentally forgetting to delete their e-mail (in light of the Microsoft trial, many companies have policies of deleting all e-mail older than a certain time.) It does no good, however, as a security measure to *prevent* someone from saving e-mail past that date. Someone can always save the decrypted e-mail to a file, embed the e-mail in an outgoing e-mail without the restriction, or even do a screen capture and save a copy of the e-mail that way. This might be a good product, but don't fool yourself into thinking it acts as a security measure.
Language as cryptography. These stories talk about a secret language used in China. The second story mentions that the Imperial Chinese punishment for inventing a secret language was death.
Arjen Lenstra and Eric Verheul have written an excellent paper on key lengths: symmetric, public key (including elliptic curve), etc. They compare key lengths from different systems, and make predictions about the future. Download this.
The Los Angeles Police Department has been accused of conducting hundreds of illegal wiretaps over the course of several years. Keep this story handy the next time someone tells you that police wiretaps are a good thing, and of course the police can be trusted.
Snake-oil alert: Jaws Technologies is taking advantage of a window of opportunity for acquisitions.
Bad ideas department: The Internet Engineering Task Force (IETF) was considering building wiretapping capabilities into future incarnations of the Internet. Anyone who has any voice should stand up at the IETF meetings in opposition to this.
A company called SecureLogix is building a firewall for PBXs. Now that's a good idea:
The Clinton administration is looking into relaxing export controls of cryptographic source code.
The Gartner Group analysts are making a lot of noise about Y2K viruses.
The National Security Agency will now assess network security for defense and civilian agencies. They will even try to break into agencies' systems to point out vulnerabilities.
Excellent interview with Ross Anderson from the New Scientist magazine:
TEMPEST is the NSA code name for the ability to eavesdrop on electronic equipment by intercepting and decoding their electromagnetic signals. An archivist intends to publish on his Web site documents, obtained from the NSA via the Freedom of Information Act, which provide more details.
Information about Echelon slowly leaks out:
The inevitable has finally happened. Someone invented an e-mail virus that can infect your system when you read the e-mail; you don't have to execute anything. The Bubbleboy virus requires a user to be running Microsoft's Outlook or Outlook Express e-mail programs; Windows 95, 98, or 2000; and Internet Explorer 5.0 or higher. It targets a security hole for which Microsoft has already created a fix, but which many users still have yet to update.
My commentary in Communications of the ACM on the future of malicious software:
DVD Encryption Broken
The scheme to protect DVDs has been broken. There are now freeware programs on the net that remove the copy protection on DVDs, allowing them to be played, edited, and copied without restriction.
This should be no surprise to anyone, least of all to the entertainment industry.
The protection scheme is seriously flawed in several ways. Each DVD is encrypted with something called Content Scrambling System (CCS). It has a 40-bit key. (I have no idea why. The NSA and the FBI shouldn't care about DVD encryption. There aren't any encrypted terrorist movies they need to watch.) It's not even a very good algorithm. But even if the encryption were triple-DES, this scheme would be flawed.
Every DVD player, including hardware consoles that plug into your television and software players that you can download to your computer, has its own unique unlock key. (Actually, each has several. I don't know why.) This key is used to unlock the decryption key on each DVD. A DVD has 400 copies of the same unique decryption key, each encrypted with every unlock code. Note the global secret: if you manage to get one unlock key for one player, you can decrypt every DVD.
But even if this were all perfect, the scheme could never work.
The flaw is in the security model. The software player eventually gets the decryption key, decrypts the DVD, and displays it on the screen. That decrypted DVD data is on the computer. It has to be; there's no other way to display it on the screen. No matter how good the encryption scheme is, the DVD data is available in plaintext to anyone who can write a computer program to take it.
And so is the decryption key. The computer has to decrypt the DVD. The decryption key has to be in the computer. So the decryption key is available, in the clear, to anyone who knows where to look. It's protected by an unlock key, but the reader has to unlock it.
The DVD software manufacturers were supposed to disguise the decryption program, and possibly the playing program, using some sort of software obfuscation techniques. These techniques have never worked for very long; they only seem to force hackers to spend a couple of extra weeks figuring out how the software works. I've written about this previously in relation to software copy protection; you can't obfuscate software.
It might be a bitter pill for the entertainment industry to swallow, but software content protection does not work. It cannot work. You can distribute encrypted content, but in order for it to be read, viewed, or listened to, it must be turned into plaintext. If it must be turned into plaintext, the computer must have a copy of the key and the algorithm to turn it into plaintext. A clever enough hacker with good enough debugging tools will always be able to reverse-engineer the algorithm, get the key, or just capture the plaintext after decryption. And he can write a software program that allows others to do it automatically. This cannot be stopped.
If you assume secure hardware, the scheme works. (In fact, the industry wants to extend the system all the way to the monitor, and eventually do the decryption there.) The attack works because the hacker can run a debugger and other programming tools. If the decryption device and the viewing device (it must be both) is inside a tamperproof piece of hardware, the hacker is stuck. He can't reverse-engineer anything. But tamperproof hardware is largely a myth, so in reality this would just be another barrier that someone will eventually overcome. Digital content protection just doesn't work; ask anyone who tried software copy protection.
One more lesson and an observation.
The lesson: This is yet another example of an industry meeting in secret and designing a proprietary encryption algorithm and protocol that ends up being embarrassingly weak. I never understand why people don't use open, published, trusted encryption algorithms and protocols. They're always better.
The observation: The "solution" that the entertainment industry has been pushing for is to make reverse-engineering illegal. They managed in the United States: the Digital Millennium Copyright Act includes provisions to this effect, despite the protests of the scientific and civil rights communities. (Yes, you can go to jail for possessing a debugger.) They got a similar law passed in the UK. They're working on the EU. This "solution" does not work and makes no sense.
First, unless reverse-engineering is illegal everywhere on the planet, someone will be able to do it somewhere. And one person is all you need; he can write software that everyone else uses. Second, the reverse-engineer can -- as in this case -- work anonymously. Laws wouldn't have helped in this case. And third, laws can't put the cat back into the bag. Even if you could catch and prosecute the hackers who did this, it wouldn't affect the hacker tools that have already been, and continue to be, written.
What the entertainment industry can do, and what they have done in this case, is use legal threats to slow the spread of these tools. So far the industry has threatened legal actions against people who have put these software tools on their Web sites. The result will be that these tools will exist on hacker Web sites, but will never be in public-domain software -- Linux, for example.
The fatal flaw is that the entertainment industry is lazy, and is attempting to find a technological solution to what is a legal problem. It is illegal to steal copyrights and trademarks, whether it is a DVD movie, a magazine image, a Ralph Lauren shirt, or a Louis Vitton handbag. This legal protection still exists, and is still strong. For some reason the entertainment industry has decided that it has a legal right to the protection of its technology, and that makes no sense.
Moreover, they are badgering legislatures into passing laws that prop up this flawed technological protection. In the US and UK (and possibly soon in the EU), it is illegal to circumvent their technology, even when you never use it to violate a copyright. It is illegal to engage in scientific research about the encryption used in these systems. It is illegal to peek under the hood of this thing you have legally bought. So not only does this system not work, it creates a black market where there was none before, while doing no social good in the process.
This DVD break is a good thing. It served no one's interests for the entertainment industry to put their faith in a bad security system. It is good research, illustrating how bad the encryption algorithm is and how poorly thought out the security model is. What is learned here can be applied to making future systems stronger.
A different version of this article appeared as a guest commentary on ZDNet.
Summary of the DVD encryption scheme:
My essay on software copy protection:
My comments on the Digital Millennium Copyright Act:
New Intel software obfuscation techniques that, I predict, will be broken soon:
The Doghouse: Microsoft Windows CE
Microsoft encrypts your Windows NT password when stored on a Windows CE device. But if you look carefully at their encryption algorithm, they simply XOR the password with "susageP", Pegasus spelled backwards. Pegasus is the code name of Windows CE. This is so pathetic it's staggering.
U.S. Legislation Update
Sometimes it feels like nothing ever changes. Bills to relax export controls on cryptography are crawling through both the House and Senate. But nothing ever comes to a vote.
In the House, over 250 members of Congress have co-sponsored H.R. 850, the Security and Freedom through Encryption (SAFE) Act introduced by Rep. Bob Goodlatte (R-VA) and Rep. Zoe Lofgren (D-CA). The bills allows for the export of off-the-shelf cryptographic devices (hardware and software) if a comparable product is available from a foreign company, and bans mandatory key escrow. On the other hand, it also includes a controversial provision that creates a new federal crime for using crypto to "further a criminal act." This bill has been approved by five committees, so you'd think that would be enough to get the issue decided. However, in two of the Committees -- the House Intelligence Committee and the House Armed Services Committee -- the bills were amended to effectively retain export controls. The House Rules Committee will have to decide which version will be voted on.
On the Senate side, Commerce Committee chair and presidential candidate John McCain (R-AZ) reversed his previous positions opposing cryptography and introduced S. 798, the Promote Reliable On-Line Transactions to Encourage Commerce and Trade (PROTECT) Act of 1999. The bill allows for the free export of products that have 64 bits or less. Stronger encryption can be exported to online merchants, major corporations that are publicly traded companies, government regulated industries, subsidiaries or affiliates of United States corporations, and to governments in NATO, OECD and ASEAN. (Go figure that last one; they want to sell strong crypto to Vietnam and Burma but not Brazil or Argentina?) An Encryption Export Advisory Board can recommend relaxing restrictions. Finally, by January 2002, products that adopt the AES or its equivalent will be freely exportable. The bill was approved by the Commerce Committee in June and is now awaiting a vote by the Senate.
Elliptic Curve Public-Key Cryptography
In September of this year, nearly 200 people using 740 computers managed to crack a message encrypted with 97-bit elliptic curve cryptography. The process took 16,000 MIPS-years of computing, about twice as much as used by the team that recently cracked a 512-bit RSA encryption key. Certicom, the company who sponsored this challenge, has offered this result as evidence that elliptic curve cryptography is stronger than RSA.
Let's take a look at this claim a little more closely.
All public-key algorithms, whether for key exchange, encryption, or digital signatures, are based on one of two problems: the factoring problem or the discrete logarithm problem. (There are other algorithms in academic circles, but they're too unwieldy to use in the real world.) The security of RSA comes from the difficulty of factoring large numbers. Strong RSA-based systems use 1024-bit numbers, or even larger.
The security of most other public-key algorithms -- ElGamal, DSA, etc. -- is based on the discrete logarithm problem. The two problems are very similar, and all of the modern factoring algorithms can be used to calculate discrete logarithms in the multiplicative group of a finite field. To a rough approximation, factoring a number of a certain size and calculating the discrete logarithm of numbers the same size takes the same amount of work. This means that for a given key size, RSA, ElGamal, DSA, etc. are approximately equally secure. (This isn't strictly true, but it's a good enough approximation for this essay.)
All of these algorithms require the use of something called an "algebraic group." When public-key cryptography was invented, the algorithms were all implemented in the simplest algebraic group: the numbers modulo n. For example, RSA encryption is m^e mod n, and a Diffie-Hellman public key is g^y mod n. As it turns out, any algebraic group will do. Elliptic curves are simply another algebraic group.
In elliptic curve cryptography, public keys and private keys are defined as points along a mathematical object called an elliptic curve. (Don't worry; it doesn't really matter what that means.) Addition is an operation that combines two points and produces a third point. The algorithms look the same, but the detailed math is very different.
But if any algebraic group will do, why is anyone bothering with elliptic curves? It turns out that for discrete-logarithm elliptic curve algorithms, perhaps we can get by with smaller keys. (This is not true for RSA, which is why you never see elliptic curve RSA variants).
All of the fastest algorithms for calculating discrete logs -- the number field sieve and the quadratic sieve -- make use of something called index calculus and a property of the numbers mod n called smoothness. In the elliptic curve group, there is no definition of smoothness, and hence in order to break elliptic curve algorithms you have to use older methods: Pollard's rho, for example. So we only have to use keys long enough to be secure against these older, slower, methods. Therefor, our keys can be shorter.
And they can be significantly shorter. In the wake of the recent break, Certicom recommends 163-bit keys. Compare this to the recommended key lengths for conventional discrete-logarithm algorithms, which are at least 1024 bits.
Whether this recommendation makes sense depends on whether the faster algorithms can ever be made to work with elliptic curves. The question to ask is: "Is this lack of smoothness a fundamental property of elliptic curves, or is it a hole in our knowledge about elliptic curves?" Or, more generally: "Are elliptic curves inherently harder to calculate discrete logs in, or will we eventually figure out a way to do it as efficiently as we can in the numbers mod n?"
If you believe the former, elliptic curves will always be more secure -- for the same key lengths -- than the numbers mod n. If you believe the latter, it's only a matter of time before they are broken.
Certicom very much wants you to believe the former. They say things like: "Elliptic curves as algebraic/geometric entities have been studied extensively for the past 150 years, and from these studies has emerged a rich and deep theory." They conclude that because of this, we can gain good confidence that new algorithmic advances won't be too devastating.
To me, this is a lot of wishful thinking. It would be nice if we had 150 years of work on the cryptographic properties of elliptic curves. But we don't; instead, we have 150 years of work on the properties of elliptic curves that mathematicians care about, almost all of it only incidentally touching on what cryptographers care about. Elliptic curve cryptography was invented only in 1985, and has only been really studied seriously for a few years.
Even today, most of the work on elliptic curves in the typical university math department is pretty irrelevant to us cryptographers. Sure, some of their results might occasionally help us understand the strength of elliptic curve algorithms; but that's almost never been the goal of the mathematicians' research studies. This is changing now, but slowly.
Furthermore, work on efficient algorithms for elliptic curves is very new. The whole notion of efficient algorithms didn't even appear until about the 1960s or 1970s, and algorithmic number theory has only become popular in the past two decades. It just wasn't relevant before computers.
The real answer to the question is "we don't know." We don't know if there are efficient ways to calculate discrete logarithms in elliptic curve groups. We don't know if there is a definition of smoothness that will allow us to apply the number field sieve to elliptic curves. We don't know if, in the long run, you can use shorter keys with elliptic curve algorithms.
In the short run, Certicom's recommendations are reasonable. Today, we can't calculate discrete logs in elliptic curves as efficiently as we can in the numbers mod n. Systems can use shorter keys with elliptic curves. But in the long run, we don't know.
There are other differences to consider, too. Checking elliptic curve signatures is still a big pain compared to checking RSA signatures. And all users of an elliptic curve system have to share the same curve. (If you don't do this, you lose most of the size benefits of the elliptic curve keys.) This has security implications: it is easier to break a key of a random user on a system than it is to break a specific user's key. I'd like to see more analysis of this aspect of elliptic curve systems.
My recommendation is that if you're working in a constrained environment where longer keys just won't fit -- smart cards, some cellphones or pagers, etc. -- consider elliptic curves. If the choice is elliptic curves or no public-key algorithm at all, use elliptic curves. If you don't have performance constraints, use RSA. If you are concerned about security over the decades (almost no systems are), use RSA.
Realize, though, that someday -- next year, in ten years, in a century -- someone may figure out how to define smoothness, or something even more useful, in elliptic curves. If that happens, you will have to use the same key lengths as you would with conventional discrete logarithm algorithms, and there will be no reason to ever use elliptic curves.
Postscript: This same analysis applies to factoring, too. RSA Security, Inc. likes to talk about the long mathematical history of the factoring problem, and how that gives us confidence about the security of RSA. Yes, it has been studied for centuries, but only recently has that study been even remotely related to cryptography. Moreover, working on factoring hasn't been a respectable area of study until very recently; before that, it was considered an eccentric hobby. And efficient algorithms for factoring have only been studied for the past couple of decades. We really have no idea how hard factoring truly is.
The truth is that companies have a tendency to advertise their products. Before making a decision about cryptographic algorithms, customers should try to get a variety of independent opinions (from parties not financially involved in the outcome of the decision) about what they are buying.
News on the recent elliptic curve cracking effort:
An excellent mathematical introduction to elliptic curves:
An excellent discussion on comparative key lengths, including RSA and elliptic curves:
Comments from Readers
Reinhard Wobst <R.Wobst@ifw-dresden.de>
Today during the congress ISSE in Berlin, we had a panel discussion about the problem "Does open source help to increase security?" Of course, we spoke about general IT-security, not only about cryptography.
What you wrote in Cryptogram about open source of crypto algorithms is absolutely right. The example of Crypto AG machines, where the secret key was enciphered by an NSA key and then probably put into the message header, is a illustrative example. In contrast to this field, we agreed that open source of operating systems or applications does not generally increase security, it only makes the process of bug finding and bug fixing faster. In commercial environments it is not possible to make patches so often as security holes are found and closed. Sometimes users note such problems and write a workaround for their application which would crash with the next release. Your theory of finding most important errors in shorter time sounds good. However, people from organizations like DFN-CERT claim that the chain is endless, and even "unimportant errors" can easily be used for automated attacks.
So we agreed to say: Open source not necessarily increases security considerably, but it increases TRUST. And this is -- of course -- very important for cryptography implementations.
From: Larry Nathanson <lanpanix.com>
Dwight Arthur <firstname.lastname@example.org> said:
I would reconsider that stance.
>From E*TRADE Customer Agreement (labeled ET100/0798 on last page): "This document contains the terms and conditions which govern your E*TRADE account. Please read it carefully and keep it for your records."
"Customer Agreement", Item 28, paragraph 2 (page 6): You shall be the only authorized user of the Service under this Agreement. You shall be responsible for the confidentiality and use of your User ID, sign-on password, trading password, and PIN. You understand that you shall be solely responsible for all orders entered through the Service using your User ID, sign-on password, trading password, and PIN.... You agree that E*TRADE and its affiliates will not be liable for any losses resulting from a cause over which E*TRADE or its affiliates does not have direct control, including but not limited to ... unauthorized access...."
Also online at https://trading.etrade.com/cgi-bin/gx.cgi/AppLogic+AcctDefault?gxml=etrade_info/customer_agreement.html -- requires login.
From: "Estes, Danal" <Danal.Estesfritolay.com>
The latest Crypto-Gram contained a reference to AMD's "Magic Packet" that could power up a PC via the network. Your expression of security concern is right on target; associating this concern with a single vendor or technology is not.
This affects anyone that supports Wake-On-Lan on his motherboard/network card, and not only AMD: http://www.microsoft.com/hwdev/specs/PMref/... [link moved to http://www.microsoft.com/hwdev/resources/specs/...]
For some time now, motherboard manufacturers and Network Interface Card manufacturers have been supporting a standard known as "Wake on Lan". This initially required a special cable from the NIC to a two pin header on the motherboard. In conjunction with the ATX power supply standards that keep a small portion of the motherboard powered up (thus enabling "Hit the spacebar to power on", etc.), the NIC could also stay powered up and send the 'power fully up' signal to the motherboard via this cable...! I seem to recall seeing a reference to enabling this same idea via the PCI bus (no special cable required) at some rev level.
IBM, Compaq, Dell, etc. having been touting this technology in presentations to me for at least two years. So, it's not just AMD, it's a whole variety of component and finished system manufacturers.
Again, the security concerns are real. The packet format to cause a "wake" is standardized and well published. You do have to know the hardware (MAC layer) address of the NIC, but this is easily obtained anytime the computer is up and communicating. Etc., etc.
Wake on Lan does need some configuration to work; it's generally not the default behavior of the motherboard/NIC combination. Who's most likely to enable this? Large companies that have "Enterprise Systems Management" initiatives. As this standard gains momentum, as it becomes part of bus(es) instead of special cables, if/when it becomes enabled by default... enough said. Keep sounding the alert.
From: Gary Ellison <gary.ellisonsun.com>
A few comments on the Clinton Administration's new crypto policy that I think are worth noting.
First, the new rules do not change anything for so called 'crypto with a hole'. In other words toolkits, such as the BSafe or Java Cryptographic Extensions, will still be under the same export restrictions in existence today. It is also not clear what the fate of hardware cryptographic accelerators (ASIC or other components) will be. In the case of software toolkits the NSA will not allow strong crypto to be exported unless the toolkit is closed (along the lines of CAPI or CDSA). According to the new policy, "retail" crypto products will go through "one time review". I presume the NSA review will be a bit more detailed in the future than it has been in the past. Given that what is to prevent the NSA from claiming that these so called "retail" products are 'crypto with a hole' and deny the export license? For example, Eudora may no longer meet the NSA's export criteria given the architecture of their plugin api.
Another point is that the Clinton Administration's plan addresses about 80% of the SAFE Act and that it is unlikely that there will ever be the kind of support to remove the restrictions for the missing 20%.
Finally, the Clinton Administration's new rules are not codified in law and could just as easily be whisked away by this or any subsequent administration.
Perhaps CESA should be referred to as the Black Bag Job Act of 1999.
From: Greg Weiss <Greg.Weissworldnet.att.net>
>With all the talk about electronic voting, it's nice that someone
I used to agree with you on this. But when talking with someone about absentee balloting this last week, it seems to me this problem is equally present in today's non-virtual scenario. How? Well, absentee ballots enable voter coercion in the privacy of non-public polling places. E-votes are not particularly more subvertible than absentee ballot votes at least from the voter coercion threat.
Now with absentee ballots, there is one further protection. One can apparently still vote in person at the polling place, and their polling-place vote takes precedence over their absentee ballot. But this same approach would work for electronic votes, right? People coerced or bought could still vote at the public polls with that vote taking precedent. So voter coercion looks like a wash to me, electronic vote or no.
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.
To subscribe, visit http://www.schneier.com/crypto-gram.html or send a blank message to email@example.com. To unsubscribe, visit http://www.schneier.com/crypto-gram-faq.html. Back issues are available at http://www.schneier.com.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of Counterpane Internet Security Inc., the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on computer security and cryptography.
Counterpane Internet Security, Inc. is a venture-funded company bringing innovative managed security solutions to the enterprise.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.