December 2003 - cypherpunks-legacy

Donate your spare cycles to a good cause
by Lucky Green 17 Dec '03

17 Dec '03

It's that time of year. Please donate the spare cycles on your Pentium or PowerPC to a good cause and help find a new Mersenne prime while you sleep. See http://ourworld.compuserve.com/homepages/justforfun/range.htm for details. Seriously, folks, what is your PC's CPU doing half the time? I thought so. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

1 0

[CRYPTO] Bank Cards, Interac, Bank Machines, etc
by C Kuethe 17 Dec '03

17 Dec '03

I'd like to hear what everyone knows about security holes in bank machines. I don't believe in that little bank machine cracker they used in Terminator 2, but I'm interested in the algorithms and protocols the ABM uses to communicate w/ the home bank. My bank says they have some special chip inside the ABM to secure the transfer, and that's all they told me. I also heard that the magnetic stripe on the back contains your card number (the shiny metallized numbers on the front) encrypted using DES using your PIN as the key. Way out to lunch? Too close for comfort? Any knowledge...heck, even rumors.... would be appreciated. That way we can see what kind of FUD is out there. My bet is that the magstrip with DES'd card number on it theory is FUD. But my bank did say that there were some fraudulent transfers (read successful hits) in Europe. I bank with Alberta Treasury Branches, and they said their hardware is immune to the attack that was performed in Europe.... I will have to dig a bit on that one. Anyway, I hope I hear something from all of you soon... -- Chris Kuethe <ckuethe(a)gpu.srv.ualberta.ca> LPGV Electronics and Controls http://www.ualberta.ca/~ckuethe/ RSA in 2 lines of PERL: http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 0

Announce PGP263UI (long message)
by Steve Crompton 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To All PGP Users: I am happy to announce the availability of PGP 2.63ui, the successor to PGP 2.6ui and 2.62ui, an unofficial international release of the famous public key encryption program, based originally on version 2.3a. This version is being made available for a number of reasons: * It is the only version fully compatible with *all* versions of PGP from 2.0 to 2.7 * It incorporates a number of bug fixes and features not available in the MIT release (see below) or in Stale Schumaker's 2.6.x.i releases based on the MIT release. * This version, like 2.3a and 2.6xui before it, is published under the terms of the GPL. Consequently: - You are not bound by the RSADSI licence since this version does not use RSAREF (which forbids commercial use and unauthorised use of the cryptograpgic routines), as you are with MIT PGP - You are not bound by the MIT licence (which requires the program to produce output that cannot be read by earlier versions), as you are with both MIT PGP and Staale Schumacher's PGP 2.6.xi. - you can therefore do what you like with the code of the program provided any derivative work is also GPL'd. - The only relevant patent for users outside the USA is Ascom-Tech's patent on IDEA. For non-commercial use it's free, anywhere. For commercial use you need a license, but Ascom-Tech offers a single- user license for a modest fee. See http://www.ascom.ch/systec Users inside the USA may not legally use 2.63ui, because the RSA patent is in effect there. USA residents are advised to obtain one of the MIT versions which have a license for non-commercial use of RSA. However, I note in passing that by using the armor_version parameter in CONFIG.TXT, that armored output from PGP 2.63ui can be made difficult or impossible to distinguish from other versions. Note that I personally have not done very much of the actual coding on this version. However if bugs are reported or constructive suggestions for improvements made I will pass them on to the individual(s) who have done the bulk of the work to make this release possible. I am assured that continuing support will be provided. This is a partial list of the changes and fixes since 2.62ui. A complete list is in file 263UICHG.ASC, which is inside both ZIP distribution files. Added CONFIG.TXT Parameters: LabelEncrypt = on # Label Encrypted Armored files with Recipient(s) This will add readable text in front of an encrypted and armored file listing the public keys used to encrypt it. The format of the text is similar to what appears on the console during (-l) decryption. PrePendSigV=on # Prepend Signature Verification msg to output text When verifying the signature on a text (not binary) file, and a detached signature (-b) is not requested, PGP 2.63ui will prepend a message with the results of the signature verification (good or bad) similar to what appears on the console. Expanded Compatibility with Early PGP Versions. version_byte=3 is usually set to Emulate PGP 2.6 after 9/1/94 Version_byte must be set to 2 before encrypting/signing messages to be decrypted/verified by PGP 2.2 or 2.3a. Also, unique to PGP 2.63ui, is the ability to set version_byte to 2 in extracted keys (-kx[a]). This allows PGP 2.63ui to extract keys which may have been created and/or signed by MIT PGP or by a ui version with version_byte set to 3 and create an extracted key which may be added (-ka) by PGP 2.3a. Note that the reverse is not true. If version_byte=3, keys created with version_byte=2 are -not- changed when extracted. Expanded Error Checking Most disk writes are now checked for errors or running out of disk space. Key Generation and other Keyring maintenance operations check for write access to public and (where required) secret keyrings before lengthy processing starts. Previous versions were not checking if the keyrings were set to read-only, which led to invalid results. PGP 2.63ui allows you to change UserID's of keys not your own (corresponding secret key not present). You can sign the new ID with your own secret key but (obviously) not with the other person's secret key. PGP 2.63ui is distributed in two ZIP files pg263ui.zip [executables & documentation] pg263uis.zip [source code & documentation] They are currently available at: ftp://ftp.funet.fi/pub/mirrors/utopia.hacktic.nl/pgp/pc/dos/ ftp://utopia.hacktic.nl/pub/replay/pub/pgp/pc/dos/ Each zip file contains a MANIFEST signed by me which gives the MD5 digests of all other files within the ZIP. You can use the MD5SUM.EXE program included in pg263ui.zip to verify the MANIFEST (after using PGP to strip the signature). Here is the MANIFEST for pg263ui.zip 840317378232e54d03424e7e49a9bd4a *263UICHG.ASC 7408f5f49f74e0209f7a712a10c95e8e *CONFIG.TXT 83c8d06f39a0984066464e9a70e62550 *ES.HLP 64fa593bc5f188cf5a3cda03f3ed0ea5 *FR.HLP 480f583a2ac6776a4de7df6e7382545e *KEYS.ASC 5ba7143bad4739a4b749e492b5eee1ce *LANGUAGE.TXT ecec59110e8a3bfd7fb195ec5964d5ce *MD5SUM.EXE ca537810f4fdf5f359ec6583eeb176bb *PGP.EXE 3e2afe9edfc197554e9de9e3d433cdd0 *PGP.HLP e1ef684d67c7e23143bca9163ce04966 *README.1ST 473d455178341f5f6e5f53394fd5a1d9 *README.2ND a7491b03c6e87d57e34ec03ace211509 *README23.DOC 01a94cd84d68ea1cb905ce29caf0961e *DOC\BLURB23.TXT ad4652e2dcfd4a0ecf91a2c01a7defd5 *DOC\COPYING fbdd95ba04c9d2be5c4b8e2769482c32 *DOC\KEYSERV.DOC 8ab813656498102101d55b9ecfddde98 *DOC\NEWFOR22.DOC cf12a2daac04470b6ad2b311cc514431 *DOC\NEWFOR23.DOC 5413061db46b1379a5489296c214ee38 *DOC\PGFORMAT.DOC 2a6c84401fc0c3b9febd77dd965c7b4f *DOC\PGP.1 33eeab5a938d0d33b8ca8ecf97038d73 *DOC\PGPDOC1.TXT ff0d028f72c4632c2b87c099dce92180 *DOC\PGPDOC2.TXT ca6253109c92944d44a9a1767f0b58ff *DOC\POLITIC.DOC b648ac7c1c3aa7b0c92f80dc18dc9bcc *DOC\README.VMS e4cfe2f3c28aab747f2396ae5e0a8ba8 *DOC\SETUP.DOC Here is the MANIFEST for pg263uis.zip 840317378232e54d03424e7e49a9bd4a *263UICHG.ASC 7408f5f49f74e0209f7a712a10c95e8e *CONFIG.TXT 83c8d06f39a0984066464e9a70e62550 *ES.HLP 64fa593bc5f188cf5a3cda03f3ed0ea5 *FR.HLP 480f583a2ac6776a4de7df6e7382545e *KEYS.ASC 5ba7143bad4739a4b749e492b5eee1ce *LANGUAGE.TXT 3e2afe9edfc197554e9de9e3d433cdd0 *PGP.HLP a7491b03c6e87d57e34ec03ace211509 *README23.DOC e1ef684d67c7e23143bca9163ce04966 *README.1ST 473d455178341f5f6e5f53394fd5a1d9 *README.2ND 1a22a466840f14025a5de0118d6daa0d *CONTRIB\README e8e9f513a273e86170e886c730a73307 *CONTRIB\ELM_NN\MAILPGP 56776ba15d847d005da2c95caa13744f *CONTRIB\ELM_NN\MOREPGP 8ae0fd91ea7ca5e041a5da4b78dce2c1 *CONTRIB\ELM_NN\POSTPGP a2e4b46d2b0a6613a19061e8755024ca *CONTRIB\ELM_NN\README 0bf0ac13b4d019ed8b010ac3c0d30241 *CONTRIB\EMACS\PGP.EL1 52f5921095dd385796ae5fe6b2badbc6 *CONTRIB\EMACS\PGP.EL2 8de46004960bbca27de290a814fa6585 *CONTRIB\EMACS\RAT-PGP.EL 0188d65c58e003d50871a60412a86e58 *CONTRIB\EMACS\PGPEMACS.DOC 3a256a88091276b667a8283614122a76 *CONTRIB\IDEA\IDEA.ASM fb995ab5c86fd45fcccc9c385d03c551 *CONTRIB\IDEA\README 1061623e095426e6ece416f75a15c643 *CONTRIB\IDEA\TEST.C 488b1cece84dd0853f491a5d10362ca4 *CONTRIB\MAIL_TIN\MAILPGP 994c5848ed0457eaf60ec086ad86048e *CONTRIB\MAIL_TIN\MOREPGP f3afdb4e57ea645e7bfdbb1eb969a48c *CONTRIB\MAIL_TIN\POSTPGP 746f7fcfb23fc18974f06243201957eb *CONTRIB\MAIL_TIN\README c037a9119d14999dc445ea47a75e7d48 *CONTRIB\MAILX\MAILER 06cebf8214342e286a7f3245c724ff4d *CONTRIB\MAILX\PGPMAIL2 eac85d75f64fef85da9afa399368890d *CONTRIB\MD5SUM\MD5SUM.C 5ca3e58ba621523b0d3feb026820fa63 *CONTRIB\MD5SUM\PGP23.MD5 6242095b32ea68409929194ad7e157bd *CONTRIB\MD5SUM\README 7bf7d12fe520767019a71d4f963fa6c8 *CONTRIB\MD5SUM\PGP26UI.MD5 501fc6ccb4e8405d75a72d9acb6a019c *CONTRIB\MH\PGPMAIL.MH bff01f6723fac1145074f6cce81ef1b8 *CONTRIB\MIME\MIMEPGP.DOC ded0f233729d58e001746708fb0ecec6 *CONTRIB\MISC\PGPNOHDR.SH a860741049e3b3285c4d96996a7e59f0 *CONTRIB\MISC\PGPPAGER.C 3af9ddacbe85b67fd3a02ce8a9421a04 *CONTRIB\VI\VIPGP.DOC 01a94cd84d68ea1cb905ce29caf0961e *DOC\BLURB23.TXT ad4652e2dcfd4a0ecf91a2c01a7defd5 *DOC\COPYING fbdd95ba04c9d2be5c4b8e2769482c32 *DOC\KEYSERV.DOC 8ab813656498102101d55b9ecfddde98 *DOC\NEWFOR22.DOC cf12a2daac04470b6ad2b311cc514431 *DOC\NEWFOR23.DOC 5413061db46b1379a5489296c214ee38 *DOC\PGFORMAT.DOC 2a6c84401fc0c3b9febd77dd965c7b4f *DOC\PGP.1 33eeab5a938d0d33b8ca8ecf97038d73 *DOC\PGPDOC1.TXT ff0d028f72c4632c2b87c099dce92180 *DOC\PGPDOC2.TXT ca6253109c92944d44a9a1767f0b58ff *DOC\POLITIC.DOC b648ac7c1c3aa7b0c92f80dc18dc9bcc *DOC\README.VMS e4cfe2f3c28aab747f2396ae5e0a8ba8 *DOC\SETUP.DOC a75c34297e3915242232242aa0147bb8 *SRC\3B1_6800.S baf854e4fd40d02a7b7b7fa2911382be *SRC\68000.S 557168162e418489bc245ab5c4030add *SRC\68000_32.S 57900fde67a6039f1b218972e74bf806 *SRC\80386.S de3f8236644a00ca45d1c41f400b2fc3 *SRC\8086.ASM 69f8d2757e5c13a1ebf17998a756e8ba *SRC\ARMOR.C 80f3854e9b76eee4167503893135839e *SRC\ARMOR.H 5b9cd4b55699685f37dd594382dda8a7 *SRC\CCC 7fb0b40db91d6da79d38b2f475110fc4 *SRC\CCC.X28 66b7d0786b5d426644591fa347a7e205 *SRC\CHARSET.C 35bbbe1de78008abae59bf12fed41291 *SRC\CHARSET.H 04b95ec3860bc3ecaf56d2fe5d837a68 *SRC\CONFIG.C eb57f96eea26bee3152fb82a5006e133 *SRC\CONFIG.H c0741f9f07cb9f7f7dff2be9ac6ed3a0 *SRC\CRYPTO.H df233c3e5793cae25adc82bd51ffe9c5 *SRC\CRYPTO.C 1c51db6958288d475e066f4b428d1324 *SRC\DESCRIP.MMS 067b372f3f13365acca772f307dd73c9 *SRC\EXITPGP.H 243453889c70b37d7444d29a162ba9bb *SRC\FILEIO.C bc273e19f5900cac30bfe8d1bc29907a *SRC\FILEIO.H a0bebb371176f8fd5ea2c34e14be8106 *SRC\GENPRIME.H 4f3f1ca25c8ad16536ba9fa4f2fa07ba *SRC\GENPRIME.C 12fb2c21d044f5cc1264d4e2f8e35d17 *SRC\GETOPT.C 70bc995b674a1041f006e0c85ad128bc *SRC\GETOPT.H 891c95125020cc39df1cfaf531baeac4 *SRC\IDEA.C cbf974a9968d4cccb3dbbb8c6e197fb3 *SRC\IDEA.H be2862fa4e729caed7f5284d0a068c2d *SRC\KEYADD.C a31d39f665562103f27fd51943eb9f80 *SRC\KEYADD.H fcd92da1ef03062aaaf4a32e9c0bfe1c *SRC\KEYMAINT.C e8b97adb23122b1e61d1c876d44405f5 *SRC\KEYMAINT.H b51b6f358baecddf27d2af1f1325b8a8 *SRC\KEYMGMT.H 55f0e339489a329813568e9e43d44087 *SRC\KEYMGMT.C 378c2c04399840ff19a1c428c86b31a3 *SRC\LANGUAGE.C fa3757f2e65cce62ccd16cf4fa71f0dc *SRC\LANGUAGE.H 2194f583f62eff5db4dacc1d032fd391 *SRC\LMUL.H 465c44debfabb9433c6b0d6416d29ff9 *SRC\M.BAT 46377c4b4ff7deb2bac93c5eee2bbbad *SRC\MAKEFILE.TC 5a7e71d8c85f7cd95825c55cd3f1bae7 *SRC\MAKEFILE.AMY 625825b93e4230440371ee2bc32616e8 *SRC\MAKEFILE.MSC 0fd62dae064f53b0c9caa7ac9302a926 *SRC\MAKEFILE.UNX 08781b63fa78e8743be80da9aace6f9f *SRC\MC68020.S 021582f73d3324be77267a0c60890e6e *SRC\MD5.C 3b254fd2c035f3081ca2ec96ea120f9a *SRC\MD5.H 517550a4f55b76767a524f8997310bae *SRC\MDFILE.C f54f6dc8ab01cb256d23f59824c38ee7 *SRC\MDFILE.H 5fbaf7195aadb77916f02c6fe3260a45 *SRC\MORE.C ad3274da77b334827113f23ba7e85730 *SRC\MORE.H 9cb7caf58ca015e4a2a88deb056c539d *SRC\MPIIO.C 4d1446ac5992abe2cf1ea12a8f2d9310 *SRC\MPIIO.H 5b5f0174cdc8d2dcf6c48240ea4bf055 *SRC\MPILIB.H f86467788e24b8484c9f9c71b8bfb692 *SRC\MPILIB.C 5db4340956609ac9debb9a517371bf9e *SRC\PASSWD.C 9344f7fe246c52d04105ddfae09de625 *SRC\PASSWD.H 8fe5084f2924836c655e84ef7f835674 *SRC\PGP.C 614f9234b18231bf92219c8a257e78cc *SRC\PGP.DEF 88c06903fc5386160e34291da980c421 *SRC\PGP.H 851e15e93234d3c466af5f9c9c932d79 *SRC\PGP.MAK 64459d86a1069f98ed6d471b39614561 *SRC\PGP.OPT 2def18122c0cf2b56e0e8caff3e3ecb5 *SRC\PGP.PRJ abf28ba7832d89abeac494e3cec45a7c *SRC\PGPPWB.MAK dbb569238f082bb4048264ffd0eb117a *SRC\PLATFORM.H 19be9bade48954274b84408fa18d4ad0 *SRC\R3000.C e64d1a208d148cd3c2400f9301360df2 *SRC\R3000.S 766825310519ca3c70395c2ccf986aa7 *SRC\R3KD.S ba19b4d87c1f1d36f00e1f180b4b9a72 *SRC\RANDOM.C 1aad27b13005436b9e2e9c7537a641e0 *SRC\RANDOM.H 62542804547db44fabdf36bc31d0802e *SRC\RSAGEN.C 6d3eb1bb77e53c7020dc6180c95adeb2 *SRC\RSAGEN.H d026b1e2ef561bf20790c81578159449 *SRC\RSAGLUE.C a62a4b12a3837571e13419559c385747 *SRC\RSAGLUE.H b13fc1755a4d36109604dd027d9a5d36 *SRC\SPARC.S e01ca7bf8ff1b5fb55b95b762569430d *SRC\SPARC5.S 9d47b06b192c264dcbf2184c1890f05f *SRC\STDLIB.H 1efd1412a867be2b00a0cd66f036c314 *SRC\SYSTEM.H 329e9a279a9cdd4ae241d03839970a6d *SRC\SYSTEM.C 270fa89c0ff884ee10d1a02a1ff9040d *SRC\USUALS.H 30861dd65fdde4a5980b7d4cdf77ffdf *SRC\VAX.MAR 4d38b8dd3fa590edac0c2c9ccbfa2c0f *SRC\VAXCRTL.OPT 0bfbf4243329095d8bedb43e9222c6f4 *SRC\VMSBUILD.COM 1f09c5096052dd04a23f82fbfbf3f735 *SRC\ZBITS.C 9ff737184ab3697105e63c314ee291bb *SRC\ZDEFLATE.C 6ce4f6a3d9a62c1f188a2c22c171242a *SRC\ZFILE_IO.C 20cc87c569e4a1ef96b700f733190201 *SRC\ZGLOBALS.C 7cf642c7a28dab19b5b257d6f06fa3a4 *SRC\ZINFLATE.C 28d41c5aea7551e8c6c3d12e69141adb *SRC\ZIP.C 6e4e3f4ae03d0d6a9d466716bafe719f *SRC\ZIP.H 1602f1e2f0836b7d2af3e071fca8a47e *SRC\ZIPERR.H d196f856bc08b1740b2679c5f5fd1411 *SRC\ZIPUP.C 988ca6b0f63791ca02524048e666cb72 *SRC\ZIPUP.H fb27196aa99cf8b47fba10581db5aa24 *SRC\ZMATCH.S 8f5d690f2652a4d4ceab1b41d1b40d01 *SRC\ZMATCH.ASM 56b97156406d0adb0e9b714c2d5bf6c6 *SRC\ZREVISIO.H 7c2f8a376a30a72eb71eff212f1a8b14 *SRC\ZTAILOR.H 17fac9f3271a8650256da28bf31b584b *SRC\ZTREES.C 3f114dac8098c09167d2d2c540520415 *SRC\ZUNZIP.C d211d2be3334c216808c376cc5b5812e *SRC\ZUNZIP.H This version of PGP has not been approved by MIT or Phil Zimmerman. Please do NOT send any questions or bug reports about this version to either pgp-bugs at MIT or directly to Phil, but rather to me, Steve Crompton <100645.1716(a)CompuServe.COM> London, 23rd November 1996 -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Requires PGP version 2.6 or later. iQCVAwUBMpc+1Qc2DukbwCfhAQHi8gP+LCT2tFyzHf54CCkzeqQKbfQdFlldddtO RwwyVLOE6R7HnHuwz8HPFOEKjz85z158Rq0RbpmZqG+G0ynChuqm/80ocEfB83PI PXLjgTzeOxqdEum9tWpa45UUlMEuC4Puni7t9AUMyNlTmNrunbRMFdcDxIajsV+j U/0r1tRhPA4= =G+nz -----END PGP SIGNATURE-----

3 2

Re: KILL cypherpunks !!!
by Eric Wilson 17 Dec '03

17 Dec '03

At 07:28 PM 11/25/96 -0500, you wrote: >On Mon, 25 Nov 1996, aga wrote: < whole bunch of stuff > >> This is a world-wide internet problem that you are about to get >> taken care of. You will be among the first locations to be >> eliminated. And just remember that your termination is your own >> doing. You had your chance to keep the fucking cypherpunks list >> OFF of your e-mail to me, and blew it. > >Oops, now what will I ever do? Wow, I'm going to miss cypherpunks. I didn't post much, but I've always been an avid reader (sniff). If I only had it to do all over again... Oh, by the way, since you're planning on doing away with things, could you get rid of some of these outfits that do the mass e-mails, thanks in advance. >> I pump iron and run three times a week. And as a Tae Kwon Do >> black belt holder, I get lots of physical activity. I am in >> better physical shape than any other man that you know. > >I have a date this weekend already, thanks. I find you're martial arts reference very interesting. But if you were truly any good, you wouldn't be waving it in everyones face like a banner. I find your demeanor to be that of someone that has never practiced the warrior arts. If you had, you'd have developed more respect for your fellow human beings. I'm guessing you're a very lonely person, whos only way of getting attention is to try and cause a conflict. Share your pain with us, and together we'll grow stronger ( Star Trek reference ;)). But if you can't do that, shut off your computer ( or leave your terminal), and go find someone to talk to, like a counselor. Eric Wilson ----------------------------------------------------------------- Join the BugList! "How many times?" The Blind Man http://case.cioe.com/~serw30

1 0

Re: IPG Algorith Broken!
by Alan Olsen 17 Dec '03

17 Dec '03

At 11:21 AM 11/24/96 -0500, Black Unicorn wrote: > >> > On Sat, 23 Nov 1996, John Anonymous MacDonald wrote: >> > > diGriz >> > >> > Use an anon. remailer and sign your posts. Brilliant. Just brilliant. > >Actually, rather clever if you're trying to estlablish reputation. Just >make sure you use the right key. Reputation is not the only reason to use a "name" with an anon remailer. Sometimes you want to post (and have a reputation) that is entirely seperable from your "real life" persona. Maybe you have a job where being involved with "The Evil Cypherpunks(tm)" could result in hastles at work (or even firing) if known. (I recieved flack from one company I worked with for posting here... Until they needed a remailer set up and someone to explain how their software worked... But that is another story.) Cypherpunks is gated to a number of Usenet News servers. (Teleport is a good example.) It is also archived in a number of search engines. (Altavista if I remember correctly, is one of them.) Someone who does not want their words to come back any byte them might just use such a method to protect themselves. --- | "Remember: You can't have BSDM without BSD." | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.ctrl-alt-del.com/~alan/ |alan(a)ctrl-alt-del.com|

2 1

Re: Another Nutty Idea about SPAM
by Omegaman 17 Dec '03

17 Dec '03

> Steven Garman wrote: > > Once method of combatting the spammers is to use disinformation. For example > > we use new addresses for their "remove" lists to check on their honesty. > > > > What about attacking the lists themselves with false data? Say you run a site. (snip) Igor Chudov wrote: > Another nutty idea: to create a database of people who do NOT want to > receive unsolicited advertisements, and make it widely available. Of course. But this does not address the issue of "unscrupulous spammers" which is what Steven was commenting upon. > The obvious problem is that some very uncsrupulous spammers would want > to grab this database and use it as a source of email addresses. > > This problem has a solution, however: instead of distributing people's > email addresses, distribute MD5 checksums of their addresses. For > example, an entry for ichudov(a)algebra.com would be > > b51175dae78f25427351d5e3ff43de30 > > There is no way to guess the original text from an MD5 checksum. > > Spammers should be advised to exclude all addresses with MD5 checksums from > that database from the recipient list, and include instructions on how > to get one added to the database into their spams. Okay fine. The spammer is "advised" but if he is unscrupulous in the first place, he'll simply ignore the advice and continue bulk-mailing to every address he can grab. > Database maintainers could even provide a email filter-bot that would > accept recipient lists by email and send back the same lists, but > WITHOUT addresses that wish not to receive spam. This way stupid > low-tech spammers (who make up the majority) will be able to process > their email lists quickly and easily. Indeed, stupid low-tech spammers would benefit from such a service if they wish to honor "do not send" requests. > This database may be maintained centrally. Users may be able to sign up > for inclusion into that database by email or by filling out a Web-based > form. Identity verifications may be done by using cookie protocol. I like the idea and if I had the resources, I would do it personally. Optimistically, many bulk e-mailers would sign on to the plan. (Ironically, one would probably have to solicit bulk e-mailers to sign up). However, many, being unscrupulous, ignorant, etc. will not be involved. The only way I see to get bulk e-mailers to utilize this service is to offer a positive and/or negative incentive for usage of the service. ie. "What do I gain by elminating people from my bulk mail-outs? What can be done if I don't follow this protocol?" Ideas? Comments? me -------------------------------------------------------------- Omegaman <mailto:omega@bigeasy.com> PGP Key fingerprint = 6D 31 C3 00 77 8C D1 C2 59 0A 01 E3 AF 81 94 63 Send a message with the text "get key" in the "Subject:" field to get a copy of my public key. --------------------------------------------------------------

3 3

The dish on TEMPEST
by Lucky Green 17 Dec '03

17 Dec '03

The following is from a tread involving a friend of mine. An ex-military fellow. Take it for what you want. I believe him. >>> This depends in large part on the strength of the >> > degausser and how long it remains powered up. The one >> > I have I used to "clean" 10.5 inch tape reels written >> > at FM broadcast quality to a noise level -20db down from >> > brand new tape - this back in my quadraphonic stereo >> > days. It will not quite suck satellites out of orbit... >> > TWA planes, maybe. >> >> >> -20dB down from new would be a better spec if new tape was typically >> nulled rather than just blank low-level white noise. >> >> However, even so, a SQUID is a very scary thing.... I've been out of commission for a week and found 276 messages in my in-box today. The tapes I was writing about were those already "prepared" for recording "items of interest", and had already been degaussed in the preparation procedure to FM broadcast standards then/there. My little hummer would take whatever whit noise remained even then to a further 20 dBA DOWN from the ridiculous levels then/there specified. In other words, it's pretty good. Of course, IF Big Brother wants, there are any number of ways for him to obtain whatever information he wishes. I recall long, long ago, I was privileged to watch a demo of equipment (1955 or 1956, I forget exactly) in a truck parked a MILE away from our CommCenter, in the years before Faraday cages, TEMPEST, etc., and watch these guys print out a 5x5 copy of our top secret traffic as it was read by the [elided upon request] one-time-tape encryption devices. Shortly after that demo, our CommCenter was moved into a cave (no joke) and modified to "low level" dc signalling voltages. And other measures were taken to screen the area... I _have_ led an interesting life... As for Squids, only if you read Jules Verne are they scary. Otherwise, cleaned and fried with a tangy dipping sauce, well, that's another story! --Lucky

1 0

Need info on non-OS specific random functions (pref C++)
by Rick Osborne 17 Dec '03

17 Dec '03

I am looking for information on non-OS specific RNGs. Nothing really complex, just easily portable to a few different OSs and compilers. Any pointers would be appreciated. Thanks! Rick Osborne / osborne(a)gateway.grumman.com / Northrop Grumman Corporation ------------------------------------------------------------------------- Q: How many surrealists does it take to screw in a lightbulb? A: Two. One to hold the giraffe and the other to fill the bathtub with brightly colored machine tools.

2 1

Re: Another Nutty Idea about SPAM
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

Steven Garman wrote: > I have had yet another twisted idea. I would be interested in your thoughts. > > Once method of combatting the spammers is to use disinformation. For example > we use new addresses for their "remove" lists to check on their honesty. > > What about attacking the lists themselves with false data? Say you run a site. > You can make and delete accounts as you please. So, make a whole bunch of > new accounts, and submit them by various means to places that will probably > use them in bulk e-mail lists. Then, delete the accounts. Viola, the lists > have some worthless addresses. Another nutty idea: to create a database of people who do NOT want to receive unsolicited advertisements, and make it widely available. The obvious problem is that some very uncsrupulous spammers would want to grab this database and use it as a source of email addresses. This problem has a solution, however: instead of distributing people's email addresses, distribute MD5 checksums of their addresses. For example, an entry for ichudov(a)algebra.com would be b51175dae78f25427351d5e3ff43de30 There is no way to guess the original text from an MD5 checksum. Spammers should be advised to exclude all addresses with MD5 checksums from that database from the recipient list, and include instructions on how to get one added to the database into their spams. Database maintainers could even provide a email filter-bot that would accept recipient lists by email and send back the same lists, but WITHOUT addresses that wish not to receive spam. This way stupid low-tech spammers (who make up the majority) will be able to process their email lists quickly and easily. This database may be maintained centrally. Users may be able to sign up for inclusion into that database by email or by filling out a Web-based form. Identity verifications may be done by using cookie protocol. - Igor.

2 1

An interesting tid-bit
by Mark Neely 17 Dec '03

17 Dec '03

I was just testing out some new search software, and polled Alta Vista to see how it all worked. I used "sex" as my search term, and Alta Vista reported that their were "no documents matching - sex ignored"! Interestingly enough it will let you search with other, sex-related terms (such as "nude", "f*ck" etc), but not sex! Very bizarre indeed. Mark Mark Neely - accessnt(a)ozemail.com.au Lawyer, Internet Consultant, Professional Cynic & Author BizWeb: For Serious Intrepreneurs - www.maximedia.com.au/bizweb

2 1