December 2003 - cypherpunks-legacy

Anonymous Remailers
by ghio＠cmu.edu 17 Dec '03

17 Dec '03

Usura(a)vox.hacktic.nl wrote: >>> Has anyone had any experience chaining from a Cypherpunk-style >>> remailer to anon.penet.fi? Can a "::" separator be used >>> successfully, or which format will work? >> >>I think it can be done... > >I know it can be done... Well, some of the remailers will only send to naxxx(a)anon.penet.fi I think remailer(a)chaos.bsu.edu requires this. Jeff Davis <eagle(a)deeptht.armory.com> wrote: > Today I used the catalyst(a)netcom.com remailer to send an anonymous > contribution to a list. They're raising hell about anonymity in their > list, but that's beside the point. The message also showed up on a > seperate beta test list. I assume this was done manually by > <mcstout(a)netcom.com> bouncing the message to the other list, since he > is the sigular person on the planet subscribed to both lists. mcstout > has been a quite vocal detractor of my catalyst contributions to the > other list. I thus strongly suspect manual sabotage. There was no > flaw in the Request-Remailing-To: adress. > > Could someone please confirm that this was not a quirck of the remailer? Try checking the headers to see what site it came from.

1 0

Re: Faster way to deescrow Clipper
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>From: "Perry E. Metzger" <perry(a)imsi.com> > >Mike Ingle says: > >An interesting idea. > >> The LEAF would look good unless you tried to decrypt the >> session key. The wrong-IV problem would remain. The NSA should have >> designed the Clipper so that, if the IV was wrong, the chips would not >> accept the LEAF. > >That can't be done, I'm afraid. Its way to difficult to distinguish a >bad IV from line noise nuking the first block of your CBC >conversation. I used to work on NSA cryptographic equipment. One of characteristic of a system designed to use crypto is the ability to detect crypto sync. If you have access to the control program (which you would if faking LEAFS), you would tend to throw out the first block. The difficulty is that the DE (distant end) ain't necessarily smart enough to do so (assuming it has not been modified), and is more than likely looking for a passed data value (typically a sync symbol) to determine the state of crypto synchronization. Were the system consuming data from the enciphered link properly prepped, it is possible that it would ignore garbage (Assuming the damaged decrypted first block did not contain the sync), while awaiting a synchronization indicator. Most duplex crypto systems use some variant of End Around Prep (EAP), where the receive data path is used to determine whether crypto synch is acheived by looking for a constant mark or space, or idle character. When the receiver does not provide the proper value the transmit side is knocked down, the DE receive notices and restarts its transmit. A data value is passed through the loop to tell the system to go to operate mode. Such functions are generally predicated on having crypto - and the data system for which it provides a link, separate. The point being that a communications system that you can't modify both ends of may not be able to accept a garbled first block. Not to mention that OFB is probably a lot more prevalent for voice applications.

2 1

IVs and synchronization
by perry＠imsi.com 17 Dec '03

17 Dec '03

Just in case it confuses people, when you are doing Matt's general attack that interoperably works with non-rogue systems, you find via exhaustive search a LEAF that corresponds to your selected Session Key/IV pair. IV synchronization problems only show up if you are using the less general "feed the LEAF back to the same processor" trick. Perry

1 0

Re: LEAF forgery
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I wrote about a possible trapdoor in Skipjack to which Perry replied: >Your belief is without evidence. It is a supposition. I'd say the NSA >has a lot to lose by putting holes in Skipjack. How true, yet the NSA also had a lot to lose by putting out a flawed backdoor in Skipjack which essentially negates much of this features (LEAF) value. They did so none the less. In addition, I remember the comments of Stuart Baker; the audacity was typical of an organization which would put in just such a hole and smugly disbelieve that anyone would find out. In addition, it is possible that the agency is not alarmed about their LEAF problems because they don't need to use it. Of course, even if the whole algorithm was compromised I don't think they would show alarm outwardly. The possibilty is still there. Since one does not know the Skipjack design, a belief that it does not contain a trapdoor is without evidence and also a supposition. My contention is that the NSA is cocky enough to disregard the consequences of putting holes in Skipjack. >None the less, I wouldn't use Skipjack, because I don't trust things I >don't know the design of. Me neither, and randomly generating new LEAF fields would not give me comfort as to the security of my transmissions. Which is the main point here in my mind. Scott G. Morham !The First, VACCINIA(a)uncvx1.oit.unc.edu! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLe92xz2paOMjHHAhAQHaUwP/T+Di/N7ej8pfW7jKJJHmV8CTfJaYkYgt ejB2M+QTs23i+6AdT6yiSfs+cGXz19F/eHiNtvemJyYujnyXP8EjxeqkhCIjtu+/ ZkF9dBWSC6V1Xj7MycPZbG8lgv7EY57nnVDU7smv42xbRx9Co9qYF9zRdhe0WRZc Hdzm4YP+8Bw= =T1Tz -----END PGP SIGNATURE-----

2 1

PGP 2.6 hoax by Sternlight
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Vincent.Cate(a)FURMINT.NECTAR.CS.CMU.EDU: > The pgp26-RSAREF_3.0_beta.tar.gz file is not real. From some other > post, it seems this came from the site in Italy that I mentioned awhile > back. They have removed the file from there. It is a lot of bytes > for a joke. It should probably be removed from soda too. > ... > [Sternlight ASCII art] I was surprised to see that this file was owned by "strnlght" on the Italian site. Anyway, the file has been removed from the Italian site, and its replacement, pgp26.zip, is real. (I haven't checked the sig, but the contents seem ok, at least ;-) -------------------------------------------------------------------------- Rishab Aiyer Ghosh rishab(a)dxm.ernet.in Voicemail +91 11 3760335; Vox/Fax/Data 6853410 H-34C Saket New Delhi 110017 INDIA The National Fairness to Game Animals Association says: Support your right to arm bears! --------------------------------------------------------------------------

1 0

Re: more info from talk at MIT yesterday.
by Mark Voorhees 17 Dec '03

17 Dec '03

>Since when can the government patent its work? I thought that works >produced by government agencies could not be copyrighted or patented. No. The patent on the digital signature algorithm, the basis of the new digital signature standard, for example, is held by NIST.

1 0

News: SecureDrive 1.3d
by edgar＠spectrx.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Maintenance: The original FPART 1.3d was not updated to check for 1.3d-level SECTSR loaded. It would run without SECTSR loaded. I have distributed now FPART13D.ZIP, which contains a replacement FPART executable, source, and signature. Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 4346 DeflatX 1717 61% 05-05-94 06:00 8ab67f77 --w- FPART.C 15452 DeflatX 9798 37% 05-05-94 06:01 bae1a9d8 --w- FPART.EXE 152 Stored 152 0% 05-14-94 23:10 7cc1bfdc --w- FPART.SIG FPART13D.ZIP is now available for download on the following public BBS's. Eagle's Nest (408)223-9821 Flying Dutchman (408)294-3065 Catacombs BBS (303)938-9654 (unverified) It is also available from a mailserver in Texas. Send mail to Server(a)Star.Hou.TX.US with body text that looks like this get /files/public/fpart13d.zip quit This file is also available via FTP from netcom.com ftp.netcom.com:/pub/mpj/I_will_not_export/crypto_???????/secdrv/fpart13d.zip (See ftp.netcom.com:/pub/mpj/README.MPJ for the ???????) Note the file SECDR13E.ZIP in this same NETCOM directory is just SecureDrive 1.3d with the new FPART modules. The internal modules all still call themselves 1.3d. Furthermore, this ZIP file is incomplete, but all the files except a trivial part of READ.ME can be retrieved after processing the file with PKZIPFIX. I haven't been able to verify if csn.org also contains FPART13D.ZIP. Also note that the ZIP files contain PGP detached signatures (*.SIG) for the executable files. Documentation: "Heavy" SecureDrive user, Duncan Frissell <frissell(a)panix.com>, offers the following update to running SecureDrive under Windows: Ordinarily, PGPPASS will not be available to DOS programs run under Windows but if you use the Windows virtual device driver EDOS (Extended DOS) PGPPASS will work in DOS windows. EDOS --- Enhanced DOS for Windows Mom's Software Box 449. 391 So. Pacific Street Rockaway, Oregon 97136 503-355-2281 Voice EDOS is Shareware. Note: Windows 3.1 and Windows For Workgroups 3.11 allow you to enable 32-bit disk access in the Virtual Memory/Windows Swapfile menu under the 386 Enhanced section of the Control Panel. In addition, Windows for Workgroups 3.11 allows you to enable 32-bit file access in the same menu. You will be able to read a logged in SecureDrive partition with 32-bit disk access enabled but *not* with 32- bit file access enabled in Windows for Workgroups 3.11. [end] Finally here is my (Edgar's) public key, also available on many public keyservers; note who has signed it. Also note that my only correct address is the sbay.org one. The saigon address is no longer valid. Type bits/keyID Date User ID pub 1024/DA87C0C7 1992/10/17 Edgar W. Swank <edgar(a)spectrx.sbay.org> sig 4AAF00E5 David Del Torto <ddt(a)lsd.com> sig 08B707C5 Anton Sherwood <dasher(a)netcom.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)fbihh.informatik.uni-hamburg.de> sig 34D74DC1 Peter Simons <simons(a)peti.GUN.de> sig DA87C0C7 Edgar W. Swank <edgar(a)spectrx.sbay.org> Edgar W. Swank <edgar(a)spectrx.saigon.com> sig 3245BF5D Jeremy S. Anderson <jeremy(a)cctwin.ee.ntu.edu.tw> sig 08B707C5 Anton Sherwood <dasher(a)netcom.com> sig 4AAF00E5 David Del Torto <ddt(a)lsd.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)fbihh.informatik.uni-hamburg.de> sig FF67F70B Philip R. Zimmermann <prz(a)sage.cgd.ucar.edu> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tCdFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYmF5Lm9yZz6JAJUCBRAt 1dNBocE4X0qvAOUBAQdhA/kB2vTXCIjZGtOw/bC6gOTHnMPBVTQeXHIZ3BZ4xYRd MfdKsxN3gTezOI8QixQoHzhvNGB02fB5EdB8+Ulw9kn08AR2b+mTwkgeNtlytvNZ 52E7UpWEVtznxlGeiwRMbOFIaGKJFsGXFSRw3F89ZqoUnoeRvRgL0kJIQOZCLF62 ZYkAlAIFEC2o/S8YM6FlCLcHxQEBHcsD9i0o2d7Q2rsG/iRRwapxGKQbHPxgQXCB 6MLVNDEa3c/png8r2PA9cOeRcwx2xY/XxNuZo7lHXNp/j5xwYhooq+yTBJIL8DZq W99QT8+c05vw7M1UCEpy7NT1exkMzoVR/Y3jKbIa4X1tX1ZrdmoozxW0T3DwCcCZ 7dR26eZXlx2JAJUCBRAtmw+uNlaXxjLdmNkBAULKA/4wqdMn2GCApAq+5kJT+iJm LvVeNZj0JVjWspGDcd+1cjCK9XWVTATVtRAfWbDukoJ2wNzNuz7gbqVHHcrV7nvc Qt3KUsxWRyahREklc75PtXBm0PKpr5TNTM2J/Kql28GXQQyL+PHawTDQVE8ybCPj +WUgK5qd1o/2QPxnb4EAmYkAlQIFEC2bGrAPRy9bNNdNwQEBhLAD/3vWoDu4msz4 YA8BcnfuovI0ApDL5ekSu447ByXgIcqNRe4oDtGdvrqXvJhpyuj5t7vVDGtzgQE0 jU8H6u+Ocpj1nBlOXL36DASSaJuLErByNCzqTaGVya5WGxmK2m+pKS6UVIXitF2t GxrKu+Pdp3rkv3oPHTWVgFT5eGRvfJIKiQCVAgUQLZj0qd4nNf3ah8DHAQFrQwP+ OeVHrxlNzhC+SxfttzIUC3g+VALuM6gv8b+cyxl0tlkwi6H9G8qmPh9nr2ppQZR5 jHUhubfsek/QGi88UwOfuRPdh+ZDl/rU4kMcXvdYGT9clOLjzXmcLM7y9v8F4mFL sNtvFN2qWLsqne6hUI7EFn2ea/8ujdm7eoNlq7t8Cyu0KUVkZ2FyIFcuIFN3YW5r IDxlZGdhckBzcGVjdHJ4LnNhaWdvbi5jb20+iQCVAgUQLAAAujTiKn8yRb9dAQGY 1AP/SNRWpPQsyhW/DtnPYVfJat0GfptGXIbF6pBaGKANdGKlnzbj98dsDa+RsBzM RrLDxmnBFWaFY2zHFaGNgUiL3YpglsA/9chuv6sS5MiE8oooqG64YtRaF9eEIWW4 eOzcIDplDCdPiOe7U2UKRydYtsviS2q5vbMvCscI9R7fUvWJAJQCBRAr1jnTGDOh ZQi3B8UBAc+sA/MFt/qVDLPBtTB3FrLMsOiHcfKCe6cuiiL7LPOIRVByE6BK3ewt 7YjXTwMvFOCn7bqUlhMBkH4aDwcbIH43PrbrcPReVVRdCL3/sJJHJ3xuFgV64U/A XMc9ZmXIsMAiy5oR8GyanYMEuB9++FQKqKJZiY/2hr6s4D7kgdL7E3y0iQCVAgUQ K5cyE6HBOF9KrwDlAQGoXQP+K0aEladxviotML5HAL6Z8Le70hGKR10pMqAvC3QK rPW37eTQ0zspIMOR9ahRtQ6KpOqEdMsWNJPdXlaAVXJS1g2/eLDTtyYxySjv0HTg 4pOQ6ZlxJ0IQXy5bo7mJArSY6Ab9fkHSJp57/WjYnRriwJ3jb2flDTanxNyEUocz cNyJAJUCBRArY+YsNlaXxjLdmNkBAQxGA/9ojDJpeuXhWjVqzT+2m2IfEFt/jJ48 peQjaQIxpMXo5iJuJ2SqlBzeQ7hs6SQ57LUcG8+nWlyteV3KDNZvILobulMyMB7P foWyhOop0ws+AtJhOeT0prxf3o43sZxs7IhabhZ4zf7Ea0h3Oe35TiFFgQmQ/B4s 892mAcZr8CfOt4kAlQIFECsRFxzidd4O/2f3CwEBsmID/2qXL/VdjGxxYFNIZdA+ DC6howUXlHw66MUArILE2/9J69VvcpbQTKmD4A+04SwH9q8SDzWxsg+1VANuy08E E0up9pm7ZBzrxkFcOydhsEwOt9fRn9EJ3tDNYe1SVoxV9Fc47of55Om7cTNrky0h dp1LA13uf/TeV3nrBYa21zaz =88H8 - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLe7bB94nNf3ah8DHAQH8IQQAmqUpS3pCl1ByhKebRbp5ingyuk4WFkY0 T57ugOcVALqfmI7L1Cju/Hz6RkrJPrmfNqVmjY55XgXbrteZ8sXJ6ZS+wSsxP281 hRSTe83oaBN/JJXNc7rUkzkv6pUvWzzdE6ngj07PSIM0uOnm6HnNhrz+Md14l4vG 04LBE5T0DPw= =qpRY -----END PGP SIGNATURE----- -- edgar(a)spectrx.sbay.org (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

digital clearinghouse idea
by edgar＠spectrx.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Eric Hughs said, If you use the ACH system, you can't pre-authorize sporadic payments for arbitrary amounts. ... Not true. Counter-example: I recently authorized automatic (ACH) payments from my bank account to pay my Discover Card (tm) bills. These are both sporadic (some months may have no purchases) and in varying amounts, usually a few hundred dollars, occasionally a few thousand. Personal note: This feature of DC is especially valuable, since they tend to have a short billing cycle and send their statement around the middle of the month, too late to pay with all the other monthly bills. The automatic payment is scheduled -after- the time limit for normal payments, at the start of the next billing cycle (but still no finance charge). DC does not publicize this option. You have to call them & ask about it. ACH also pays my PG&E bill, which is not sporadic, but (obviously) does vary in amount. Same with the water bill. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLe9z1N4nNf3ah8DHAQH3pQQAknjEoByxvF5XGQYrUvOq6Tdw4agBqPzD THbC2JQaJJ0jRUVu7wvW/oU381MlTRIKU5EsR32pJb1qu0lARUbbxint1Atn4Ini e8TBfKR49WX5cNVrbpKVYMrMCLTv5yWhA1RtasSggoTLHqm9XSq2NpK5LIiEtpPc FUaYJ/2F2Pg= =bFyB -----END PGP SIGNATURE----- -- edgar(a)spectrx.sbay.org (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

FW: NSA Takes Over Healthcare Reform
by Blanc Weber 17 Dec '03

17 Dec '03

From: Dr. David Chaos <dchaos(a)delphi.com> Newsgroups: comp.org.eff.talk Date: Fri, 3 Jun 94 02:07:20 -0500 June 3, 1994 NSA CLIPPER CHIP FAILS, AGENCY SETS SIGHTS ON HEALTHCARE (ups) After the discovery of a fatal design flaw in the Clipper chip's "crime-busting" LEAF system, NSA has shifted its focus to a "more attainable goal, healthcare reform", said an anonymous government source. "It appears that President Clinton's healthcare reform package will likely result in citizens, who can afford it, leaving the country for private healthcare provided by foreign countries. Based on this, NSA believes they have a clear, jurisdictional mandate to develop healthcare policy." the source further stated. "With NSA's technological superiority, we should have a system in place which will prevent medical subversion within a few months. Even the Bahamians will be powerless to overcome it" said the source. Despite objections from diverse medical organizations, the President supported NSA's position that they are the most qualified to determine healthcare policy. He further justified the agencies assertion that the details of the policy must remain secret to prevent medical malingerers from abusing the system. Secret details of the policy, obtained by confidential informants, indicated that it would be based on the "KneeCapstone" and the "Clapjack" algorithms. An "independant" examination by the renowned doctor and cold-fusion investigator, Dr. Staley Ponz, was recently conducted on the KneeCapstone and Clapjack algorithms. "These algorithms are totally and completely malingerer proof...I really mean it, this time, honest!" said Dr. Ponz from an undisclosed location in South America. Further details on the plan will be forthcoming "real soon now" said government policy advisor, Tyrone Shoelaces. Reprinted, with permission, by, Dr. David Chaos

1 0

No compulsory licensing of patents in USA.
by greg＠ideath.goldenbear.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Perry Metzger writes: > smb(a)research.att.com says: > > Why can't they refuse to license a patent? > I was under the impression that the law obligated you to license > patents -- albeit not necessarily at an attractive price. I am quite > likely to be mistaken on this -- my memory on the topic is very > sketchy, as demonstrated by the fact that I didn't realize the > government can patent things (although I was right on copyrights.) - From "Intellectual Property: Patents, Trademarks, and Copyright in a Nutshell", pp 12-13, Miller & Davis, West Pub., 1990. (not a particularly authoritative cite, but it ought to do) "During the life of the patent, the owner has the complete right to determine who, if anybody, will have the right to use, make, or sell the patented item, 35 USCA (s) 261, and to a more limited extent, how or where it will be initially exploited. It is important to understand that American law does not require the patentee to put the patent into use or allow others to do so. The first requirement, of putting the patent into use, is called 'working' the patent, a requirement with some historical meaning and considerable foreign patent law significance. The second requirement, of allowing others to use the patent, is called 'compulsory licensing.' Like working, there is no absolute American requirement of compulsory licensing, but other aspects of the law, especially antitrust, may have the effect of obliging a patent owner to license others to use the patent." -----BEGIN PGP SIGNATURE----- Version: 2.5 iQCVAgUBLe+bQn3YhjZY3fMNAQFMbQP/d6MuZtq87sbJIyZQaG05fMfvd2M0uCNP hL18MTRCMAr+6esg5/QOsSwJ7Xd4XiRPFG3Dhq8U1Itl0zemcKd+5u0pxgAP3Dbu GkNTDfk3x5TQMjzScchdkL7+V/yZ3G00GnH+kJwGdfIckJd/35nocN0KFVAle/28 Zi66/HIz3Sc= =AnQK -----END PGP SIGNATURE-----

1 0