December 2003 - cypherpunks-legacy

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

Re: Intel to rule the basic crypto engine market?
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 08:27 PM 8/29/96 -0800, jim bell <jimbell(a)pacifier.com> wrote: >The one kind of standardization in the crypto market that we truly need, >NOW, is a standard format/protocol so that crypto telephones from all >manufacturers can talk to each other. The last thing we need is a >tower-of-Babel situation, which would be even worse than the VHS/Beta wars >of 20-10 years ago. I think it'll be a while before we're at that point - there's too much experimenting to do, and too many different options of crypto and voice compression that are useful in different situations. Simple issues like Internet vs. modem vs. frame relay vs. cellphone make a radical difference in performance. A standardized _option_negotiation_ method would be valuable; that would at least let systems figure out if they can talk as well as exchanging keys. You can use PGPtalk if you want a single standard program that will often work - for now the best approach for non-hardware-based systems is probably to have several popular encrypted phone programs, and negotiate by voice which ones to use :-) The non-crypto-internet-phone business has been in a similar bind, but Intel's announcement that H.323 shall be the One True Standard may get enough support to cut through that. Is there some hook in their system that could make it easy to add encryption, or do we need to design Internet-Crypto-Phones that recycle the H.323 from Intel but add several layers of wrapper around them? (ITU standards being what they are, I haven't yet found an on-line source of the document, and the ITU itself has a badly organized web site that lets you order paper copies of the documents by mailing paper Swiss Francs to them, which is annoying. (It could at least do SSL web forms and Visa cards or something.) And Intel's free reference implementation needs Win95, which I'm not running.) # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Reassign Authority!

1 0

Re: Encryption (shuffling proposal)
by peter.allan＠aeat.co.uk 17 Dec '03

17 Dec '03

> DALE THORN ON CRYPTOGRAPHY: (edited for brevity) > 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? > 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. > "Due to the nature of compounded bit-shuffling, no algorithm ever developed > or proposed could 'crack' multi-pass encoding with a single decryption pass. You are producing a permutation table. Repeat passes just get you a new table, no different in principle. > [Time calc for 12kb file....] > "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. But the internet worm of 1988 was captured, decompiled and analysed in days. Self-modifying viruses get analysed (by single stepping). Your programs will go the same way as soon as there is (financial ?) motivation. So the users have to know the algorithms, including "tweaks" in order to communicate ? Not the most convenient key. > EXAMPLE when_it_rains_it's_a_bath (least significant bit at left): > 11101110000101101010011001110110111110101001011000 > 10111011111010010011101000011010010110011101101100 > 11101111101010010110001011101110010011001110111110 > 10100001101111101001000110100001100010111000010110 becomes > 01011100010110101100011110101000011101101111101011 > 00101101100011111010010101111001011001000100000101 > 00111101010101011011000011101111001111110101001011 > 11101000001101101110101011000100111111000010111001 >From this known plaintext-cyphertext pair the enemy can list all the possible sources and destinations of each bit. EG first bit of plaintext (position 0, value 1) can move to 1,3,4,5,....,199 second bit of plaintext (position 1, value 1) can move to 1,3,4,5,....,199 Given a number of pairs of the same length, produced with the same key details each of these lists of possibilities shrinks by around half. Your 12kb file is well on the way to being cracked after 4+10+3=17 pairs are discovered. If the intention is never to reuse keys, then this scheme gets you nothing you couldn't have with a normal stream cipher. And they, don't reveal the number of 1-bits and 0-bits in the message. Different messages will be recognisable different. A chosen plaintext attack (where these are possible) becomes a breeze. > 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. How are the above remarks invalidated ? I don't want to stifle creativity. If you keep thinking you may come up with a good idea. But this isn't it. I encourage you to read about existing systems. There have been bright people before, and things are done (or not done) for a reason. -- Peter Allan peter.allan(a)aeat.co.uk

1 0

Re: Encryption
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 05:40 PM 8/30/96 +0200, Germano Caronni <caronni(a)tik.ee.ethz.ch> wrote: >Dale Thorn wrote: >> 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. >Very nice. There are just two little issues: >a) How do you generate the random bytes? >b) How do you transmit them to the other side, without having a secure channel? I agree. This method can be looked at as two parts: 1) Generate a stream of random numbers 2) Use the stream to transform the plaintext into cyphertext by shuffling. Generating a stream of random numbers can be done by cryptographically strong methods, or by physical methods such as throwing dice or counting gamma rays, or by cryptographically weak methods such as using the RANDOM function provided by your BASIC compiler. If you're using strong crypto, the method is strong if the transform is strong. If you're using physical randomness, that's also true, and you'll definitely need to use agents with briefcases handcuffed to their arms to haul the randoms around, which doesn't gain you much operational security, since the random stream needs to be longer than the plaintext. If you're using weak crypto, we can use those fast computers you're so impressed with to try all 32767 or 2**32 random streams on your input to see what works - brute force isn't that hard when you've got a small keyspace, even if you don't take advantage of the special forms (e.g. there are good methods for reversing linear congruential multiplicative generators.) How long a stream of random numbers do you need to do the transform? And how secure _is_ the transform? For a simple XOR, you know that each bit in the stream will diddle one bit in the plaintext, so you're fine (as long as you only use the random stream once.) But for your shuffling method, you'd have to shuffle much longer to make sure that the "random" selection of bitgroups hits all the bits, and hits them often enough that adjacent bits will be separated. For instance, if your message is a 3000-word set of instructions to your fellow plotters, you need to be sure that the phrases "gunpowder", "Parliament", and "November 5th" get shredded, not merely moved to different places in the document. This takes much longer than deterministic methods, and risks not being as good. There are some advantages with the shuffling method - assuming you've cranked the system long enough to really shred everything, it's hard to take cyphertext and reconstruct plaintext, and brute force is a bit more work than with a deterministic method that uses one pass. But you can get that effect by using stronger methods, such as the des | tran | des | tran | des where "tran" is a simple key-or-input-driven shuffle that doesn't need to be totally strong. (Is Carl Ellison the person who proposed this? I've forgotten.) # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Reassign Authority!

1 0