- cypherpunks-legacy - lists.cpunks.org

RE: Location Escrow anyone ?
by Pearson Shane 17 Dec '03

17 Dec '03

Hey guys, I wasn't suggesting that they do record exactly where everyone is at the highest resolution possible. Just suggesting that should they want to investigate an individual, they could do it with pretty high detail. Though I'm sure they'd record when and where you switch your phone on, switch off / loose signal, switch cells and make and receive calls and messages. That wouldn't be all that much data. Bye for now.

1 0

1998 - the year we must make a stand.
by Global Web Builders 17 Dec '03

17 Dec '03

---------------------------------------------------------------------------- PLEASE NOTE: No unsolicited email is sent. If you do not want to be on the mailing list please say "REMOVE" in the subject line and return the message in the body of this email (so that we can track your state). ---------------------------------------------------------------------------- Dear One Nation Supporter in New South Wales, As Australia moves towards the year 2000 we Australians move into a critical stage of our history. A stage which is the culmination of years of deception by the Labor and Coalition parties leading to the undermining of our democracy. With a Federal Election in the wind 1998 provides a chance for Australians to rectify the wrongs of the past. Voting for the major parties will provide no solutions - only more of the same. However, expect the major parties to claim that voting for Pauline Hanson's One Nation will be a wasted vote. They are wrong - tell your friends and make a stand for your children's future by voting for Pauline Hanson's One Nation. I am going to cite just one example of many on how you, as an Australian voter, are being misled by the mainstream political parties. In a word the subject is 'MAI' an international agreement to which Australia will be a signatory. MAI is being debated more and more on the Internet through the World Wide Web. Here are some web site links on the subject. Please take the time to visit these sites because they demonstrate how the transnational companies, through MAI (the multilateral agreement on investment), are bargaining away your future with senior Canberra-based bureaucrats. 1) ABC interview - full transcript: http://www.gwb.com.au/gwb/news/onenation/press/maiabc.html Extract: 'Sadly there's no catch title for this trade deal. It's called the Multilateral Agreement on Investment, or MAI. But what it promises holds more drama. It aims to grant multinational corporations unprecedented powers over governments. And it's not getting many good reviews.' and 'In effect, the MAI is a bill of rights for international giants like Shell, Lockheed, Du Pont, and Arthur Andersen. It prevents governments asking more of those multinationals than they ask of their own domestic companies. And any laws that discriminate in favour of locals, such as Australian media ownership laws, don't fit.' 2) MAI Information Centre (Canada): http://www.islandnet.com/~ncfs/maisite/homepage.htm Extract: 'It incorporates a powerful dispute resolution system which would allow any investor to sue the government of its host nation if it considers laws or regulations to be discriminatory and detrimental to immediate or projected profits. The Agreement would therefore disable regional development and national measures to protect the well-being of people, create employment, safeguard small business, conserve resources and protect the environment. Once signed, the MAI cannot be denounced for five years. Investments under the MAI would remain protected for a further fifteen years.' The MAI debate is being discussed openly in Canada and New Zealand while in Australia we are being closeted from this debate by the duopoly which runs this country's media. It is a very real issue. An issue that the major parties refuse to bring out into the open. An issue, amongst many, many others that Pauline Hanson's One Nation is trying to expose. BUT we cannot do that without your support. Your vote and those of your friends will be critical to ensure that issues such as MAI are heard, are questioned, can be rejected by you and I - the Australian people. Clearly the major political parties have failed in drawing issues like this out into the public arena for discussion. Pauline Hanson PS. If you are able to help with donations to help us fund our candidates in state and federal elections this year please visit: http://www.gwb.com.au/pledge.html

1 0

Eureka! Thu Jan 8 '98
by eureka＠eureka.abc-web.com 17 Dec '03

17 Dec '03

Welcome to Thursday's issue of Eureka! HARD CITY Ouch! Like it's name says, this is a HARD site, or at least, *you'll* be hard after you see it! Hard City is superbly constructed and has just about every type of porn you could want, and what's more, we've arranged for all our Eureka! readers to get to try out the site totally FREE of charge! So what are you waiting for? Go see! .. http://hardcity.com/ GAYEUREKA! The gay newsletter is now available. You can get it here! Gay Eureka! ........... http://eureka.abc-web.com/gayeureka/ EUREKA! TRANSLATIONS As well as English you can now choose any of these languages DEUTSCH ....... http://eureka.abc-web.com/eureka/deutsch.htm ESPAÑOL ....... http://eureka.abc-web.com/eureka/espanol.htm FRANÇAIS ..... http://eureka.abc-web.com/eureka/francais.htm ITALIANO ..... http://eureka.abc-web.com/eureka/italiano.htm PORTUGUESE . http://eureka.abc-web.com/eureka/portuguese.htm BEST SEX MOTEL Somebody is always in at the Motel and the rooms are cheap. Surf down the page to the "rooms", there you'll find a bunch of great pussy pix of all sorts. Nice nipple ring room1b! Best Sex Motel ................... http://www.sex-motel.com/ LICKITY SPLIT Oh yeah, what a superb site. You are really going to love all the photos and links you find here. Absolutely excellent! Lickity Split ............... http://207.254.20.141/lickity/ L.A. SEX "L.A. SEX has been designed for easy surfing but more impor- tant than that we have a ton of great free nude xxx pics for your pleasure! This site has no consoles..." You bet, this is a great site. Shaved, black or redheads, take your pic. L.A. Sex ...................... http://209.50.230.238/pk.htm SABRINA'S HOUSE OF HARDCORE FUN They has gathered together dozens of free pix for us. Once there you have a lot of choices. They offer a free video for us as well! Not a bad deal. Pretty juicy stuff. Facials, young women and asians. Lick it up girls! Worth the Surf! Sabrina's House ............ http://www.sexhost.net/sabrina/ FREE CONTEST! The excitement escalates! This week's competition now has just has two free 3 Month memberships to the King of "Hard- Core" left to play for. Eureka's Halarious question master awaits you. Visit Hardcoresmut and click on "Free Guided Tour" for the tour, and email us the answer (found in XXX CHAT) to this head-scratching question: "What does everyone want to get in the XXX Hardcore chat rooms?" ............... Answers to .................. mailto:contest@www.usachat.com HardCoreSmut ................... http://www.hardcoresmut.com FREE STREAMING VIDEO Please note that most of these feeds require a Netscape bro- wser in order to successfully view them. Unfortunately Micr- osoft's browser does not have all the features of Netscape's yet. However, many of the feeds use the RealPlayer and will work in most browsers. If you do not have Netscape and want a free copy click here ... http://www.netscape.com/download/ Three dicks .................... http://207.168.184.26/trip/ CHAT WITH OTHER READERS This chat is growing fast, and already there are a number of regulars you will meet most days. It's good to see Eureka! readers interacting with each other and having a great time! Adult/Sex Chat .................. http://137.39.63.229/chat/ General/Fun Chat ........ http://137.39.63.229/chat/funchat/ THE BEST PHONE SEX NEW!!!! LD Call only! - Live Hot Girls!!!!....1-664-410-3912 LIVE: 1-on-1, 2-on-1, Group, Dateline.........1-800-644-8779 FREE: Live 1-on-1 (international call only)....011-678-77416 AMATEUR SITE OF THE DAY LEATHER ROSE: A busty Bi-BBW woman who is NOT afraid to show off. She considers herself an "eclectic kinda gal with ecce- ntric tastes", and believe us, she has a lot of loving to give. Her web page is devoted to her, and fans of BBW women. Check out her site! ............................ http://amateurindex.com/eureka/ EROTIC STORY SITE OF THE DAY HotStories.com: Tired of all those pics? Hot Stories lets you use your imagination to is full potential. Over 100 free sex stories in 8 different categories. Our stories are worth a thousand pics! ................ http://www.hotstories.com/ DAILY MPEG AND CARTOON The internationally renowned erotic artist Raffaelli has made his award-winning videos available exclusively to Eros in Orbit and NOW to subscribers of Eureka! These high- quality video clips feature the best of Raffaelli's erotic masterpieces. Raffaelli has gained world wide recognition for his quality productions, featuring beautiful non profes- sional models captured in passionate sexual intercourse. These video clips also portray exotic single girls in auto- erotic masturbation. The color, quality and detail of these MPEGs is superb. ........ http://www.erosinorbit.com/eureka/ ADULT STAR PIC OF THE DAY Every day we bring you an exclusive choice pic of a famous adult porn star. And we must tell you - these pix are abso- luletly brilliant! ....... http://www.adultstars.com/eureka/ TODAY'S FREE PIX Pic 1 ........................... http://137.39.63.229/?080 Pic 2 ........................... http://137.39.63.229/?081 Pic 3 ........................... http://137.39.63.229/?082 Pic 4 ........................... http://137.39.63.229/?083 Pic 5 ........................... http://137.39.63.229/?084 Pic 6 ........................... http://137.39.63.229/?085 Pic 7 ........................... http://137.39.63.229/?086 Pic 8 ........................... http://137.39.63.229/?087 Pic 9 ........................... http://137.39.63.229/?088 Pic 10 ........................... http://137.39.63.229/?089 PLEASE VISIT THIS EUREKA! PARTNER SITE A Babe For You - 350+ FREE Naked Babes http://www.babes4free.com 350+ FREE Quality Blonde, Teen, Lesbian, Teen Fuck, Asian, Black and Series Pics. All thumbnail selection. Plus we feature Free Pics from Free Sites. =========================================================== TO UNSUBSCRIBE FROM THIS NEWSLETTER, USE THE REPLY FUNCTION IN YOUR EMAIL PROGRAM, AND SEND THIS NEWSLETTER BACK TO US. ===========================================================

1 0

Fiat's Batch RSA
by Anonymous 17 Dec '03

17 Dec '03

Batch RSA invented by Amos Fiat Described in Crypto 89 and J Cryptology 1997. RSA works as follows. The key owner chooses two secret primes p and q, and forms their product n = p*q. He then chooses a public exponent e relatively prime to p-1 and q-1. His public key is (n, e). To encrypt a message m into cyphertext c, m is raised to the power e, mod n: c = m^e mod n. To decrypt the message, the key holder calculates d as the multiplicative inverse of e mod (p-1)(q-1): d = 1/e mod (p-1)(q-1). He recovers m from m = c^d mod n. For simplicity, below we will write this as m = c^(1/e) mod n, where it is understood that the 1/e is done mod (p-1)(q-1). An RSA signature s on a message m is calculated as for a decryption: s = m^(1/e) mod n. The signature is verified by m ?=? s^e mod n. The time consuming part of an RSA decryption or signature is this exponentiation step. e can be chosen to be small, so encryption and verification is fast, but 1/e will generally be about the same size as n, so many multiplications must be done to raise a number to that power. Amos Fiat describes a method whereby multiple messages can be decrypted or signed using only one full-sized exponentiation. The "catch" is that the messages must all use different exponents with the same n. Here is a concrete example. You want to decrypt or sign two messages, M1 and M2, raising M1 to the 1/3 power and M2 to the 1/5 power. Perform the following steps: M12 = M1^5 * M2^3 I12 = M12 ^ (1/15) This is the only full-sized exponentiation needed. This gives: I12 = M1^(1/3) * M2^(1/5). This is the product of the two values that we want. Fiat uses a trick to disentangle the two values. He raises I12 to the 6th power. The number 6 is chosen so that it is a multiple of one of the two exponents, 3, and is 1 more than a multiple of the other exponent, 5: I12^6 = M1^2 * M2 * M2^(1/5) Therefore: M2^(1/5) = I12^6 / (M1^2 * M2) which is one of the values we need. Since I12 is the product of the two values we want, we can recover the other value just by dividing this into I12: M1^(1/3) = I12 / M2^(1/5) Here is another example. Suppose we want M3^(1/7) and M4^(1/11). (Note that we are using prime numbers for the exponents; the reason will be explained below.) We calculate: M34 = M3^11 * M4^7 I34 = M34 ^ (1/77) This gives us: I34 = M3^(1/7) * M4^(1/11) Again this is the product of the two values we want. As before we will raise this to a power which is 1 more than a multiple of one of the two exponents (7 and 11) and is a multiple of the other one. The smallest such power is 22. I34^22 = M3^3 * M3^(1/7) * M4^2 So we can divide to get M3^(1/7): M3^(1/7) = I34^22 / (M3^3 * M4^2) And we can divide to get the other value needed: M4^(1/11) = I34 / M3^(1/7) This illustrates how to derive two RSA roots using only one full sized exponentiation. A few small exponentiations are also needed, as well as two divisions, but these are much faster than doing the full exponentiation (raising to the 1/15 or 1/77 powers above). Fiat's idea can then be applied recursively. Note that in the examples above we had to take two full-sized exponentiation, M12 to the 1/15 power and M34 to the 1/77 power. We can combine both of these exponentiations into one just as was done above: M14 = M12^77 * M34^15 I14 = M14 ^ (1/1155) Now: I14 = M12^(1/15) * M34^(1/77) the product of the two values we want. We need an exponent which is 1 more than a multiple of 15 while being a multiple of 77, giving 615, or vice versa, giving 540. Choosing the latter since it is smaller we have: I14^540 = M12^36 * M34^7 * M34^(1/77) so: M34^(1/77) = I14^540 / (M12^36 * M34^7) and dividing gives the other factor: M12^(1/15) = I14 / M34^(1/77) These values can then be fed into the expressions above to recover M1^(1/3) and the other three values, all with only one full-sized exponentiation for the four messages. In general, finding the exponent for Ixx can be handled by the Chinese Remainder Theorem. However it requires that the two values be relatively prime. That is why the exponents used in Batch RSA must all be relatively prime, so that there is a solution to the value of the exponent for Ixx. As the number of values in the batch increases, the "small" exponents needed to recover the values increase as well. We saw above that the exponents went from 6 and 22 for the size-two batches to 540 for the size-four batch. This means that you reach a point of diminishing returns where increasing the batch size no longer provides much benefit. Fiat suggests a batch size of n/(log^2 n) messages, where n is the length of the full-sized exponentiation (e.g. 1000 for a 1000 bit modulus). This would correspond to about a 10 message batch for a 1024 bit key. Fiat describes a few situations where it may be appropriate to use different exponents for multiple RSA operations. In the case of a server issuing multiple RSA signatures it could define its public key to be (n, e1, e2, e3,...) and specify that the signature was valid for any exponent in the list. Then it could batch up signatures and use a different exponent for each one. Another case is "pure RSA" encryption, where the message itself is broken into blocks and each one is RSA encrypted. In that case the blocks could use successive exponents from the list, and the receiver could decrypt a batch of blocks using one large exponentiation. There is another case of interest to us, related to the task of searching through messages from a message pool, possibly steganographically hidden. That will be described in another message.

1 0

lists
by nobody＠nsm.htp.org 17 Dec '03

17 Dec '03

Can someone tell me if the toad cypherpunk list gets *all* the cypherpuink traffic? As I understand it there are three possible subscription points -- does one subscription cover all? Thanks in advance...

2 1

UNSUBSCRIBE CYPHERPUNKS-ANNOUNCE
by Brian＠HyperSoft.Net 17 Dec '03

17 Dec '03

UNSUBSCRIBE CYPHERPUNKS-ANNOUNCE

1 0

UNSUBSCRIBE CYPHERPUNKS-ANNOUNCE
by bRIAN＠4qsi.com 17 Dec '03

17 Dec '03

UNSUBSCRIBE CYPHERPUNKS-ANNOUNCE

2 1

Lessig on antitrust and government regulation
by Declan McCullagh 17 Dec '03

17 Dec '03

Lessig is the special master appointed by the judge in the Microsoft consent decree case. He once wrote: >Whether a regulation is >rational turns on the facts, and what counts as "the facts" turns on the >theory that animates inquiry into the facts. Wow. How do we know what theory is the right one, and when we should change it? -Declan

2 1

Bruce Schneier, Sandia, FBI and the REAL WORLD
by bill payne 17 Dec '03

17 Dec '03

Wednesday 1/7/98 12:57 PM Bruce Schneier wrote and a burglar willing to try all 10,000 is guaranteed to break into your house. This is posted at jya.com. Sandia employees Jack Hudson and Jack Menako, both in my division when Sandia transferred me to break electronic locks for the FBI/ERF [Engineering Research Facility, Quantico, VA], were TRYING to defeat combination locks on file cabinets. Menako built a frame to connect a stepper-motor to the combination dial. The stepper motor was wried to a PC. Hudson wrote the software to try all possible combinations. What happened, IN FACT, was that the combination lock wore-out before the combination which opened the lock was reached. Combinations locks are NOT ENGINEERED for such heavy use. The file safe had to be destroyed to open it! So Schneier's statement may be incorrect. No guarantee. Guys, this is the REAL WORLD. bill Title: Security Pitfalls in Cryptography Security Pitfalls in Cryptography by Bruce Schneier Cryptography Consultant Counterpane Systems e-mail: schneier(a)counterpane.com Magazine articles like to describe cryptography products in terms of algorithms and key length. Algorithms make good sound bites: they can be explained in a few words and they're easy to compare with one another. "128-bit keys mean good security." "Triple-DES means good security." "40-bit keys mean weak security." "2048-bit RSA is better than 1024-bit RSA." But reality isn't that simple. Longer keys don't always mean more security. Compare the cryptographic algorithm to the lock on your front door. Most door locks have four metal pins, each of which can be in one of ten positions. A key sets the pins in a particular configuration. If the key aligns them all correctly, then the lock opens. So there are only 10,000 possible keys, and a burglar willing to try all 10,000 is guaranteed to break into your house. But an improved lock with ten pins, making 10 billion possible keys, probably won't make your house more secure. Burglars don't try every possible key (a brute-force attack); most aren't even clever enough to pick the lock (a cryptographic attack against the algorithm). They smash windows, kick in doors, disguise themselves as policemen, or rob keyholders at gunpoint. One ring of art thieves in California defeated home security systems by taking a chainsaw to the house walls. Better locks don't help against these attacks. Strong cryptography is very powerful when it is done right, but it is not a panacea. Focusing on the cryptographic algorithms while ignoring other aspects of security is like defending your house not by building a fence around it, but by putting an immense stake into the ground and hoping that the adversary runs right into it. Smart attackers will just go around the algorithms. Counterpane Systems has spent years designing, analyzing, and breaking cryptographic systems. While we do research on published algorithms and protocols, most of our work examines actual products. We've designed and analyzed systems that protect privacy, ensure confidentiality, provide fairness, and facilitate commerce. We've worked with software, stand-alone hardware, and everything in between. We've broken our share of algorithms, but we can almost always find attacks that bypass the algorithms altogether. We don't have to try every possible key, or even find flaws in the algorithms. We exploit errors in design, errors in implementation, and errors in installation. Sometimes we invent a new trick to break a system, but most of the time we exploit the same old mistakes that designers make over and over again. Attacks Against Cryptographic Designs A cryptographic system can only be as strong as the encryption algorithms, digital signature algorithms, one-way hash functions, and message authentication codes it relies on. Break any of them, and you've broken the system. And just as it's possible to build a weak structure using strong materials, it's possible to build a weak cryptographic system using strong algorithms and protocols. We often find systems that "void the warranty" of their cryptography by not using it properly: failing to check the size of values, reusing random parameters that should never be reused, and so on. Encryption algorithms don't necessarily provide data integrity. Key exchange protocols don't necessarily ensure that both parties receive the same key. In a recent research project, we found that some--not all--systems using related cryptographic keys could be broken, even though each individual key was secure. Security is a lot more than plugging in an algorithm and expecting the system to work. Even good engineers, well-known companies, and lots of effort are no guarantee of robust implementation; our work on the U.S. digital cellular encryption algorithm illustrated that. Random-number generators are another place where cryptographic systems often break. Good random-number generators are hard to design, because their security often depends on the particulars of the hardware and software. Many products we examine use bad ones. The cryptography may be strong, but if the random-number generator produces weak keys, the system is much easier to break. Other products use secure random-number generators, but they don't use enough randomness to make the cryptography secure. Recently Counterpane Systems has published new classes of attacks against random-number generators, based on our work with commercial designs. One of the most surprising things we've found is that specific random-number generators may be secure for one purpose but insecure for another; generalizing security analyses is dangerous. In another research result, we looked at interactions between individually secure cryptographic protocols. Given a secure protocol, we show how to build another secure protocol that will break the first if both are used with the same keys on the same device. Attacks Against Implementations Many systems fail because of mistakes in implementation. Some systems don't ensure that plaintext is destroyed after it's encrypted. Other systems use temporary files to protect against data loss during a system crash, or virtual memory to increase the available memory; these features can accidentally leave plaintext lying around on the hard drive. In extreme cases, the operating system can leave the keys on the hard drive. One product we've seen used a special window for password input. The password remained in the window's memory even after it was closed. It didn't matter how good that product's cryptography was; it was broken by the user interface. Other systems fall to more subtle problems. Sometimes the same data is encrypted with two different keys, one strong and one weak. Other systems use master keys and then one-time session keys. We've broken systems using partial information about the different keys. We've also seen systems that use inadequate protection mechanisms for the master keys, mistakenly relying on the security of the session keys. It's vital to secure all possible ways to learn a key, not just the most obvious ones. Electronic commerce systems often make implementation trade-offs to enhance usability. We've found subtle vulnerabilities here, when designers don't think through the security implications of their trade-offs. Doing account reconciliation only once per day might be easier, but what kind of damage can an attacker do in a few hours? Can audit mechanisms be flooded to hide the identity of an attacker? Some systems record compromised keys on "hotlists"; attacks against these hotlists can be very fruitful. Other systems can be broken through replay attacks: reusing old messages, or parts of old messages, to fool various parties. Systems that allow old keys to be recovered in an emergency provide another area to attack. Good cryptographic systems are designed so that the keys exist for as short a period of time as possible; key recovery often negates any security benefit by forcing keys to exist long after they are useful. Furthermore, key recovery databases become sources of vulnerability in themselves, and have to be designed and implemented securely. In one product we evaluated, flaws in the key recovery database allowed criminals to commit fraud and then frame legitimate users. Attacks Against Passwords Many systems break because they rely on user-generated passwords. Left to themselves, people don't choose strong passwords. If they're forced to use strong passwords, they can't remember them. If the password becomes a key, it's usually much easier--and faster--to guess the password than it is to brute-force the key; we've seen elaborate security systems fail in this way. Some user interfaces make the problem even worse: limiting the passwords to eight characters, converting everything to lower case, etc. Even passphrases can be weak: searching through 40-character phrases is often much easier than searching through 64-bit random keys. We've also seen key-recovery systems that circumvent strong session keys by using weak passwords for key-recovery. Attacks Against Hardware Some systems, particularly commerce systems, rely on tamper-resistant hardware for security: smart cards, electronic wallets, dongles, etc. These systems may assume public terminals never fall into the wrong hands, or that those "wrong hands" lack the expertise and equipment to attack the hardware. While hardware security is an important component in many secure systems, we distrust systems whose security rests solely on assumptions about tamper resistance. We've rarely seen tamper resistance techniques that work, and tools for defeating tamper resistance are getting better all the time. When we design systems that use tamper resistance, we always build in complementary security mechanisms just in case the tamper resistance fails. The "timing attack" made a big press splash in 1995: RSA private keys could be recovered by measuring the relative times cryptographic operations took. The attack has been successfully implemented against smart cards and other security tokens, and against electronic commerce servers across the Internet. Counterpane Systems and others have generalized these methods to include attacks on a system by measuring power consumption, radiation emissions, and other "side channels," and have implemented them against a variety of public-key and symmetric algorithms in "secure" tokens. We've yet to find a smart card that we can't pull the secret keys out of by looking at side channels. Related research has looked at fault analysis: deliberately introducing faults into cryptographic processors in order to determine the secret keys. The effects of this attack can be devastating. Attacks Against Trust Models Many of our more interesting attacks are against the underlying trust model of the system: who or what in the system is trusted, in what way, and to what extent. Simple systems, like hard-drive encryption programs or telephone privacy products, have simple trust models. Complex systems, like electronic commerce systems or multi-user e-mail security programs, have complex (and subtle) trust models. An e-mail program might use uncrackable cryptography for the messages, but unless the keys are certified by a trusted source (and unless that certification can be verified), the system is still vulnerable. Some commerce systems can be broken by a merchant and a customer colluding, or by two different customers colluding. Other systems make implicit assumptions about security infrastructures, but don't bother to check that those assumptions are actually true. If the trust model isn't documented, then an engineer can unknowingly change it in product development, and compromise security. Many software systems make poor trust assumptions about the computers they run on; they assume the desktop is secure. These programs can often be broken by Trojan horse software that sniffs passwords, reads plaintext, or otherwise circumvents security measures. Systems working across computer networks have to worry about security flaws resulting from the network protocols. Computers that are attached to the Internet can also be vulnerable. Again, the cryptography may be irrelevant if it can be circumvented through network insecurity. And no software is secure against reverse-engineering. Often, a system will be designed with one trust model in mind, and implemented with another. Decisions made in the design process might be completely ignored when it comes time to sell it to customers. A system that is secure when the operators are trusted and the computers are completely under the control of the company using the system may not be secure when the operators are temps hired at just over minimum wage and the computers are untrusted. Good trust models work even if some of the trust assumptions turn out to be wrong. Attacks on the Users Even when a system is secure if used properly, its users can subvert its security by accident--especially if the system isn't designed very well. The classic example of this is the user who gives his password to his co-workers so they can fix some problem when he's out of the office. Users may not report missing smart cards for a few days, in case they are just misplaced. They may not carefully check the name on a digital certificate. They may reuse their secure passwords on other, insecure systems. They may not change their software's default weak security settings. Good system design can't fix all these social problems, but it can help avoid many of them. Attacks Against Failure Recovery Strong systems are designed to keep small security breaks from becoming big ones. Recovering the key to one file should not allow the attacker to read every file on the hard drive. A hacker who reverse-engineers a smart card should only learn the secrets in that smart card, not information that will help him break other smart cards in the system. In a multi-user system, knowing one person's secrets shouldn't compromise everyone else's. Many systems have a "default to insecure mode." If the security feature doesn't work, most people just turn it off and finish their business. If the on-line credit card verification system is down, merchants will default to the less-secure paper system. Similarly, it is sometimes possible to mount a "version rollback attack" against a system after it has been revised to fix a security problem: the need for backwards compatibility allows an attacker to force the protocol into an older, insecure, version. Other systems have no ability to recover from disaster. If the security breaks, there's no way to fix it. For electronic commerce systems, which could have millions of users, this can be particularly damaging. Such systems should plan to respond to attacks, and to upgrade security without having to shut the system down. The phrase "and then the company is screwed" is never something you want to put in your business plan. Good system design considers what will happen when an attack occurs, and works out ways to contain the damage and recover from the attack. Attacks Against the Cryptography Sometimes, products even get the cryptography wrong. Some rely on proprietary encryption algorithms. Invariably, these are very weak. Counterpane Systems has had considerable success breaking published encryption algorithms; our track record against proprietary ones is even better. Keeping the algorithm secret isn't much of an impediment to analysis, anyway--it only takes a couple of days to reverse-engineer the cryptographic algorithm from executable code. One system we analyzed, the S/MIME 2 electronic-mail standard, took a relatively strong design and implemented it with a weak cryptographic algorithm. The system for DVD encryption took a weak algorithm and made it weaker. We've seen many other cryptographic mistakes: implementations that repeat "unique" random values, digital signature algorithms that don't properly verify parameters, hash functions altered to defeat the very properties they're being used for. We've seen cryptographic protocols used in ways that were not intended by the protocols' designers, and protocols "optimized" in seemingly trivial ways that completely break their security. Attack Prevention vs. Attack Detection Most cryptographic systems rely on prevention as their sole means of defense: the cryptography keeps people from cheating, lying, abusing, or whatever. Defense should never be that narrow. A strong system also tries to detect abuse and to contain the effects of any attack. One of our fundamental design principles is that sooner or later, every system will be successfully attacked, probably in a completely unexpected way and with unexpected consequences. It is important to be able to detect such an attack, and then to contain the attack to ensure it does minimal damage. More importantly, once the attack is detected, the system needs to recover: generate and promulgate a new key pair, update the protocol and invalidate the old one, remove an untrusted node from the system, etc. Unfortunately, many systems don't collect enough data to provide an audit trail, or fail to protect the data against modification. Counterpane Systems has done considerable work in securing audit logs in electronic commerce systems, mostly in response to system designs that could fail completely in the event of a successful attack. These systems have to do more than detect an attack: they must also be able to produce evidence that can convince a judge and jury of guilt. Building Secure Cryptographic Systems Security designers occupy what Prussian general Carl von Clausewitz calls "the position of the interior." A good security product must defend against every possible attack, even attacks that haven't been invented yet. Attackers, on the other hand, only need to find one security flaw in order to defeat the system. And they can cheat. They can collude, conspire, and wait for technology to give them additional tools. They can attack the system in ways the system designer never thought of. Building a secure cryptographic system is easy to do badly, and very difficult to do well. Unfortunately, most people can't tell the difference. In other areas of computer science, functionality serves to differentiate the good from the bad: a good compression algorithm will work better than a bad one; a bad compression program will look worse in feature-comparison charts. Cryptography is different. Just because an encryption program works doesn't mean it is secure. What happens with most products is that someone reads Applied Cryptography, chooses an algorithm and protocol, tests it to make sure it works, and thinks he's done. He's not. Functionality does not equal quality, and no amount of beta testing will ever reveal a security flaw. Too many products are merely "buzzword compliant"; they use secure cryptography, but they are not secure. Home page - <a href="http://www.counterpane.com/cpaneinfo.html">Counterpane - Applied Cryptography - E-Mail Security - Crypto Links Bruce Schneier Bio - <a href="http://www.counterpane.com/blowfish.html">Blowfish - Publications - Contact Counterpane Bruce Schneier Copyright 1998 Counterpane Systems.

3 2

Re: The Digital Society Group
by jalonz＠openworld.com 17 Dec '03

17 Dec '03

>>Without getting into too much detail, The Digital Society Group is >>constructing a pure-technology infrastructure to provide for the operation, >>governance and existence of a complete digital society within a free >>enterprise zone. >The web site doesn't explain what methods you are using to establish these >zones. Do you have a mailing list set up for discussion? The plan >sounds interesting and ideologically supportable, but I'm skeptical. Blanc, I'm trying to get more docs online ASAP to explain things. The physical free zones are very popular in the interational business world, but I as a computer type had never heard of them other than Hong Kong, etc. When a country wants to set up a free zone, they come to Openworld and its partner companies who do everything from clearing land, construction, setting up businesses, schools, hospitals, etc. One of the soon to be required components of a free zone installation is a digital infrastructure to link all of the things together. We're talking smart cards for physical structure security and personal ID, email, web hosting, net access, all kinds of stuff. Since we are building a "country" from scratch, rather than have to automate paper workflows and do document management, the governance processes are designed to be digital from the start. Thus, to provide incorporation services to its citizens, a free zone allows them to sign up via web browser, and the daily maintenance, processing and management of the corporate records is also done almost exclusively via web browser and email. Its fast, cheap, and requires far less labor than a paper-based system. Another feature is that rather than maintaining the records for the customer, the customer can log in via web browser and update their own corporate record. (similar to Internic) This reduces labor even further and reduces the cost of incorporation to around $100 per year making instant offshore incorporation accessible to the general global public for the first time. That kind of solution applied across an entire governance and communications infrastructure make for some radical things to become possible. Another concept being implemented is that each new free zone (being fully wired) can easily replicate records and data with other free zones (they will actually be required to for certain things) and thus a citizen in one free zone can access banking, etc. services (even physical access) in another. So, we see the emergence of a phsically distributed, digitally cohesive network of "corporate states". This lends to applications like data protection and hiding via distributed storage or data sharing via common dataspaces and replication. The technical methods to perform all of this work are a bit touchy. At the risk of starting endless flame wars, I was looking at Lotus Bloats for its replication and hierarchical security structure as well as easy forms to web publishing and workflow management. That got shot down at the thought of actually administrating the mess and also the costs are fairly significant. The final nail in the coffin was the encryption key escrow fiasco with the Swiss. I was also looking at NT due to the nice database-to-web interface and the fact that IIS 4 isn't too bad. But again software license costs are large and who knows if Microsoft is doing, or will do, a key escrow deal for future products? Who knows what they are doing now with NT on the OS level? You can't run around making structures which allow people around the world to move money and communicate anonymously, incorporate and have software agents be owners of property and bank accounts without someone getting very pissed off. Thus, a good solution seems to be Linux in that its cheap, Unix is good for multi-process routing, and the toolkits and components created by the Digital Society can be easily moved into the public domin in some form or another. Also, the export mess can be gotten around in one way or another. Any comments? Any better alternatives than Linux? The coding being done now is either cross-platform or prototype which will be scrapped as soon as the kinks are worked out and the real fun can begin. The Digital Society is purposefully working cheap and small to enable the tools and communities to be deployed at as close as possible to no cost for the end-user - that is the priority. Most things are being coded from scratch to ensure security and keep the costs low. Labor is cheap - when its your own. :) Jalon --------------------------------------------------------------- Jalon Q. Zimmerman, Director The Digital Society Group A division of Openworld, Inc. http://www.openworld.com/ jalonz(a)openworld.com --------------------------------------------------------------- The government is not your mommy. ---------------------------------------------------------------

1 0