December 2003 - cypherpunks-legacy

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

Image Encryption Request Filled!
by Jim choate 17 Dec '03

17 Dec '03

I would like to thank all of those who sent mail relating to my earlier post requesting help finding information on graphical encryption - encoding. I have enough information to finish the project that I am working on.

1 0

Secure phones - STU3
by Mike Ingle 17 Dec '03

17 Dec '03

"lear35!mdbomber(a)nebula.acs.uci.edu" wrote: >Subj: secure phones - STU3 >I browsed through the owner's manual for the AT&T STU-III secure phone >unit today. It has no technical information whatsoever (security >through obscurity?). Never Say Anything... >It uses a so called CIK (Crypto Ignition Key), which resembles one of >those electronic keys that hotels use. It must be inserted in a >"lock" in the phone, and turned 90 degrees. This will enable one of >the crypto keys that is stored in the phone's battery backed up memory >(loaded previously by a "COMSEC custodian" through a data port on the >phone. The manual warns the phone must be in a relatively secure >location and points out an emergency erase button that wipes out the >keys stored in memory. They should put a mercury switch in it, so if you steal it and move it around much, it wipes the keys. Also a "duress number" which works okay, but displays a warning on the other party's phone display, in case you're forced to call someone with a gun to your head. >Then you call someone, say you want a secure channel, wait for >them to insert their CIK (and tell you so), then touch the "secure >voice" button on the panel. What all buttons does the phone have? Normal dialing, secure voice, self-destruct, anything else? >The manual then says it will go through an "authentication process", >the results of which will be displayed on the STU-III's screen. It >will show data such as the other stations ID number, the security >level of the channel (secret, top secret, etc), and the baud rate. What baud rates does it use? How is the sound quality in secure mode? It must use either a DSP (good sound, high baud) or a vocoder (robot voice, low baud). >Does anyone know how this works technically? My speculation: It seems >to be a public key system. The phone's memory seems to contain a >secret keyring, and a CIK is a 'passphrase' to a secret key, to make >an analogy to PGP. Then the authentication process includes >exchanging a session key for a conventional crypto system - no doubt >DES. It could be public-key or DH exchange. Does the manual tell you to read a hash value to the other party and verify it? If so, it's DH and that's the protection against the man-in-the-middle. If not, it's either public-key or DH-like but with authentication. In any case, the key probably contains a small EPROM which selects and decrypts one of the keys in the memory. If classified secret and top secret info is involved, DES would not be used. The NSA wants us to use DES, but they know better than to use it for classified info. Probably something similar to Skipjack, in a similar tamper-proof chip. >Apparently the NSA issues the keys to authorized agencies and >contractors. The public keys contain information such as the ID >number of the key, possibly the authorized user's name, the security >clearance level for that key, etc, which is exchanged during >authentication. NSA issues the keys...I feel safer already! Can you say, "key escrow"? --- MikeIngle(a)delphi.com

2 1

Review of "Design and implementation of an RSA cryptosystem using multiple DSP chips"
by an5877＠anon.penet.fi 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Source: Computing Reviews, November 1993, pp. 602-603; 9311-0871 ER, M. H.; WONG, D. J.; SETHU, A. A.; AND NGEOW, K. S. (Nanyang Technological Univ., Singapore) Design and implementation of an RSA cryptosystem using multiple DSP chips. Microprocess. Microsyst. 15, 7 (Sept. 1991), 369-378. The authors propose implementation of the Rivest-Shamir-Adelman (RSA) public key cryptosystem using multiple digital signal processing (DSP) chips. They achieve a speed- up factor of 70 compared with a C software implementation on a PC. The use of multiple DSP chips (three in the authors' example) is hard to justify, in light of other known results. For example, Dusse and Kaliski reported a 25-50 millisecond decryption of 512-bit RSA with a single DSP chip [1]. My C implementation on a SPARC station runs in 2 seconds, about the same factor claimed by the authors. The design suffers from some other problems as well. One problem is the key size (160 bits). This is too small (even 512 bits is not enough for some applications). Another problem is that in this design the secret key is chosen first, and the corresponding public key is calculated accordingly. In most cases, the other way around is preferable, since it is advantageous to have short secret keys. A third problem is that any Carmichael number will pass the proposed primality test (Carmichael numbers are not primes). Better methods exist. The paper is intended for electrical engineers with little or no background in cryptology. The length of the paper is suitable, the drawings are clear, and the physical form of the material is suitable. A reference to Dusse and Kaliski [I] is missing. I believe that the authors did not know about that work, and would have reconsidered the project if they had. Overall, this paper is a fair description of a graduate-level project, but the quality of the design leaves something to be desired. Y. Yacobi, Morristown, NJ References [1] DUSSE, S. R. ND KALISKI, B. S., JR. A cryptographic library for the Motorola DSP56000. In Advances in Cryptology - Eurocrypt '90, I. B. Damgard, Ed., Springer, New York, 1991, 230-244. GENERAL TERM: DESIGN, MEASUREMENT, PERFORMANCE Brought to you by the Information Liberation Front and DEADBEAT <na5877(a)anon.penet.fi> -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBFAgUBLOkhMfFZTpBW/B35AQEU0AF/f9OF6e7asmftL0fTvsNTAxwSPB5GHXuG M9tIK5U9lH7AEC3VWPLgflsVIe/DO6ZS =PvRB -----END PGP SIGNATURE----- ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0