December 2003 - cypherpunks-legacy

No Subject
by XXCLARK＠indst.indstate.edu 17 Dec '03

17 Dec '03

>From: thomas.hughes(a)chrysalis.org > >Date: Tue, 16 Nov 93 02:38:02 >Subject: ENCRYPTED FILE SYSTEMS >To: cypherpunks(a)toad.com > ObInTheSameVein?: > anyone ever thought of taking a "software MNP" program > and creating a "V42enc" software modem protocol? > auto-generate unique/random keys after the connection is etablished, > allow for "re-training" the connection by generating/switching to a new > key. maybe re-train every "set number of seconds" ... > pick a "fast" encryption method, and a RSA public key length that is > proportional to the strength of the encryption, and have at it. Yep.

1 0

Re: The Courtesies of Cypherpunks
by Clark Reynard 17 Dec '03

17 Dec '03

yep, it's happened before. and loudly; it repeats itself about once every couple months; some people have even been _more_ floridly and spectacularly whack-o.

1 0

Windows NT password Encryption.
by Darren Reed 17 Dec '03

17 Dec '03

Does anyone know what algorithm Microsoft are using for password encryption on Windows NT ? I've just been to a talk and told it was a proprietry 1-way algorithm, but not DES based (so as to avoid US export laws).

2 1

Re: Info on L.Detweiler
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> On Mon, 15 Nov 1993, Douglas Barnes wrote: > > > Here's some info folks might appreciate (all numbers area code > > 303, unless otherwise noted): [handy info to help you ruin Detweiler's life deleted] > > Note that this is just the easy stuff, I have folks digging deeper. > > More to come... > > > > -- > > ---------------- /\ > > Douglas Barnes cman(a)illuminati.io.com / \ > > Chief Wizard (512) 448-8950 (d), 447-7866 (v) / () \ > > Illuminati Online metaverse.io.com 7777 /______\ I'd just like to say that I think this sucks bad. I don't like cops, and you're being one, or worse. And with a team of folks helping you to dig even deeper? This is ugly, vicious, and authoritarian, and I can't believe that you would actually BRAG to hundreds of people that you're doing it. Sounds to me like you're a very frustrated person. You are clearly an insensitive bastard. I just hope that you encounter this kind of sympathy if YOU go through a "difficult period" in your life. --Dave.

1 0

Re:Info on L. Detweiler
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Douglas Barnes wrote: >here's some info folks might appreciate (all numbers area code 303, unless >otherwise noted). >[irrelevent information] I know that I do not appreciate knowing this and it is difficult to believe that you would actually waste your time by digging up information to make someone's life difficult (even if he does keep the list noise level up). Use the delete key or kill file. If you really succeed in annoying him enough, I hope for your sake you have few leaders as to where you reside and that you live far away. Gestapo tactics such as these, used by certain governments, are what we seek to eliminate in the digital world. Why would you seek to implement on the list that which we (at least some of us) are trying to eliminate from the net? It's crap that can be done without. Direct your efforts more profitably. Scott G. Morham !The First, VACCINIA(a)uncvx1.oit.unc.edu! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLOhyqz2paOMjHHAhAQHrSwP9GXG6nv1/ICtwCgvWte7Z15nhL/+wPSz2 LWFgFdJ/mJ1ecf9SVSNp2m3uyAoxG0ZARY/5Q6dPEm917W7gxCMxJ/JAFeNoH2hU 1FBLiP4vzNQYlqhiexqFQFOO4SgMLO6QNEAK2zLSv00SwQhqVdMHEHkp7KCMpESg bO46x8BGaYk= =D0tP -----END PGP SIGNATURE-----

1 0

Re: LAW: Wireless interception
by karn＠qualcomm.com 17 Dec '03

17 Dec '03

Mike is correct that early models of cordless phones could often be picked up on broadcast radios. Their base stations transmitted just above the AM broadcast band (in the 1.7 Mhz region). Since then, all new cordless phones operate on the 46 and 49 Mhz bands, which generally require a scanner to receive. However, cell phones still operate in what used to be UHF TV channels 70-83, and it is still possible in some cases to intercept cell phone calls on a UHF TV set. So much for *that* theory. :-) I still think my original explanation for the ECPA's distinction between cordless and cellular phones is the dominant one. Phil

3 2

Image crypto info needed...
by Jim choate 17 Dec '03

17 Dec '03

Hi everyone, I am looking for any references or sources of information or code dealing w/ the use of images as a means of both transmission and encryption of plain- texts. Specificaly, I am interested in taking the 3 byte feild for each pixel in a .gif and replacing the lsb w/ the bits in a 'plain-text'. This in effect converts the image to a 'cypher-text'. The only real indication of a message is the individual pixel brightness will be altered. However, unless you have a source of known clean images there is little way to decode the messagr reliably. Right now we (a friend is helping work on it) are using the .gif galore CD as our library of reference images. We eventualy hope to have a source of such images available for all to access. Any information or feedback would be appreciated (keep your flames to yourself), thanks ahead of time!

1 0

count me out
by jet＠netcom.com 17 Dec '03

17 Dec '03

I joined this list thinking there'd be a lot of good information about crypto. There was. Now, I'm better off reading sci.crypt. So I'm gone. -eric

1 0

Portable crypto code
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

One thing that frustrates me is the difficulty of easily providing implementations of cryptographic algorithms that would be useful on a wide range of machines. A lot of these algorithms are really simple, almost trivial. Yet to write programs to implement them takes pages and pages of code, and making them portable so that people on PC's, Mac's, and Unix machines can use them is almost impossible. Take the simple Chaum cash we have discussed here a few times. The user picks a random x and a random r, calculates r^3*f(x) where f is some one-way function, and sends it to the bank. The bank takes the cube root and sends it back, then the user divides by r. That's pretty simple. Yet to actually implement software to perform these steps raises a host of complications. First, we want to choose a "random" x and r in the range 0..m-1, where m is the bank's public key modulus. But we want these to be strong, unguessable random numbers. We need an unpredictable RNG, and we need to seed it. There are various URNG's that are provably as strong as breaking factoring, discrete logarithms, and such, so these would have to be implemented (as before, most are conceptually trivial). Or you could run DES or IDEA in a feedback mode and take bits from there, for a little less security but more speed. For seeding the RNG you could do like PGP does and retain random numbers from earlier runs, mixing in new randomness when feasible; you could do like RIPEM and scan disk partitions hoping for randomness (I think RIPEM has a lot of other ways of looking for entropy); you could use hardware features like /dev/audio or the free-running, high-speed timers some PC's have; you can get the user to click the mouse or type keys at random. OK, we've got our random numbers. Now we want a one-way function. Again, there are several choices: MD4 and MD5 from RSA; the Secure Hash Standard NIST is pushing; Ralph Merkle's (I forget the name); others based on conventional ciphers like DES or IDEA. Implementations of these are probably available, but portability is a question mark. Now we need a multi-precision math package. We may have needed one for the URNG, too. There are a lot of libraries available in source code for these, but not many of them will work with 16-bit ints, and are tested on DOS and Mac's as well as Unix. Finally, to send the data around, we may want to convert to and from ASCII, and once again there are a lot of choices, but perhaps not too many portable libraries. I suppose RFC1113 and MIME, which are similar but not quite identical, would be the encodings of choice. The point I'm getting to is that it would be nice if all this were done ONCE, and a library made and tested which would work on a wide range of machines. Entry points for one-way functions, multi-precision arithmetic, unpredictable random numbers, conventional encryption, and ascii conversions could all be provided. Multiple alternatives would be supported as much as possible and it should not be difficult to add more as time goes on. Once you had such a library, it would be possible to add a user interface to allow interactive use of the routines. It could be as simple as the Unix "bc" program where you can say "x = y*z" to do arithmetic, or perhaps "x = md5(y)" to call a one-way function. Or the library could perhaps be linked into perl or some other high-level program (does mathematica have hooks for compiled user code?). The nice thing is that since most of the compute time is spent doing the MP arithmetic in these algorithms, an interpreted system which calls compiled libraries can be as efficient as a purely compiled program. I know that others here have made similar proposals in the past, but I have not heard of many results. I'd like to hear more about whether these efforts have produced anything that could be incorporated. It would also be good to hear suggestions for specific existing packages that would meet the portability requirements. I've looked at a couple of MP packages from ripem.msu.edu but so far I haven't had much luck running them under DOS. Perhaps a project like this could allow progress to be made more easily toward cypherpunk goals. By providing a toolkit to programers newly interested in cryptography people will be able to try out ideas more easily without having to re-invent the wheel each time. Let me know if you would be interested in participating in this effort. Hopefully a lot of the pieces already exist and it will just be a matter of pulling them together. Hal Finney hfinney(a)shell.portal.com

3 2

Re: Should we oppose the Data Superhighway/NII?
by habs＠panix.com 17 Dec '03

17 Dec '03

I have stayed quiet on this topic but now feel I should put my views forward. 1) I feel the government, in this case and others, should never force the adoption of any particular technology (ISDN, ATM, etc) 2) While I am pro-market in the Extropian Way, I think that what we need from the government is the following: a) recognize that Cable and Telco are the same business b) set very minimum standards required for basic services (basic telco, basic cable (e.g., local broadcast channels) c) I don't see data as a basic service d) apply the same regulation to both companies. e) Let cable and telco compete head to head 3) Let the rich pay for it ;) There is this liberal idea that only the rich will get the "good stuff" That their kids will study on-line with Nobel prize winners while the poor kids will still be using chalk and erasers in the "slums." The same liberals what to raise taxes "on the Rich," so they can pay for things. I feel if you don't "push" for universal access the systems will be build that way anyway. They will cost $$$, and the "rich" will buy into it. As economies of scale and scope come into pay, the cost of these systems will come down and the poor will get it too. Thus, the rich have paid for it, and the poor have got it cheap. There is one problem with this. In NYC, the "POOR" are already bigger users of CLASS services (call waiting, three way dialing, etc.), and of Cable premium channels; no marketer is going to leave this group unwired. No one is going to do an Interactive Test Market in the Lower East Side, but trust me systems will be built there. -- Harry S. Hawk - Extropian habs(a)extropy.org In Service to Extropians since 1991

5 7