December 2003 - cypherpunks-legacy

Crypto and six yr old sex perverts: Project Electric Potatoes [CRYPTO]
by Scottauge＠aol.com 17 Dec '03

17 Dec '03

Using crypto may be required to keep ya outta jail, given the guberment has gone so far low as to "route out this six year old sex pervert busy kissing the girls." (Quoted for emphasis.) I wonder when sexual harassment will become a sex offence. Are the red sashed sex cores of Orwell's 1984 around the corner? I wonder if he will need to register with the sheriffs office in any towns he moves into as a sex offender - or has that law not passed yet? Soon I believe our communications will be turned against us - as I am sure I will hear about this one in the future.... Crypto can help us from the all intrusive guberment - it is far to big. Hence a new project for us all: Multicast Crypto referred to as Electric Potatoes as mashed up potatoes are hard to put back together. Purpose: Already we are seeing problems for speech on the internet (see radikal postings - though they are a bit fruity IMHO.) And it sounds like the law in one country is going to be very interested in arresting people in another. Hence, perhaps we need a crypto system (including human procedures and fail safes) for community discussions. Crypto is very much one to one right now, but can we implement a crypto for wide distribution to a very defined set of people? This should be useful in commerce too... like CC of mail to others, etc. Problem Definition Time: Who will be responsible for allowing a member into the community? (And all the other trust issues...) The software to implement the community must be available on multiple platforms like UNIX, Windoze, Macintosh, NeXT, etc. How do we over come the problems of storage - should the messages remain encyphered at all times in local storage of a member in case of a knock on the door, requiring the user to use the software to read, write, store, and organize messages. Is it even possible to overcome the human turncoat factor? Can we protect them as well as us from coercian, black mail, seizure, or defection? Is this even possible, because we are looking for the freedom to speak, yet nobody will be able to hear us!!! ********** Method of discussion: Since we will all hopefully have many ideas and comments on this exercise,may I provide a protocal: Please have Project Electric Potatoes in the subject heading - some of us use the delete key quite freely and don't want to accidently remove your valued comments and ideas. Should the message contain a problem definition, please have Problem in the subject. Should the message contain an answer please have Answer in the subject. Should the message contain a rant, please have Rant in the subject. I leave it to the writer to include [CRYPTO] in the header.... Thank You All, and I hope we get a great discussion going on here.

3 2

Re: GPS
by Bill Stewart 17 Dec '03

17 Dec '03

>2. The DoD is doing a study right now on how to make GPS useless to the >enemy at wartime. >I think figuring out a way to turn off A/S and getting accurate GPS on >commercial equipment at all times would make a nifty Cypherpunks project >- if it really involves breaking some encryption. Essentially the A/S works by having the publicly-readable signal contain fuzz fuzz in the low-order bits and the encrypted signal contain the real stuff; if they've done decent encryption, you won't crack it. However, the fuzz _is_ consistent - if you've got two nearby points, and you really know where one of them is, you can correct for it, and get better accuracy even than the full GPS with A/S turned off. The approach the Feds are taking to prevent competition from real differential GPS is to field a differential GPS system of their own, located at/near airports (who are the real people who want D-GPS, so they can do things like better instrumented or automated landings.) This way, nobody's got much financial incentive to deploy D-GPS correction transmitters of their own, and manufacturers have an incentive to deploy equipment tuned to the FAA's correction transmitters, so they can still turn them off if they want to. Except for takeoff/landing, airplanes don't much need differential GPS; you shouldn't be flying within a hundred meters of other planes anyway, and if you're doing cropdusting or barnstorming you'd better be able to see what you're doing or have good radar anyway - most topographic maps don't have tall trees marked on them. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

3 2

Re: Internet plug pulled on Colombia's guerrillas
by jim bell 17 Dec '03

17 Dec '03

At 03:05 PM 9/26/96 -0700, Chris Adams wrote: >Internet plug pulled on Colombia's guerrillas > 3:05pm EDT, 9/26/96 >BOGOTA, Colombia - A Colombian guerrilla group currently >involved in a bloody offensive in the mountains and jungles, >suffered a setback in its propaganda battle when its new-tech >voice on the Internet was mysteriously silenced. > >The Revolutionary Armed Forces of Colombia (FARC), which >has periodically paralyzed half the country with road blocks, >found its route to the information superhighway barred. > >The Communist insurgents, who rose up in arms in 1964, >embraced new technology last year in their fight to overthrow the >government by launching a home page on the Internet. I couldn't resist smiling when I read this. Not that I want their access cut; quite the opposite. But it is REALLY reassuring to see the authorities behave in exactly the fashion you expect them to! Attempting to cut off dissenting political voices IRL is de rigeur; now, this shows that they believe "threat" to the government posed by allowing others to voice contrary opinions on the 'net is real. Jim Bell jimbell(a)pacifier.com

1 0

Re: sophie germain primes
by Ross Wright 17 Dec '03

17 Dec '03

Sir: Lot's of stuff on primes, right here: http://daisy.uwaterloo.ca/~alopez-o/math-faq/node10.html Hope it helps. On or About 28 Sep 96 at 23:44, Serge E. Hallyn wrote: > Could anyone direct me to an online list of small (less than 800-digit) > Sophie Germain primes? > > (actually any list would do) > > many thanks, > -serge > > hallyn(a)cs.wm.edu > > =-=-=-=-=-=- Ross Wright King Media: Bulk Sales of Software Media and Duplication Services http://www.slip.net/~cdr/kingmedia Voice: 415-206-9906

1 0

Re: In defense, sort of, of Phill Hallam-Baker
by Hallam-Baker 17 Dec '03

17 Dec '03

Robert Hettinga wrote: > However, I also think that Phill has this passion for order that sometimes > borders on the pathological. Maybe because, like Bertrand Russell (who > Phill and I both admire) says, romanticism, leftism and communism are > basically feudalism in disguise, and Phill's a closet aristocrat. ;-). > Maybe not. Of course socialism is grounded in paternalism. Robert Owen, its founder was in his day the equivalent of Steve Jobs, an extreemly rich and successful merchant who considered that wealth also implied responsibility. > I think what we see as his blustering trolls on this list come from > passion. But, I don't think they're trolls at all. I think they show, more > often than not, his outrage at the way the world's going to go. Which, > obviously, is *our* way, and not his. He knows very well the power of the > technology we talk about here, and deep down, I think he knows we're right. If people want to have a sensible disscussion about technology and policy then I think that keeping the discussion grounded in reality is a good thing. I don't think that the political situation is going in a libertarian direction, quite the opposite. I see technology as having greatly increased the power of government and that it will be necessary to institute checks and balances to make it work. I also think that you are being very naive with regards to the threat posed by corporations to individual liberties. I see no reason to distinguish between corporate intrusions and state intrusions except in one respect. If we can't find a way to make society work without some form of intrusion the agency that is responsible has to be under democratic control. I think that unless the case for privacy is put in a way which society at large accepts then Freeh and the corporations will win. HMOs will be touting peoples medical records on the open market (many already do), employers will vet empoloyees on the basis of reports drawing on information on video rentals and so on. I certainly don't agree with Denning or Sternlight. Sternlight is either a fool or an invention of the NSA. Denning bases her argument against crypto on hidden sources. I know my experience in the area concerned to be significantly greater than hers since if she had operational experience she would say so. Phill

1 0

Possible subs attack????
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> whose list is this, and why am I on it? Please delete my name > now. I have noticed a lot of these messages on the list over the last day or two, I can only assume Vilus/Detweiller/Some other troublemaker has decided to subscribe a few people using fake return addresses, anyone else got any ideas on what else could have caused people to be subscribed? Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Paul(a)crypto.uk.eu.org, Paul(a)cryptography.uk.eu.org Http://www.cryptography.home.ml.org/ Email for PGP public key, ID: 5BBFAEB1 "Don`t forget to mount a scratch monkey"

2 1

quotation
by um＠c2.net 17 Dec '03

17 Dec '03

Found in a sig file: "The people involved in the crypto debate are all intelligent, honorable and pro-escrow, but they never possess more than two of these qualities at once." -- Kenneth Neil Cukier (100736.3602(a)compuserve.com)

2 1

Re: Public domain SHA-1 in C
by Steve Reid 17 Dec '03

17 Dec '03

Thanks to Eric Young's suggestions, my SHA-1 is now _very_ fast. If you downloaded the older version (before 5:30pm Pacific time) you'll probably want to download the new-and-improved version. http://www.edmweb.com/steve/sha1.c ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve(a)edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:)

1 0

Re: VCRS and Crypto
by craigw＠dg.ce.com.au 17 Dec '03

17 Dec '03

If the average person cared about quality rather than what is marketed as bestand the must have, we might have laser disk instead of video rental stores. Also, where would M$ be > >Remember the VHS/Beta VCR wars? With a fairly equal market in about 1978, > >Beta died 10 years later because the market couldn't support two > >incompatible standards. It wasn't that one was dramatically better than the > >other, it was simply that having two standards forced the market to > >duplicate stocks, for the machines as well as tapes, particularly > >pre-recorded tapes. Notice, however, that VCR's are relatively "isolated": > >It doesn't really matter if you have one format and your neighbor has > >another, unless you want to swap tapes. But crypto telephones inherently > >require (in the long term) full intercompability. If you didn't have that, > >there'd be half a world of people you couldn't call! > ,'~``. \|/ ,'``~. (-o=o-) (@ @) ,(-o=o-), +--.oooO--(_)--Ooo-----oOO-(_)-OOo-------oooO--(_)--Oooo.------+ | | | Soon, we may all be staring at our computers, wondering | | whether they're staring back. | | | | [Network Admin For WPA Business Products. aka doshai >;-) ] | | .oooO http://pip.com.au/~doshai/ Oooo. | | ( ) Oooo. .oooO ( ) | +-----\ (----( )-------oooO-Oooo--------( )--- ) /---------+ \_) ) / \ ( (_/ (_/ \_) Key fingerprint = 2D F4 54 BB B4 EA F1 E7 B6 DE 48 92 FC 8D FF 49 Send a message with the subject "send pgp-key" for a copy of my key. (if I want to give it to you)

1 0

Re: Mousepad RNG's?
by James A. Donald 17 Dec '03

17 Dec '03

At 08:14 PM 9/27/96 +0200, Anonymous wrote: > I just downloaded a copy of the beta version of Datafellows > Windows 3.1 SSH and it asked to move the mouse around to > generate some randomness. In reading Applied Crypto, it > mentioned that there is no such thing as generating > randomness from a personal computer unless something like > a Geiger counter is used. Is there any way to create a > fairly random sample from the mouse? Should one use lots > of jerky movements, or take ones time with it? In this case the entropy is the negative of the logarithm of the probability that you or someone else could exactly duplicate those mouse movements. I would guess that you get at least three bits a second just doodling around, so half a minute of doodles (a pretty long time) should be unbreakable. Some time ago, at a cypherpunks conference, people were making all sorts of ridiculous proposals for being really, really, really, sure that you had real entropy, and a prominent cypherpunk, possibly Tim May, said, "This is ridiculous: Nobody ever broke good crypto through weakness in the source of truly random numbers". Sometime after that Netscape was broken through weakness in the source of truly random numbers. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

Snake Oil FAQ 1.0
by C Matthew Curtin 17 Dec '03

17 Dec '03

Obviously, there's still work to be done, but that's why there are numbers higher than 1.0, right? :-) -matt URL: http://www.research.megasoft.com/people/cmcurtin/snake-oil-faq.html Version: 1.0 Archive-name: cryptography-faq/snake-oil Posting-Frequency: monthly Snake-Oil Warning Signs Encryption Software to Avoid Copyright © 1996 Matt Curtin $Id: snake-oil-faq.html,v 1.0 1996/09/27 21:15:04 cmcurtin Exp $ Distribution Distribution of this document is unlimited. We're specifically interested in reaching people making decisions about what sorts of crypto to use (if any at all), both for their organizations and for themselves, especially those who are non-experts in the field of cryptography and security. This is a work-in-progress. Feedback is greatly appreciated. The Snake Oil FAQ is posted monthly to cypherpunks, sci.crypt, alt.security, comp.security, comp.answers, and comp.infosystems. Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves. This is a compilation things that are common among snake oil vendors. It cannot be the sole metric by which a security product is rated, since there can be exceptions to most (or all?) 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 that exceptions to general rules can exist.) 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, Matt Curtin <cmcurtin(a)research.megasoft.com> History With the rise in the number of crypto products becoming available came a rise in the amount of ineffective or outright bogus products. After some discussion about this on the cypherpunks list, Robert Rothenburg <wlkngowl(a)unix.asb.com> wrote the first iteration of the Snake Oil FAQ. Matt Curtin took the early text and munged it into its current state with the help of the listed contributors (and probably some others whose names have inadvertently missed. Sorry in advance, if this is the case.) Introduction This really isn't much of a "FAQ" in the sense that one generally expects to see them: in a question and answer format. Perhaps it will be rewritten as such in the future, but currently, it is more traditionally-formatted paper that covers many topics that are the subject of frequently asked questions. 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. Why "snake oil?" The term is used in many fields to denote something that is sold without consideration of its quality, or its ability to live up to claims made by its vendor. This term originally applied to that sold in traveling medicine shows, where the salesmen would claim their elixer would cure just about any ailment that a potential customer could have. Listening to some of the claims made some by modern day crypto vendors, "snake oil" is a surprisingly apt name. 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 to present some obvious "red flags" 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? How secure is "secure enough?" Does the data need to be unreadable by third parties for 5 minutes? One year? 50 years? 100 years? Is the third party someone's kid sister? An individual? A corporation? A government? Beware of products that are designed for a specific task (such as data archiving, for example), and add encryption in as an additional feature. Typically, it's better to use an encryption utility for encryption, rather than some tool designed for another purpose that adds encryption to its list of features. Some basics The cryptography-faq (found at http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/top.html) 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 "secret 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. The problem here is getting the sender and recipient to share the key. 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 (and verifies!) Bob's public key, encrypts her message with it, and sends it off to Bob. When Bob gets the message, he uses his private key to decrypt the message. Secrecy vs Integrity: What are you trying to protect? For many users of computer based crypto, preserving the contents of a message is as important as as protecting its secrecy. Damage caused by a modified message can often be worse than that caused by its disclosure. For example, it may be disquieting to discover that a hacker has read the contents of your funds transfer authorization, but it's a disaster for him to change the transfer destination to his own account. Encryption by itself does not protect a message from change. In fact, there are several techniques for changing the contents of an encrypted message without ever figuring out the encryption key. If the integrity of your messages is important, don't just rely on secrecy to protect them. Check the vendor's claims for an explanation of how their product protects the message from undetected modification. The verification of public keys is an important step. Failure to verify Bob's public key leaves open the possibility that Alice is sending her secrets to someone else, who simply claims to be Bob, using a key that has Bob's name on it, but whose associated private key is in the hands of an attacker. Asymmetric ciphers are much slower than their symmetric counterparts. Also, key sizes must be much larger. See the cryptography FAQ for a more detailed discussion of these topics. Key Sizes Some ciphers, while currently secure against most attacks, are not considered viable in the next few years because of relatively small key sizes and increasing processor speeds (making a brute-force attacks - trying every possible key - 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. Having stated the above, it is important to note that a common feature of snake oil is to have large keys. Often, the claimed key lengths are much longer than what is practical, usually due to the vendor's confusion between symmetric and asymmetric cipher key length requirements. (For example, a vendor who claims to use a strong symmetric cipher with a 2048 bit key is probably lacking some basic understanding of key length requirements, and requisite computing power for performing various functions with the keys in question.) 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. This is included so the reader will be able to get a reasonable idea of symmetric key length requirements, and have some sort of a guideline for determining whether the key length of the product he's interested in even makes sense.) The following chart appears in [1]. 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 [1]. (Due to differences between symmetric and asymmetric algorithms, key length comparisons between the two is difficult. The following is intended to give the reader just a general idea of what is roughly comparable, in order to be able to weed out claims of security of, for example, ciphers with 100-bit asymmetric keys.) 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 *These key sizes are for public key cryptosystems based on the problem of factoring large integers, and apply to a number of ciphers based on the discrete log problem (difficulty of taking logarithms in a finite field.) A variation of the discrete log problem (known as Elliptic Curve Discrete Logarithm Problem), where the cryptosystem is based on computations on points of an elliptic curve over a finite field, for example, has been shown to be resistant to brute-force attacks with much smaller keys than other discrete log problem-based ciphers. Ciphers based different problems have different key size requirements. Each type of algorithm's key size requirements depend on the mathematical problem on which the system is based. So, it's important to find out what algorithm (or at least mathematical problem the algorithm uses) and key size is used. One without the other is meaningless. Implementation Environment Other factors that can influence the relative security of a product are related to its environment. For example, in software-based encryption packages, is there any plaintext that's written to disk (perhaps in temporary files)? What about operating systems that have the ability to swap processes out of memory on to disk? When something to be encrypted has its plaintext counterpart deleted, is the extent of its deletion a standard removal of its name from the directory contents, or has it been written over? If it's been written over, how well has it been written over? Is that level of security an issue for you? Are you storing cryptographic keys on a multi-user machine? The likelihood of having your keys illicitly accessed is much higher, if so. It's important to consider such things when trying to decide how secure something you implement is (or isn't) going to be. 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 description 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 literature about cryptology. Further, if the marketing material isn't clear, what reason is there to believe that the instructions are any better? Even the greatest of products, if not used properly, can be rendered useless. If you can't understand what a vendor is saying, you're most likely better off finding something that makes more sense. * New Type of Cryptography? Beware of any vendor who claims to have invented a "new type of cryptography" or a "revolutionary breakthrough". Truly "new breakthroughs" are likely to show up in the research literature, and professionals in the field are typically won't 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 a different method of computation doesn't make it more secure. (As a matter of fact, these techniques are the subject of ongoing cryptographic research and nobody has published successful results based on their use yet.) Anything whose authors claim to have invented a new public key cryptosystem without publishing the details or underlying mathematical principles is highly suspect. Modern cryptography is grounded in mathematical theory. The security is based on problems that are known (or widely believed) to be hard to solve. It's important to understand the difference between a new algorithm or cipher and a new product. Engaging in the practice of developing ciphers and cryptographic products is a fine thing to do. However, to do both, at the same time, is foolish. Many snake oil vendors brag about how they do this, despite the lack of wisdom in such activity. The strength of any encryption scheme is only proven by the test of time. New crypto is like new pharmaceuticals, not new cars. In some ways, though, it's worse: if some pharmaceutical company has some bogus stuff out there, people will start getting really sick. If you're using bogus crypto, you likely won't have any idea that your secrets aren't as secret as you think. * Secret Algorithms Avoid software which uses 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 and professional crypto community, then you should be wary of trusting it. (Note that a vendor who specializes in 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. On the other hand, if you don't know which vendors are and aren't reputable, you can't take their words for it. You're typically best off avoiding that which is secret.) Beware of specially modified versions of well-known algorithms. This may intentionally or unintentionally weaken the cipher. The use of a trusted algorithm, with technical notes explaining the implementation (or better yet, availability of the source code for the product itself) are signs that a vendor is confident about their product's security. You can take the implementation apart and test it yourself. A lock where attackers can see the internal mechanisms, and still not be able to break it is a strong lock, indeed. 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) to 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. (If it sounds too good to be true, it probably is.) 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. Some companies that claim "unbreakability" actually have serious reasons for saying so. Unfortunately, these reasons will generally turn out to depend on some narrow definition of what it means to "break" their security. For example, true one time pads are technically "unbreakable" as far as secrecy goes, but only if several difficult and important conditions also hold. Even then, they are trivially vulnerable to known plaintext attacks on the message's integrity. Other systems may be "unbreakable" only until one of the communicating devices (a laptop, for example) is stolen. So, be sure to find out exactly what the "unbreakable" properties of the system are, and decide if the more breakable portions also provide adequate security. Often, less experienced vendor representatives will roll their eyes and say, "Of course it's not unbreakable if you do such-and-such." The point is that the exact nature of "such and such" will vary from one product to another. Pick the one that matches your operational needs the best. * One-Time-Pads A vendor might claim the system uses a one-time-pad (OTP), which is theoretically unbreakable. (Technically, OTP-generated ciphertext has an equal chance of being each possible plaintext. For example, "598v *$ _+~xCtMB0" has equal probabilities of decrypting to "the whole year in", "the hole youre in", and "you are a weenie!") Snake-oil sellers will try to capitalize on the known strength of an OTP. It is important to understand that any variation in the implementation (which is often done to get around the inherent key management problems of OTPs) means that it is not an OTP, and has nowhere near the security of an OTP. An OTP system is not an algorithm. It works by having a "pad" (called such because originally paper pads were used, before general-purpose computers came into being) of random bits in the possession of both the sender and recipient, but absolutely no one else. (The pad must be sent from one to the other securely, such as in a locked briefcase handcuffed to the carrier, and that sort of thing.) 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. Further, if the keys (i.e., random bit "pads") are provided by the vendor, the quality of these cannot be verified. How do you know that they aren't sending the same bits (or some trivial mutation thereof) to everyone? Or keeping a copy for themselves? Or selling a copy to your competitors or enemies? OTPs are highly impractical for general purpose cryptography, since the need for random bits is very high, and key management is so cumbersome. OTPs are only practical for extremely low bandwidth communication channels where two parties have the means to exchange pads through a different method from that of their messages. (It is rumored that a link from Washington, D.C., to Moscow was (is?) encrypted with an OTP.) A lesson from the VENONA project (see NSA's web site) is that OTPs are seriously vulnerable if a pad is ever reused. It does not take the resources of a government agency to crack a reused pad. Therefore, the real limitation to their practical use is the generation and distribution of truly random keys for them. You have to distribute at least one bit of key for every bit of data transmitted, including any encrypted protocol data that's sent. If you reuse your pads you run the risk of compromising all data sent with the reused pad. The vendor might (or might try to) 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. These usually involve either trying every possible combination of bits for form keys, and trying every possible key until a solution is found, factoring large numbers, or some other cryptanalysis that's just as computationally intensive as one of these methods. * Keys and Passwords The "key" and the "password" are 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. If the system limits the size of the key or passphrase to something that seems too low, it probably is. 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 puts too much emphasis on ease of use, without due consideration to cryptographic strength. 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 secret-key (symmetric) cryptography. * Lost keys and passwords If the vendor (or a third party) claims it can recover lost passwords (without using a key-backup or escrow feature), avoid it: a flaw is obviously present, and used to retrieve the contents of an encrypted message. 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? (Is someone else able to recover your key as easily as you can?) Remember, you have no security against someone who has your key. * Exportable from the USA If the software is made in the US, 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. (For example, if someone claims that the IDEA cipher is exportable from the US, while most other vendors (or the State Department!) do not make such assertions, they're probably lacking sufficient clue to provide you with strong cryptographic software.) 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. (Of course, a freely exportable version isn't secure, since it probably just uses a much smaller key, one that could be easily broken.) Also note that just because software has made it outside of the US does not mean that it is exportable: sometimes a utility will be illegally exported and posted on an overseas site. There are no restrictions on importing crypto products into the US, so a foreign vendor can legally offer a single, secure version of a product for the entire world. * "Military Grade" Encryption Many crypto vendors claim their solution is "military grade." This is a term with no real meaning, since there isn't a real metric by which something can be judged "military grade," except for it to be actually used by various armed forces. Since they don't reveal what they're using, it's neither possible to prove nor to disprove something as being "military grade." Some good crypto products unfortunately also use this term. (Watch for this one especially in combination with other snake oil indicators, i.e., "our military grade encryption system is exportable from the US!") 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 of any product that claims it is. Glossary algorithm A procedure or mathematical formula. Cryptographic algorithms convert plaintext to and from ciphertext. cipher Synonym for "cryptographic algorithm" cryptanalysis To solve or "break" a cryptosystem. escrow A third party able to decrypt messages sent from one person to another. Although this term is often used in connection with the US Government's "Clipper" proposals, it isn't limited to government-mandated ability to access encrypted information at will. Some corporations might wish to have their employees use cryptosystems with escrow features when conducting the company's business, so the information can be retrieved should the employee be unable to unlock it himself later, (if he were to forget his passphrase, suddenly quit, get run over by a bus, etc.) Or, someone might wish his spouse or lawyer to be able to recover encrypted data, etc., in which case he could use a cryptosystem with an escrow feature. initialization One of the problems with encrypting such things as files vector in specific formats (i.e., that of a word processor, email, etc.) is that there is a high degree of predictability about the first bytes of the message. This could be used to break the encrypted message easier than by brute force. In ciphers where one block of data is used to influence the ciphertext of the next (such as CBC), a random block of data is encrypted and used as the first block of the encrypted message, resulting in a less predictable ciphertext message. This random block is known as the initialization vector. The decryption process also performs the function of removing the first block, resulting in the original plaintext. ITAR International Traffic in Arms Regulations. These are the rules by which munitions (including cryptography), as defined by the US State Department, may (or may not) be exported from the US. key A piece of data that, when fed to an algorithm along with ciphertext, will yield plaintext. (Or, when fed to an algorithm along with plaintext, will yield ciphertext. random session This is a temporary key that is generated specifically for key one message. Typically, in public key cryptosystems, the message to be sent is encrypted with a symmetric key that was specifically generated for that message. The encrypted version of that message, as well as the associated session key can then be encrypted with the recipient's public key. When the recipient decrypts the message, then, the system will actually decrypt the message it gets (which is the ciphertext message and the symmetric key to decrypt it), and then use the symmetric key to decrypt the ciphertext. The result is the plaintext message. This is often done because of the tremendous difference in the speed of symmetric vs. asymmetric ciphers. Contributors The following folks have contributed to this FAQ. Jeremey Barrett <jeremey(a)forequest.com> Gary Ellison <gary.f.ellison(a)att.com> <fifersl(a)ibm.net> Larry Kilgallen <KILGALLEN(a)Eisner.DECUS.Org> Dutra Lacerda <dutra.lacerda(a)mail.telepac.pt> <geeman(a)best.com> Jim Ray <liberty(a)gate.net> Terry Ritter <ritter(a)io.com> Robert Rothenburg <wlkngowl(a)unix.asb.com> Adam Shostack <adam(a)homeport.org> Rick Smith <smith(a)sctc.com> Randall Williams <ac387(a)yfn.ysu.edu> Jim Ray <liberty(a)gate.net> 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 from ftp://ftp.research.att.com/dist/mab/keylength.ps -- 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

Re: Newsgroup proposal: misc.anonymous
by David E. Smith 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: Fri Sep 27 22:31:58 1996 remailer(a)cypherpunks.ca blathered thusly... > This sounds like a good idea. I would certainly vote for such a news > group. Should the name be misc.anonymous or misc.anonymous.messages? > Are alt.anonymous and alt.anonymous.messages basically to different > newsgroups for exactly the same purpose, or is there some difference > between them. I believe that a.a is for discussion, and a.a.m is the "message pool." dave - ----- David E. Smith, P O Box 324, Cape Girardeau MO USA 63702 dsmith(a)prairienet.org http://www.prairienet.org/~dsmith send mail with subject of "send pgp-key" for my PGP public key "Madness takes its toll . . . please have exact change ready." -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMkycMjVTwUKWHSsJAQFiOwf+K5IdIzZim++s9mRK9K0cIG1Ofh6+kWhV R9nrR8EglLTxOw97JdOIGhWeGFivWmU5IDbKaDVDnZFp3b14FWUu4680K5jRjGIU 3/M2DzKHOLKiZmoSkpBIuCYQ4IolrH4mBOMqNUpI/+mN0ORdDZ+ybfX4ThxTfabR jxDNAMSbhmls9SNpBOyYPV9bWCdrhSXyQ4jE8g5lljDa6YZX8fToBN6uIyEC6DJ2 t2FwLLWGhs9VKQPFwg9guguN3yFEYi9hVtrjHyFTzva3Vj/algpukdTTMXvLXV9N 4bVwULnh58X0J3ov9+vd4LOXWAlYD6b7ejbqZ8mw3NBJkzeAJyzmVw== =CfWp -----END PGP SIGNATURE-----

1 0

Re: Newsgroup proposal: misc.anonymous
by David E. Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: dlv(a)bwalk.dm.com, cypherpunks(a)toad.com Date: Fri Sep 27 22:31:14 1996 > "Mark M." <markm(a)voicenet.com> writes: > > In an effort to get anonymity and message pools more widespread, I > think it > > would be a good idea to establish a newsgroup for anonymous message > pools tha > > would get the same distribution as any other newsgroup in the "big 8". > The > > "misc" hierarchy is probably the best place for such a newsgroup since > it > > already carries groups like "misc.misc" and "misc.test". Does anyone > have an > > suggestions or objections? > > It should be under misc.activism: misc.activism.anonymity or even > m.a.privacy. This doesn't seem entirely appropriate for a message-pool group, which is what I understood as the original idea. m.a.anonymity would be a great place for a discussion group, though. dave - ----- David E. Smith, P O Box 324, Cape Girardeau MO USA 63702 dsmith(a)prairienet.org http://www.prairienet.org/~dsmith send mail with subject of "send pgp-key" for my PGP public key "Madness takes its toll . . . please have exact change ready." -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMkycBTVTwUKWHSsJAQFuXgf7BWoshYYQ4qIjBLpZznba90iDlkCOgBBr dyAQDohGs8euJcUxAYejmg2MufekGR5KlhSq7qlqutF7b0ngcgQj0OtDboZz4M3y SIDZtealn5f6rNCz/r8utgc5hhUrkxJty9zYWphJxesBzSqWWw9yq5zU+7m0uKj0 9P3zN+9ezWpF9F45XH/c1NX9pIrJSax7n1ONYg6SyuSX+WfhFKSlFGHseBi7kV8f 5B/PhPFpYwCKfiqiW4Wang5qOqXzojXdddWOyBTTRoSxXHGoGlxcZ+aat+A7moI8 yjzwyDW2MA+yRLN0Z8a9rbIhuaBgpsqNL+fU5nFqaXOv98ZPiXcJDQ== =Zj+K -----END PGP SIGNATURE-----

1 0

Basis of FCC Jurisdiction [RANT]
by azur＠netcom.com 17 Dec '03

17 Dec '03

Last week I started a thread on the Telecom Regulation list. My intention was to introduce discussion of some circe-1780s Republican questioning, as opposed to the widely accepted Federalist. The most interesting composite result is below: >Date: Sat, 21 Sep 1996 22:08:03 -0500 >Reply-To: telecomreg(a)relay.doit.wisc.edu >Originator: telecomreg(a)relay.doit.wisc.edu >Sender: telecomreg(a)relay.doit.wisc.edu >Precedence: bulk >From: "Michael D. Sullivan" <mds(a)access.digex.net> >To: Multiple recipients of list <telecomreg(a)relay.doit.wisc.edu> >Subject: Re: Basis of FCC Jurisdiction (Republican rant) >X-Comment: Requests (UNSUBSCRIBE/HELP) to: listserver(a)relay.doit.wisc.edu >MIME-Version: 1.0 > >Steve Schear <azur(a)netcom.com> wrote: > > >I've been wondering lately about the jurisdictional limits of the FCC > >vis-a-vis the Article(s) of the Constitution from which they derive their > >authority. My understanding is that the FCC is empowered under the Fed's > >interstate commerce clauses. If so, how valid is their jurisdiction over > >low power and/or millimeter wave transmissions. It seems a case can be > >made that such transmissions represent little or no possibility of > >interstate transmission. > >To which Bob Jacobson <bob(a)worldesign.com> replied: > > >The FCC derives its authority by Congressional mandate, so the question is > >rightly posed as "Does Congress have rights to regulate local radio trans- > >missions?" Congress abrocated to itself the right to regulate all radio > >transmissions, on the grounds that any transmission might interfere with > >the transmissions of interstate broadcasters. Generally, this right has > >been upheld by the courts, although states have successfully challenged > >the absolute power of the FCC with regard to certain aspects of non-radio > >transmissions -- for example, telephone calls -- that do not cross state > >boundaries and even some that do. To my knowledge, no form of electronic > >transmission is invulnerable to some type of regulation, whether federal > >or state (including municipal regulation by cities and counties, creatures > >of the states). Of course, there are loopholes, as the Internet has amply > >demonstrated. > >In further response, John Levin <jlevin(a)paonline.com> added: > > >This discussion is incorrect by omission. The reason that states have > >authority over intrastate telephone service is because Congress says they > >do. The Telecommunications Acts carve out areas of state and federal > >jurisdiction. The FCC, like any other agency, takes an expansive view of > >their authority and courts occasionally rein in such excursions after > >looking at their enabling statutes. The technical doctrine is 'federal > >preemption', and unless Congress expressly preempts the states, or the > >preemption is necessary to effectuate a national policy authorized by > >federal legislation, the states retain control of state activities. As to > >what constitutes 'interstate commerce' for the purposes of the U.S. > >Constitution, there are hundreds, if not thousands of court decisions on > >that topic. During most of this century, usually even a very slight > >impact on interstate commerce has been found to be sufficient for Congress > >to legislate. Those of you who plan on using 'states rights' as a basis > >for disobeying Federal laws or regulations should consult an attorney and > >get your affairs in order before you act. > >Although nothing in the Communications Act of 1934 or it predecessor Radio >Acts states so explictly, it is implicit that the Interstate Commerce Clause >is the basis for the statute and for FCC radio licensing jurisdiction. That >was undoubtedly one of the bases for earlier legislative and Commerce >Department regulation of radio, along with providing for the national >defense. Under the Commerce Clause and the Necessary and Proper Clause, >Congress can assert jurisdiction over virtually anything affecting >interstate commerce. This clearly underlies Section 301 of the >Communications Act, which asserts federal jurisdiction and control over all >interstate radio transmissions and requires FCC licensing for the same. > >The Communications Act does not assert jurisdiction over, or require FCC >licenses for, radio transmissions between two points in a single state (not >including D.C.). In fact, this doesn't remove virtually anything from >federal jurisdiction or licensing as a matter of law, because radio >transmissions don't stop at any particular point, they merely attenuate as >they continue to propagate onward ad infinitum. As a technical matter, a >milliwatt-level millimeter-wave radio transmission from one end of a >steel-encased underground chamber to a receiver at the other end propagates >to points thousands of miles away, albeit at an undetectible level (i.e., >waaaaay below the noise floor), and it therefore could be viewed as an >interstate radio transmission. Practically, however, such transmissions >stop at the steel shielding. The FCC, therefore, will be unable to document >that there was an interstate radio transmission and would likely be unable >to shut you down. > >The FCC has adopted rules that permit unlicensed operation under common >circumstances when there is unlikely to be any interstate effects. Part 15 >sets forth power levels and other transmission parameters for certain >frequency bands that do not require licensing. Although the jurisdictional >basis for Part 15 has never been expressly stated, the FCC views such >transmissions as not, in any practical sense, likely to interfere with >licensed transmissions, and the unlicense use of spectrum is conditioned on >not interfering. > >One could argue that other low-power or physically confined radio >transmissions are also unlikely to cross state lines as a practical matter, >or to interfere with licensed transmissions, and are therefore beyond the >FCC's jurisdiction. The FCC has not conceded its jurisdiction in such >cases, however. There is currently litigation ongoing regarding a >California (Berkeley, perhaps?) low-power FM station that did not obtain a >license. It doesn't interfere, and it can't be received out-of-state. Can >the FCC shut it down? Yet to be decided. > >Steve Schear also wrote: > > >Another question has to do with spectrum ownership. Prior to the '34 Act > >who owned the spectrum. Was any compensation made for the taking? > >To which Bob Jacobsen replied: > > >As to ownership of the spectrum, the spectrum still is owned by the people > >of the United States, held in public trust. So-called "sales" of spectrum > >are actually licenses to use various frequencies under different rules. > >Presumably Congress has the right to sell this "property" in the same way > >that it sells forests on public lands, but so far it has not done so. On > >the other hand, the federal government has exacted remarkable fees for > >certain licenses: PCS operators have already put up over $17 billion in > >fees for licenses auctioned by the FCC! > >Actually, spectrum isn't "owned" by anyone, including the people of the >United States. One can't own a physical dimension such as frequency, any >more than distances, speeds, or colors. The federal government has asserted >*control* over the *use* of spectrum, however, just as it and the states >assert control over the use of particular speeds in particular locations >(e.g., 55 or 65 mph on freeways). As Bob said, the right to use spectrum, >within specifically defined geographic, frequency, power, and time limits, >is conferred by licenses awarded by the FCC. These licenses, for a >specified term, are sometimes given away to the first person who asks for >them, sometimes awarded by hearing or lottery, or, more recently, sometimes >awarded on the basis of the highest bid. The FCC isn't selling spectrum per >se, but a license for the exclusive right to use particular spectrum under >the defined terms of the license. This is very different from selling >public land, but is somewhat like selling the right to harvest the trees (or >mine the coal, or drill and pump the oil) from a piece of federal land for a >certain number of years. > > >---------------------------------------------------------------------- >Michael D. Sullivan, Bethesda, Maryland, USA >mds(a)access.digex.net / avogadro(a)well.com / 74160.1134(a)compuserve.com >---------------------------------------------------------------------- > PGP Fingerprint: FE 90 1A 95 9D EA 8D 61 81 2E CC A9 A4 4A FB A9 --------------------------------------------------------------------- Snoop Daty Data | Internet: azur(a)netcom.com Grinder | Voice: 1-702-655-2877 Sacred Cow Meat Co. | Fax: 1-702-658-2673 7075 W. Gowan Road, #2148 | Las Vegas, NV 89129 | --------------------------------------------------------------------- Just say NO to prescription DRUGS. "Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive." -- C.S. Lewis "Surveillence is ultimately just another form of media, and thus, potential entertainment." -- G. Beato

1 0

Making Remailers Widespread
by Bill Stewart 17 Dec '03

17 Dec '03

I've been thinking about how to make one-way remailers a widespread commodity, rather than the novelty item they are today. Doing two-way remailers would be better, but that's still a hard problem, and I don't want to widely deploy shoddy two-way-remailers. Suppose we add form-based remailer support to a popular SSL-equipped HTTP server, such as Apache-SSL, by putting remailer.pl and a remailer form in the default setup, which would deploy hundreds of remailers with minimal effort. What would we have to do to make it work well, rather than turn into a public relations disaster and spam explosion? - The remailer script would have to add disclaimers at the beginning and/or end of the message reminding readers that the message is anonymous, and to contact the remailer cabal rather than the postmaster. - Blocking becomes a big problem - it's annoying enough now, when there are a small number of remailers with hard-working operators; we'd need some sort of automated blocking support to make it usable by relatively non-involved operators - A centralized block list (e.g. http://www.remailer.net/block.txt) which all of the form-based remailers could load and reference would allow non-picky operators not to have to handle it themselves - Implementing the blocking list as a web form for people who want to be blocked would make it relatively painless to use; remailer-operators wouldn't have to transcribe email from the remailer-operators list to use it, which helps with other problems. - Of course, once anybody can fill out their name and ask to be blocked, it's possible for spoofers to block people who don't want to be. One approach for preventing this is to implement a three-way handshake - user fills out form, form mails back blocking notice with cookie, user returns cookie to complete blocking - this is a bit messier for mailing lists, but we can ignore... - special-case for "postmaster", who may want to block all of foo.domain instead of just postmaster(a)foo.domain - special-special-case for postmasters of big sites, e.g. aol, netcom, who we may want to ignore? - A sender-blocking list is harder, and may still take human attention - remailer chaining - allow user to put in another Apache-remailer site so we don't have to limit the chaining to known short list of sites. The remailer.pl can send an https foo.bar.com remailer.pl PUT - The remailer form can probably just have field for second site, if empty don't use. I suppose remailer.pl could also automagically add that in when it posts. Technical question: - How do we initiate an http or https PUT from a script? I assume there's probably some perl add-in for posting http/https? Is there a command-line-shell interface that can fetch URLs? # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

4 3

Re: Mitsubishi MISTY LSI
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

>Does anyone have a reason not to consider this algorithm snake oil? e.g.: > >Was it developed by a well known cryptographer? >Has it been vetted by someone/some organization with reputation? > >I other words, why should we trust it? It was developed by a team lead by Mitsuru Matsui and has been subject to fairly intense analysis, although not by non-Mitsubishi people AFAIK. In any case it's not the usual snake oil. When I last talked to someone from Mitsubishi who was working on Misty I tried to convince them to make details available online, you could try something like www.melco.co.jp to see if there's anything available. Peter.

1 0

Re: Technical difficulties with AP [AP NOISE]
by jim bell 17 Dec '03

17 Dec '03

At 09:07 PM 9/28/96 -0700, Bill Stewart wrote: >Aside from details like dead bodies, vendettas, and government suppression, >there are technical complications with Assassination Politics >that make it more than the simple job Jim Bell is imagining. >Some of them provide ways to defend against AP, and turn it into more like >Extortion Politics. > > [Do I _really_ want to bring up more discussion of AP? > Not sure, but if it's clear that it won't work very well, > it'll be less likely for the government media to freak about :-)] OTOH, if it's going to work, the earlier you're satisfied about that the better, huh? >Let's look at the critical part of the problem - paying the assassin. >The model we've generally been using is that the players are the >victim, the escrow agent who manages the system, an enthusiastic public, >and the assassin or assassins who are competing for the jackpot. All of whom could play multiple roles in difference circumstances, incidentally, at different times. The public should be particularly interested in this process, BTW, because they realize that someday they may want to participate as donors, bettors, or they may have no choice but to participate as...victims. >I can see three approaches to identifying the correct payee: >1) Payee provides physical evidence to the escrow agent - > the traditional approach doesn't work here: since the > escrow agent is anonymous, so you can't mail him the > victim's wallet or finger with well-known fingerprint or whatever. >2) Assassin leaves physical evidence at the scene which the news media > would be likely to report, which payee confirms with escrow > agent, presumably committing in advance (e.g. after the event, > the payee sends a key which allows the escrow agent to decode > the encrypted message that said "I'm leaving a note on the body > saying 'Jacques De Molay is Avenged - Assassin's Guild Member #32767'.") > Works fine for the first couple of assassinations, but after a while > the police will catch on and stop revealing kinky details to the media. >3) The main solution has been the gambling deal - > it's just a lottery on the date of death of the victim, which presumably > the payee will win because he knows when the assassin will strike. > For a lottery to be effective, prospective assassins need to > be able to determine how much the jackpot is and who the victim is, > so they can place their bets and be the closest winner. There are a number of advantages to the gambling scenario. The first, obviously, is that it is, technically, gambling, and gambling is legal in many locales and "accepted" (morally) in most. The second is that being gambling, no participant other than an assassin knows, for sure, that the person collecting the payoff is actually guilty of any crime. A third is that to many people, gambling is fun, which means that they are already primed to partipate. > But the prospective victim can also play, individually or as part > of an insurance pool (which is especially valuable for victims like > "the first IRS agent to be assassinated".) Obviously you don't want > to just bid up the price on your own head, so it needs to be accompanied > by publicity that the IRS Agents' Benevolent Association is placing > a large number of small bets every day to maximize the chances that > _they_ will collect the money rather than the assassins. > If the times that the bets are for are published, you can beat this, > but you also invite speculators to be small bets just before and after > your bets, so it becomes a mishmash and perhaps a race condition. > If the times aren't published, the assassin can make lots of bets > surrounding the planned date of the hit, which is also a warning > to the prospective victim to be careful if the bets on his demise > start increasing rapidly. The way I've envisioned it, the bettor must commit to his prediction, but he then encrypts it so that nobody else knows what he's predicted, either the date or the target, and he must "buy" his prediction by including digital cash. One advantage of this system is that the victim isn't warned (although the victim is already aware of how much money has been donated to fund the prize), but a potential disadvantage is that there might be a collision between the predictions of two or more people. This probably can't be entirely avoided, but it can be minimized by forcing the bettors to compete with their bets. It is impractical for a person who just guesses to make such a bet, against somebody who knows the date. The bettor doesn't reveal the decrypt key to the particular prediction involved unless he chooses to do so; when he does presumably, it's because the prediction has come true. A failed prediction isn't disclosed, so it doesn't alert anyone else, including the "escrow agent" AP organization. The amount of digital cash included with the prediction will be revealed publicly, the moment it is received by the organization, as well as the (still encrypted) prediction. Saving these predictions allows anyone to verify (after the decrypt key has been released) that the prediction actually identified a particular person. This allows the public and the other players to verify that the game is being played honestly. > This does make the AP lottery somewhat of an extortion deal - > by advertising that someone is a target, you're forcing them to > continually make lots of bets. This, of course, is only true if the specifics of the predictions are revealed, which is not the scenario I envision. Obviously, revealing the predictions allows the victim to lay low whever he's likely to be hit, which is why I think that's a bad idea. > But if they've got any way of tracing > money, even partially, it'll help them find the escrow agent, > who can then be targeted for justice of one sort or another. > You're also forcing the assassin to make lots of bets, though in > a jackpot system the successful payee will recover most of it. It is at least conceivable that an assassin won't know the exact date he'll be successful. If he sends a letter-bomb, for instance, he won't know for sure when that letter will be delivered, or the day it will be opened. However, he need merely make two or three predictions, and he won't have to make the last one or two unless the prediction didn't come true on the first day. Multiple predictions does raise his cost, but it will still be economical to do given the probabilities. > To some extent the defense can be fought if the escrow agent > wants to establish a minimum bet, say $100, which an assassin > can afford to make a few of for the targeted day, but the > victim can't keep paying too much. This also reduces the > since of the potential better pool, and therefore reduces > the jackpot and the attractiveness of the job to the assassin. > Lots of people might be willing to spend $5 to contribute; > $100 bets are much fewer, especially if there are enough > targets to successfully overthrow a government. Originally, I had anticipated that the AP organization would require specific payments included with a prediction based on the value of the reward and the estimated probability of the death on any particular day. I was never comfortable with this system, because it would involve a great deal of calculation based on numbers that no particular people know. I don't know whether you saw my idea a couple weeks ago in which I pointed out that it should merely be necessary to allow all predictors to include whatever amount of money they want with their prediction, with the reward split up and paid to all successful predictors, pro-rated based on the size of their contribution. This shifts the burden to the public to estimate the amount they should include, which should be okay since a predictor is probably a fairly good judge of the probabilities associated with his target. At least hypothetically, it means that an assassin might have a portion of his reward "stolen" by another lucky predictor, but this is unlikely and in any case, the fact that this loss was genuine can be verified by all participates after the fact. And a predictor need merely increase the value included with the prediction to increase his pro-rata share of the reward. Jim Bell jimbell(a)pacifier.com

1 0

Re: "Confessing to a felony"
by Greg Broiles 17 Dec '03

17 Dec '03

At 06:30 PM 9/27/96 -0800, Tim May wrote: > >Hearing me say I "exported crypto," a hearsay claim, and happening to find >one or more laptops at my home, weeks or months later, implies nothing. >Legal proof is still needed. Given only a nebulous statement like "I >exported crypto in violation of the ITARs," or "I shipped PGP to Europe," >is not enough for a case even to be brought to trial. > >(If it reached trial, I would expect a defense attorney to move for >dismissal. Absent any evidence that a crime occurred, absent any proof >beyond the nebulous hearsay statement of a "braggart," there is simply no >basis for criminal action.) > >"Stupid bragging criminals" may be common, but bragging is not in and of >itself illegal. There still has to be evidence of a crime. > >"Produce the body." I mostly agree re the "corpus delicti" rule (a confession must be corroborated by independent evidence that a crime has been committed, common law federally, statutory in Oregon (ORS 136.425(1)) but disagree with your use of "hearsay" - statements of a defendant in a criminal proceeding are not hearsay because they're the statements of a party opponent. (In federal court and in Oregon, anyway - in California they're hearsay but admissible as an exception. FRE 801(d)(2), ORE 801(4)(b), Cal Evid Code 1220.) This quote from _US v. Singleterry_ (CA1, 1994) (sorry no F2 cite, found it on a net database of slip opinions) does a nice job of addressing the question at hand: "To begin with, we note that a defendant's own statements are never considered to be hearsay when offered by the government; they are treated as admissions, competent as evidence of guilt without any special guarantee of their trustworthiness. See Fed. R. Evid. 801(d)(2) & advisory committee's note; see also United States v. Barletta, 652 F.2d 218, 219 (1st Cir. 1981). Nevertheless, there is a danger that the jury will rush to credit a confession without seriously considering whether the defendant confessed to a crime he did not commit. As a result, the federal courts have adopted common law rules designed to prevent a jury from convicting the defendant solely on the basis of an untrustworthy confession. The general rule is that a jury cannot rely on an extrajudicial, post-offense confession, even when voluntary, in the absence of "substantial independent evidence which would tend to establish the trustworthiness of [the] statement." Opper v. United States, 348 U.S. 84, 93 (1954). See also Smith v. United States, 348 U.S. 147 (1954); Warszower v. United States, 312 U.S. 342 (1941); United States v. O'Connell, 703 F.2d 645 (1st Cir. 1983). The Court has explained that independent proof of the commission of the charged offense is not the only means of establishing the trustworthiness of the defendant's confession; another "available mode of corroboration is for the independent evidence to bolster the confession itself and thereby prove the offense `through' the statements of the accused." Smith, 348 U.S. at 156." (footnotes omitted) I think the question of what *would* constitute the corpus delicti is interesting; the mere presence of PGP overseas shouldn't be enough. And evidence like PGP's presence on a laptop which had once been overseas, or airline ticket stubs or passport stamps or testimony from a security officer who remembered making the defendant turn on the laptop at the metal detector, or even surveillance camera footage would corroborate the defendant's confession but not establish that a crime was committed. Such evidence would seem to get us closer to the latter test mentioned in _Singleterry_ but wouldn't meet Oregon's test of "some other proof that the crime has been committed" (ORS 136.425) nor California's "the charged crime actually happened" (People v. Jennings (1991) 53 Cal.3d 334, 368) standard. But an ITAR prosecution would occur in Federal court, where evidence which merely corroborates the confession (instead of proving a crime) may be sufficient. (And, of course, this is all just so much jawboning. Not legal advice. I'm inclined to avoid confessing to crimes via the Internet whether or not it seems likely to lead to prosecution or conviction. I've already been to one job interview where the employer had seen (and was unnerved) by my vocal presence on the net.(!?!) Which is OK with me because if I make someone nervous when they read Alta Vista, just wait until they meet me. :) It's time to get used to the idea that whatever we write may come back in 20 or 30 or 40 years, whether we like it or not. I think it'll teach us both a sense of forgiveness and a sense of discretion, but that may take awhile.) -- Greg Broiles | "We pretend to be their friends, gbroiles(a)netbox.com | but they fuck with our heads." http://www.io.com/~gbroiles | |

2 1

Technical difficulties with AP [AP NOISE]
by Bill Stewart 17 Dec '03

17 Dec '03

Aside from details like dead bodies, vendettas, and government suppression, there are technical complications with Assassination Politics that make it more than the simple job Jim Bell is imagining. Some of them provide ways to defend against AP, and turn it into more like Extortion Politics. [Do I _really_ want to bring up more discussion of AP? Not sure, but if it's clear that it won't work very well, it'll be less likely for the government media to freak about :-)] Let's look at the critical part of the problem - paying the assassin. The model we've generally been using is that the players are the victim, the escrow agent who manages the system, an enthusiastic public, and the assassin or assassins who are competing for the jackpot. I can see three approaches to identifying the correct payee: 1) Payee provides physical evidence to the escrow agent - the traditional approach doesn't work here: since the escrow agent is anonymous, so you can't mail him the victim's wallet or finger with well-known fingerprint or whatever. 2) Assassin leaves physical evidence at the scene which the news media would be likely to report, which payee confirms with escrow agent, presumably committing in advance (e.g. after the event, the payee sends a key which allows the escrow agent to decode the encrypted message that said "I'm leaving a note on the body saying 'Jacques De Molay is Avenged - Assassin's Guild Member #32767'.") Works fine for the first couple of assassinations, but after a while the police will catch on and stop revealing kinky details to the media. 3) The main solution has been the gambling deal - it's just a lottery on the date of death of the victim, which presumably the payee will win because he knows when the assassin will strike. For a lottery to be effective, prospective assassins need to be able to determine how much the jackpot is and who the victim is, so they can place their bets and be the closest winner. But the prospective victim can also play, individually or as part of an insurance pool (which is especially valuable for victims like "the first IRS agent to be assassinated".) Obviously you don't want to just bid up the price on your own head, so it needs to be accompanied by publicity that the IRS Agents' Benevolent Association is placing a large number of small bets every day to maximize the chances that _they_ will collect the money rather than the assassins. If the times that the bets are for are published, you can beat this, but you also invite speculators to be small bets just before and after your bets, so it becomes a mishmash and perhaps a race condition. If the times aren't published, the assassin can make lots of bets surrounding the planned date of the hit, which is also a warning to the prospective victim to be careful if the bets on his demise start increasing rapidly. This does make the AP lottery somewhat of an extortion deal - by advertising that someone is a target, you're forcing them to continually make lots of bets. But if they've got any way of tracing money, even partially, it'll help them find the escrow agent, who can then be targeted for justice of one sort or another. You're also forcing the assassin to make lots of bets, though in a jackpot system the successful payee will recover most of it. To some extent the defense can be fought if the escrow agent wants to establish a minimum bet, say $100, which an assassin can afford to make a few of for the targeted day, but the victim can't keep paying too much. This also reduces the since of the potential better pool, and therefore reduces the jackpot and the attractiveness of the job to the assassin. Lots of people might be willing to spend $5 to contribute; $100 bets are much fewer, especially if there are enough targets to successfully overthrow a government. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

2 1

Re: crypto anarchy vs AP
by jim bell 17 Dec '03

17 Dec '03

At 02:06 PM 9/26/96 -0500, snow wrote: >Mr. Beck said: >> Been reading the AP thread, and thought I'd donate some of my views. > >> the Internet. You'd just cause the government to panic, and this >> would have negative effects, it would take ages for them to calm down, >> and the laws they'd pass in the mean time would mean a near certainty >> of mandatory GAK as a condition to switching the Internet back on. >> (Before someone takes me to task for the impossibility of switching >> the Internet off, it all depends on the level of government panic. >> More specifically perhaps they would disconnect key backbones, and >> ISPs briefly while they rushed into effect a few presidential decrees >> outlawing non GAKed crypto, anonymous ecash, remailers, PGP, DC-nets, >> etc.) > > This would be cutting their own throats. There is SO much commercial >and government traffic going across "The Net" that many businesses would >scream bloody murder, and the government would have MASSIVE trouble with >it's agenda. Yes, that "they'll cut off the Internet!" talk doesn't seem to be very practical. Society very quickly develops dependency on inventions. Try to take away their computers and they'd scream; take away their telephone and it'd be worse! Give Internet another couple of years and 50% of big business would be severely impacted should it be cut off. Wait five years and the world would practically stop rotating without Internet. On a related issue, GPS (global-positioning system) contains a de-accurizing mis-feature called S/A, which adds a little error to the location as detected by a receiver. Ostensibly, it was added so that this could be turned on in wartime, to deny the enemy the ability to make 10-meter fixes. Turns out that it was kept on all the time, probably because if it WASN'T it would become politically impossible to de-accurize the system even in wartime. Jim Bell jimbell(a)pacifier.com

5 4

[CRYPTO], or hash, anyway
by P. J. Ponder 17 Dec '03

17 Dec '03

I need a copy of the appendix to the SHA FIPS pub (180-1?) that has the three test texts and corresponding SHA hashes, so that I can test an SHA implementation I'm working with. I have tried the NIST site, and can't seem to get through. If anybody has this test deal, or knows where it is out there on the net somewhere, please let me know. Thanks in advance. (My problem is I keep getting different hashes between an MS-DOS version I'm running and one running on a Linux box, when I ftp the same files back and forth. @#$%. I thought maybe I was having problems with some kind of Line-feed vs. Carriage Return/Line-feed conversion deal, but it also generates different hashes on binary files. So I thought I would test the Linux and the DOS one against the specs in the FIPS, and see which one is hosed up.) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to unsubscribe, send to majordomo(a)toad.com a message that reads: unsubscribe cypherpunks in the message body, not the SUBJECT: line. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 0

Re: WARNING: This Message Actually Contains a Question Reguarding Crypto!
by cvhd＠indyweb.net 17 Dec '03

17 Dec '03

>A program called F-Secure Desktop for Windows 3.x and Windows 95 is using >Blowfish with 256-bit keys. It is meant for encrypting the files on your >hard disk and it works nicely together with Windows File Manager or >Windows95 shell. I would say it is one of the best strong and easy to use >HD encryption programs (only that it costs $$). Yes, but how "safe" is a 256-bit key with blowfish? Would it withstand the efforts of big bro' ?

1 0

[NOISE, was CRYPTO], or hash, anyway
by P. J. Ponder 17 Dec '03

17 Dec '03

Please disregard earlier message about finding copy of the SHA document: FIPS PUB 180-1, I found it at: http://bilbo.isu.edu/security/isl/fip180-1.html Thanks, anyway.

1 0

EFF Distributes Terrorist Information On Internet - Wiretaps Needed!! :-)
by Bill Stewart 17 Dec '03

17 Dec '03

The recent electronic newsletter of that suspicious organization calling itself the EFF contains terrorist material: > Received: (from daemon@localhost) by eff.org (8.7.5/8.6.6) id QAA17422 for > effector-comc-exploder; Fri, 27 Sep 1996 16:57:26 -0700 (PDT) > ^^^^^^^^^^^^^^^^^^^^^^ Comic exploders? How totally un-American. They must be stopped! Because a MIME is a terrible thing to waste.... # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

2 1

Re: GPS and other Dual-use technologies
by jim bell 17 Dec '03

17 Dec '03

At 10:34 AM 9/29/96 -0700, Steve Schear wrote: >I used to be an avid RC modeler and have contemplated organizing an >on-going amateur cruise missile contest. The object would be to accurately >deliver various payload weights over courses of various terrain and >distances (perhaps out to a hundred miles or more in the case of Giant >Scale craft). Judging would be based on speed, stealth (noise, IR >emissions and radar cross section) and accuracy. > >Craft are free to use any navigational technology, but must be autonomous >from launch to delivery. To aid navigation I was considering the design of >a substitute differential GPS beacon functionally interchangable with those >offered by the USCG. My device would work on a different frequency, >possibly using very wideband direct sequence spread spectrum (for low >probability of intercept/detection) and be actuated by the missile as it >neared the target in order to refine its position. The data standard for differential corrections is called "RTCM-104", and it's the signal you input into differential-capable GPS receivers. Boxes to generate RTCM-104 are probably relatively cheap, primarily needing a multi-channel GPS receiver and another processor for coding. Differential corrections can, of course, be transmitted on any frequency you'd like, including frequency-hopping if you're really concerned about intercept. (which you won't be...) Incidentally, GPS receivers are getting REALLY small these days, particularly for just the module-level products. A size like about 1 inch by 2-inches is pretty close to state-of-the-art. Power consumption is about 3/4 watt. Jim Bell jimbell(a)pacifier.com

1 0