December 2003 - cypherpunks-legacy

Mr. May's Posts. Other Things.
by Ross Wright 17 Dec '03

17 Dec '03

On or About 21 Dec 96 at 10:36, Dr.Dimitri Vulis KOTM wrote: > Interesting. Paul Bradley does not consider Timmy May's (fart) > latest rants on "ebonics" and "colored race" to be racist? I think > Timmy May hates blacks even more than he hates Jews. Let's quote > Timmy's sick garbage on soc.culture.african.american and ask if they > find it offensive and racist. > Yes, Dr., this latest tripe that has spewed forth from Tim's keyboard reeks of bigotry. And all this time I felt you may have been too hard on him. This latest rant of his has made me reconsider your rough treatment of Mr. May. I kinda think he deserves a slapping right now. I find Mr. Mays comments quite racist and are quite off topic for this list. I would much rather talk about what rights I have to do bulk, targeted e-mailings! Or the fame of "The Spam King" I saw him on a TV show called The Web on the SciFi channel. This guy is a great example of the old adage that there is no such thing as bad publicity. Just my two cents. It's been too long since I last posted, but I was compelled to post about this racist crap. I went to an inner-city school in South Gate, California and found it better to be friendly with anyone who would be my friend, despite the color of their skin. I went into the US Military and that idea was reinforced there. So I hate to hear people who are unwilling to find humanity behind a darker color skin. That just pisses me off! Ross =-=-=-=-=-=- Ross Wright King Media: Bulk Sales of Software Media and Duplication Services http://www.slip.net/~cdr/kingmedia Voice: 415-206-9906

3 3

Super Crypto
by Erase56＠aol.com 17 Dec '03

17 Dec '03

Can someone help me on finding a program with super crypto. E-mail me back at Erase56(a)aol.com with the program attatched or e-mail me on where can I find it. On the internet of where ever. Thanks.

1 0

Re: the word is "NIGGAZ"
by aga 17 Dec '03

17 Dec '03

On Sun, 22 Dec 1996, Dr.Dimitri Vulis KOTM wrote: > >From cypherpunks-errors(a)toad.com Sun Dec 22 18:36:40 1996 > To: cypherpunks(a)toad.com > Subject: Re: the word is "NIGGAZ" > Sender: owner-cypherpunks(a)toad.com > Precedence: bulk > > > Actually the word is "niggus." "Niggaz" is the white man's nasal rendition > of this term. Nope, that is from the black man. In JET Magazine, they say "NIGGAZ," and they are the nationwide authority on the black subculture. If you do not read JET, you do not know anything about the blacks, unless you live next to them like we do in the city here. "Soul Brothers" hate "niggers," because a "nigger" is defined as somebody who: 1) lies, 2) cheats, 3) steals, 4) stinks, or 5) fucks with your woman. There are good blacks and bad niggers, good jews and bad kikes good dagos and bad wops good gay boys and bad faggots good ladies and bad cunts good and bad of all kind...

1 0

Privtool 0.87
by Mark Grant 17 Dec '03

17 Dec '03

I've finally released a new version of Privtool -- my PGP-aware X-windows mailreader for Linux, SunOS, FreeBSD and Solaris. Version 0.86 is available on utopia.hacktic.nl in the incoming directory (and possibly elsewhere) and I'll be uploading 0.87 shortly. For more details and screenshots see http://www.c2.org/~mark/privtool/privtool.html. Mark -----BEGIN PGP SIGNED MESSAGE----- Privtool Beta Release 0.87 -------------------------- Privtool ("Privacy Tool") is intended to be a PGP-aware replacement for the standard Sun Workstation mailtool program, with a similar user interface and automagick support for PGP-signing and PGP-encryption. Just to make things clear, I have written this program from scratch, it is *not* a modified mailtool (and I'd hope that the Sun program code is much cleaner than mine 8-) !). When the program starts up, it displays a list of messages in your mailbox, along with flags to indicate whether messages are signed or encrypted, and if they have had their signatures verified or have been decrypted. When you double click on a message, it will be decrypted (requesting your passphrase if neccesary), and/or will have the signature checked, and the decrypted message will be displayed in the top part of the display window, with signature information in the bottom part. The mail header is not displayed, but can be read by pressing the 'Header' button to display the header window. In addition, the program has support for encrypted mailing list feeds, and if the decrypted message includes another standard-format message it will replace the original message and be fed back into the display processing chain. When composing a message or replying to one, the compose window has several check-boxes, including one for signature, and one for encryption. If these are selected, then the message will be automatically encrypted and/or signed (requesting your passphrase when neccesary) before it is sent. You may also select a 'Remail' box, which will use the Mixmaster anonymous remailer client program to send the message through one or more remailers. Being an Beta release, there are a number of bugs and unimplemented features. Known Bugs: None reported. Unimplmented features: When you save changes to the mail file, it throws away the signature verification and decrypted messages, so that the next time you view a message it has to be verified or decrypted again. Currently if you send encrypted mail to multiple recipients, all must have valid encrpytion keys otherwise you will have to send the message decrypted. Also, the message will be sent encrypted to all users, not just the one who is receiving each copy. Code should be more modular to assist with ports to Xt, Motif (under way), Mac, Windows, etc. I may port it to C++ in the near future. Not very well documented! Encrypted messages are saved to mail files in encrypted form. There is currently no option to save messages in decrypted form. No support for anonymous return addresses. Not very well tested on Solaris 2.x, or SunOS. No support for attachments (either Sun, uuencode or MIME). Changes for 0.87: Added support for signature files. Solaris patches for 0.86 from Glenn Trigg -- as usual a few bugs crept in because I couldn't test it on all operating systems. Added Vincent Cojot's (coyote(a)step.polymtl.ca) new icons for Linux. Some versions of Unix are set up to have mail programs setgid mail, and give write access to /usr/spool/mail only to mail and root. This caused hangs when saving changes. I've now incorporated changes which allow Linux to run privtool setgid mail, and these should work on FreeBSD. Fixed a number of compile-time warnings. Only display the compose window *after* it's been filled with data. This should prevent the time-consuming scrolling update which used to occur. Allow the user to specify the organization in their header. Changes for 0.86: Optionally use /dev/audio to supplement the random number generation code. Anders Baekgaard fixed a few bugs that sneaked in at the last minute, updating the header window, parsing dates, compose window layout, and SEGV when tabbing between fields on the compose window. Gregory Margo (gmargo(a)newton.vip.best.com) provided multiple display windows. Tony Gialluca (tony(a)hgc.edu) made some of the compose window buttons work. Fixed some file descriptor leaks in pgplib.c. On Linux we now read the contents of a number of files under /proc, and use these as an additional source of random data (e.g. /proc/interrupts, /proc/meminfo). Added 'Reseed Random' menu option, which will reseed the random number generator at any time. If possible this will come from the audio device and/or the /proc files. Added FreeBSD patch from Stuart Arnold (sja(a)epo.e-mail.com) See README.FREEBSD for more information. No longer destroy compose windows when you select 'Done'! Graphical properties window added. I've lost the address of the person who did the original work, so if it was you then please contact me! This was expanded and incorporated into 0.86 by Scott Cannon (rscott(a)silver.cal.sdl.usu.edu) Fixed memory corruption in pgplib.c. Limited support for secret keys on floppy disks. Allow users to specify their domain name and reply-to: header lines. Privtool can be compiled to either use PGP Tools, or to fork off a copy of PGP whenever it is needed. There are also a number of different security level options for the passphrase, varying from 'read it from PGPPASS and keep it in memory' to 'request it every time and delete it as soon as possible', via 'request it when neccesary and delete it if it's not used for a while'. I've now patched PGP Tools for Linux. The code is available on utopia.hacktic.nl as pgptools.linux.1.0.tar.gz. See the README file for information on compiling the code, and the user.doc file for user documentation (the little that currently exists). You should also ensure that you read the security concerns section in user.doc before using the program. Mark Grant (mark(a)unicorn.com) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBMr0+o1VvaTo9kEQVAQEfiQf6A1ZKDVijf/65NXDTVvsMw9G3nmjqNK4F mrIJiyoWr3KX66SbC6nSfWKtpjjZFi2R0633BGNA2kVqCpyk5F5UXTZMAXYzVhP6 f9drmWOsThdh07vpVuK2W96W/cpPh3m+Jhzp2pDpUWN0MNgX6ZmNsJzoSng8DmK9 YTERh93ZQ7rrBM6mMsz6ASEzpcu5grH0teAQdbvWHYEguwDn2K2hn1oTcuVXw74C UFDmx5I86Flfk0nfahldefHO5aSI4fSe+bs7vrZdIRVK60YSxw1dIFYv89bGJAQZ AfZxchmbMVtTBgI4/B1Lziqr/EJ1QI9+FH+LA7XQSmSWm0QFi5Rz9A== =6g9Z -----END PGP SIGNATURE----- "[Hollywood's] way is so slow and expensive that you'll find yourself falling asleep on the set and forgetting to say 'action'." - Robert Rodriguez, 'The Ten Minute Film School' |-----------------------------------------------------------------------| |Mark Grant M.A., U.L.C. EMAIL: mark(a)unicorn.com | |WWW: http://www.c2.org/~mark MAILBOT: bot(a)unicorn.com | |-----------------------------------------------------------------------|

2 1

Re: Blowfish Performance
by edgarswank＠juno.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- David Stoler recently commented: >I ftp'd the Blowfish implementation from ftp.ox.ac.uk and ran some >benchmarks. > >Encryption and decryption are faster than the fastest DES implementation >I've found, but the key expansion (subkey generation) is slow. > >On a 100 Mhz PowerPC I get the following results: > >Key expansion: >350 keys per second = 3.33 milliseconds per key > >Encryption/Decryption: >190,000 8 byte blocks per second = 5.26 microseconds per block > >This is 40% faster (encryption/decryption) than the best DES I have. > >Questions: >... >3. Is there a way to improve key expansion performance for applications >that change keys frequently? (Other than caching expanded keys...) Actually this (slow key expansion) is a feature. It limits the speed of a brute-force attack, since each new key to be tried must be expanded. What applications need to change keys more than once a second? I'd also be interested in comparisons of Blowfish to IDEA. Edgar W. Swank <EdgarSwank(a)Juno.com> (preferred) Edgar W. Swank <Edgar_W._Swank(a)ilanet.org> Edgar W. Swank <EdgarSwank(a)Freemark.com> Home Page: http://members.tripod.com/~EdgarS/index.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMr4fSt4nNf3ah8DHAQHycwP7BWTgyHVVZrtEhlMQKmSFFQGcMKqxaa5V y7D0OSVGTuddkwFDsVR7Qt3YGV0q3sMWbXFbicn2R/25rBbFNzA8d2rdgIxJVEzZ 0uKb1xdWkVR7GLIlQDciQW/zdQxdXjkiQ9sVbUJtPwYzUdZt6us3Izac1FZ4fKAX mvlqa4yWG58= =Tmc6 -----END PGP SIGNATURE-----

1 0

HIH_and
by John Young 17 Dec '03

17 Dec '03

12-21-96: "In Encryption Politics, Some Good News for Bankers" "Everyone knows that DES is not enough," said Perry Metzger. This dispute places the banking and financial services community squarely in opposition to government intelligence agencies with which it has historically worked hand in hand on security matters. "The Feds won't realize export controls don't work even after the dried, strangled corpse of the U.S. security software industry is laid before the Congress," Mr. Metzger said. "They will leave the manacles on the corpse long after it is obvious that the body isn't going anywhere." "Central Banks' Task Force Sees No Need for Alarm" While the security architectures of most electronic money systems share many design features, a wide range of options is available to product developers in terms of specific chip-card security measures, cryptographic algorithms, key lengths, and transaction monitoring. "SPA Voices Concerns Over Clinton Encryption Policy" In a letter last week to Vice President Al Gore, SPA raised several concerns that the software industry has with the administration's interim rules on encryption policy. "NSA/ On The Costs of Anonymity" "How to Make a Mint: The Cryptography of Anonymous Electronic Cash" has been making the rounds of the electronic money community. It raises security and law enforcement concerns about anonymous systems designed like Digicash Inc.'s Ecash. ----- HIH_and (25 kb)

1 0

MERRY CHRISTMAS
by BJORN2LUZE＠prodigy.com 17 Dec '03

17 Dec '03

cypherpunks(a)toad.com I am getting into the HOLIDAY SPIRIT with MY WEB PAGE: http://pages. prodigy.com/VT/hackersguide Enjoy! Fifthnail

1 0

RE: Legality of requiring credit cards?
by Mike Topalovich 17 Dec '03

17 Dec '03

> > Not always true. > > Go shopping with a wad of $100.00 bills. Most stores don't > accept them, regardless of the amount of purchase, without > additional ID. > > Try buying a new car, paying for it with $100.00 bills. > You might enjoy filling out the paperwork that is required > to do so. > It's not necessarily because you are paying with $100 bills. The IRS requires banks and other businesses to report all cash transactions exceeding $10,000 by means of a Currency Transaction Report (CTR). This is a way for the IRS to track money laundering. There happens to be two lines on the form asking for the number of $50 and $100 bills, but those lines are optional. Mike topalovich(a)terraglyph.com >

2 1

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk mix pgp hash latent cut ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle ?"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"death"} = "<x(a)deathsdoor.com> cpunk pgp hash latent post"; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix) (weasel squirrel) The alpha and nymrod nymservers are down due to abuse. However, you can use the nym or weasel (newnym style) nymservers. The cyber nymserver is quite reliable for outgoing mail (which is what's measured here), but is exhibiting serious reliability problems for incoming mail. The squirrel and winsock remailers accept PGP encrypted mail only. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. This seems to be fixed now. The penet remailer is closed. Last update: Mon 23 Dec 96 6:49:12 PST remailer email address history latency uptime ----------------------------------------------------------------------- extropia remail(a)miron.vip.best.com ._____.- 60:10:34 95.00% mix mixmaster(a)remail.obscura.com ++*.-*++- 5:25:14 71.83% dustbin dustman(a)athensnet.com ++..++--+ 2:13:28 67.50% nym config(a)nym.alias.net *#+..+### 1:20:12 67.08% cyber alias(a)alias.cyberpass.net **+**+* * 33:27 67.01% replay remailer(a)replay.com +*+- +++- 33:30 66.29% reno middleman(a)cyberpass.net --------- 2:26:15 65.86% exon remailer(a)remailer.nl.com ##* * **+ 3:12 65.36% middle middleman(a)jpunix.com -------- 2:43:49 65.05% balls remailer(a)huge.cajones.com ********* 12:37 64.91% haystack haystack(a)holy.cow.net *-++*#** 5:07 64.87% lucifer lucifer(a)dhp.com +++++++++ 34:36 64.70% winsock winsock(a)rigel.cyberpass.net -..----- 5:29:44 63.62% weasel config(a)weasel.owl.de ++ +-++- 1:29:46 57.96% squirrel mix(a)squirrel.owl.de ++++-+++ 1:27:45 57.55% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

RE: [NOT NOISE] Microsoft Crypto Service Provider API
by Blake Coverett 17 Dec '03

17 Dec '03

jim bell wrote: > Even if, arguably, once-imported software becomes subject to ITAR, it is by > no means clear that a "signature" is in any way controlled by ITAR. After > all, looked at generously, the "signature" might simply be a plaque or paper > certificate, saying "this is wonderful software!" The signature in question (on a Win32 Crypto Service Provider) is embedded in the executable. Certainly I could rip it out and inject it into an unsigned but otherwise identical copy outside the U.S., but that is obviously not going to be legal under ITAR. ITAR is wrong and should be abolished, but that sort of weasling isn't going to make something legal under the current laws. --- More interesting would be the OS patch that allows an unsigned (or signed by someone other than MS) CSP to be loaded... Hmm, logically the patch must be built in and only need to be switched on as it would be too annoying to debug a CSP if you needed to get it signed every time you built a new version. Microsoft's Authenticode system had such a patch at one time for just that purpose, and all it required was a registry setting. regards, -Blake (off to grep around inside some binaries)

2 1

~digicash at Shell
by Brad Dolan 17 Dec '03

17 Dec '03

Shell is now marketing a stored-value card in $25, $50, and $100 face denominations. The $100 card retails for $94 right now. I'm not sure if that discount will be a long-term thing or if it's just to get people hooked. Anyway, the card can be purchased anonymously for cash and can be used to buy anything at Shell. I like to use the automated pay-at-the-pump gizmos to save time but I don't like to leave a digital footprint behind on my credit card statement for Louis' Legions to peruse, so I think the stored-value card is a step forward for privacy. Anybody know if these cards are useable overseas? bd

2 2

Lack of security of police Mobile Data Terminals (MDTs)
by Dave Emery 17 Dec '03

17 Dec '03

Some months ago I posted an article to cypherpunks commenting on how easy it is to intercept the supposedly secret traffic on the Motorola mobile data terminals used by many police forces to access criminal history and other sensitive information. This data is not seriously encrypted (or encrypted at all in most systems) and illustrates the kind of security by obscurity that some people would like to see continue as the only protection for such information as it is broadcast to the world on open radio channels. Apparently someone saw my comments or had similar thoughts and today I found the following article posted to alt.radio.scanner. I do not know who the author is, and I did not write the article myself - but I think the article may interest some members of the list as it illustrates what civilian cryptography would be like if the NSA had its way... Dave Emery N1PRE die(a)die.com DIE Consulting Weston Mass. ----------------------- Begin quoted article ---------------------- >From lord(a)heaven.com Mon Dec 23 23:11:43 EST 1996 Article: 44420 of alt.radio.scanner Xref: world alt.radio.scanner:44420 Path: world!blanket.mitre.org!news.tufts.edu!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!newsfeed.internetmci.com!news.ro.com!news From: lord <lord(a)heaven.com> Newsgroups: alt.radio.scanner Subject: MDT stuff Date: Mon, 23 Dec 1996 16:04:39 -0600 Organization: screw Lines: 765 Message-ID: <32BF01F6.2742(a)heaven.com> Reply-To: lord(a)heaven.com NNTP-Posting-Host: ts2p5.ro.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; name="Mdt.txt" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (Win95; I) Content-Disposition: inline; filename="Mdt.txt" Greetings one and all, Have you ever lusted to decode Mobile Data Terminal (MDT) tranmissions? Have you ever wanted to see the same NCIC and motor vehicle information that law enforcement officers see? Have you ever wanted to see what officers send to each other over "private" channels? And all this with an interface you can build with only a few dollars worth of parts from your local radio shack? If so this posting might be your rendevous with destiny. The tail end of this posting includes the source code of a program that decodes and displays MDT messages. It stores roughly 30k of messages in a buffer and then writes the whole buffer to a file called "data.dat" before terminating. The program may be interrupted at any time by pressing any key (don't use control-c) at which point it writes the partially filled buffer to "data.dat". This program only works for systems built by Motorola using the MDC4800 tranmission protocol. This accounts for a large fraction of public service MDT systems as well other private systems. The existence of this program is ample evidence that Motorola has misrepresented its MDT systems when it marketed them as a secure means of communcications. The interested reader will soon discover that these systems do not use any form of encryption. Security concerns instead have been dealt with by using a code. "And what might this code be called?" asks the reader. The code turns out to be plain ASCII. What follows is a brief description of how the program and the MDC4800 protocol work. If you don't understand something go to your local library and check out a telecommunications theory book. 1. The raw transmission rate is 4800 baud. The program's interrupt service routine simply keeps track of the time between transitions. If you're receiving a perfect signal this will be some multiple of 1/4800 seconds which would then give you how many bits were high or low. Since this is not the best of all possible worlds the program instead does the following: transitions are used to synchronize a bit clock. One only samples whenever this clock is in the middle of the bit to produce the raw data stream. This greatly reduces jitter effects. 2. Whenever a tranmitter keys up the MDC4800 protocol calls for bit synchronization (a sequence of 1010101010101010....). In the program this will result in receive bit clock synchronization. There is no need to specifically look for the bit sync. 3. Look for frame synchronization in raw bit stream so that data frames can be broken apart. Frame synchronization consists of a 40 bit sequence : 0000011100001001001010100100010001101111. If this sequence is detected (or 35 out of 40 bits match up in the program) the system is idling and the next 112 bit data block is ignored by the program. If the inverted frame sync is detected one immediately knows that 112 bit data blocks will follow. 4. Receive the 112 bit data block and undo the bit interleave. This means that one must reorder the bits in the following sequence : {0,16, 32,48,64,80,96,1,17,33,49,65,81,97,2,18,34,...} if the orignal sequence were received as {0,1,2,3,4,5,6,7,8,...}. 5. Check the convolutional error correcting code and count the number of errors. The error correcting code is rate 1/2 which means we will be left with 56 data bytes. The encoder is constructed so that the output consists of the original data bits interspersed with error correcting code. The generating polynomial used is : 1 + X^-1 + X^-5 + X^-6 Whenever an error is detected a counter is incremented. An attempt is made to correct some errors by finding the syndrome and looking for the bogus bit. 6. Keep receiving 112 bit data blocks until either a new frame sync is found or two consecutive data blocks have an unacceptably large number of errors. 7. Each data block consists of six data bytes; the last 8 bits are status bits that are simply ignored. The program shows the data in two columns - hexadecimal and ASCII. This data is kept in a buffer and is written to the file "data.dat" when the program terminates. 8. What the program doesn't do: As a further check on the data there can be CRC checks. This varies from protocol to protocol so this program does not implement the CRC checks. Nonetheless, it is a relatively trivial matter to find the generating polynomial. The addresses, block counts, and message ID numbers are also quite easy to deduce. As you can see, there is no encryption. The bit interleave and the error correcting coding are there solely to insure the integrity of the ASCII data. Since any moron could have figured this stuff out from scratch one could argue that MDTs do not use "...modulation parameters intentionally witheld from the public". Therefore the Electronic Communications Privacy Act may not prohibit receiving MDT tranmissions. However, consult your attorney to make sure. The total disregard for security will no doubt annoy countless Motorola customers who were assured that their MDT systems were secure. Since Federal law states that NCIC information must be encrypted your local law enforcement agency might be forced to spend millions of dollars to upgrade to a secure MDT system - much to the delight of Motorola and its stockholders. Cynics might conclude that the release of a program like this is timed to coincide with the market saturation of existing MDT systems. Also, this program is completely free and it had better stay that way. What's to prevent you from adapting this into a kit and selling it >from classified ads in the back of Nuts and Volts? Nothing. But take a look at Motorola's patents sometime. You'll notice that this program does things that are covered by a shitload of patents. So any attempt to take financial advantage of this situtation will result in utter misery. Please keep the following in mind: this program only works with the first serial port (COM1). If your mouse or modem is there too bad. If you don't like this rewrite the program. ------------------------------------------------------------------------ What equipment do I need? RADIO SCANNER: A scanner that can receive 850-869 MHz. For those of you who don't know, this is the band where most business and public service trunked radio systems can be found along with the mobile data terminal transmissions. Chances are excellent that if your local authorities have a motorola trunked radio system and mobile data terminals that this is the frequency band in use. Very rarely will one find mobile data terminals in other frequency bands. Now for the fun part - your scanner should probably be modified to allow you to tap off directly from the discriminator output. If you wait until the signal has gone through the radio's internal audio filtering the waveform will likely be too heavily distorted to be decoded. This is exactly the same problem that our friends who like to decode pager transmissions run into - some of them have claimed they can only decode 512 baud pager messages using the earphone output of their scanner. These mobile data terminal messages are 4800 baud so I don't think you have a snowball's chance in hell without using the discriminator output. If you don't know where to begin modifying your scanner you might want to ask those who monitor pagers how to get the discriminator output for your particular radio. COMPUTER/SCANNER INTERFACE Those of you who have already built your interface for decoding pager messages should be able to use that interface without any further ado. For those starting from scratch - you might want to check out packages intended for pager decoding such as PD203 and the interfaces they describe. The following excerpt gives an example of a decoder that should work just fine (lifted out of the PD203 POCSAG pager decoder shareware documentation): > > 0.1 uF |\ +12v > ---||-----------------------|- \| > AF IN | |741 \ > ---- | | /--------------------- Data Out > | \ ------|+ /| | CTS (pin 5/8) > | / 100K | |/-12v | or DSR (pin 6/6) > | \ | | > GND / ----/\/\/\---- GND ------ GND (pin 7/5) > | | 100K > | \ N.B. Pin Numbers for com port are > GND / given as x/y, where x is for a 25 > \ 10K way, y for a 9 way. > / > | > GND > > The above circuit is a Schmitt Trigger, having thresholds of about +/- 1v. > If such a large threshold is not required, eg for a discriminator output, > then the level of positive feedback may be reduced by either reducing the > value of the 10K resistor or by increasing the value of the 100K feedback > resistor. > > The +/- 12v for the op-amp can be derived from unused signals on the COM > port (gives more like +/- 10v but works fine !):- > > > TxD (2/3) --------------|<-------------------------------------- -12v > | | > RTS (4/7) --------------|<-------- GND - - > | | _ + 10uF > --------->|------- - - | > Diodes 1N4148 | - + 10uF GND > | | > DTR (20/4) ------------->|-------------------------------------- +12v > If I were building this circuit I would strongly suggest tying the non-inverting (+) input of the op-amp to ground since you are working directly with the discriminator output and don't need a Schmitt trigger. All these parts or equivalents are easily available (even at your local Radio Shack which stocks the finest collection of components that have failed the manufacturer's quality control checks and supported by a sales staff that's always got the wrong answers to your questions). Also: DO NOT use the RI (ring indicator) as an input to the computer. ------------------------------------------------------------------------- How do I check things? As a first step, I would get a package such as PD203 and use it to decode a few pages. If you can get that working you know that that your interface circuit is functioning correctly. If you are in a reasonably sized town you might be part of the ardis network. The ardis network is a nationwide commercial mobile data terminal network where one can send/receive E-mail messages from one's portable computer. It has been exclusively assigned the frequency of 855.8375 MHz. Therefore, if you can hear digital bursts on this frequency you are basically guarranteed that these are MDC4800 type messages. You should be able to get stuff popping up on your screen although a lot of the messages will not be plain english. If your interface works but you can't seem to get any messages on the screen for a channel you know is a Motorola MDT system then it might be possible that your scanner/interface is putting out data with the polarity reversed. To check for this run the program with a command line arguement. When it runs you should an initial "Polarity reversed" message and hopefully then things will work out for you. Other than that: if this program doesn't work pester someone else who has got it working. Don't bother pestering the author(s) of this posting; the shit(s) aka "she/he/it (s)" are afraid of a thousand lawyers from Motorola descending like fleas to infest their pubic hair and accordingly have decided to remain forever anonymous. No doubt someone on the usenet who sees this post will know what to do with this program and also hopefully rewrite into a more user friendly form. When you do please don't forget to release the source code. ------------------------------------------------------------------------- Future projects/nightmares you might want to think about: Certain MDT systems embed formatting information in the text in the form of ESC plus [ plus a few more bytes. Someone might want to decode these on the fly and format the output so it looks exactly the same way as the user sees it. Make it so that this program works with com ports other than COM1. Make it user friendly? Enlarge the data buffer from the current 30k. Give the output data file an unique name each time the program is run instead of "data.dat". How about sorting through the past traffic so that you only see traffic to a specified user? The program does not cut data blocks off in the display but it might add an extra one or two (which will display as all zeroes). Someone might want to make all those zeroes be shown as blanks instead. Write some real instructions. Now the more ambitous stuff: Are you half-way competent with RF engineering? Then listen in to the tranmissions from the mobile units back to the base station. That way you get everyone's password and user IDs as they log on to the MDT system. By this point you will no doubt have been able to figure out all of the appropriate communications protocols so you should think about getting your own transmitter up and running along with the necessary program modifications so that you can transmit MDT messages. The required transmitter can be very simple - for example, those masocists who want to start from scratch might want to special order an appropriate crystal (pulling the frequency with the computer's tranmit signal), building a frequency multiplier chain, and adding a one watt RF amplifier to top it all off (see the appropriate ARRL publications for more information on radio techniques). Now you can log in and look at the criminal records and motor vehicle information on anybody you can think of. Find out what your neigbors are hiding. Find out who that asshole was that cut you off downtown. Find out where your former girl/boy friend is trying to hide from you. And on and on... Those with simpler tastes might want to simply transmit at the base station's frequency to any nearby MDT terminal - now you too can dispatch your local law enforcement agencies at the touch of your fingers!!! See your tax dollars at work tearing apart every seam of your neighbor's house. Or create strife and dissension in your local law enforcement agency as more and more officers come out of the closet using their MDTs trying to pick up fellow officers. There are municipalities that have put GPS receivers on all of their vehicles. Should it happen that the information is sent back over one of these networks you could have your computer give you a real-time map showing the position of every vehicle and how far away they are from you. Extend your knowledge to other data networks. Here you will want to look at the RAM mobile data network. It uses the MOBITEX protocol which is really easy to find information on. Since it is an 8 kilobaud GMSK signal there is a decent chance that you can use the interface described here. This transmission mode demmands much more from your equipment than MDT tranmissions. At the very least you must be much more careful to make sure you have adequate low frequency response. Despite this it is possible to receive and decode MOBITEX transmissions with a simple op-amp circuit! This just goes to show you what drivelling bullshit RAM's homepage is filled with - they explain in great detail how hackers will never be able to intercept user's radio tranmissions (incidentally explaining how to decode their tranmissions). The necessary program will be the proverbial exercise left for the reader. For better performance buy a dedicated MOBITEX modem chip and hook it up to your computer. ----------------------------------------------------------------------- A few words about the program: Remember - you must have your decoder hooked up to COM1. The RTS line will be positive and the DTR line negative but if you built the decoder with a bridge rectifier you really don't have to worry about their polarity. Stop the program by punching any key; don't use control-c or control-break! If you must reverse polarity run the program with any command line arguement (example: type in "mdt x" at the command line if your program is mdt.exe). You should then see the "Polarity Reversed." message pop up and hopefully things will then work. As far as compiling this - save the latter portion of this posting (the program listing) and feed it to a C compiler. Pretty much any C compiler from Borland should work. If you (Heaven Forbid) use a Microsoft C compiler you might need to rename some calls such as outport. Follow any special instructions for programs using their own interrupt service routines. This program is not object oriented. It also does not want anything whatsoever to do with Windows. Please don't even think about running this program under Windows. Finally, here it is: Good Luck and may God be with you! ---------------------- C u t H e r e ! ! ! -------------------------- /* start of program listing */ #include <stdio.h> #include <conio.h> #include <dos.h> #include <math.h> /* Purpose of program: receive messages using the Motorola MDC4800 */ /* protocol and show them on the screen */ /* */ /* WARNING TO ALL : This program is free. Please distribute and modify*/ /* this program. I only request that you always include the source */ /* code so that others may also learn and add improvements. The */ /* status of this program at the time of the original release is : */ /* it doesn't have much in the way of a user interface or options but */ /* it should work if you follow the procedure in the text file. Don't */ /* expect any sort of support (you get what you pay for - nothing in */ /* this case). Finally, here's a special message to all of you who */ /* might have the urge to try to make money with this information: */ /* I know where you live. I will shave your pets and pour rubbing */ /* alcohol all over them (unless said pet happens to be a Rottweiler).*/ /* I will have sex with your wife while you off at work; on the rare */ /* occasions when you have sex with your wife she will in the throes */ /* of passion cry not your name but mine. I will sell drugs to the */ /* demented spawn you refer to as your children. And if that's not */ /* enough for you let a thousand lawyers from motorola descend on you */ /* and pound your fat rear end so far into the ground that it finally */ /* sees daylight again somewhere in Australia. */ /* */ /* */ /* General tidbits (a few of those "Why were things done this way */ /* questions). */ /* 1. Why is captured data kept in an array and only written to a */ /* disk file at the very end? Because disk access seems unreliable */ /* when so much time is taken up by the background interrupt service */ /* routine. */ /* 2. Why is the array storing this so small? Because yours truly was */ /* too damn lazy to use a pointer and allocate a huge chunk of memory.*/ /* (Hint for those of you who would like to improve this. */ /*--------------------------------------------------------------------*/ /* global variables */ int lc=0; char fob[30000];/* output buffer for captured data to be sent to disk */ int foblen=29900; int fobp=0; /* pointer to current position in array fob */ char ob[1000]; /* output buffer for packet before being sent to screen */ int obp=0; /* pointer to current position in array ob */ static unsigned int buflen= 15000; /* length of data buffer */ static volatile unsigned int cpstn = 0; /* current position in buffer */ static unsigned int fdata[15001] ; /* frequency data array */ void interrupt (*oldfuncc) (); /* vector to old com port interrupt */ /**********************************************************************/ /* this is serial com port interrupt */ /* we assume here that it only gets called when one of the status */ /* lines on the serial port changes (that's all you have hooked up). */ /* All this handler does is read the system timer (which increments */ /* every 840 nanoseconds) and stores it in the fdata array. The MSB */ /* is set to indicate whether the status line is zero. In this way */ /* the fdata array is continuously updated with the appropriate the */ /* length and polarity of each data pulse for further processing by */ /* the main program. */ void interrupt com1int() { static unsigned int d1,d2,ltick,tick,dtick; /* the system timer is a 16 bit counter whose value counts down */ /* from 65535 to zero and repeats ad nauseum. For those who really */ /* care, every time the count reaches zero the system timer */ /* interrupt is called (remember that thing that gets called every */ /* 55 milliseconds and does housekeeping such as checking the */ /* keyboard. */ outportb (0x43, 0x00); /* latch counter until we read it */ d1 = inportb (0x40); /* get low count */ d2 = inportb (0x40); /* get high count */ /* get difference between current, last counter reading */ tick = (d2 << 8) + d1; dtick = ltick - tick; ltick = tick; if ((inportb(0x3fe) & 0xF0) > 0) dtick = dtick ^ 0x8000; else dtick = dtick & 0x3fff; fdata[cpstn] = dtick; /* put freq in fdata array */ cpstn ++; /* increment data buffer pointer */ if (cpstn>buflen) cpstn=0; /* make sure cpstn doesnt leave array */ d1 = inportb (0x03fa); /* clear IIR */ d1 = inportb (0x03fd); /* clear LSR */ d1 = inportb (0x03fe); /* clear MSR */ d1 = inportb (0x03f8); /* clear RX */ outportb (0x20, 0x20); /* this is the END OF INTERRUPT SIGNAL */ /* "... that's all folks!!!!" */ } void set8250 () /* sets up the 8250 UART */ { static unsigned int t; outportb (0x03fb, 0x00); /* set IER on 0x03f9 */ outportb (0x03f9, 0x08); /* enable MODEM STATUS INTERRUPT */ outportb (0x03fc, 0x0a); /* push up RTS, DOWN DTR */ t = inportb(0x03fd); /* clear LSR */ t = inportb(0x03f8); /* clear RX */ t = inportb(0x03fe); /* clear MSR */ t = inportb(0x03fa); /* clear IID */ t = inportb(0x03fa); /* clear IID - again to make sure */ } void set8253() /* set up the 8253 timer chip */ { /* NOTE: ctr zero, the one we are using*/ /* is incremented every 840nSec, is */ /* main system time keeper for dos */ outportb (0x43, 0x34); /* set ctr 0 to mode 2, binary */ outportb (0x40, 0x00); /* this gives us the max count */ outportb (0x40, 0x00); } /****************************************************************/ int pork(int l) { static int s=0,sl=0x0000,t1,asp=0,ll,k,v,b,tap,synd=0,nsy; static char line[200]; /* array used to format 112 bit data chunks */ static int lc=0; /* pointer to position in array line */ if (l == -1) { /* printf (" %2i\n",asp); */ sl = 0x0000; s = 0; synd = 0; if ((asp <12) && (lc > 50)) { ll = 12 - asp; for (ll=0; ll<6; ll++) { v = 0; for (k=7; k>=0; k--) { b = line[ (ll<<3) +k ]; v = v << 1; if ( b == 49) v++; } ob[obp] = (char) v; if (obp < 999) obp++; } } lc = 0; tap = asp; asp = 0; return(tap); } else { s++; if (s==1) { line[lc] = (char) l; lc++; } /* update sliding buffer */ sl = sl << 1; sl = sl & 0x7fff; if (l == 49) sl++; if (s >1) { s = 0; if ((sl & 0x2000) > 0) t1 = 1; else t1 = 0; if ((sl & 0x0800) > 0) t1^=1; if ((sl & 0x0020) > 0) t1^=1; if ((sl & 0x0002) > 0) t1^=1; if ((sl & 0x0001) > 0) t1^=1; /* attempt to identify, correct certain erroneous bits */ synd = synd << 1; if (t1 == 0) { asp++; synd++; } nsy = 0; if ( (synd & 0x0001) > 0) nsy++; if ( (synd & 0x0004) > 0) nsy++; if ( (synd & 0x0020) > 0) nsy++; if ( (synd & 0x0040) > 0) nsy++; if ( nsy >= 3) /* assume bit is correctable */ { printf ("*"); synd = synd ^ 0x65; line[lc - 7] ^= 0x01; /**********************************************/ } } } return(0); } void shob() { int i1,i2,j1,j2,k1; /* update file output buffer */ i1 = obp / 18; if ( (obp-(i1*18)) > 0) i1++; fob[fobp] = (char) (i1 & 0xff); if (fobp < 29999) fobp++; for (i2 = obp; i2<=(obp+20); i2++) ob[i2] = 0; for (j1 = 0; j1 < i1; j1++) { for (j2 = 0; j2 < 18; j2++) { k1 = j2 + (j1*18); printf("%02X ", ob[k1] & 0xff); fob[fobp] = (char) (ob[k1] & 0xff); if (fobp < 29999) fobp++; } printf (" "); for (j2 = 0; j2 < 18; j2++) { k1 = j2 + (j1*18); if (ob[k1] >=32) printf("%c",ob[k1]); else printf("."); } printf("\n"); } obp=0; printf("BUFFER: %3i percent full\n",(int)(fobp/299.0)); } /**********************************************************************/ /* frame_sync */ /**********************************************************************/ /* this routine recieves the raw bit stream and tries to decode it */ /* the first step is frame synchronization - a particular 40 bit */ /* long sequence indicates the start of each data frame. Data frames */ /* are always 112 bits long. After each 112 bit chunk this routine */ /* tries to see if the message is finished (assumption - it's finished*/ /* if the 40 bit frame sync sequence is detected right after the end */ /* of the 112 bit data chunk). This routine also goes back to hunting */ /* for the frame sync when the routine processing the 112 bit data */ /* chunk decides there are too many errors (transmitter stopped or */ /* bit detection routine skipped or gained an extra bit). */ /* */ /* inputs are fed to this routine one bit at a time */ /* input : 48 - bit is a zero */ /* 49 - bit is a 1 */ void frame_sync(char gin) { static unsigned int s1=0,s2=0,s3=0,nm,j,t1,t2,t3,ns=0,st=0,n,m,l,chu=0,eef=0; static char ta[200]; if (st == 1) { ta[ns] = gin; ns++; if (ns >= 112) /* process 112 bit chunk */ { chu++; ns = 0; for (n= 0; n<16; n++) { for (m=0; m<7; m++) { l = n + (m<<4); pork(ta[l]); } } if (pork(-1) > 20) eef++; else eef=0; if (eef > 1) /* if two consecutive excess error chunks - bye */ { st = 0; shob(); eef = 0; } /* else eef = 0; */ } } /* s1,s2,s3 represent a 40 bit long buffer */ s1 = (s1 << 1) & 0xff; if ((s2 & 0x8000) > 0) s1++; s2 = (s2 << 1); if ((s3 & 0x8000) > 0) s2++; s3 = (s3 << 1); if (gin == 49) s3++; /* xor with 40 bit long sync word */ t1 = s1 ^ 0x0007; t2 = s2 ^ 0x092A; t3 = s3 ^ 0x446F; /* find how many bits match up */ /* currently : the frame sync indicates system id / idling / whatever */ /* inverted frame sync indicates message follows */ nm = 0; for (j=0; j<16; j++) { if (t1 & 1) nm++; if (t2 & 1) nm++; if (t3 & 1) nm++; t1 = t1 >> 1; t2 = t2 >> 1; t3 = t3 >> 1; } if (nm < 5) { st = 1; ns = 0; } else if (nm > 35) { if (st==1) { shob(); } st = 0; ns = 0; } } void main (int argc) { unsigned int n,i=0,j,k,l,cw1=49,cw0=48; FILE *out; char s=48; double pl,dt,exc=0.0,clk=0.0,xct; if (argc > 1) { printf ("Reverse Polarity.\n"); cw1 = 48; cw0 = 49; } /* dt is the number of expected clock ticks per bit */ dt = 1.0/(4800.0*838.8e-9); oldfuncc = getvect(0x0c); /* save COM1 Vector */ setvect (0x0c, com1int); /* Capture COM1 vector */ n = inportb (0x21); /* enable IRQ4 interrupt */ outportb(0x21, n & 0xef); set8253(); /* set up 8253 timer chip */ set8250(); /* set up 8250 UART */ while ((kbhit() == 0) && (fobp<29900)) { if (i != cpstn) { if ( ( fdata[i] & 0x8000) != 0) s = cw1; else s = cw0; /* add in new number of cycles to clock */ clk += (fdata[i] & 0x7fff); xct = exc + 0.5 * dt; /* exc is current boundary */ while ( clk >= xct ) { frame_sync(s); clk = clk - dt; } /* clk now holds new boundary position. update exc slowly... */ /* 0.005 sucks; 0.02 better; 0.06 mayber even better; 0.05 seems pretty good */ exc = exc + 0.020*(clk - exc); i++; if( i >buflen) i = 0; } } outportb (0x21, n); /* disable IRQ4 interrupt */ setvect (0x0c, oldfuncc); /* restore old COM1 Vector */ /* save captured data to disk file */ i = 0; out = fopen("data.dat","wt"); if (out == NULL) { printf ("couldn't open output file.\n"); exit(1); } i = 0; while ( (i < fobp) && (i < 29800)) { j = ((int)fob[i] & 0xff); i++; for (k=0; k<j; k++) { for (l=0; l<18; l++) { fprintf(out,"%02X ",((int) fob[i + l]&0xff)); } fprintf(out," "); for (l=0; l<18; l++) { n = ((int)fob[i]&0xff); i++; if (n >=32) fprintf(out,"%c",n); else fprintf(out,"."); } fprintf(out,"\n"); } fprintf(out,"\n"); } fclose(out); } /* end of program listing */

2 1

Re: the word is "NIGGAZ"
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

From: jlucas4(a)capital.edu (Jesse Lucas) >Actually the word is "niggus." >"Niggas" would be referring to other black fellows in a friendly way. > >More or less. > >Gangsta J Where does "coons" fit into this oh so intellectual discussion? Is this one of Dale's? Down Home

1 0

Re: Certified primes
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

From: lucifer(a)dhp.com (Anonymous) >Timmy `C' May is a certified sexual pervert who wears women's >underwear. Pardon, what does one have to do with the other? And who really gives a rat's ass anyway? Where is Logos now that we need him?

1 0

Re: One-time pads
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Timmy C. Mayo studied yoga back-streching exercises for five years so he could blow himself (nobody else will). /o)\ Timmy C. Mayo \(o/

1 0

RE: Legality of requiring credit cards? (fwd)
by James A. Tunnicliffe 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mike Gurski asks: > But that still doesn't answer whether or not a credit card can be > requested when paying by check. I believe it can be. Until a few years ago, it was common to request a credit card AND TO RECORD THE NUMBER ON THE CHECK. Legislation was enacted (this might have been just in California, I'm not sure) to prevent them from recording the number, but I believe it specifically allowed them to continue to ask to see that you have a card (they shouldn't need to see the number, so I believe you are within your rights to, say, obscure it with your thumb). Of course, they are (and should not be) under any obligation to accept your check in the first place, so I would think the ID they request would be up to them. Tunny ====================================================================== James A. Tunnicliffe | WWWeb: http://www.inference.com/~tunny Inference Corporation | PGP Fingerprint: CA 23 E2 F3 AC 2D 0C 77 tunny(a)Inference.com | 36 07 D9 33 3D 32 53 9C ====================================================================== -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: which I won in the PGP raffle at Cypherpunks 12/96... iQEVAgUBMr7n+/AmQsmyRPddAQFFGAf9EHlEKf4k3wuGfIQKV7ZKxHtgMwZi3MWf yzADHsHlLDo7c3fN4qPoMMsXh0odO5JDGjXKg+zJ+LhcuKaPjfe4mzHwYOxDD8fJ JxG6Gex1l9iNSOfqDIgrk+29DR5noMnpdBUwTkznBlm35y32ucxC1Spc/G8zqwdJ cyl/6oCuGAY+xvgHi30dnNHX1b+KcqihESm6huSQJkDMVb1ctp84aEzP894iHrnl aq4Kt8H174lj4ke0fwEaPT2SmGpnXLn+I9xw4sYlhCzMfMz3VEMIZCfmVDWI5OgM R1ktJJs9KM5jXSBA/fSZoRdD9FogwNSiaMEkQ1IRYA4EAQqJd8hOpw== =9xWW -----END PGP SIGNATURE-----

2 1

Papers Galore
by John Young 17 Dec '03

17 Dec '03

The NSA-hosted National Information Systems Security Conference, held in October, 1996, has made a wide range of papers available (in PDF format), and listed in: http://csrc.nist.gov/nissc/1996/papers/NISSC/toc.pdf (110kb) One panel's papers eye all-optical networks and security, including optical encryption, which NSA appears to be leading: http://csrc.nist.gov/nissc/1996/papers/NISSC/paper236/ Many others -- long and short, informative and fatuous -- address sizzling and old-grease sec issues -- techie, lawless, bad-hair-brained. Several archists cry cyber crime and plead for vigilance for on-line anarcho-ebonics: "Industrial Espionage Today and Information Wars Tomorrow." "Rise of the Mobile State: Organized Crime in the 21st Century." "Ethical and Responsible Behavior for Children to Senior Citizens in the Information Age." "Monitoring Your Employees: How Much Can You Do and What Should You Do When You Uncover Wrongdoing?" Despite such blow, there's much other solid reading. Take a nap while the PDFs glaciate in.

1 0

RE: Certified primes
by pclow 17 Dec '03

17 Dec '03

So? Are you jealous? >Timmy `C' May is a certified sexual pervert who wears women's >underwear.

1 0

Re: Privtool 0.87
by sbase 17 Dec '03

17 Dec '03

> From: Dr.Dimitri Vulis KOTM <dlv(a)bwalk.dm.com> > To: cypherpunks(a)toad.com > That's the kind of software we need. How about a PGP aware client for > Windows 95 and NT that would talk to POP3 and SMTP servers? Sort of > like a drop-in replacement for the mail programs that come with Netscape > and MS IE. Try here: http://www.eskimo.com/~joelm/pi.html

1 0

Re: Ebonics
by Matthew J. Miszewski 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 08:55 AM 12/23/96 -0500, Jeff Barber wrote: >I've never seen Tim "advocate the unemployment" of anyone or any group. Funny, did he stutter when he said he regularly *practiced* such discrimination at Intel? (Such discrimination being based upon Title VII's dispirate impact scenario, a law that Tim and others disregard as is their civic, as in civil disobedience, duty.) I guess he was unclear when he stated "Fuck 'em" in a follow up post. Tim is an anarchist (and I do not mean that in any derogatory way). He not only advocates, but he practices what he preaches. >He has merely argued that an employer should be free *not* to hire an >individual for any reason whatsoever. Such a reason might include his/her >language/dialect, appearance, race, gender, religion or any other >(arbitrary-to-an-outsider) criterion. This is a standard libertarian >position and shouldn't be too difficult to grasp. I think Tim's position was that if people couldnt communicate with him or his supervisors he would not recommend their hire. He had not stated as you did above, although I do not doubt it is his belief. > >-- Jeff > P.S. I have posted to rebut several political points made on the list only to show that some of us on the list do not agree with certain viewpoints. As Tim has pointed out, it has caused an innordinant amount of flame bait and our signal is getting lost. I do accept responsibility for setting some of the fires but will now attempt to reply only to highly-crypto-relevant material on the list. Apparently folks get too excited when others disagree with them. Matt -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMr73pbpijqL8wiT1AQHLQwP/U5jakb7Ed3Sm2GpxsbNYol549jitBpOX SI9D+cROf1jX2zz0iA6mXgwv/w9ywK5oranR7PMW7q5KB4yfy+rJQXhOLe/7Sbgp wEMu39iZ0pFgg1yjJlFS+X1kCOjC2AkniNrb5fyW/Ifk+R7iT/8a+hNN8R8rObdA RIDVj9xp5Jw= =iUqA -----END PGP SIGNATURE-----

3 3

Re: Legality of requiring credit cards?
by azur＠netcom.com 17 Dec '03

17 Dec '03

Merchants are free to adopt most any non-descrimatory policy insofar as transactions are concerned. If you want hassle-free shopping use legal tender (except for rentals, where a CC is most welcome). -Steve >-----BEGIN PGP SIGNED MESSAGE----- > >It's that wonderful season again, when all the assholes are out in >force, and people feel obligated to purchase merchandise to give to >each other. For various reasons, I don't believe in credit cards, and >yet, trying to pay for something by personal check at the local >Hecht's, they either *require* a credit card, or go through the Nazi >check-warranty company Equifax. However, it doesn't stop there...only >SOME departments seem to have this requirement (Electronics/Luggage >not requiring). Is it legal to require credit cards? > >|\/|ike Gurski mgursk1(a)umbc.edu http://www.gl.umbc.edu/~mgursk1/ >finger/mail subject "send pgpkey"|"send index" Hail Eris! -><- O- |Member, >1024/39B5BADD PGP Keyprint=3493 A994 B159 48B7 1757 1E4E 6256 4570 | Team >My opinions are mine alone, even if you should be sharing them. | OS/2 > Senate Finance Committee Chair, SGA 1996-1997 > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.2 >Comment: I am not a number, I am a free man! > >iQCVAwUBMr2dZiKEMrE5tbrdAQGNEwQAjxsj387SAbEQnGr+8j0z12cWpREK/Y8U >e5xCYMMwJ6J+rLip05nZ8uMHfY/anfGW5m2mMrvsVOggMh5Sv9Ljrw3u4uFl66B5 >yU3iU3couXIZx5Dv1QhGdOSZPRpIo7wZGwCGtF4z9TM+cUzEUzA8LMDgavG8fY0D >T+yrGuzhSzg= >=aQ97 >-----END PGP SIGNATURE-----

13 20

Re: [NOT NOISE] Microsoft Crypto Service Provider API
by jim bell 17 Dec '03

17 Dec '03

At 11:21 PM 12/22/96 -0800, geeman(a)best.com wrote: > >Software that is imported becomes subject to ITAR with respect to >re-exportation, of course (but of course IANALetc.) > >If you can't demonstrate to MSFT that you are >playing by the rules --such that you have the proper export papers >for your code if you plan to export it, for example-- they won't sign, >even if developed outside US. Except that it isn't clear that there are any enforceable "rules," particularly after the Patel decision. >So: you develop a CSP outside US ... you have to IMPORT it to get it signed. >It becomes subject at that point to ITAR export regs. Unless you demonstrate >that you fulfull those requirements, no signature. So there's no relief by >looking at just exporting the signature. You've stated a position, but you haven't supported it. It's the position you might expect the government to take, given its past behavior, but it isn't yet clear that this is the case. Even if, arguably, once-imported software becomes subject to ITAR, it is by no means clear that a "signature" is in any way controlled by ITAR. After all, looked at generously, the "signature" might simply be a plaque or paper certificate, saying "this is wonderful software!" Remember, no matter how long that signature it, it might just happen to be the same string as a compressed bit of data from some other source, etc. The signature might be 16 bits long, for all we know. In short, the "you can't export signatures" is simply more steps removed from the "you can't export crypto software." We have yet to see anybody attempt to enforce this. Jim Bell jimbell(a)pacifier.com

1 0

Re: Untraceable Payments, Extortion, and Other Bad Things
by jim bell 17 Dec '03

17 Dec '03

At 10:17 PM 12/22/96 -0800, Vladimir Z. Nuri wrote: >Timmy writes: >>Fortunately for the bulk of us, the likely number of deaths and economic >>losses from such crimes of kidnapping, extortion, and even murder for hire, >>is still likely to be vastly lower than the number of deaths caused by >>powerful central governments enriching themselves and their cronies with >>foreign wars. Not to mention the deaths in the Drug War, the lives wasted >>in other interferences in private behavior, etc. > >imho, it's a very warped kind of mind that insinuates some evil is no >big deal because greater evils exist in the world. You obviously (deliberately?) are misrepresenting May's comment above. It isn't that some kinds of evil are "no big deal": It's that quantiatively, refusing to accept a solution that would prevent, say, 100 deaths, simply because it would cause _one_ DIFFERENT death is foolish and misguided. If you feel inclined to deny this, consider the reverse situation: Would you approve of the saving of one life if it cost 100 lives? (all things being equal.) While most people would feel uncomfortable being asked to make decisions of this kind, that does not mean that one outcome is not identifiably better than another. Jim Bell jimbell(a)pacifier.com

3 2

domestic laws/policies
by bobbi 17 Dec '03

17 Dec '03

hello: I have been following the controversy regarding cryptographic software for some time now, and I am hoping that someone on the list could clarify a point for me: If I wanted to develop software that employs cryptography, or a new cryptographic algorithm, strictly for domestic use and sale, does this algorithm have to be registered with any domestic agency? There is a great deal of information on Gak, and the controversy surrounding it, but as of yet I have not been able to find out this type of information. thanks jg

2 4

RE: [NOT NOISE] Microsoft Crypto Service Provider API
by jim bell 17 Dec '03

17 Dec '03

At 11:18 PM 12/23/96 -0500, Blake Coverett wrote: >jim bell wrote: >> Even if, arguably, once-imported software becomes subject to ITAR, it is by >> no means clear that a "signature" is in any way controlled by ITAR. After >> all, looked at generously, the "signature" might simply be a plaque or paper >> certificate, saying "this is wonderful software!" > >The signature in question (on a Win32 Crypto Service Provider) is embedded >in the executable. Certainly I could rip it out and inject it into an unsigned >but otherwise identical copy outside the U.S., but that is obviously not >going to be legal under ITAR. Who says "that is obviously not going to be legal under ITAR"? Personal computers themselves are devices which can do encryption, given appropriate software, and yet export of such devices goes on every day. Operating systems are capable of calling programs like PGP, and yet they are exported every day. (This is by no means a trivial issue. If I were to ask you, "Would you rather somebody give you a $1000 computer and FAIL to give you a copy of good encryption software (which is also available, free, on the 'net), or give you the software and FAIL to give you the $1000 computer, I think most people would happily choose the former, knowing that they can easily remedy the former's drawbacks.) Remember, the only reason "signatures" have any significance is if somebody else writes a program which looks for that signature before deciding whether to run a program. If the "signature" involved simply says "Hi there!" (or is sufficiently short as to be easily reverse-engineerable), presumably the fault lies with somebody else, NOT the person who just happens to export 128 bits of value suspiciously identical to a value appended to a domestic copy of the program. >ITAR is wrong and should be abolished, but that sort of weasling isn't >going to make something legal under the current laws. It isn't necessary to "make something legal." Ostensibly, under our legal system, activities are legal unless there is a law to make them illegal. (some would include regulations in this... I don't believe that constitutionally, "regulations" are enforceable against non-government people or corporations.) I believe we should fight to decrease the envelope of what the government tries to force us/keep us from doing. If I had proposed, 10 years ago, that programs be signed (whether or not they had anything to do with crypto), that would have been legally irrelevant under ITAR. I argue that the fact that a program exists, somewhere out there, that looks at the signature before running a program, that cannot per se make the signature non-exportable. (Otherwise, if NO program existed with those characteristics of being able to run that software, presumably that software could be exported freely because it was totally non-functional.) If anything, if the government doesn't want crypto to leave the US, that's their row to hoe and they're gonna fail. Giving ANYONE authority to export a program (or OS, or computer) simply because it first checks a signature, should not be interpreted as to put the onus on everyone else to ensure that the signatures are "legal." Otherwise, it could have been just as effectively argued that once PGP 1.0 had been written, any PC-clone ever built automatically because a device potentially capable of encryption, and thus the government would (arguably) be entitled to prohibit its export. Since the US government hasn't insisted that every computer being exported since 1991 be incapable of running good crypto (example: PGP) presumably that is a valid precedent that merely enabling good crypto does not constitute some sort of automatic ban. A signature enables crypto no more than a CPU or operating system does. I say all this, not because I believe the government CAN'T do this, or WON'T do this, but because there is no precedent (that I know of) restricting the export of small pieces of data. They aren't crypto programs, or anywhere close. The only nexus of restriction is presumably crypto programs, and signatures aren't that! Jim Bell jimbell(a)pacifier.com

1 0