December 2003 - cypherpunks-legacy

RE: Workers Paradise. /Political rant.
by jbugden＠smtplink.alis.ca 17 Dec '03

17 Dec '03

tcmay(a)got.net (Timothy C. May) writes: > Crypto Anarchy means getting rid of deadwood the old-fashioned way. dlv(a)bwalk.dm.com (Dr.Dimitri Vulis KOTM) wrote: >Starting with the lying old fart himself. You shouldn't be so hard on Tim. I tried giving up farting years ago but I found I gained a lot of weight. It's also become more socially acceptable as evidenced by the new farting section in many English pubs. They even have a special section for me on some international flights. And unlike smoking, you *can* do it in the toilet. Besides, it can't be worse than smoking. Unless, perhaps, you do both at the same time... Cheers, James

2 1

Re: 56 kbps modems
by Remo Pini 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: cypherpunks(a)toad.com Date: Mon Sep 16 15:59:53 1996 I think I have to throw in some words here, too: 1. BAUD is one distingushable signal form. 2. BPS is bits per second 3. NO transmission over a standard phoneline can have more than 3100 baud, because the frequency of anything transmitted over that line is band limited to 300hz - 3400hz. (If you have ISDN it's not relevant anyway, since you are fixed with 8000hz or 64000 bps->in europe :), 56000 bps in usa) 4. Most modern transmission schemes work with multiple bits per baud. I.e. you transmit 10 bits in one baud if you have a 31000 bps modem. the only limitation in transmission speed is the amount of binary values you can pack into one baud. that on the other hand is limited by the S/N (signal to noise) ratio of your line. If you have a noise of 0.9%, you can't use more than 100 steps or you have ambiguous signals. since people talk about 56000 bps modems (we tried 34000 modems here and they couldn't produce more than 28800 on a very good connection) that would mean, that you have to transmit 18 bits = 262144 (!) distinguishable signal forms per baud. Comments? Remo Pini - ------< fate favors the prepared mind >------ Remo Pini rp(a)rpini.com PGP: http://www.rpini.com/crypto/crypto.html - ----< words are what reality is made of >---- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBMj1dWhFhy5sz+bTpAQHmVAgAqRHydyZdElXlwMSgdKB6hg1fDBCMfhia JoI5W8n0JLcKe9HYN/H0DPqFHHDIATEhlN3b3OIhYCw52cNJ/e3b9Nbp5RQo+sDX zAogz5wZiDV7EA/gL589lNQZ9VKHlgTYBLzu1tqyJ5cD2KhWEUjvXyN4lYuxcEQT NIaiNPeYXrC0BeoLa/AE8mCrtu+7nhxy5HlSjDiu3lEYaVygKIPQHM3+Ljzq0jkq bmbqJbTyZshos+5gxHyXLsbL8rkpST53YT4Z3clL6PCv1ntNGXtb/loWgIDallYJ bHgfh/bAS5Utg7fpzuVNS8AJV8L2VLirScBd4Bq5RAXZxnoTVVQxOw== =9JSI -----END PGP SIGNATURE-----

5 4

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)rigel.cyberpass.net> mix cpunk pgp hash latent"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash latent cut ek"; $remailer{"winsock"} = "<winsock(a)c2.org> cpunk pgp hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash middle latent cut ek reord"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash ksub latent cut ek mix reord"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (cyber mix) The alpha and nymrod nymservers are down due to abuse. However, you can use the cyber nymserver. The nym.alias.net server will be listed soon. See http://www.cs.berkeley.edu/~raph/n.a.n.html for details. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. Hopefully, this is fixed by now. The penet remailer is closed. Last update: Mon 16 Sep 96 6:48:06 PDT remailer email address history latency uptime ----------------------------------------------------------------------- exon remailer(a)remailer.nl.com *#**##*#***# 1:16 100.00% jam remailer(a)cypherpunks.ca *****++***** 17:07 99.99% squirrel mix(a)squirrel.owl.de -+++---++++ 2:04:26 99.98% mix mixmaster(a)remail.obscura.com +++++++++--+ 1:01:22 99.98% lead mix(a)zifi.genetics.utah.edu + -++*++++++ 41:18 99.84% amnesia amnesia(a)chardos.connix.com ----------- 3:38:09 99.82% dustbin dustman(a)athensnet.com -+ ++----+ 1:24:30 99.74% cyber alias(a)alias.cyberpass.net * **+ ++*+ * 33:26 99.37% extropia remail(a)miron.vip.best.com ------.--.- 13:13:34 99.13% haystack haystack(a)holy.cow.net *###-#*##### 3:35 98.87% middle middleman(a)jpunix.com -- - --+ 2:53:19 98.74% replay remailer(a)replay.com ****+* ***** 4:45 98.13% winsock winsock(a)c2.org --- -+--++ 1:20:34 97.83% balls remailer(a)huge.cajones.com ******** * 5:06 88.34% nemesis remailer(a)meaning.com * 24:33 4.73% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

RE: Workers Paradise. /Political rant.
by jbugden＠smtplink.alis.ca 17 Dec '03

17 Dec '03

tcmay(a)got.net (Timothy C. May) wrote: >"Saving for a rainy day," whether saving, investing, getting an education (while others are out partying), preparing, etc., all takes effort and commitment. If those who save and prepare are then told they have to pay high taxes to support those who partied....well, the predictable effect [...] is _more_ people in agony. When you tell people that a compassionate society will meet their basic needs, a predictable fraction of them will choose not to work hard and prepare themselves. Two questions, two observations: Do you have health insurance? Do you have life insurance? I have commented on your line of reasoning before and and it still seems to me that an important part of the discussion is missed. Specifically, that anyone can "save for a rainy day" and still not be able to provide for events that can always happen: Heart attack, stroke, car accident, pinched nerve that leaves you in excruciating pain and unable to work for several years. I don't think that a reasonable person would argue that medical insurance should be outlawed because everyone should take care of their own needs. A social safety net is simply a form of health and life insurance. Statistical arbitrage if you will. By spreading the risk you minimize the cost. Yes, some people will take advantage of the system. But like a virus, a robust system should be able to withstand this form of attack. I'm reminded of a Bloom County cartoon with Opus, Steve Dallas and Bill the cat sitting on a park bench as a jogger runs past. he derides the trio saying, "I jog three miles and work out every day, eat only healthy foods, and have regular medical checkups. I'll live twice as long as you lazy slobs." In the next panel the jogger is hit by lightning as the trio on the bench look on in shock. The last panel: "Here's to no guarantees!" and "Pass the ding dongs." Prend soin, James [Bible excerpt awaiting review as a motivation for human decency.] The ground of a certain rich man brought forth plentifully: And he thought within himself, saying, What shall I do, because I have no room where to bestow my fruits? And he said, This will I do: I will pull down my barns, and build greater; and there will I bestow all my fruits and my goods. And I will say to my soul, Soul, thou hast much goods laid up for many years; take thine ease, eat, drink, and be merry. But God said unto him, Thou fool, this night thy soul shall be required of thee: then whose shall those things be, which thou hast provided? [excerpted from Luke 12:16-20, King James Version]

4 3

Re: Workers Paradise. /Political rant.
by Rick Smith 17 Dec '03

17 Dec '03

Asgaard wrote: : .... But suppose the population problem could : be fixed. Then, with technology escalating towards singularity, : machines doing almost all labor, there could certainly exist a : system where the 'dumb' and 'lazy' could be fed and housed properly : without anybody complaining. I'm always fascinated when people trot out this notion of technology giving us a maintenance free world that provides all our needs. Like Rifkin's "End of Work." I'm sorry but I just don't see how the problems of food and shelter are solved simply because we've automated the production of bank statements. All the really effective automation has involved symbolic activities, not the basic stuff of life, like food and shelter. : P.S. Mac Donalds could easily be replaced by a bot. Very unlikely. Despite the incredible degree of mechanization that happens in food production, *most* of it requires people in the loop. Part of it is health concerns -- you're far more likely to poison a significant portion of the population if you don't keep active human involvement in food production. But there's also a lot having to do with the structure of the work. You *can't* send a robot tractor into the fields and expect it to treat your corn right. And milking machines, well .... I did a lot with fault tolerance and industrial robotics in a previous life. Robots work fine in highly structured environments. Their value decreases dramatically as you remove structure. In unstructured environments they're either useless or just plain dangerous. Even the so called "industrialized" farms are wildly unstructured compared to a factory floor. And there's little reason to assume that 'biological units' (plants and animals produced for food) in a fully structured factory-like setting will yield all the products necessary for an adequate food supply. It seems that whenever we develop a "complete" model of what people need to survive and subject a few people to it, we discover that something fatal has been left out. : But to force people into menial service jobs just to literally : survive is not to my taste. No, give them minimal shelter for : nothing and from there on let the market anarcho-capitalistic : struggle begin, for obtaining a higher than minimum material : standard or reputational standing. I suspect that the Real World will always require a large portion of the available labor pool to do work that supports the production of food and shelter. The support has gotten pretty indirect in modern industrialized countries, I admit. Rick. smith(a)sctc.com

1 0

RE: Workers Paradise. /Political rant.
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 3:18 PM 9/16/96, jbugden(a)smtplink.alis.ca wrote: >I don't think that a reasonable person would argue that medical insurance >should >be outlawed because everyone should take care of their own needs. A social >safety net is simply a form of health and life insurance. Statistical arbitrage >if you will. By spreading the risk you minimize the cost. Yes, some people will >take advantage of the system. But like a virus, a robust system should be able >to withstand this form of attack. I have never argued against insurance! People who wish to buy insurance are welcome to, obviously. As to the "social safety net," things are far, far beyond a simple safety net. When 14-year-old pregnant inner city girls are given money to set up their own households (cf. Charles Murray's "Losing Ground"), this is not a "safety net," this is subsidized breeding. And so on. --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Re: IBM_gak
by declan＠well.com 17 Dec '03

17 Dec '03

> 9-13-96. BuWi: > > "Revolutionary Intranet security product to be > demonstrated at Interop DotCom " > > DSN's NetFortress fully automates hardware-based > authentication, encryption and key exchange into a > plug and play solution. It completely eliminates the > possibility of IP spoofing, eavesdropping and > break-ins. "After installing it, I couldn't even tell > which service a given packet was from - everything but > the packet header itself was rendered undecipherable > as it traversed the Internet." DSN Technology was > founded by Dr. Aharon Friedman and Andy Savas. Thanks, John, for forwarding. I spoke with the DSN folks today. They developed NetFortress in the U.S. and have recently found a substantial overseas market for it. "That's definitely a problem for us. We're actively lobbying senators to pass procode, to get it out of committee." Since of course multinationals would be unwilling to use DSN stuff under current export-control regime. -Declan

1 0

Snake Oil FAQ 0.4 [comments appreciated]
by C Matthew Curtin 17 Dec '03

17 Dec '03

The Snake Oil FAQ version 0.4 is waiting for you to look at it and comment on http://research.megasoft.com/people/cmcurtin/snake-oil/snake-oil-faq.html The text version follows... -matt --------------------------- snake-oil-faq ---------------------------- Snake-Oil Warning Signs Encryption Software to Avoid $Id: snake-oil-faq.html,v 0.4 1996/09/16 13:52:26 cmcurtin Exp $ Distribution Please do not distribute this beyond the circles of cryptographic competence yet. This is an incomplete work-in-progress. Feedback is greatly appreciated. The Snake Oil FAQ is (to be) posted monthly to cypherpunks, sci.crypt, alt.security, comp.security, and comp.infosystems. We're targeting those who have influence over or direct involvement in the purchasing decisions of computer security software and equipment in the corporate and academic worlds, as well as individual users who wish to assert their privacy through the use of good cryptography. Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves, based on our own experiences, etc., etc., etc. This is a general guideline, and as such, cannot be the sole metric by which a security product is rated, since there can be exceptions to any of these rules. (But if you're looking at something that sounds familiar on several of the 'things to watch out for,' you're probably dealing with snake oil. From time to time, a reputable and decent vendor will produce something that is actually quite good, but will use some braindead marketing technique, so be aware of exceptions.) Every effort has been made to produce an accurate and useful document, but the information contained herein is completely without warranty. If you find any errors, or wish to otherwise contribute, please contact the document keeper, C Matthew Curtin <cmcurtin(a)research.megasoft.com> Introduction Good cryptography is an excellent and necessary tool for almost anyone. However, there is a multitude of products around. Many good cryptographic products are available, both commercial (including shareware) and free. However, there are also some extremely bad cryptographic products (known in the field as "Snake Oil"), which not only fail do their job of providing security, but are based on, and add to, the many misconceptions and misunderstandings surrounding cryptography and security. Superficially, it is difficult for someone to distinguish the output of a secure encryption utility from snake oil: both look garbled. The purpose of this document is present some obvious "red flags" so that people unfamiliar with the nuts and bolts of cryptography can use as a guideline for determining whether they're dealing with snake oil or the Real Thing. For a variety of reasons, this document is general in scope and does not mention specific products or algorithms as being "good" or "Snake Oil". When evaluating any product, be sure to understand what your needs are. For data security products, what do you need protected? Do you want an archiver that supports strong encryption? An E-mail client? Something that will encrypt on-line communications? Do you want to encrypt an entire disk or partition, or selectively some files? Do you need on-the-fly (automatic) encryption and decryption, or are you willing to select when and which files you want encrypted? How secure is "secure enough?" Does the data need to be unreadable by third parties for 5 minutes? One year? 50 years? 100 years? Different products will serve different needs, and it's rare that a product will serve every need. (Sometimes a product won't be needed: it may be better to use a utility to encrypt files, transmit them over a network using standard file transfer tools, and decrypt them at the other end than to use a separate encrypted utility in some cases.) Some basics The cryptography-faq (found at ftp://rtfm.mit.edu/pub/usenet/cryptography-faq/) is a more general tutorial of cryptography, and should also be consulted. In an effort to make this FAQ more complete, some very basic topics are included below. Conventional vs. Public Key Cryptography There are two basic types of cryptosystems: symmetric (also known as "conventional," sometimes also called "private key") and asymmetric (public key). Symmetric ciphers require both the sender and the recipient to have the same key. That key is applied to encrypt the data by the sender, and again by the recipient to decrypt the data. Asymmetric ciphers are much more flexible, from a key management perspective. Each user has a pair of keys: a public key and a private key. The public key is shared widely, given to everyone, while the private key is kept secret. If Alice wishes to mail Bob some secrets, she simply gets Bob's public key, encrypts her message with it, and sends it off to Bob. When Bob gets the message, he uses is private key to decrypt the message. Asymmetric cryptosystems are much slower than their symmetric counterparts. Also, key sizes must be much larger. See the cryptography FAQ for a more detailed discussion of the topic. Key Sizes Some ciphers, while currently secure against most attacks, are not considered viable in the next few years because of relatively small keysizes and increasing processor speeds (making a brute-force attacks feasible). The tables below should give some general guidelines for making intelligent decisions about the key length you need. If the key is too short, the system will be easily broken, even if the cipher is a good one. In [1] and [2], we're presented with some guidelines for deciding appropriate key length. (It is important to note that this is based on the ability to predict computing power 40, 65, and 100 years from now. Major breakthroughs in computing power 30 years from now might render everything on this chart kiddieplay.) Security Requirements for Different Information Type of Traffic Lifetime Minimum [Symmetric] Key Length Tactical military information minutes/hours 56-64 bits Product announcements, mergers, interest rates days/weeks 64 bits Long-term business plans years 64 bits Trade secrets (e.g., recipe for Coca-Cola) decades 112 bits H-bomb secrets >40 years 128 bits Identities of spies >50 years 128 bits Personal affairs >50 years 128 bits Diplomatic embarrassments >65 years at least 128 bits U.S. Census data 100 years at least 128 bits As mentioned earlier, asymmetric ciphers require significantly longer keys to provide the same level of security as their symmetric cipher counterparts. Here is a comparison table, again, from Applied Cryptography, second edition. Symmetric and Public-Key Lengths With Similar Resistance to Brute-Force Attacks Symmetric Key Length Public-key Key Length 56 bits 384 bits 64 bits 512 bits 80 bits 768 bits 112 bits 1792 bits 128 bits 2304 bits Some Common Snake-Oil Warning Signs The following are some of the "red flags" one should watch for when examining an encryption product * Technobabble The vendor's description of the product may contain a lot of hard-to-follow use of technical terms to describe how the product works. If this appears to be confusing nonsense, it may very well be (even to someone familiar with the terminology). Technobabble is a good means of confusing a potential user and masking the fact that the vendor doesn't understand anything either. A sign of technobabble is a descrption which drops a lot of technical terms for how the system works without actually explaining how it works. Often specifically coined terms are used to describe the scheme which are not found in the literature. * New Type of Cryptography? Beware of any vendor who claims to have invented a "new type of cryptography" or a "revolutionary breakthrough". Truly "new break-throughs" are likely to show up in the literature, and many in the field are unlikely to trust them until after years of analysis, by which time they are not so new anymore. Avoid software which claims to use 'new paradigms' of computing such as cellular automata, neural nets, genetic algorithms, chaos theory, etc. Just because software uses to different method of computation doesn't make it more secure. Anything that claims to have invented a new public key cryptosystem without publishing the details or underlying mathematical principles is highly suspect. Modern cryptography, especially public key systems, is grounded in mathematical theory. The security is based on problems that are believed, if not known to be hard to solve. The strength of any encryption scheme is only proven by the test of time. New crypto is like new pharmaceuticals, not new cars. * Proprietary Algorithms Avoid software which uses "proprietary" or "secret" algorithms. Security through obscurity is not considered a safe means of protecting your data. If the vendor does not feel confident that the method used can withstand years of scrutiny by the academic community, then you should be wary of trusting it. (Note that a vendor who specializes in the cryptography may have a proprietary algorithm which they'll show to others if they sign a non-disclosure agreement. If the vendor is well-reputed in the field, this can be an exception.) Beware of specially modified versions of well-known algorithms. This may intentionally or unintentionally weaken the cipher. The use of a trusted algorithm, if not with technical notes explaining the implementation (if not availability of the source code for the product) are a sign of good faith on the part of the vendor that you can take apart and test the implementation yourself. A common excuse for not disclosing how a program works is that "hackers might try to crack the program's security." While this may be a valid concern, it should be noted that such 'hackers' can reverse engineer the program to see how it works anyway. If the program is implemented properly and the algorithm is secure, this is not a problem. (If a hypothetical 'hacker' was able to get access you your system, access to encrypted data might be the least of your problems.) * Experienced Security Experts and Rave Reviews Beware of any product claiming that "experienced security experts" have analyzed it, but it won't say who (especially if the scheme has not been published in a reputable journal). Don't rely on reviews in newspapers, magazines or television shows, since they generally don't have cryptologists (celebrity hackers who know about telephone systems don't count) take the software apart for them. Just because the vendor is a well known company or the algorithm is patented doesn't make it secure either. * Unbreakability Some vendors will claim their software is "unbreakable". This is marketing hype, and a common sign of snake-oil. Avoid any vendor that makes unrealistic claims. No algorithm is unbreakable. Even the best algorithms are breakable using "brute force" (trying every possible key), but if the key size is large enough, this is impractical even with vast amounts of computing power. One-time pads are unbreakable, but they must be implemented perfectly, which is, at best, very difficult. See the next section for a more detailed discussion. * One-Time-Pads A vendor might claim the system uses a one-time-pad (OTP), which is theoretically unbreakable. That is, snake-oil sellers will try to capitalize on the known strength of a OTP. It is important to understand that any variation in the implementation means that it is not an OTP, and has nowhere near the security of an OTP. A OTP system is not an algorithm. It works by having a "pad" of random bits in the possession of both the sender and recipient. The message is encrypted using the next n bits in the pad as they key, where n is the number of bits in the message. After the bits are used from the pad, they're destroyed, and can never again be used. The bits in the pad must be truly random, generated using a real random source, such as specialized hardware, radioactive decay timings, etc., and not from an algorithm or cipher. Anything else is not a one-time-pad. The vendor may confuse random session keys or initialization vectors with OTPs. * Algorithm or product XXX is insecure Be wary of anything that makes claims that particular algorithms or other products are insecure without backing up those claims (or at least citing references to them). Sometimes attacks are theoretical or impractical (requiring special circumstances or massive computing power running for many years), and it's easy to confuse a layman by mentioning these. * Keys and Passwords The "key" and the "password" are often not the same thing. The "key" generally refers to the actual data used by the cipher, while the "password" refers to the word or phrase the user types in, which the software converts into the key (usually through a process called "hashing" or "key initialization"). The reason this is done is because the characters a user is likely to type in do not cover the full range of possible characters. (Such keys would be more redundant and easier for an attacker to guess.) By hashing a key can be made from an arbitrary password that covers the full range of possible keys. It also allows one to use longer words, or phrases and whole sentences as a "passphrase", which is more secure. Anything that restricts users' passwords to something like 10 or 16 or even 32 characters is foolish. If the actual "password" is the cipher's key (rather than hashing it into a key, as explained above), avoid it. If the vendor confuses the distinctions between bits, bytes and characters when discussing the key, avoid this product. Convenience is nice, but be wary of anything that sounds too easy to use. Avoid anything that lets anyone with your copy of the software to access files, data, etc. without having to use some sort of key or passphrase. Avoid anything that doesn't let you generate your own keys (ie, the vendor sends you a key in the mail, or it's embedded in the copy of the software you buy). Avoid anything by a vendor who does not seem to understand the difference between public-key (asymmetric) cryptography and private-key (symmetric) cryptography. * Lost keys and passwords If there's a third-party utility that can crack the software, avoid it. If the vendor claims it can recover lost passwords (without using a key-backup or escrow feature), avoid it. If there is a key-backup or escrow feature, are you in control of the backup, or does the vendor or someone else hold a copy of the key? * Exportable from the USA If the software is made in North America, can it be exported? If the answer is yes, chances are it's not very strong. Strong cryptography is considered munitions in terms of export from the United States, and requires approval from the State Department. Chances are if the software is exportable, the algorithm is weak or it is crackable (hence it was approved for export). If the vendor is unaware of export restrictions, avoid the software: the vendor is not familiar with the state of the art. Because of export restrictions, some legitimate (not-Snake Oil) products may have a freely exportable version for outside of the USA, which is different from a separate US/Canada-only distribution. Also note that just because software has made it outside of North America does not mean that it is exportable: sometimes a utility will be illegally exported and posted on an overseas site. Other Considerations Interface isn't everything: user-friendliness is an important factor, but if the product isn't secure then you're better off with something that is secure (if not as easy to use). No product is secure if it's not used properly. You can be the weakest link in the chain if you use a product carelessly. Do not trust any product to be foolproof, and be wary any product that claims it is. Contributors The following folks have contributed to this FAQ. Jeremey Barrett <jeremey(a)forequest.com> <geeman(a)best.com> Jim Ray <liberty(a)gate.net> Robert Rothenburg Walking-Owl <wlkngowl(a)unix.asb.com> References 1. B. Schneier, Applied Cryptography, second edition, John Wiley & Sons, 1996 2. M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, E. Thompson, M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security," available via ftp://ftp.research.att.com/dist/mab/keylength.ps ---------------------------------------------------------------------------- C Matthew Curtin Last modified: Mon Sep 16 09:51:41 EDT ---------------------------------------------------------------------- -- C Matthew Curtin MEGASOFT, INC Chief Scientist I speak only for myself. Don't whine to anyone but me about anything I say. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet cmcurtin(a)research.megasoft.com http://research.megasoft.com/people/cmcurtin/

1 0

IBM Boosts Encryption Initiative
by Weld Pond 17 Dec '03

17 Dec '03

http://www.pcweek.com/news/0916/16enc.html IBM will roll out several security initiatives next month that include a new way to build encryption into software and technology that could enable U.S. companies to export products with strong encryption algorithms. and uhhh... IBM also will introduce several "key-recovery" technologies that could enable businesses to export encrypted data or software beyond the current 40-bit limit--without breaking U.S. government restrictions and whoa... The sources also added that the technology may satisfy the requirement imposed by the U.S. government that it be able to access encrypted data on demand. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio

1 0

Re: Snake Oil FAQ 0.4 [comments appreciated]
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To: cypherpunks(a)toad.com Date: Mon Sep 16 12:05:17 1996 > (First off, I'd like to thank Matt for doing this.) > > The key length stuff is good, but a common component of snake oil is > that it claims to have very long key sizes. > > | Some ciphers, while currently secure against most attacks, are not > | considered viable in the next few years because of relatively small > keysizes > | and increasing processor speeds (making a brute-force attacks > feasible). The > | tables below should give some general guidelines for making intelligent > | decisions about the key length you need. If the key is too short, the > system > | will be easily broken, even if the cipher is a good one. > | > | In [1] and [2], we're presented with some guidelines for deciding > | appropriate key length. (It is important to note that this is based on > the > | ability to predict computing power 40, 65, and 100 years from now. > Major > | breakthroughs in computing power 30 years from now might render > everything > | on this chart kiddieplay.) > > | * One-Time-Pads > | > | A vendor might claim the system uses a one-time-pad (OTP), which > is > | theoretically unbreakable. That is, snake-oil sellers will try > to > | capitalize on the known strength of a OTP. It is important to > | understand that any variation in the implementation means that it > is > | not an OTP, and has nowhere near the security of an OTP. > | > | A OTP system is not an algorithm. It works by having a "pad" of > random > | bits in the possession of both the sender and recipient. The > message is > | encrypted using the next n bits in the pad as they key, where n > is the > | number of bits in the message. After the bits are used from the > pad, > | they're destroyed, and can never again be used. The bits in the > pad > | must be truly random, generated using a real random source, such > as > | specialized hardware, radioactive decay timings, etc., and not > from an > | algorithm or cipher. Anything else is not a one-time-pad. > > The phrase easy-to-use should not appear in proximity to one > time pad, except in the context 'Easier key management than a one time > pad!" > I would also suggest that the generation of OTP 'pads' for users is *highly* questionable. Who else is getting a copy of them, assuming they're even valid? Dave Merriman - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- PGP Email welcome, encouraged, and PREFERRED. Visit my web site at http://www.shellback.com/p/merriman for my PGP key and fingerprint "What is the sound of one hand clapping in a forest with no one there to hear it?" I use Pronto Secure (tm) PGP-fluent Email software for Windows -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMjzSBMVrTvyYOzAZAQGVwQP+N6vjyniDH0ad3G8dWu1cPHi5yfvksbS7 EJmgpSVTlaLf1Kp7rX2zBULxKvd2bqN3z3tAhj6reeG8la+P3Skw9gPJS8ggYvOn cXwdRsCyRICgHYMcbaEB/91YsJMweYyzWLe2JZazs3NfsafxdNKerGR7kvoQF0bG oBNR169sGlo= =WqlN -----END PGP SIGNATURE-----

2 1