December 2003 - cypherpunks-legacy

Re: Singapore Global Action Alert (8/29/96)
by Jean-Francois Avon 17 Dec '03

17 Dec '03

On 29 Aug 96 at 19:25, Declan McCullagh wrote: > Bill speaks sooth. Personally, I agree with Jean-Francois in that > the Singapore government *does* understand the Net, and is using > that knowledge to control it within their borders reasonably well. > Remember the next phase of restrictions goes into effect on > September 15. > > But I don't see a problem in being polite the first time. Dear Declan. This post is not personnally against you Declan. I like your posts. Only, I don't agree with you last post. And permit me to advance this: it is through an honnest error of yours that you have this opinion. So, here it is: I don't agree with you. The world is being stangulated and bloodsucked dry by peoples who are nothing but cheap shots. It is not a matter of being polite or not, it is a matter of saying things as they really are. It is a matter of acknowledging reality. It is a matter of integrity. The best way to blow up their cheap littles looting schemes is to simply *say* the truth. We live in an age where everybody is terrified of stating what everybody damn well know but tries as hard as they can to blank out. By giving a simulacre (english word?), a make believe of moral sanction, you permit them to commit their crimes against human mind and life. It is *us*, the producers, who grant them a recognition by being polite to them while they propose to eat us alive. You wouldn't let a hiway robber to mug you without trying everything you can to prevent it, yet, you permit thoses statists leeches to confiscate an enormous part of your life, to rule an enormous part of your life, to define an enormous part of your life rules. I grant much more respect to a bank robber than to a politician: the bank robber puts his own ass on the line, takes his own risks, and doesn't pretend he's doing it for you. He is a robber but he makes no bones about it and he accepts the risks of the "trade". Ask yourself if your friendly neighboorhood politician fits this definition. My famnily owned a land. The city expropriated us at around 1.85$/sq.ft. while they evaluated, "for taxation purposes", the land at 4.85$/sq.ft. They sold the land to a local "silicon-valley-style" project who went bankrupt so the city could repossess it. We fighted the provincial govt (and won partially) because they planned to have the capacity to re-sell the land for housing projects, therefore speculating on expropriated land. Hey, I'd rather have the 10$ it is worth that let them have them. We damn worked this land for 50 years. And all of this was done in the name of "for the good of science", technology and high-tech employement, all with the full moral sanction of our universities most famous universities, provincial, federal and municipal govt. Only, there is not a damn business that came to establish itself there. Finally, one big pharmaceutical did but there is probably a lot of corruption underneath. It stinks. The way they could perform that extortion was with the aid of hundreds of half baked semi truths and fallacies, all in the name of some "unknown but all desserving" fucking "public". If we would have simply stood up and named their fallacies in the first place, they would have had a much harder time doing what they did to us. but our modern lawyers and "counsellors" said that we should "play along". Since the land had 9 co-owners, FUD worked well and most owners were convinced to play the game, therefore granting them the moral sanction of acknowledging realism and legitimacy. It was *all* done in the name of "tolerance" and of being "open minded". But as I said, a little poison is still poison. In retrospect, by granting them the semblance of reason, *WE* forged reality for them, *WE* gave them a moral sanction. I am not one of the owner. My mom's family is. I watched the scene with rage but I couldn't do anything. Try to make theses peoples understand after being told for all their life that "being polite" and "being tolerant" is a must... There is no such thing as being tolerant to being killed. You don't just "die only a little". In the same way, you don't loose "only a little" taxed dollars or free speech. I am not a Randian, but I agree with many ideas of Ayn Rand. I don't recite half-memorized paragraph out of her books, I fought and still fight as I can the govt in their looting schemes. I was there, sitting with ministers and arguing with them. I saw the leeches in action. So, if you persist at advocating politeness in thoses situations, next time a mugger try to beat you, try to remain polite in the first time... Many friends of many politicians will get rich on it. Our layers will get rich on it. We worked the damn place for 50 years and *owned* it. Land, not that far from there was sold at around 16$. Land behind ours was sold 7$. We got 1.85$. If anybody wants to argue with me, first send a check for the difference between 10$ and 1.85$, times the sq.ft. surface of the land. (e-mail me by PGP to have the figures :) Then, we could *start* discussing the virtues of statism. Regards. JFA Who is John Galt? :) DePompadour, Societe d'Importation Ltee; Limoges porcelain, silverware and crystal JFA Technologies, R&D consultants: physicists, technologists and engineers. PGP keys at: http://w3.citenet.net/users/jf_avon ID# C58ADD0D : 529645E8205A8A5E F87CC86FAEFEF891

1 0

Re: Exploring (RSA (001)
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 10:39 PM 8/29/96 -0400, Scottauge(a)aol.com wrote: >Exploring Rivest, Shamir, Adelman algorithm, but hoping someone out there is >interested in very large number manipulations. > >... > >Other than using Mathematica or Maple, I would like to use C or perferrably >C++. > >Just some basics such as multiplication, addition, subtraction, division, >mod, etc over the Z set. I have been collecting information about crypto libraries for the Mac Crypto conference next week. Here is what a quick AltaVista search came up with. Since you want C++, I would particularly look at Wei Dai's Crypto++ library. If anyone has other strongly recommended libraries, please let me know. Crypto Libraries http://www.clark.net/pub/cme/ has source for MD5 http://www.homeport.org/~adam/crypto/ for a comparison of crypto libraries http://www.enter.net/~chronos/cryptolog1.html has a collection of links to crypto resources http://www.openmarket.com/techinfo/applied.htm - Internet Locations for Materials on the Disks for Applied Cryptography Crypto++ in C++ by Wei Dai. - Has been tested under Codewarrior 2.0. ftp://ftp.csn.net/mpj/README - in the USA Cryptolib in C by Jack Lacy - No Mac version, C, Sparc, SGI, i486 assembler To obtain, send email to cryptolib(a)research.att.com with a statement of the following form: "I am a U.S. or Canadian citizen or a legal permanent resident of the U.S. and am aware that some parts of CryptoLib may be restricted under United States Export regulations. I have read and understand the CryptoLib license." Name: Location: E-mail: Are you licensed to use the RSA patent? If yes, give name of licensed organization: RSAref 2.0, by RSA Data Security Inc. - Tested with Mac ftp://ftp.rsa.com:/rsaref/README - In the USA http://www.consensus.com/RSAREF/rsaref_toc.html - in the USA SSLeay in C by Eric Young - C, gcc and system cc for Solaris 2.[34] (sparc and x86), SunOS 4.1.3, DGUX, OSF1 Alpha, HPUX 9, AIX 3.5, IRIX 5.[23], LINUX, NeXT (intel) ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/ The Systemics Cryptix Cryptography Library in Java or Perl by Gary Howland - Java on Win95, WinNT, Solaris, Linux, Irix. http://www.systemics.com/software/ The Cryptlib free Encryption Library in C by Peter Gutmann - Unix, DOS, windows (16 & 32 bit DLL available), Amiga http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html ------------------------------------------------------------------------- Bill Frantz | Cave ab homine unius libri | Periwinkle -- Consulting (408)356-8506 | [Beware the man of one | 16345 Englewood Ave. frantz(a)netcom.com | book] - Anonymous Latin | Los Gatos, CA 95032, USA

1 0

Encryption
by Dale Thorn 17 Dec '03

17 Dec '03

It appears to me that PGP encryption et al is really 1940's technology, albeit fancied up by 1990's computers. Why use keys and cyphers when all you should have to do is maximize the randomization of bits in a script? Big computers should not be able to de-randomize such encoding, since the permutations/combinations would be astronomical after just a half-dozen or so random number initializations, as well as the fact that the bits are relatively undifferentiated (just ones and zeros) and are not maintained with their original bytes, words, paragraphs, or pages? DALE THORN ON CRYPTOGRAPHY: ABSTRACT 23 August 1996 ------------------------------------------------------------------------------ Algorithm: Select bit-groups of random length from the file until the file is completely processed. Shuffle the bits in each group randomly and save each group back to the file. Repeat if needed using different key-strings for each successive encryption, for increased security. "If a high-speed computer could perform 'a trillion processor ops per second', and it took just one millionth of a second to 'crack' my test file on such a machine (i.e., a million ops), it would still require 10^36 ops to 'crack' 6 consecutive encodings, which translates to 10^24 seconds, or 3 x 10^16 years." "Due to the nature of compounded bit-shuffling, no algorithm ever developed or proposed could 'crack' multi-pass encoding with a single decryption pass. In plain English, if a file were encoded six times (in six passes, with six different password phrases), you'd have to decode all six passes before you would know whether even the first decryption pass was successful or not." "Since each byte in the encrypted file may contain bits from other 'original' bytes, multi-pass encoding moves you rapidly in the direction of true-random distribution of the source bits (note the 'Intelligent User' comment below)." "My desktop computer (a 90 mhz Pentium) can encrypt a 12 kb file in less than one second (in a single pass) using 'C', and takes less than two seconds with the PDQ version of Basic I use, hence, the six passes that I normally perform on such a file require nine seconds or less total computer time." "One of the difficulties in breaking this type of encryption (other than the numerical time factors) is the fact that you might have to deal with several unknown random number generators from different compiled executable programs. Add to this another factor, the 'Intelligent User' who adds their own tweaks to the source code. The tweak is added, the program is compiled, the file(s) are encrypted, and then the modified source code is destroyed along with the executable file. This type of modification, together with the fact that the individual bits in the encrypted text file are scattered very effectively in normal encoding, yields the ultimate level of security for concerned persons." ------------------------------------------------------------------------------ A SIMPLIFIED EXAMPLE FOR ENCRYPTION/DECRYPTION ------------------------------------------------------------------------------ We're going to encrypt the following 25-character text string: when_it_rains_it's_a_bath The unencrypted string (in bit form, least significant bit at left) is: 11101110000101101010011001110110111110101001011000 10111011111010010011101000011010010110011101101100 11101111101010010110001011101110010011001110111110 10100001101111101001000110100001100010111000010110 We now generate 200 random numbers, and sort them in ascending order. The following list represents the original physical positions of the numbers, and we move the bits as shown above from these positions in the 25-byte text string to bit positions 0, 1, 2, etc. (move bit #4 to the first position, move bit #179 to the second position, etc.). 4 179 67 127 46 76 136 74 92 54 88 121 134 192 77 36 47 26 45 144 111 141 150 58 110 12 94 13 161 177 18 155 153 175 91 95 86 195 79 20 23 172 51 96 126 93 64 3 125 81 166 131 71 63 170 78 140 87 107 147 15 35 10 168 33 149 189 118 42 90 6 85 120 68 102 173 103 104 138 83 53 43 182 139 29 60 146 184 176 114 123 44 191 56 70 185 73 137 148 199 196 27 65 62 37 181 28 0 106 158 100 1 190 2 25 194 8 30 174 101 105 135 162 61 75 32 115 142 14 49 186 50 183 21 119 52 69 99 11 89 72 34 98 188 82 17 163 9 167 109 113 171 38 157 84 5 59 178 22 57 151 122 160 130 39 116 133 156 164 66 159 40 124 193 108 180 152 41 97 7 197 145 132 169 55 16 24 165 198 112 19 129 187 31 154 48 80 128 117 143 The text string (in bit form) following the first encryption is now: 10001010010000110111011110111010001011000001110010 10000110110100101101110111010111101110100001100110 01110101111111100111101001111011010110111101001000 00110110110111001010011010101011010100110100001110 At this point, it's obvious (with a sufficient length of text to analyze) that we could restore the original text using an algorithm equivalent to the pseudo- random number generator we used above. However, we're going to encrypt again: Generate another 200 random numbers and sort them in ascending order. The following list represents the original physical positions of the numbers, so move the bits the same way we moved them above (move bit #41 to the first position, move bit #9 to the second position, etc.). 41 9 38 86 67 108 8 99 157 69 91 6 15 150 28 192 56 98 54 72 145 19 48 64 183 147 102 7 138 177 167 29 164 176 97 82 83 168 181 95 185 22 21 30 93 182 109 39 197 14 96 40 84 137 155 143 16 126 58 33 149 144 140 159 88 189 4 190 153 90 68 114 129 45 53 112 119 125 127 124 20 141 142 77 188 115 175 105 60 194 106 80 31 49 51 116 1 113 151 94 2 199 161 146 71 101 62 66 154 166 3 128 5 118 10 61 110 165 43 122 42 47 184 46 133 85 74 173 36 44 111 171 89 35 163 136 162 198 17 23 78 152 121 37 12 186 55 169 103 24 34 26 178 87 81 123 132 195 65 11 174 191 193 172 18 25 196 107 120 187 27 100 180 134 59 135 179 57 148 0 63 13 158 130 70 131 117 139 32 104 92 170 50 76 73 79 75 160 52 156 The text string (in bit form) following the second encryption is now: 01011100010110101100011110101000011101101111101011 00101101100011111010010101111001011001000100000101 00111101010101011011000011101111001111110101001011 11101000001101101110101011000100111111000010111001 Now that we've doubly-encrypted the text string, try to describe an algorithm that will restore the original string in a single decryption step, i.e., move directly from the last-encoded text to the original text without the need for an intermediate decryption step. Text parsers and lexical analyzers won't do you any good in intermediate steps as described above, since all intermediate encodings will be garbage text (not only will the bits in each character be scrambled, but bits will be scrambled across characters, words, and paragraphs as well. Multi-step decryption could be facilitated where text can be analyzed a few characters or words at a time, assuming the analysis engine could determine from where to get the appropriate bits when processing a large text stream. In the above examples of bit-level encryption, the individual bits migrate to various places in the text string rather than remain within each set of eight bits which DOS arbitrarily designates as character bytes. Therefore, the ONLY tenable (but not necessarily viable) methods for decoding such text are: 1. Try rearranging the bits randomly. The disadvantages are: a. You could come up with "Mary had a little lamb...", etc., given that the bits are minimally differentiated (just ones and zeros). b. Decryption would require eons of time (an exponential factor of the number of bits processed, divided by the cycle time of the computer). 2. Decrypt the text one step at a time, in the reverse order of the encryption steps. The disadvantages are: a. You can't be sure you've decrypted any step correctly until decryption is completed (until all steps are performed and the text is readable). b. Passwords/phrases, algorithms, code routines, and even whole programs might change from step to step, thereby invalidating any 'single-pass' decryption scheme that's likely to be proposed.

4 3

Re: Nuke Singapore Back into the Stone Age
by Charley Sparks 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: tcmay(a)got.net, cypherpunks(a)toad.com Date: Fri Aug 30 05:45:44 1996 We could launch a mail-bomb campaign.. I am looking for the source for a mail bomb program. WinTel would be nice but I could use Linux -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCXAwUBMia4SeJ+JZd/Y4yVAQGlpgQMCuPtwANs1N4JbQDyUsNEpib2rR2CNrsY lRIQ1gVNHNZhptnDaHxu69R0dLhBF/hjbnQwhINGYZcuCVfE7kxRdgwVVmU+G7Bw ods0qCVe2CFddD0cxxQ8mdURnnTQGkN2nz4wA2zx1DHN/pKqzrCYxlLLllzGb+MH 50BM7K2Wj6BShQ== =wB2W -----END PGP SIGNATURE-----

2 1

Re: see you guys later
by Charley Sparks 17 Dec '03

17 Dec '03

You might want to reconsider the 2x Lithium.... too much really does make you feel like shit ! Actually the lobotimizing effects of stellazine (sp) aren't too bad for a short time

1 0

Ian's Linux Filesystem Patches
by mixmaster＠remail.obscura.com 17 Dec '03

17 Dec '03

I installed Ian's filesystem patches for Linux 2.0.11, and then patched the kernel up to 2.0.15. Unfortunately I soon realized that the entire system grinds to a halt as the kernel performs cryptographic operations on a block of data. I lack enough crypto expertise to fix this, but I believe it just needs to be made preemptable, however that works. The filesystem patch, while a definite step in the right direction, is all but useless in its present form. For an idea of what I'm talking about, kill your turbo switch, or install on a slow machine so that this is a bit more noticable. Users may want to kill their internal chip cache. Patch the kernel up to 2.0.15, and install the kernel. Setup the loopback device as the README file states. Then make a filesystem on that device. The system will slow to a halt about the time that it actually needs to write some data to the filesystem, probably during the superblock write in mke2fs. Then, mount the filesystem and try to write a large block of data to the device. Again, it dies. This will need to be fixed if everyone wants to install such a patch into their kernel to reduce suspicion, or if it is to be included as standard in the kernel source tree. I would fix this if I knew more about the way the kernel is set up. I do fear making it preemptable may open a large can of worms, at which point it may be more useful to implement this in userspace, maybe by the creation of a seperate entry in the device hierarchy.

1 0

Re: Errors-To: for cypherpunks
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> Hi, > > Whoever is in charge of maintaining this mailnig list, PLEASE > add header > > Errors-To: cypherpunks-errors(a)toad.com > > I am flooded by stupid "Mailbox is full" messages from Banyan and > CC-mail gateways. > > - Igor. > While an Errors-To: field can't hurt, it shouldn't be needed. The problem is *broken* gateways. There are plenty of properly set up and running Banyan and CC-mail gateways, we just need to harass the admins into running the broken ones properly. Let me quote from "scripture" (RFC-822) below in a typical message I send to such idiots. This particular person had neither the use Sender: set up correctly, or a postmaster address. <sigh> ----- included message ---- Your SMTP to Banyan gateway is broken and missing a postmaster address. I sent a message to cypherpunks(a)toad.com, to which someone at your site is apparently subscribed. The listserver at toad.com correctly puts a "Sender:" field in the header of all outgoing messages, and according to RFC-822 all SMTP handleing agents must send any bounces to that address. RFC-822 specifically states (starting at line #1430 in rfc-822.txt) 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO For systems which automatically generate address lists for replies to messages, the following recommendations are made: o The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used. Also, RFC-822 states that you must have an address of postmaster that people can send email to (starting at line #2046 in rfc-822.txt) 6.3. RESERVED ADDRESS It often is necessary to send mail to a site, without know- ing any of its valid addresses. For example, there may be mail system dysfunctions, or a user may wish to find out a person's correct address, at that site. This standard specifies a single, reserved mailbox address (local-part) which is to be valid at each site. Mail sent to that address is to be routed to a person responsible for the site's mail system or to a person with responsibility for general site operation. The name of the reserved local-part address is: Postmaster so that "Postmaster@domain" is required to be valid. Note: This reserved local-part must be matched without sensi- tivity to alphabetic case, so that "POSTMASTER", "postmas- ter", and even "poStmASteR" is to be accepted. So, please fix your gateway, or contact Banyan on how to correctly configure it. Thank-you, ----- end included message ---- ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

Reprogramming Beepers?
by William F. Towey 17 Dec '03

17 Dec '03

Does anyone know how to reprogram a beeper to a new number. Please Help Brendan

1 0

Re: Selling your sole to DOJ ...err, devil Zimmermann?
by Marc J. Wohler 17 Dec '03

17 Dec '03

At 06:20 AM 8/30/96 GMT, attila(a)primenet.com ranted: > > Zimmermann is a political flake, a warmed over 60s > liberal. > <snip> > I would find it difficult, despite his apparent altruism > and left-over 60s need for redress, to believe that > Zimmermann's coding of PGP was other than a commercial > stepping stone (judging from both his prior and later > actions); and, > I guess that according to the Code of Attila, us left over 60's liberals are prohibited from any commercial commerce. mjw

1 0

Re: Why I Pay Too Much in Taxes
by Duncan Frissell 17 Dec '03

17 Dec '03

Better late than never: At 08:43 AM 5/7/96 -0400, Clay Olbon II wrote: >There are a couple of main reasons that the poor spend more than their >reported income. First, many of the elderly are included in the "poorest >20%", since this is based on income alone and not net worth. Many of the >elderly are spending down their retirement savings. Also students living on loans, grants, and gifts. Also members of the retail pharmaceutical trade living on their markup. >Another factor, of >course, is that welfare, food stamps, free/subsidized housing and other >transfer payments are not included in income calculations. I have seen >reports that show that in many states, this is equivalent to a full-time >job paying ~$9/hr. The Cato Institute Study. AFDC+Food Stamps+Housing Assistance+Medicaid+WIC = a fair chunk of change when compared to the taxed earnings from work. Equivalent to the take-home pay from a $16/hour job in NYC (mostly because of health insurance). The commies complained that the study didn't account for the fact that the working poor can also get food stamps and Earned Income Tax Credit. Of course, if you just establish the value of welfare benefits, you are doing a lot. >Not showing these as income helps keep the "official" >poverty rate high. I'm not sure if social security is included in income >calculations for "poverty rate" purposes, anyone know? The poverty rate calculations (how many people below the poverty level?) do not include SS or welfare cash or non-cash benefits. Thus people are not as poor as claimed even ignoring unreported income from legal and illegal employment. Adding everything up, we find that poor households spend twice what they officially report taking in. Hardly surprising since if one has a low income, one unreported job in the household can double that income. It is also likely that a higher proportion of the income and assets of the poor are not recorded (as against the rich) because most of the assets are personalty rather than realty and they are less likely to be audited, etc. So the level of income and asset inequality in America is less than you will have heard. DCF

1 0