December 2003 - cypherpunks-legacy

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

Article on PGP (Noise)
by Eric Anderson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- C'punks I saw a good article on PGP in this month's issue of American Survival Guide. Not only did the article portray the use ofstrong crypto as a good thing for privacy and liberty, it also tells the reader where to obtain PGP. After that, the article goes into some of the issues surrounding PGP such as ITAR, Phil Zimmerman's legal troubles (It even tells how to contribute to his legal fund.) and how the government is really against it. After the background, the article gives clear, detailed, step by step instructions on how to use it; from the inital unzipping of the program to setup and key generation and management. All in all, I found this a very informative article for the new user and even some of the more advanced users (Hey-you learn something new every day, right?). It wasn't the type of article that wouldn't be covered in Time or Newsweak that's for sure. Eric -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMJWDeyQV+sMsxjC5AQGT9QH9E8BHovGCmu7p9wB2nYQzmebqFPw3sfnR 2CuFTSvkdbg/4yArOsE87S+g28I2B/tscaVYdAO8HA5CdhVVAxbH0w== =wjpi -----END PGP SIGNATURE-----

1 0

Pinkerton Risk Assessment & "Security 2000"
by blancw＠accessone.com 17 Dec '03

17 Dec '03

I have been broswing through the MSN (Microsoft Network), and discovered a section in the "SOHO" (Small Home Owner's Guidebook) called "Partners Pages". In it there is a list of companies with icons which subscribers can click on to view these companies' business/financial-related services. One of them is the Pinkerton Risk Assessment Service. I opened & examined their several icons, and it suddenly occurred to me how useful this kind of on-line information could be to individuals in the new anarcho-capitalist, nationally-borderless world. Sort of in keeping with the theme which Sandy Sandfort and Duncan Frissell brought up with their "lectures" on "Risk" last year, as well as what I had said in an earlier post about people in our brave new world needing to become imaginative in providing for their own self-defense (seeing as how trusting the goverment doesn't work so well), it occurred to me that having information on threats to one's physical safety would be fitting for this need - like the RISK mailing list is for computers/software. This kind of data would be different from what we can get on the regular news, which is combined with many other kinds of news and is very generalized, in that it deals more specifically with the subject. They advertise their services as: "... the risk assessment tool for the 21st century. If you or other members of your company travel internationally, the Global Risk Network on MSN. is an invaluable service, keeping you informed of worldwide events, political turmoil, global sensitive spots, and more! Now you have direct online access to a wealth of exclusive Pinkerton information, all via your computer. You can even order hard copy reports or have customized research performed by Pinkerton Risk Assessment experts, simply type in your request. Tailored for the individual traveler, as well as the corporate executive, our risk services give you several options to know the security situation anywhere." Although their services are advertised for the corporate business traveler, it obviously is of use to any traveler, and particularly to the person who is in the location mentioned. They have icons opening up to BBSes where they report on trouble spots and potential threats in a timely manner: "The Global Risk Network provides even more detailed country data, including The Daily Risk Assessment Weekly Risk Assessment Special reports Statistical analysis of significant incidents by country and region Security tips Eye on Travel " You would think that if the NSA & other State Departments used their services, that they wouldn't need to poke around people's computers to better predict where to put added security for high honcho dignitaries or State office buildings. But isn't that what the intelligence services are for? Oh, well. Here, I thought, is a great service for the regular person which they can use to be prepared for the exigencies of life's little problems, like terrorists and other restive types with violence on their mind. For any of you in the Washington, D.C. area, there will be a lecture from Pinkerton next week as detailed below. If anyone from this list goes, it would be interesting to get a post on what they say - the section on cybersecurity might be of relevance to the list. (I got this from the same location on their MSN site.): IN COOPERATION WITH THE GEORGE WASHINGTON UNIVERSITY PRESENTS SECURITY 2000 Please join us at The George Washington University's Marvin Center on November 9, 1995, for a seminar on topics of vital interest to security professionals. The seminar will highlight the opportunities and challenges of the security environment in China; computer crime and how it can affect your business; a global overview of political unrest, terrorism and crime,; and a demonstration of the new Pinkerton Global Risk Network on the Microsoft Network. Join us for the news, views and tools for ensuring your organization's security as we approach the 21st century. Featuring: 0800-0900 China and Southeast Asia - Dan Grove, Pinkerton - Asia 0910-1000 Cybercrime - Special Agent Jim Christy, Air Force Office of Special Investigations 1010-1110 Global Patterns and Trends - Hugh Barber, Pinkerton Risk Assessment Services 1120-1220 Pinkerton Global Risk Network on the Microsoft Network - Demonstrated by Frank Johns and Hugh Barber, Pinkerton Risk Assessment Services 1230-1400 Lunch - GWU Club (no charge) The GWU campus is just off the Foggy Bottom Metro stop, in Washington D.C., near the U.S. Department of State, where the annual OSAC conference will take place on November 7-8. There is no fee for the seminar, however, seating is limited. Please RSVP by calling Pinkerton Risk Assessment Services at (703) 525-6111, Fax (703) 525-2454 or via e-mail at: pras(a)access.digex.net -------------- .. Blanc

2 1

Re: Cuban Security Conference
by James A. Donald 17 Dec '03

17 Dec '03

At 01:22 PM 10/30/95 -0500, s1113645(a)tesla.cc.uottawa.ca wrote: > For that matter is civilian use of strong (or any other kind) crypto actually > legal in Cuba? Anyone know the policies? (duh, lemme guess...) Well everything is legal in Cuba since there are no discernable laws, only policies, however at they time that I visited Cuba those phones available to ordinary citizens had a phonekeeper seated right beside the phone. On the other hand, no one would stop you setting up a data haven or some such in Cuba, provided it was strictly off limits to Cubans, but you could not set up a bank, because sooner or later somebody quite important would help themselves to the banks assets. --------------------------------------------------------------------- | 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

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

17 Dec '03

All your individual answers make sense. Taken together, tho, they make HTTP-NG worrisome on the crypto front. For example, it's probably a real bad idea to replace DES with something commonly called RC4. The former has been under public scrutiny for years, the later still has not formally emerged from the shroud of trade secret. The keyed MD5 responses also don't inspire confidence. With all due respect, I strongly encourage you to leave crypto out of HTTP-NG for the time being. Wait to see what happens from the various IPng security, SSL, S-HTTP, the W3C work, et cetera. Leave some "holes" in the protocol, but don't tie anything down now. For better for the Web to wait six to 12 months for HTTP-NG, then for mistakes to occur in this area. /r$

4 5

Copy Protection Schemes
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 10:58 PM 10/30/95, Andrew Loewenstern wrote: >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... The copy-defeat and SCMS scrubbers exist in a legal limbo, mainly being sold for "other purposes" and often by companies which come and go in the back pages of audio and video magazines. For example, I've used a audio gadget (Audio Alchemy "DTI") that reclocks the bit stream out of a digital source (CD or DAT player)...one of the side effects is that it also strips (or resets, to be more precise) the SCMS bits on a DAT recording. Effectively, it defeats the SCMS (Serial Copy Management System) copy protection scheme. The company that makes it is of coure well aware of this side effect, as is the audiophile/DAT community, but the company (Audio Alchemy) takes great pains _not_ to mention this side effect in their literature. Likewise, the various Macrovision video copy protection scheme defeaters, such as may be found in the back pages of video magazines, are "for the legitimate user only." I'm fairly certain that any open and aboveboard advertising of such products as "copy protection defeaters" would face legal challenges under the copyright laws. The Go Video and other dual-cassette systems have ostensible legitimate uses (notably, copying of tapes one has made, perhaps of lectures or speeches or other personal recordings) and have been "allowed." In particular, Go Video was held up in its plans for a couple of years while lawyers and regulators negotiated. Other cases, such as the Sony-Disney Betamax case, and, indeed, the Xerox machine itself, involve other issues. Practicalities of enforcement are one of the most important issues. The Supreme Court obviously looked at the noninfringing uses (home movies, for example), the difficulty of enforcing laws against the taping of television shows and movies, etc., and concluded that technology and markets had made that particular aspect of copyright law moot. The rationale of "time-shifting" was just the best face they could put on it, in my view. Anyway, there are lots of issues and lots of nuances. --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."

1 0

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

17 Dec '03

How are you going to handle mechanism negotiation?

3 2

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

17 Dec '03

> When /dev/random doesn't have "enough" enthropy left does reading > from it return an error, or block? I would strongly suggest > blocking, as the non-blocking behavur is not really all that useful. It returns EOF. 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

1 0

Re: InfoWar
by koontz＠MasPar.COM 17 Dec '03

17 Dec '03

>Industry representatives played down the privacy loopholes. >Ronald Plesser, a Washington attorney who represents online >services and direct marketing firms, said, "I know of no >example of anybody trafficking in e-mail descriptions." A >spokeswoman for Hughes Electronics Corp.'s DirecTV said, "We >do not release names of customers that ordered movies. The name of the customer of a video tape rental may be disclosed only under narrow constraints (USC 18 Chap 121 2710): * (b) Video Tape Rental and Sale Records. - (1) A video tape service provider who knowingly discloses, to any person, personally identifiable information concerning any consumer of such provider shall be liable to the aggrieved person for the relief provided in subsection (d). (2) A video tape service provider may disclose personally identifiable information concerning any consumer - o (A) to the consumer; o (B) to any person with the informed, written consent of the consumer given at the time the disclosure is sought; o (C) to a law enforcement agency pursuant to a warrant issued under the Federal Rules of Criminal Procedure, an equivalent State warrant, a grand jury subpoena, or a court order; o (D) to any person if the disclosure is solely of the names and addresses of consumers and if - + (i) the video tape service provider has provided the consumer with the opportunity, in a clear and conspicuous manner, to prohibit such disclosure; and + (ii) the disclosure does not identify the title, description, or subject matter of any video tapes or other audio visual material; however, the subject matter of such materials may be disclosed if the disclosure is for the exclusive use of marketing goods and services directly to the consumer; o (E) to any person if the disclosure is incident to the ordinary course of business of the video tape service provider; or o (F) pursuant to a court order, in a civil proceeding upon a showing of compelling need for the information that cannot be accommodated by any other means, if - + (i) the consumer is given reasonable notice, by the person seeking the disclosure, of the court proceeding relevant to the issuance of the court order; and + (ii) the consumer is afforded the opportunity to appear and contest the claim of the person seeking the disclosure. If an order is granted pursuant to subparagraph (C) or (F), the court shall impose appropriate safeguards against unauthorized disclosure. (3) Court orders authorizing disclosure under subparagraph (C) shall issue only with prior notice to the consumer and only if the law enforcement agency shows that there is probable cause to believe that the records or other information sought are relevant to a legitimate law enforcement inquiry. In the case of a State government authority, such a court order shall not issue if prohibited by the law of such State. A court issuing an order pursuant to this section, on a motion made promptly by the video tape service provider, may quash or modify such order if the information or records requested are unreasonably voluminous in nature or if compliance with such order otherwise would cause an unreasonable burden on such provider. * (c) Civil Action. - (1) Any person aggrieved by any act of a person in violation of this section may bring a civil action in a United States district court. In other words it can be a federal crime to release personal info. (Without regard to ordering movies over the internet)

2 1