December 2003 - cypherpunks-legacy

QUF_jpg
by John Young 17 Dec '03

17 Dec '03

We have scanned "Quantum Computation's" seven formulae and six figures as JPEG graphics files and will send for a plea: quf1.jpg -- Formulae 1-7; 32 kb. quf2.jpg -- Figures 1 and 2; 72 kb. quf3.jpg -- Figures 3 and 4; 95 kb. quf4.jpg -- Figures 5 and 6; 72 kb. Or, we will mash'em up .TIF, .PCX, .GIF, or tire-smeared pigeon. QUF_jpg (4-part package, or items selected) [or *_tif, *_pcx, *_gif, *_tsp]

1 0

Brit conference asks for more cyberspace violations
by Attila T. Hun 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- *** Fraudbusters seek fresh angles as cybercrime grows Crimebusters must devise more ingenious ways of combating fraud and will need new international policing powers to stem a rising tide of high-tech economic crime, experts say. Delegates at an economic crime conference in Cambridge, England, this week complained they lacked the tools and power to take the fight to the organized criminals whose only barrier was the speed of their modems. Culprits were hard to pin down, said Rosalind Wright, head of Britain's Serious Fraud Office. It was harder still to "swat the fly-by-nights," she said. See http://www.infobeat.com/stories/cgi/story.cgi?id=4974072-ff5 ______________________________________________________________________ "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0 -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 Comment: No safety this side of the grave. Never was; never will be iQCVAwUBNB9t9704kQrCC2kFAQGLEQP/Xo9+l5MV3KE3X1X7hCdJpaWr8gprctKR jIm2k+2RwHIVBT9IzQ0s/VEWI+8ftO43b18qlYYdbyiSGCPnJsoZtXOmivTTdcg3 U8FAJNTrbILZ4lcTYbxsAUm0U12xc4flOjK16UWzKrI3gli8Y/YPO2hMbxkBcH6P aknorOx6BpY= =1+3N -----END PGP SIGNATURE-----

1 0

Re: Digicash will not fly (not)
by msprague＠owens.ridgecrest.ca.us 17 Dec '03

17 Dec '03

"James A. Donald" <jamesd(a)echeque.com wrote: >While Chaum is a brilliant cryptographer, he is an incompetent businessman > >He has demonstrated this in numerous ways. > >The latest being "Cash" where the bank skims off 4% to 10% every time. > >No one is going to use digicash under these kinds of terms and >conditions. Doesn't just about everyone do precisely this when they pay sales tax? Every time a buck arrives or departs a hand one pays a tax yet the system (you and I)continues accepting these terms albeit painfully. > --------------------------------------------------------------------- > | >We have the right to defend ourselves | http://www.jim.com/jamesd/ >and our property, because of the kind | >of animals that we are. True law | James A. Donald >derives from this right, not from the | >arbitrary power of the state. | jamesd(a)echeque.com

2 1

Re: Digicash will not fly (not)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:41 AM 10/30/95, M. F. (Pat wrote: >"James A. Donald" <jamesd(a)echeque.com wrote: >>While Chaum is a brilliant cryptographer, he is an incompetent businessman >> >>He has demonstrated this in numerous ways. >> >>The latest being "Cash" where the bank skims off 4% to 10% every time. >> >>No one is going to use digicash under these kinds of terms and >>conditions. > > >Doesn't just about everyone do precisely this when they pay sales tax? >Every time a buck arrives or departs a hand one pays a tax yet the system >(you and I)continues accepting these terms albeit painfully. Many types of business dealings are exempt from sales tax, through arrangements for resales. I don't know if the "skims off 4% to 10% every time" point accurately describes how the current Digicash model works, but certainly this will not fly as a long term rate. So many monetary transactions happen in the course of business that even a 4% fee _per transaction_ would rapidly wipe out most of the value. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2

Cuban Security Conference
by Ross Anderson 17 Dec '03

17 Dec '03

Mr Guevara of the Cuban embassy in London asked me to post this announcement. Pass it on. CALL FOR PAPERS INFORMATICS 96 International Conference Center Pabexpo, Havana, Cuba March 4-9, 1996 INCLUDING 3rd Ibero-American Seminar on Protection against Computer Viruses and Security of Information Technologies * Antivirus and protection software * Security of information technologies, including - diagnostic and security plans - risk analysis, contingency and recovery plans - technical aspects: identification and authentication, cryptography, security models - security organisation and management, security policy, information sorting, training of users and authentication - security evaluation - integration of security systems - audit trail * Experience Chairman of the organising committee: Jose Bidot Pelaez, Chairman, National Committee for Data Protection AND 1st International Seminar on Information Audit * Information audit in business and financial management * Information audit and current technology * Tools for information audit * Controls and risks in information systems * Information audit for information systems Chairman of the organising committee: Fransisco Deiros, President, Information Audit Group, National Committee of Informatics Papers should be sent to the convention secretariat: Lic. Nancy Batard Najarro INFORMATICS 96 Executive Secretary Palacio de las Convenciones Apartado 16046, La Habana, Cuba Tel: +537 33-1466 / 20-6850 Fax: +537 33-1657 / 33-1708 Email: infor96(a)cenisi.cu

1 0

Re: Important Digital Cash Question...
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>What's the right name to use for the Banker? I've been using "Nick", >after Nick Leeson; any other suggestions? How about "Pip", J. Pierpont Morgan's childhood nickname. OK, OK, I'll sit down now... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

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, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33a.tar.gz 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)extropia.wimsey.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub reord"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post ek reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp hash cut reord mix post"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub"; $remailer{"hroller"} = "<hroller(a)c2.org> cpunk pgp hash mix cut ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp. hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)valhalla.phoenix.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut"; $remailer{"ncognito"} = "<ncognito(a)gate.net> cpunk"; $remailer{"precip"} = "<mixmaster(a)mix.precipice.com> cpunk mix pgp hash latent cut ek reord"; $remailer{"ecafe"} = "<remail(a)ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut ek"; 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. Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. remailer email address history latency uptime ----------------------------------------------------------------------- ideath remailer(a)ideath.goldenbear.com -.-.-.---.- 7:12:57 99.97% hacktic remailer(a)utopia.hacktic.nl ************ 9:03 99.95% rmadillo remailer(a)armadillo.com ++++++++++++ 42:02 99.93% ecafe remail(a)ecafe.org **####+*##*# 1:37 99.93% wmono wmono(a)valhalla.phoenix.net ************ 13:17 99.91% penet anon(a)anon.penet.fi ---------+++ 2:58:18 99.74% robo robo(a)c2.org ###--*# 25:08 99.71% spook remailer(a)valhalla.phoenix.net ******** *+* 16:41 99.69% replay remailer(a)replay.com *****+* * ** 6:34 99.52% mix mixmaster(a)remail.obscura.com ---- -- --- 1:44:59 99.46% c2 remail(a)c2.org + +++-- * 53:17 98.82% syrinx syrinx(a)c2.org - _ ____ .+ 55:55:41 97.38% bsu-cs nowhere(a)bsu-cs.bsu.edu *** # #-+# 24:49 97.23% flame remailer(a)flame.alias.net * **+* 24:32 92.21% vishnu mixmaster(a)vishnu.alias.net * +*** 10:39 90.65% rahul homer(a)rahul.net ***#*+ +#*** 2:53 99.79% alumni hal(a)alumni.caltech.edu +++#**-*+# 7:27 86.61% portal hfinney(a)shell.portal.com **##*#-### 5:38 86.60% ford remailer(a)bi-node.zerberus.de ____.-- 38:06:00 86.33% extropia remail(a)extropia.wimsey.com - . - - 5:24:35 63.83% 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: Digicash will not fly (not)
by Michael J Gebis 17 Dec '03

17 Dec '03

> >While Chaum is a brilliant cryptographer, he is an incompetent businessman > >He has demonstrated this in numerous ways. > >The latest being "Cash" where the bank skims off 4% to 10% every time. > >No one is going to use digicash under these kinds of terms and > >conditions. > Doesn't just about everyone do precisely this when they pay sales tax? > Every time a buck arrives or departs a hand one pays a tax yet the > system (you and I)continues accepting these terms albeit painfully. Theoretically, when I pay sales tax I get something in return (better roads, nicer schools, improved NSA wiretaping, and other government services.) With digicash, you're paying for the use of the money itself. What sort of charges do Visa/Mastercard impose upon merchants? I thought it was 3%; if so, I would suspect that this is the level of "off-the-top" skim that the market will sustain, and DigiCash should probably use a similar rate. -- Mike Gebis gebis(a)ecn.purdue.edu Corporate Operating Systems Still Suck

2 1

Re: Digicash will not fly (not)
by Dave Farber 17 Dec '03

17 Dec '03

> >What sort of charges do Visa/Mastercard impose upon merchants? I >thought it was 3%; if so, I would suspect that this is the level of >"off-the-top" skim that the market will sustain, and DigiCash should >probably use a similar rate. > >-- >Mike Gebis gebis(a)ecn.purdue.edu Corporate Operating Systems Still Suck > Pricing is usally set so it includes the 3%. Cash prices are usually by agreement the same as credit card. Will Digicash be an extra %age or will the credit card agreements be changed Else it is 3% plus digicash for those goods that offer the credit card option

1 0

Re: Cuban Security Conference
by Bill Stewart 17 Dec '03

17 Dec '03

> International Conference Center > Pabexpo, Havana, Cuba > March 4-9, 1996 > 3rd Ibero-American Seminar on Protection against > Computer Viruses and Security of Information Technologies I wonder if they'd be receptive to talks on private communications, digicash, tax avoidance through digital technology, anarchy and collapse of government power, etc. :-) (Maybe they would; Cuba's got to do something to get their economy out of the post-Soviet-subsidy doldrums, and with the US preventing free trade in sugar for them, maybe allowing capitalism will be their only choice...) For any Yankees interested in going, you generally need to be a journalist of some sort to avoid the Trading With The Enemy Act restrictions, but in cyberspace, that's easily arranged. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

3 2

Re: Pinkerton Risk Assessment & "Security 2000"
by Joel McNamara 17 Dec '03

17 Dec '03

For even more, free information of this type, see the Counter-Terrorism page: http://www.interlog.com/~vabiro/ An interesting collection of links and data... Joel

1 0

I-D ACTION:draft-eastlake-cybercash-v08-01.txt
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 70 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : CyberCash Credit Card Protocol Version 0.8 Author(s) : D. Eastlake, B. Boesch, S. Crocker, M. Yesil Filename : draft-eastlake-cybercash-v08-01.txt Pages : 55 Date : 10/27/1995 CyberCash is developing a general payments system for use over the Internet. The structure and communications protocols of version 0.8 are described. This version includes credit card payments only. Additional capabilities are planned for future versions. This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. CyberCash is committed to the further development of its system and to cooperation with the Internet Engineering Task Force and other standards organizations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eastlake-cybercash-v08-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-eastlake-cybercash-v08-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-eastlake-cybercash-v08-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts(a)cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Charset: us-ascii X-Sun-Content-Lines: 24 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv(a)ds.internic.net" Content-Type: text/plain Content-ID: <19951027135555.I-D(a)CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-eastlake-cybercash-v08-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-eastlake-cybercash-v08-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951027135555.I-D(a)CNRI.Reston.VA.US> --OtherAccess-- _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Important Digital Cash Question...
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>I think that the bankers name should be Ethel however. > > Phill Wait, wait! I have another one. I call digital cash bankers "underwriters", because they're basically underwriting digital certificates, like an underwriter in the capital markets does. So, we need a "U" name... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

3 2

DOD_com
by John Young 17 Dec '03

17 Dec '03

10-30-95. Wash Rag: "Pentagon Plans More Espionage. Business Fronts Abroad Would Expand Efforts Of a Unified Service." The Defense Department has merged its separate covert intelligence operations and plans to expand its espionage abroad, starting with establishment of phony businesses overseas as cover, and has formed the Defense HUMINT (Human Intelligence) Service, or DHS. Under the fiscal 1996 intelligence authorization bill, the DHS has been given a trial period of three years to carry on commercial activities "to provide cover security to intelligence collection activities undertaken abroad." The authority "to provide bona fide commercial cover," was so that DHS's covert operatives could "withstand detailed investigation by hostile foreign intelligence services as well as domestic scrutiny." ... scandal of the Army's Yellow Fruit op ... CIA case officers are working with DHS on the cover companies abroad; cooperation is needed because in recent years military spies overseas inadvertently had set up relations with foreigners known to be double agents. Sen. Bob Kerrey called on CIA Director John M. Deutch to "develop his human collectors, planning 10 or more years in advance for their peak usefulness," a reference to placing them abroad under deep cover for use in future crises. DOD_com (8 kb)

1 0

/dev/random for FreeBSD [was: Re: /dev/random for Linux]
by Mark Murray 17 Dec '03

17 Dec '03

> > > On this same track, I suggest that "/dev/random" devices for unix are > > > an excellent idea. Ted Tso did one for Linux that steals all the bits > > > of semi-random timing information it can. > > > > Anyone know where I can find more information on this wonderful device? > > I've just sent patches (versus the Linux 1.3.28 kernel) off to Linus. > There's a fairly long exposition at the beginning of > drivers/char/random.c which explain its theory of operation. A colleague drew my attention to this, and I was so pleased with it that I ported it to FreeBSD. I kept the interface as close to the original as I could, but made some changes for efficiency and ease: 1) I turned the huge comment at the top explaining the theory of operation into a man page (random(4)). 2) We felt that hooking all interrupts might be dangerous. IDE drives can interrupt at a heck of a rate, and so can some serial ports, and we felt that in these cases _not_ using the interrupt was a good idea. So I added an ioctl to allow the superuser to select his own set, appropriate to the hardware in use. It is nearly impossible to do this automatically. Gimme a yell if you want copies :-) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

2 1

Re: CJR returned to sender
by James A. Donald 17 Dec '03

17 Dec '03

At 10:16 PM 10/30/95 -0800, Jeff Weinstein wrote: > It [CJR application for T shirts] will force the bureaucrats > to make a decision, You cannot force bureaucrats to make a decision. They will act if it suits their purpose, and otherwise they will not act. Basic of principle of strategy in Go: If you give the other guy choices, you will lose. That is why go players always play asymmetrically if the stones are symmetric. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Keyed-MD5, ITAR, and HTTP-NG
by Simon Spero 17 Dec '03

17 Dec '03

To summarise: the consensus is that using keyed-MD5 for authentication is ok under ITAR, but using it for confidentiality is out. The reason I wanted to check is that I'm solidifying some of security paramaters for HTTP-NG so we can add them to the test implementation before the Dallas IETF. In addition to the slight problem of having half the development team on the other side of the Atlantic, I want to make at least a subset of the security schemes mandatory, and that means making the core stuff exportable. At the moment, I'm thinking of making the mandatory schemes be Keyed MD5 for authentication, and weakened RC4 with an IV for confidentiality, with the added stipulation being that the user must be informed when key weakening is being used. I may swap RC4 for DES; they're both public domain, but RC4 is simpler. They're both shared key, but I don't make PK stuff mandatory. The other pre-defined schemes I'm planning on getting at least speced are 3-DES and IDEA for confidetiality, SHA for hashing, and RSA & DH for key exchange, signatures, and authentication. Certificate format is currently X.509- PGP format will go in ASAP. Simon --- (defun modexpt (x y n) "computes (x^y) mod n" (cond ((= y 0) 1) ((= y 1) (mod x n)) ((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n)) (t (mod (* x (modexpt x (1- y) n)) n))))

10 13

Re: Don't Kill the Messenger--A New Slant on Remailers
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Sun, 29 Oct 1995, Bill Stewart wrote: > More of a problem with this system is that it's only useful for terminal > remailers; to use it in the middle of a chain, the next remailer would > need to be configured to auto-accept such messages, or else your remailer > would need to have a list of known remailers and use direct delivery > for all mail sent to them. That's not a problem with Mixmaster, as it already knows whether the message is the last hop of a chain or not. I was hoping to get my hack finished this weekend, but got caught up in CTCP instead (which I'll release once I find out why it kills my xterm on exit 8-().. Mark

1 0

Keyed-MD5, and HTTP-NG
by baldwin 17 Dec '03

17 Dec '03

Simon, There are a few different ways to add key material to MD5 to make it suitable as a shared-secret authenticator function. Some of these are less resistant to attacks than others. For example, the keyed MD5 mechanism that is part of the current IPsec specifications can be attacked using 2**60 chosen messages. Fortunately, the IPsec specs also require that the shared MD5 key be changed every 2**32 messages, so this attack is unlikely to succeed. Specifically, IPsec uses MD5 as follows: X = MD5(key | keypad | Message), where "|" means concatenation and the "keypad" pads out the key to 512 bits. Basically, this function is the same as standard MD5 with a different initialization vector for the compression operation on the first block of the message. RSA Labs recommends that a people use an authenticator like X = MD5(key1, MD5(key2, Message)). This resists the chosen plaintext attacks that were published at the crypto conference in Spring 1995. There are also some very fast MAC algorithms being proposed these days. As Phill Hallam mentioned, you may want to look at the work of Phil Rogaway. At a minimum, make sure that your standard allows people to migrate from a current solution based on MD5 to a future solution based on new functions. However, I would be relunctant to require new functions until they have had a chance to be tested by the cryptographic research community. --Bob Baldwin

3 2

[joanne@theory.lcs.mit.edu: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!!]
by lethin＠ai.mit.edu 17 Dec '03

17 Dec '03

From: joanne(a)theory.lcs.mit.edu (Joanne Talbot) Date: Mon, 30 Oct 95 12:23:33 EST To: theory-seminars(a)theory.lcs.mit.edu Reply-To: theory-seminars-request(a)theory.lcs.mit.edu Subject: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!! MIT TOC SEMINAR Thursday, November 2, 1995 Refreshments at 4:00pm, Talk at 4:15pm in NE43-518 ``Quantum Cryptoanalysis of Hidden Linear Forms'' by Dan Boneh Princeton University ABSTRACT Recently there has been a great deal of interest in the power of Quantum Computers. The driving force is the recent beautiful result of Shor that shows that discrete log and factoring are solvable in random quantum polynomial time. We use a method similar to Shor's to obtain a general theorem about quantum polynomial time. We show that any cryptosystem based on what we refer to as a `hidden linear form' can be broken in quantum polynomial time. Our results imply that the discrete log problem is doable in quantum polynomial time over any group including Galois fields and elliptic curves. Joint work with Richard Lipton. Host: Shafi Goldwasser

1 0

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
by Mark Murray 17 Dec '03

17 Dec '03

> Date: Mon, 30 Oct 1995 20:16:24 +0200 > From: Mark Murray <mark(a)grondar.za> > > A colleague drew my attention to this, and I was so pleased with it that > I ported it to FreeBSD. > > Which version did you grab? More recent versions of the driver use a > more efficient mixing algorithm suggested by Colin Plum. There's also > the beginnings of support for user-mode deamons to add randomness into > the random pool by writing to /dev/random. I also added support for > reading the instruction timing register for x86 platforms that support > it. Version 0.92 21st Sept 1995. Something I didn't mention earlier; we felt that letting the unwashed masses read /dev/*random was not a good idea, as they could deplete the pool of entropy all to easily for attack purposes. For the same (or similar) reason, giving the said unwashed masses _write_ privelige might allow them to set /dev/*random to a known state. You've probably already thought of this, but I just had to say it :-). > 2) We felt that hooking all interrupts might be dangerous. IDE drives can > interrupt at a heck of a rate, and so can some serial ports, and we felt > that in these cases _not_ using the interrupt was a good idea. So I > added an ioctl to allow the superuser to select his own set, appropriate > to the hardware in use. It is nearly impossible to do this automatically. > > Indeed; I can't emphasize this enough. The clock interrupt, for > example, is a very bad irq to try to use. In the Linux driver, only > device drivers who register their interrupt driver with the > SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for > the random number generator. (Hmm.. Thinks of ways of doing something similar. I'm not functioning too well right now.) > People have suggested using making it possible to select at run-time > which interrupts to sample, instead of at compiling it into the device > drivers. I've generally not been convinced this is a good idea, because > most system administrator won't likely know which irq's are good and > which are bad for random number generation. For example, although it > may not be obvious, the network interrupt may not be a good choice, > since an adversary who is monitoring the ethernet cable can make a > pretty good guess about the timing of your network interrupts, and hence > what the likely inputs are to the random number pool might be. Are you sure about this? The stochastisity if this would be pretty hefty. Not only would our attacker have to get the _time_ that the interrupt occurred (if it interrupted our machine), he would then have to process in brute-force mode all possible times in his error range. What is more, more interrupts are coming in... > Gimme a yell if you want copies :-) > > Sure, why not. I'd be interested to see what you did. Hokay! Please also send me _your_ latest. (BTW - did Linus put it in his latest kernel?) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

3 2

Re: Keyed-MD5, ITAR, and HTTP-NG
by Rich Salz 17 Dec '03

17 Dec '03

>At the moment, I'm thinking of making the mandatory schemes be Keyed MD5 >for authentication, and weakened RC4 with an IV for confidentiality, with >the added stipulation being that the user must be informed when key >weakening is being used. I may swap RC4 for DES; they're both public >domain, but RC4 is simpler. They're both shared key, but I don't make PK >stuff mandatory. The licensed version of RC4, or the software that was posted anonymously? Do you really feel comfortable basing an IETF standard on that? When you use the term RC4 do you mean the real version or the posted one, what will you do if they ever conflict? Can you even use the name RC4 for the posted version? It seems to me that RC4 means the RSA licensed code, which presumably you wanted to avoid when you wrote no mandatory PK. Where would you swap RC4 for DES? I assume your added stipulation is a "should" not a "must" item. How are you going to handle key management and naming? /r$

2 1

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
by Mark Murray 17 Dec '03

17 Dec '03

> Something I didn't mention earlier; we felt that letting the unwashed > masses read /dev/*random was not a good idea, as they could deplete > the pool of entropy all to easily for attack purposes. > > That should be a system administration issue. If someone wants to make > /dev/random readable only by root at their site, that's their business. > I don't see any point in trying to enforce that in the kernel code. Is not in the kernel, this is just the permissions on /dev/*random. > I don't agree that restricting read access is useful. First of all, if > the pool of entropy is depleted, someone who tries to obtain entropy by > reading /dev/random will know that they didn't get enough entropy. So > assuming a program that actually checks return values from system calls, > this is at worse a denial of service attack, and there are much easier > ways of performing those srots of attacks: "while (1) fork()", for > example. Hmm. Lemme think about this... > Secondly, making /dev/random only readable by "privileged programs" > means that people won't be able to compile their own version of PGP that > can take advantage of the random number generator. Instead, they would > have to use a setuid version of PGP, and I'm quite sure PGP wasn't > written such that it would be safe to turn on its setuid bit. How about SetGID? We were going for 660 root.kmem. > Finally, even if you did have trustworthy applications which you could > setuid and only allow those programs to have access to /dev/random, > someone who repeatedly ran those applications could still end up > depleteing the pool of entropy. > > So in the general case I would advise that /dev/random be left world > readable, since you *do* want general user programs to have access to > high quality random numbers. Ponder... I'll put this forward. > Again, /dev/random can be set to whatever permissions the system > administrator wants. Secondly, writing to /dev/random merely adds > randomness to the pool, via the mixing algorithm. It won't actually > permit people to *set* the state of the pool, and assuming that the > state of the pool is not known before the write operation, writing to it > won't allow the user to know what the state is after the write > operation. What happens if some attacker does: for (;;) { write_to_devrandom(NULL); check_to_see_if_state_is_crackable(); } ? "Gut feel" suggests to me that large ammounts of "predicted" input might be worse than the normal sort of system noise you have been using. > And, for race condition reasons, something which I need to implement > soon is an ioctl(), usuable only by root, that simultaneously updates > the entropy estimate *and* submits data to be mixed into the pool. (Why > this is necessary should be obvious after a few minutes thought.) Clue me in - I'm not quite with you? :-) > Are you sure about this? The stochastisity if this would be pretty > hefty. Not only would our attacker have to get the _time_ that the > interrupt occurred (if it interrupted our machine), he would then have > to process in brute-force mode all possible times in his error range. > What is more, more interrupts are coming in... > > I didn't say that it would be trivial for an attacker to do this, but > it's certainly *doable*. Some of the network traffic analyzers that > have been made available (I think Sandia National Labs has one that does > this), records down to millisecond accuracy when a packet was sniffed on > the network. Is this millisecond accuracy quantifiable in terms of bits of entropy? if so, the ethernet is surely safe? > For this reason, people shouldn't really trust initializing PGP's random > number generator over a network connection, since it is possible for an > adversary to obtain very high quality timings of when your telnet or > rlogin packets appeared on the network, and hence be able to guess > (within some error range) what the interkeyboard timings which PGP used > to initialize its random number generator. > > The adversary might have to try a large number of possibilities, but if > the number of possibilities is less than a brute-force search, you > definitely have a weakness --- a fact which Netscape learned to its > embarassment a few weeks ago. Again, if you can quantify the number of possibilities into bits of entropy, your code is good. Depending on current technology, this may have to change. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

5 5

payee anonymity
by Hal 17 Dec '03

17 Dec '03

Another way payees could be anonymous would be to immediately spend their received coins, and do so anonymously. This works for the online ecash system. They simply pass the coins on without first exchanging them at the bank. There would have to be something they wanted to buy that they could receive anonymously, though. Hal

1 0

Re: S. 1284 To Amend (C) Act
by Weld Pond 17 Dec '03

17 Dec '03

>> S. 1284, s1201: "No person shall import, manufacture or distribute >> any device, product, or component incorporated into a device or >> product, or offer or perform any service, the primary purpose or ^^^^^^^^^^^^^^^ >IANAL, but I thought these types of laws were already tested and deemed >unconstitutional in cases involving video-tape copying boxes, dual video >cassette dubbing decks, SCMS 'scrubbers', etc... I think the large gray area here is the phrase primary purpose. The primary purpose of a device is in the users mind only. Videotape copying of noncopyright materials is done on a vast scale now due to home camcorders. But even if only a few people had camcorders they should be able to purchase equipment that can be used legally. Introducing the concept of "primary purpose" makes law abiding citizens suffer because some people are breaking the law. If an item has any legal purpose it must be allowed. This trend to take technology that *can* be used to commit crimes out of the hands of citizen units is growing. We see it with crypto export controls and recently with the PA law and Federal law making it a crime to posess devices and software to reprogram cell phones. When this doesn't make a dent in the number of these crimes I predict we will see licensing of technologies such as eeprom programmers, spectrum analyzers, frequency counters, and yes of course strong crypto. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio

1 0