December 2003 - cypherpunks-legacy

Re: [NTSEC] NT 5 questions (fwd)
by Ray Arachelian 17 Dec '03

17 Dec '03

=====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian |Prying open my 3rd eye. So good to see |./|\. ..\|/..|sunder(a)sundernet.com|you once again. I thought you were |/\|/\ <--*-->| ------------------ |hiding, and you thought that I had run |\/|\/ ../|\..| "A toast to Odin, |away chasing the tail of dogma. I opened|.\|/. .+.v.+.|God of screwdrivers"|my eye and there we were.... |..... ======================= http://www.sundernet.com ========================== ---------- Forwarded message ---------- Date: Sun, 12 Oct 1997 16:44:38 -0000 From: Peter Fey <fey(a)nue.et-inf.uni-siegen.de> To: ntsecurity(a)iss.net Subject: Re: [NTSEC] NT 5 questions Hi Matt, first - the last 2-3 days I've been 'BEHIND' the list - had to read some 200 mails to get by. ;-)() So maybe someone else did anser just your first question. > One of the addition to NT is disk encryption w/escrow. Is this the > Kerberos aspect of it? Right, one of the new features of NT 5 is the EFS (Encryption File System) including a feature called data-recovery. The EFS is an additional layer above good-old NTFS to allow users to encrypt single files, directories and whats below or whole drives. One reason Microsoft added EFS was to nihilate tools like NTFSDOS --- reading an NTFS-volume just by booting it on a DOS-disk in the NTbox. Another is protection of -lost- notebooks and the like ... As the whitepaper on the M$ site shows, the made up a pretty easy to handle and ?? pretty secure ?? to deal with system. Using asymmetric cryptography - i.e. private and public keys - they are up2date in technology and supporting weak and strong encryption 40/56 bit DES they confirm with the US export restrictions on cry. An migration path from 40 to 56 bit is mentioned too - if restrictions will lower down. (Hope so !) The second aspect of EFS ist the ?option? to data-recovery (not key recovery or key escrow). There is one/more Security Agents -the Admin or delegated persons- whose public key will be used in an additional encrypted-block to give companies the possibility to restore the !! DATA !!! encrypted with the public key of that Sec-Agent. NOTE: The private key of the user will not be used or made public to anyone at anytime !! (Replace anyone by Company, Manager, Hacker, Government, FBI or the like) By this it seems to be true data-recovery as should be. The open question states itself - what backdoors did/had to M$ implement to cope with US. --- Kerberos v5 is something completely different ! It is build up to replace the silly plaintext and the clever (but broken) challenge/response protocols of older versions of NT. [Call for Hackers] On the one hand you will loose lots of compatibility but gain lots of security. It is strongly used in the authentication of the new directory structure of NT 5 (another withepaper to read). Kerb v5 also points in the direction of DCE / *NIX compatibility. --- IMHO the effort of M$ is quite good but not nearly completed as there are several needed features not implemented yet and announced for NT 5.x or 6. And its a BETA if you have it ! As you can think I'm really hot to get the NT5 beta to test those new features. --- Discuss it : ) Peter simply a german student (and nearly MCSE)

1 0

Re: Stronghold
by John Young 17 Dec '03

17 Dec '03

Dimitri and Adam queried about me receiving a C2-lawyer letter to DV: I didn't see the letter, either on cpunks unedited (where I remained subscribed throughout the experiment and happily continue to be despite genocidal warnings to desist). Nor did I get a copy directly from Dimitri as he claims to have sent as cc, which I doubt. I suspect that if there is, or was, such a letter, it's either a fabrication of Dimitri himself, or a message he calculatedly sought so he could flag wave it. A page from the book of secret agents. Dimitri, Allah bless his carcass, is a learned and deft provocateur. So the problem I've got with Dimitri's allegations is that he's demonstrated that he has the skills and godless urge to spoof, spook and hound anybody who crosses him for Rasputin purposes not yet disclosed. Not that that's unusual hereabouts -- and who truly wants forgo comforting righteousness to confront an evil soul. Insecure smart cards, those (we) highly miseducated warriors seeking warfare, in our ability to engender and prolong grievances against others and deny theirs of us, and draw people into our webs of revenge and expatiation, against enemies of imagination and passion. In this DV, among many, is a fierce do-or-die competitor with, say, Tim May, and I still have a hunch that the two (or many) are in cahoots (if only in like mindedness and bulldog tenacity), now, and maybe at the beginning of the grand experiment of testing cypherpunkian elasticity with orchestrated provocateurism. All of us stirring the witches brew with fake innocence and real malice. None of us are going to quietly give up addiction to bloodlust, and will forever nightsweat insults and succumb to the urge to do vainglorious battle for vaporware honor. Dementia, due, as ever, to miseducation, haywire ambition, filmic fantasies of glory and immortality, dampened only by inevitable glandular wind-down. Is this dustup really about the faults of likeminded C2 and Dimitri, or our shared need for diversion from dread of disappearance without a trace? Billy Sunday

2 1

No Subject
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

http://www.telcomtraining.com/downloads/

1 0

Re: Stronghold
by John Young 17 Dec '03

17 Dec '03

Dimitri wrote: >Give me your fax # and and I'll fax it to you. Ask c2Net to verify >whether it's authentic. Okay. That's a deal. Send it under the river, and I'll put it on our site. Fax: 212-799-4003. Don't give up if it's busy, the line's also used for losing bets. My credibility went south years ago, sent packing by disbelieving housemates and offspring. Inflated baby jesus loves me, though. John

1 0

Re: PGP CAKware & IETF controlled Open-PGP standard
by Adam Back 17 Dec '03

17 Dec '03

Jonathan Seybold <jseybold(a)pgp.com> writes: > > Adam, one aspect of your suggestion puzzles me: > One thing which concerns me most is KNOWING when a message I send > (or receive) could be read by someone else. The PGP CMR scheme makes this > very clear: if there is an extra CMR key, the message may be read by > whomever controls that key, if not, only the recipient may decrypt the > message. > If, however, the message is secretly re-encrypted to a corporate > storage key AFTER it is received, I will never know that. You will if you mark the key with this information. This is the same approach PGP is already using to provide the GAK compliant implementation of corporate access to stored emails. > The reality is that: > 1) Organizations have a legitimate need to recover information. You > can argue about this as much as you want. I'm not arguing. Of course they do. What I _am_ arguing is that in designing systems to provide companies with data recovery mechanisms that you should a) not weaken security more than necessary, and b) that it would be nice if you used a method which doesn't introduce GAK compliancy for communications keys. I presented I think in plenty of detail an alternate mechanism which is both non-GAK compliant, and more secure. So what is the problem? Is there a technical flaw in my solution? > A great many organizations will simply NOT INSTALL systems which do > not accommodate this. If businesses, law firms and many other > organizations will not use PGP, we will not have a viable standard. Agreed 100%. This is why I went to great pains to demonstrate precisely how you could achieve recovery of stored messages in a more secure and non-GAK compliant way. > which are easy to use and administer, which balance the rights of > the individual against those of the organization, and which do not > mislead people inside OR OUTSIDE of the organization. my proposed mechanism for stored email recovery copes with all that. > This means, I believe, that they should NEVER INVOLVE HIDDEN BACK > DOORS THAT USERS ARE NOT AWARE OF. Agreed. You can flag backdoors with either solution. > PGP Inc. has tried to work through these issues in a new way. I think that > we have agonized through a lot of trade-offs and come up with something > that will really work -- and work well. It works well enough, but it could be made much more secure, by separating storage key functionality from transient message key functionality. This would also give you the chance to resolve the articificially created need for GAK compliancy, which arises because you are being forced by this lack of distinction between key functionalities to use one key for both long term storage and what should be transient communications key usage. > There is always the danger that someone is going to use your tools > in ways that you do not approve of. We are trying to make it as easy as > possible for people to do the "right" thing, and to discourage them from > doing the "wrong" thing (like secret snooping). > With regard to GAK, the objective should be to accommodate > legitimate corporate needs without setting in place the foundation for GAK. If that is PGP's aim, they failed most miserably. > We have tried very hard to do this by creating the foundation for a highly > flexible and decentralized approach which allows different organizations to > do things in very different ways. We have also tried to keep everything > very visible so that every party to a conversation knows exactly how > "private" that conversation is. Decentralised control is good, of course, but the pgp5.5 and SMTP policy enforcer is a ready to roll GAK system. The visibility principle is good but is an entirely separable issue. > I think that the sort of thing that PGP Inc is doing is the best > defense against GAK. It knocks the pins out from under the argument being > used in this country that corporate message recovery requires a key escrow > infrastructure, Yes, it is better than a government arranged "key recovery" key infrastructure. > and will almost certainly lead to a wide variety of > organization-specific implementations that will be jealously guarded > and very difficult to corral. I cannot imagine your 80% scenario > working in the U.S. where there are so many small and medium-sized > organizations and so much concern about government intrusion. If the OpenPGP standard is to include the GAK compliancy features, and these competing systems use this standard, as long as the sum of the OpenPGP compliant systems gets to 80% (or whatever) it doesn't matter whether this is mostly provided by PGP, or mostly by GAK sellout companies like IBM, or TIS. It is a dangerous development to have a largely fielded compatible set of GAK compliant products, whoever the providers are. Email encryption needs to be standardised, otherwise people can't talk to each other. This suggests to me that one standard _will_ evolve as the winner, or if there are other standards, they will be backwards compatible to this main standard. A very related example of this kind of principle in action is the fact that most secured web traffic is secured by Netscape's SSL. > I do worry a little more about countries like France, but I have yet > to see any guaranteed "safe" alternative (including yours) that the > French Government is likely to accept. The French Government used require licenses for crypto, which were hard to come by, and crypto without licenses was illegal. In that framework you couldn't see them liking PGP period. More recently they have been swaying towards allowing crypto without licenses, but only if it is GAK compliant. PGP 5.5 & SMTP policy enforcer should be a sell out. Maybe y'all should pitch it to the French government and SCSII (their NSA). > I am very interested in seeing criticism and suggestions for > improvement and would like to see this discussed and debated as openly as > possible. In particular, I would be interested in how one could reconcile > your scheme of separate transmission and storage keys with my concern that > everyone party to an exchange always be informed about who might be able to > read that exchange. That's simple: you already have the mechanism, just put one of those attributes Jon described on the key stating this fact. > However, I think that some of this discussion should be separated from the > Open PGP discussion. NO ONE wants to build any sort of mandatory message > recovery scheme into the base Open PGP specification. PGP Inc itself is > committed to always providing a base client software product which does not > implement message recovery keys. Glad to hear it. Can we take it from that that PGP won't be arguing for the GAK compliancy flag Jon Callas described to be part of the standard then? This is needed for said non "message recovery" base client product to also be OpenPGP compliant. > The key structure needs to be flexible enough to accommodate all > kinds of uses we cannot now envisage. Yes, I believe that CMR keys should > be supported -- as should a lot of other things we need to talk about. CMR keys and the way that PGP has designed their associated flags and the SMTP policy enforcer app are what make PGP GAK compliant. Also there are clear security advantages to _never_ send communications encrypted to two keys. There are clear security advantages to separating the functionality of storage and communications keys. Communications keys are the most sensitive of all, and should have the shortest life times. In some applications this could be minutes. > Finally, let's dispense with the non-productive PGP Inc- bashing. We > founded this company to take something which was going to die because it > had no company behind it, and push it forward. PGP Inc was the first step > in that process. Open PGP is the next step. The PGP bashing PGP observes is an attempt by the pro-privacy crypto community to influence PGP to re-think the GAK compliancy, and to point out the more secure way to implement corporate recovery of stored email messages without GAK compliancy. I reserve the right to bash any company which attempts to field GAK compliant software. > Most companies are very ambivalent about "open" standards. Most of > the time, "open" to them means something which they control and everyone > else adheres to. PGP Inc, on the other hand, is very committed to the > spirit of open standards. We understand very well that we will only be > successful if there is an open and completely interoperable international > standard. > > I also want to assure you that all of the things we do get > extensively debated within PGP. Thus far, we have always been able to work > out consensus decisions which, I believe, are more sophisticated and better > thought-out for that debate. In all of this I have never heard ANYONE at > PGP Inc. suggest that the company add any feature or capability to the > software in order to appease any government agency. GAK is just as scary to > us as it is to you. If PGP wants to make an additional stance against GAK here are my recommendations: 1. remove GAK compliancy fields 2. scrap SMTP GAK compliancy policy enforcer app 3. separate storage and communications keys 4. use shorter lived communications keys giving forward secrecy 5. implement corporate recovery of stored mail folders with escrowed storage keys Forward secrecy is _the_ strongest statement you could possibly make against GAK. > Jonathan Seybold > Chairman, PGP Inc. Adam Back Protocol designer, Cypherpunks list member

1 0

Re: negative security aspects of GAK compliance
by Adam Back 17 Dec '03

17 Dec '03

I also was pondering this question as to which purpose the current "encryption key" could be used for; should it become the "communications key", or should it be the "storage key". Clearly it could be used for either; and is in fact currently used for both, which is where the security problem arises. What you have described (very clearly as always) is the case for making the current "encryption key" the "communications key". You are forced to make this choice because there is only one key available, and without a communications key .. well you can't communicate :-) However this leaves the question: what do you use for a "storage key"? To see why this argument is important, you can see that you have painted yourself into a corner where you will be forced to admit that you need to have separate storage and communications keys. Probably this doesn't bother you as you didn't react adversely to my earlier description of how it was a good idea to separate key functionality. Let me quote: Hal Finney <hal(a)rain.org> writes: > This should facilitate more frequent changeover of encryption keys as Adam > Back describes, which can be good security practice. It is a significant > improvement provided by the new key structures of PGP 5. It is indeed. It is also very good for another reason: it allows corporate escrow of encryption keys without simultaneously allowing the company to forge signatures. However you have created a problem for your self in the following argument which suggests that you must have two encryption keys; one for storage and one for communication. It also suggests that my method for achieving corporate recovery of email is better acheived without the GAK compliancy field (second recipient) which was my earlier point. > Adam wrote: > > > This argues that if people are to insist on using the enforced second > > recipient model for corporate snooping at all, they should for > > security reasons be at least using short lived communications keys for > > the GAK compliancy packet also. > > That sounds reasonable, at least if the first recipient is also using > short lived keys. Presumably these kinds of policies would be established > by the corporate security office. But certainly if one class of keys > uses short lived keys then it would be logical for the other class to > do so as well. By doing it this way you do claw back some of the security lost by having a second crypto recipient, as you say. However you now can't recover communications past the expiry date of the short lived corporate key. As the whole point of corporate message recovery is to guarantee message recovery of stored messages (or at least this is the user requirement Jon Callas gave in his post explaining the need for CAK), you have just thrown away much of that ability. This is an extreme pity because you are now faced with a dilemma. Your dilemma is, do you: a) use short lived encryption keys (for both user and corporate master key), and have good security but limited recovery of stored encrypted email after that short period. Also the poor user won't be able to even access, never mind recover his stored encrypted email! b) or do you use a long term encryption key for the corporate master key, and hence good recovery of stored encrypted email, but poorer security (and as an additional disincentive end up building a GAK compliant system.) This dilemma highlights really very well my point as to why you really do need separate storage and encryption keys. Introduce them, and both problems vanish. You can then: - Have short term communications keys for the employee - Have long term storage keys for the user escrowed with the company - Have long term key recovery storage key for the company It's beautiful, everything falls into place, and it's more secure. Also as a convenient side-effect the way that you build a corporate stored message recovery scheme under this system is non-GAK compliant, which saves you from being screamed at by cypherpunks, and from being dissed in the NYT and other places. Presumably given Jonathan Seybolds clear statement of PGP's aims: Jonathan Seybold <jseybold(a)pgp.com> wrote: > With regard to GAK, the objective should be to accommodate > legitimate corporate needs without setting in place the foundation > for GAK. this side-effect of removing the GAK compliancy should therefore be very pleasing to PGP also. The way that you implement corporate recovery of stored encrypted messages once you accept the clear need for separate communications and storage keys is easily derivable from new the key purposes. It is basically as easy to circumvent as the previous GAK compliant method. Several PGP employees commenting on this didn't seem to think enforceability was that big a deal. (I agree with them: if all it takes is to super encrypt with PGP itself, it's not worth losing sleep over.) Here's how to do corporate recovery of stored encrypted messages, now with the new separated storage and communications key functionality: 1. Corp. employee receives encrypted email, the email is encrypted to the employee's short life time communications key. - employee decrypts email with pgp5.6 client - pgp5.6 client encrypts the plaintext to users long term storage key, and to the companies recovery key as a second "storage-recipient", and places in received mail folder 2. Corp. employee sends encrypted email - The pgp5.6 mail client encrypts plaintext of email to users long term storage key and to the companies long term storage recovery key and stores in the sent email folder - The pgp5.6 mail client encrypts the plaintext of the email to the recipients short lived communications key and passes on to the MTA 3. Normal user access of encrypted stored email - user's email client decrypts stored email with users storage key 3. User forgets password, or dies, or leaves in a huff, company needs access to stored email - company uses company recovery key to decrypt users stored email An alternate set up would be to escrow the users long term storage key with the company. Basically equivalent. But I think it is probably easier to use multiple recipient as it saves the headaches of having to securely transmit 10000 users storage keys securely. Much easier to install the software with the department/company recovery key bound into it, and to remote update the company recovery key by fetching the new from the company key server when it expires. There are lots of other issues of course, with regard to architecture of recovery setup. However there is a basic equivalence between key escrow and session key recovery methods, and you can acheive all kinds of departmental escrow jus the same as you could with the previous system. > Actually it's likely that the corporation will change its shared access > keys more frequently than user keys, at least if they are using an > access model where there are relatively few shared keys. It will be > easier to change a few keys which are controlled by corporate officers > than to get every one of 10000 employees to generate a new key every week. I can't see any reason why you would not be able to entirely automate and hide the process of generating new communications keys every week, every day, or _every communication_. The process can be handled automatically by the software. With El Gamal you have a very computationally cheap way to generate keys other than the first key; discard the private components, and treat the public modulus as a pre-computed prime as you currently do for the fast key generation option on EG key generation. I feel somewhat better about this post than previous ones; I haven't been rude to PGP, and I feel some progress has been made in clarifying things. Perhaps it's just interacting with Hal, who always was one of the most level headed people on cypherpunks; it's much harder to pick faults in what he says, and he doesn't make ill thought out political statements. I think there are still some issues to resolve if we start to talk about "per communication" communication key updates, but for per week, or per month or whatever, I think the above is good. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 0

DCSB: Carl Ellison on Identity and Certification for Electronic Commerce
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Sender: rah(a)pop.sneaker.net Mime-Version: 1.0 Date: Mon, 13 Oct 1997 12:52:18 -0400 To: dcsb(a)ai.mit.edu, dcsb-announce(a)ai.mit.edu From: Robert Hettinga <rah(a)shipwright.com> Subject: DCSB: Carl Ellison on Identity and Certification for Electronic Commerce Cc: cme(a)cybercash.com Sender: bounce-dcsb(a)ai.mit.edu Precedence: bulk Reply-To: Robert Hettinga <rah(a)shipwright.com> -----BEGIN PGP SIGNED MESSAGE----- The Digital Commerce Society of Boston Presents Carl Ellison CyberCash, Inc. Identity and Certification for Electronic Commerce Tuesday, November 4, 1997 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA It is a common belief that you can not trust someone on the net unless/until you establish his "identity" via an interactive protocol in which the other person establishes proof of ownership of a given private key and a transfer of certificates which establish a binding between that key and a person's "identity" (in the form of a common name plus enough information to make it unique in some global hierarchy of names). This talk will establish that the proof of key ownership is the primary value obtained from this process and that the global hierarchy of names is effectively useless. It will propose certificates for electronic commerce which use a person's public key to identify him, avoiding the hierarchy of names. Carl Ellison is a cryptographic engineer with CyberCash, Inc., of Reston VA. He has been involved in cryptography since about 1978 and seriously involved since doing his first cryptanalysis in 1986. With the introduction of PEM in the early 1990's, he found the PEM certification process to be a killing roadblock and has studied certification and the establishment of identity since that time. This meeting of the Digital Commerce Society of Boston will be held on Tuesday, November 4, 1997, from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, on One Federal Street. The price for lunch is $30.00. This price includes lunch, room rental, various A/V hardware, and the speaker's lunch. ;-). The Harvard Club *does* have dress code: jackets and ties for men (and no sneakers or jeans), and "appropriate business attire" (whatever that means), for women. Fair warning: since we purchase these luncheons in advance, we will be unable to refund the price of your lunch if the Club finds you in violation of the dress code. We will attempt to record this meeting and put it on the web in RealAudio format at some future date We need to receive a company check, or money order, (or, if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, November 1, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston", in the amount of $30.00. Please include your e-mail address, so that we can send you a confirmation If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Upcoming speakers for DCSB are: December James O'Toole Internet Coupons January Joseph Reagle "Social Protocols": Meta-data and Negotiation in Digital Commerce February Donald Eastlake SET We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the DCSB Program Commmittee, care of Robert Hettinga, <mailto: rah(a)shipwright.com> . For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> . We look forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNEJRn8UCGwxmWcHhAQGICggAoRXxsE1E2LsAxMX0jeg0nWbBxTKV5u6k riMP3EGN1UC/niyJu5rz8cB98y+YpdhfMBcw/qvgPvqt8h/ep897KMNKvVtYGloE 8Uyb6xf8czX3cD2VQ/M5c+eTEcjlorojUYSeo3d2eyc2e1aX+g23ydVkfawZPDBa f5DCUs5hN1s+ehThV9QpsyN31lpuc4YgUiSpWZCscbkrpXPM0zY2m/GhMdgNXw97 sHs2P3Pmnkgt61Yfkf6u1pMdxt3hpmgv78LLuFaZcsyIAk2Aur2yku53FqarFomo 55Qu1BnrRYH21+RE757wLzic4fXreYnkfNCo2bz/RXLkO7piVwqGsQ== =E24t -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/> For help on using this list (especially unsubscribing), send a message to "dcsb-request(a)ai.mit.edu" with one line of text: "help". --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

1 0

James A. Michner [non-crypto]
by Jim Choate 17 Dec '03

17 Dec '03

Hi, Thought some of you might care to know that James A. Michner the Pulitzer prize winning author who lives here in Austin, Tx. has decided to take himself off the kidney dialysis machine that has been keeping him alive. ____________________________________________________________________ | | | The financial policy of the welfare state requires that there | | be no way for the owners of wealth to protect themselves. | | | | -Alan Greenspan- | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

2 1

attn bianca@dev.null
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

1 0

patenting big brother
by Ariel Glenn 17 Dec '03

17 Dec '03

if it's not one thing, it's another. Ariel Glenn ariel(a)columbia.edu ----- http://www.nytimes.com/library/cyber/week/101397patents.html Engineer Invents Computerized Surveillance System By TERESA RIORDAN Imagine that a city park were studded with discreetly placed cameras that fed images into computers programmed to keep a watchful eye. This may sound darkly Orwellian, but David Aviv, a former aerospace engineer, has patented exactly such a system as a way of combating crime. Aviv said his invention, which he calls the Public Eye, used pattern recognition to detect robberies or acts of violence. He said he had digitized and stored a library of physical interactions. "We employed actors to do re-enactments of muggings," he said. "We had 10 different sizes of muggers and 10 different sizes of victims." The camera sends to a computer the real-time images of a person getting money from an automated teller machine, for example. The computer then takes a snapshot and compares the image against the library of threatening interactions. "It takes another snapshot and then another snapshot and does a similar comparison over and over again to reduce false alarms," Aviv said. "I'm describing this in slow motion, but it actually takes place every fraction of a millisecond." If the computer detects a malicious act, an alarm promptly alerts the police or a paid guard. Aviv said he also used a type of pattern recognition, called word gisting, to detect aggressive verbal interactions. Muggers, according to Aviv's research, use a limited vocabulary. "Mostly they say, 'Give me your money,' and then use a lot of cuss words," he said. His word-gisting library contains about 20 basic words, spoken in a number of different dialects. How is Aviv's system different from having a human guard observe a bank of television monitors? "Guards get tired," Aviv said. "And they are expensive." Aviv estimated that it cost about $130,000 a year to have one site manned by guards 24 hours a day. "My system you could lease at $500 a month," he said. "You're not going to eliminate all guards, because you still need someone to run over when a hostile act is taking place." Aviv's company, ARC Inc., which is based in Las Vegas, is seeking financing for further development of the surveillance system. He received patent 5,666,157.

2 1