December 2003 - cypherpunks-legacy

Re: The Continued Attack on Cash (Was: "The Right of Anonymity"...) (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > From: "Attila T. Hun" <attila(a)hun.org> > Date: Mon, 02 Feb 98 18:07:57 +0000 > Subject: Re: The Continued Attack on Cash (Was: "The Right of Anonymity"...) > >I've been doing it for many years. Don't have a checking account, don't > >own a credit card. I do have a saving account with a local credit union > >and go in every 3-4 days and withdraw what I need for the next 3-4 days. > >Pay every bill in cash or money order. > > first, the use of the credit union includes your SSN and > they have a total cash transaction at least on your primary > expenses. Wrong. I go in once a week and pull out money in a lump sum. I then budget that money myself. The only thing they have is a sequence of deposits from paychecks and withdrawals to cash. > if you have "consulting" income which can be > converted to cash, and dont deposit it, then you can do you > 'high on the hawg' living with the cash --until they bring > the IRS CID along and look at your 'imputed' income which is > almost indefensible in their kangaroo courts. I either take the fees in check and deposit them or else take 'in kind' trade (eg I did a job if installing Win95 for a customer on some laptops he'd bought via auction. There was a Tadpole 3XP Sparcbook on there. I took it for my fee). > >I'm going to go tomorrow and buy a new laptop at around $1500. > > what are you getting for $1500? out here in the boonies > we dont see those kind of prices. Looks like a Toshiba Satellite 445CTX (133MHz Pentium). > well, in the first place, you live in Texas where the > attitude to the Feds is rather strong --not as strong as our > attitude in rural Utah where the usual transaction is in > cash. out here, a Fed is the same as a revenuer in Eastern > Kentucky or Tennessee. reminds me of the Fed approaching a > child and telling him he'd give him $5 if he took him to his > father (still) --the boy asked for the money up front. when > the Fed asked why, the boy said: "...'cause you aint coming > back". You don't know Texas or Texans very well... ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

2 1

whit diffie on national radio
by Russell Nelson 17 Dec '03

17 Dec '03

FWIW, Whit Diffie is on NPR's Talk of the Nation RIGHT NOW. Find your local NPR affiliate, usually in the low end of the dial. -- -russ <nelson(a)crynwr.com> http://web.crynwr.com/~nelson Crynwr Software supports freed software | PGPok | Freedom is the primary 521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love, Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.

1 0

distributed cryptographic attack demo
by Jon Cooper 17 Dec '03

17 Dec '03

hi, i'm trying to do a demo of a distributed object technology and it seems to me that many cryptographic attacks would be facilitated by our approach. do you have any ideas for what a neat distributed effort might be? the ones i've thought of just don't seem too exciting: * GNFS of RSA modulus * attacking SSL * brute-force RC5 attack i'm looking for something that would be a sort of viscerally engaging attack, something that will make people who aren't necessarily number theorists or cryptographers take note. any input would be helpful! *jon PS - note that I'm not on cypherpunks so a direct reply would be most highly appreciated.

2 1

Eureka! Tue Feb 3 '98
by eureka＠eureka.abc-web.com 17 Dec '03

17 Dec '03

Welcome to Tuesday's issue of Eureka! PINKBITS Voted the #1 Teen (18+) site on the web, this is one pay site you don't want to miss out on! Here's just one quote from a satisfied member: "This site delivers awesome value. I have been a member of 3 other sites, and this is the best by far. It has the best pics, more live video, younger girls and more hardcore cumshots than the other sites put tog- ether". And we have negotiated a special FREE trial member- ship for Eureka subscribers, so don't take our word, go see! PinkBits .. http://207.33.10.198/cgi-bin/gate1/pbm/pb_0024/0 PLEASE VISIT THIS FINE EUREKA! PARTNER SITE Playgal - No.1 in Internet Hardcore! http://www.playgal.com/playgal/banner_eureka.html Playgal presents FREE LIVE FUCKING, and over 2,000 FREE XXX MOVIES! XXX 4 EVERY 1 Overall this site looks pretty good. Click on the View Free Sample Pics to get to the good stuff. Once over that fence your in! There are thumbnails of some hot looking babes! Wet bush filled with hard dick. Not a bad combination! XXX 4 Every 1 .................... http://www.xxx4every1.com DO ME LIVE Do me too! Do this, do that and do the other. If she lets you! This is a paysite but they have a pretty juicy free picture section. Girl on girl, shaved pussy, dildo, panties, and clit rubbing images. Stroke your browser over there! Do Me Live ........................ http://www.domelive.com/ CYBERJOY Basic text links that deliver! Check out first time, that is one big black log, and she is enjoying it! Cum shots and links that will take you all over the place. See the Hungry for pussy picture. That tramp looks possessed! Take a look. Cyberjoy .......... http://www.cyberjoy.inter.net/adult3.htm ADULT CHARTS Here is one to see. Go there right now. Tons of free pix! Click on the free pictures area and your in. Take your pick of anal, cum shots, oral sex, girlgirl, teens, group action, I could go on more but you get the idea. High quality jpeg images that load quickly! These are some of the best free porno pix on the internet. Grab your mouse and get surfing! Adult Charts .................... http://www.adultcharts.com BRAND NEW - HOORAY! THE ADULT SEARCH ENGINE Now adult surfers have our very own search engine, directly designed to only list adult sites, and so run fast because all other types of site are ignored. Check it out today! Hooray! -----------------> http://eureka.abc-web.com/hooray/ FREE STREAMING VIDEO Please note that most of these feeds require a Netscape bro- wser in order to successfully view them. Unfortunately Micr- osoft's browser does not have all the features of Netscape's yet. However, many of the feeds use the RealPlayer and will work in most browsers. If you do not have Netscape and want a free copy click here --> http://www.netscape.com/download/ College teens -----> http://207.240.169.122/teens/start.html CHAT WITH OTHER READERS This chat is growing fast, and already there are a number of regulars you will meet most days. It's good to see Eureka! readers interacting with each other and having a great time! Adult/Sex Chat -----------------> http://137.39.63.229/chat/ General/Fun Chat -------> http://137.39.63.229/chat/funchat/ THE BEST PHONE SEX NEW!!!! LD Call only! - Live Hot Girls!!!!--->1-664-410-3912 LIVE: 1-on-1, 2-on-1, Group, Dateline-------->1-800-644-8779 FREE: Live 1-on-1 (international call only)--->011-678-77416 AMATEUR SITE OF THE DAY Octavia: "Caught you looking" is the motto of this sweet 23- year-old coed's web page. She loves to show off, and claims that she gets off thinking about all the horny guys checking her out. Her photos exhibit her exhibitionist streak and are of extremely high quality. Get caught looking at Octavia - it's well worth sneaking a peak! ---------------------------> http://amateurindex.com/eureka/ EROTIC STORY SITE OF THE DAY T-Bone's Sex Club: T-Bone gives you a new selection of erotic stories illustrated with nasty hardcore pics! Last week was Slut Wife week... what will it be this week? Visit T-Bone and find out! ............... http://www.rawsexx.com/ DAILY CARTOON ----------> http://www.erosinorbit.com/eureka/ ADULT STAR PIC OF THE DAY Every day we bring you an exclusive choice pic of a famous adult porn star. And we must tell you - these pix are abso- luletly brilliant! ---> http://www.xxxadultstars.com/eureka/ GAYEUREKA! The gay newsletter is now available. You can get it here! Gay Eureka! ----------> http://eureka.abc-web.com/gayeureka/ EUREKA! TRANSLATIONS As well as English you can now choose any of these languages DEUTSCH ------> http://eureka.abc-web.com/eureka/deutsch.htm ESPAÑOL ------> http://eureka.abc-web.com/eureka/espanol.htm FRANÇAIS ----> http://eureka.abc-web.com/eureka/francais.htm ITALIANO ----> http://eureka.abc-web.com/eureka/italiano.htm PORTUGUESE > http://eureka.abc-web.com/eureka/portuguese.htm TODAY'S FREE PIX Pic 1 --------------------------> http://137.39.63.229/?030 Pic 2 --------------------------> http://137.39.63.229/?031 Pic 3 --------------------------> http://137.39.63.229/?032 Pic 4 --------------------------> http://137.39.63.229/?033 Pic 5 --------------------------> http://137.39.63.229/?034 Pic 6 --------------------------> http://137.39.63.229/?035 Pic 7 --------------------------> http://137.39.63.229/?036 Pic 8 --------------------------> http://137.39.63.229/?037 Pic 9 --------------------------> http://137.39.63.229/?038 Pic 10 --------------------------> http://137.39.63.229/?039 ============================================================ TO UNSUBSCRIBE FROM THIS NEWSLETTER, USE THE REPLY FUNCTION IN YOUR EMAIL PROGRAM, AND SEND THIS EMAIL RIGHT BACK TO US. ============================================================

1 0

distributed computing
by Jon Cooper 17 Dec '03

17 Dec '03

I'm in the planning phase of a demo which should demonstrate the power of a distributed object technology which I'm working with. Any ideas for neat crypto-related distributed computation demos would be much appreciated. I've thought of: * brute forcing RC5 (lots of people are doing this already) * factoring attack on RSA modulus * Certicom's ECC challenge But I'm looking for something with more of a sort of gut-level appeal. Cracking SSL packets might be good. Hrmm. thanks for any input ... *jon

1 0

No Subject
by Mix 17 Dec '03

17 Dec '03

subskribe cyferpunks bill(a)whitehouse.gov

1 0

Re: The Continued Attack on Cash (Was: "The Right of Anonymity"...)
by Black Unicorn 17 Dec '03

17 Dec '03

At 06:07 PM 2/2/98 +0000, Attila T. Hun wrote: > I did-- tried to lay $14K out for a Mercedes (25 years ago). > they wouldnt take it. so I went and picked up two $7K > cashiers from two different banks. same thing with a pair > of Lycoming IO540 aircraft engines: 2 8s and a 9 --stay > under the $10K transaction. Careful. This may well be illegal now. Structuring transactions to avoid reporting requirements is a felony. (I'm not on cpunks, mail me).

5 4

An update on MS private key (in)security issues
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

A fortnight ago I posted a message exposing a number of weaknesses in the way various Microsoft security products handle users private keys. A few days before I was due to vanish for a security conference (where it was very difficult to contact me), the article started getting a bit of attention. This is a general response which clarifies several issues relating to the original message. First, Russ Cooper (moderator of the NT Bugtraq mailing list) made some wildly inaccurate claims about the article. I've had a bit of feedback which indicated that it wasn't even worth dignifying this stuff with a response but I've written one anyway, at least for the original NT Bugtraq messages he posted (the stuff he put on a web page is just more of the same). You can find it at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms2.txt (even if you don't want to plough through the whole thing, you might want to read the last two paragraphs for a giggle). After this, Microsofts spin doctors leaped into action and posted a response to the article. I've replied to this one in a bit more detail, since it raises several important issues. Comments on Microsofts Response ------------------------------- >Microsoft's Response to Recent Questions on the Recovery of Private Keys from >various Microsoft Products >[...] >With the exception of the details about a possible PKCS-12 attack, all the >issues raised in the recent discussions are specifically aimed at Microsoft's >base CSPs, not at CryptoAPI. The base CSPs are the royalty-free, >software-based CSPs provided with Windows NT 4.0, Windows 95, and Internet >Explorer. These attacks do not apply in general to other CryptoAPI CSPs and do >not indicate any fundamental concerns with the security of the CryptoAPI >architecture or applications built upon it. This statement is mere obfuscation. As Microsoft have said, every single (recent) copy of Windows NT, Windows'95, and MSIE (and, presumably, other products like IIS and Outlook, which rely on them) ship with these CSP's, therefore every recent system comes with this security hole installed by default. In addition, the CryptExportKey() function is a standard CryptAPI function, which is described by Microsoft with the text "The CryptExportKey function is used to export cryptographic keys out of a cryptographic service provider in a secure manner" (obviously some new use of the term "secure" with which I wasn't previously familiar). There's nothing in there that says "Only the Microsoft CSP's support this" (some may not support it, but by Microsofts own admission the default used on any recent system does indeed exhibit this flaw). >Microsoft products do not "store" private key material using PKCS-12, contrary >to recent descriptions on the Internet. I was unfortunately somewhat unclear in my article, I've fixed up the online version at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt. To summarise, if you want to get at an exported key stored on disk, you can use the pre-4.0 key file/PKCS #12 key file flaws. If you want to get at the current users key, you can use the CryptExportKey() flaw. >The example of breaking a PKCS-12 data blob, which was given in discussion on >the Internet, is not an attack on the "weak" cryptography of PKCS-12. Rather, >it is simply a dictionary attack (long known and well understood in >cryptography), This statement is accurate. As Microsoft have said, dictionary attacks have been known to the computer industry for a long, long time (several decades). For example the Unix password encryption uses 25 iterations of DES to protect users passwords from dictionary attacks (this is rather inadequate now, but was appropriate more than two decades ago when it was introduced). If this is a well-known flaw which the entire industry has known about for decades, why are Microsoft's very latest "security" products so extremely vulnerable to it? As I mentioned in my writeup, I published an attack on the exact format used in older MS products more than 1 1/2 years ago, but Microsoft made no attempt to fix this problem at the time. It wasn't until I published the current writeup that they finally addressed it. >One statement by the original poster argues that Microsoft managed to design a >security format that actually makes it easier to break into the protected >data. As stated above, a number of well respected companies were involved >extensively in the design and review of PKCS-12 before it became a standard. The problem is that Microsoft ignored the other companies recommendations for increasing security. I'll refer people back to the original writeup for mention of the various security features which were added to PKCS #12 and subsequently ignored by Microsoft. PKCS #12 is just a basic modification of PFX, which was a purely Microsoft invention, and Microsofts implementation of PKCS #12 does indeed make it very easy to perform the attack I described (you'd have to read my writeup for the full technical details in which I describe each individual flaw which, as each is exploited in turn, make it progressively easier and easier to recover a users private key). In addition (as I mentioned in my original message), Microsoft use RC2/40 to encrypt the private keys, which means that no matter how good a password you choose, the default PKCS #12 format private key produced by MSIE can be recovered in a few days with fairly modest computing power. There already exists a Windows screen saver which will recover RC2/40 keys for S/MIME messages, and the prize of an RSA private key is a much higher motivating factor than the "Hello, how are you?" typically found in an S/MIME message. As Microsoft point out, Netscape can indeed handle RC2/40-encrypted files, however they usually use triple DES and not RC2/40 (they encrypt the private key components - the really valuable part of the PKCS #12 payload - with triple DES and the other odds and ends with RC2/40). Since Netscape also iterate the password and MAC processing, they aren't vulnerable to the attacks which the Microsoft software is vulnerable to, even though both are based on the same PKCS #12 standard. >Exploiting Internet Explorer > >One of the fundamental requirements to perform any possible cryptographic >attack discussed in the recent postings is the assumption that a malicious >entity could somehow access to data on a user's computer system, without the >permission or knowledge of the user. This is a large leap of faith. > >Users that are using Public Key Certificates today are generally sophisticated >and savvy users, Bwahahahahaha! Sorry, I guess I should explain that in more precise terms. Now I'm not trying to claim that the average Win95 user isn't as sophisticated and savvy as Microsoft seem to think, or that relying entirely on the sophistication of the average Win95 user for security is a dangerous move. However these statements do seem to completely ignore the reality of the situation. Let me go into the background of the weaknesses a bit further. When I tested the weaknesses, I asked some "guinea pig" users to send me their exported keys, with the promise that I'd destroy the keys and not keep any record of where the keys came from and so on. Because of this I can't give exact figures, however here are a few data points: - More than half the keys (I can't remember the exact figure) were in the older, pre-4.x format. This indicates that the majority of users (or at least of the crypto-using guinea pigs) are still running old versions of MSIE which contain a number of widely-publicised problems, including precisely the weaknesses required to run arbitrary code on the machine or read files off the machine. One of the respondents commented that the key was "the key I use with Outlook", I'm not sure what that says about the origins of the key. Another key was one used with IIS for a web site which runs an online commerce service that processes credit-card based orders. This must have been an older version of IIS since the key was in the pre-4.x format. - When I asked two of the people why they were still using an old version, the responses were "It came installed with the machine when we bought it" and "It does what I want, so I haven't upgraded". I expect most users of the older version would have a similar reason for using it. In a company of 20 people (some of whom participated in this test), only two were running 4.x. These people are all highly competent software developers (presumably this includes them in the group of "sophisticated and savvy users" which MS were referring to), however none of the remaining 18 wanted to risk installing MSIE 4 because of the extent with which it messed with their system, possibly jeopardising their development work. Therefore most of these "sophisticated and savvy users" were still running old, insecure versions of MSIE, and weren't going to upgrade any time soon. - For the two remaining 4.x users in the company, both are still using straight, unpatched 4.0 because they considered it painful enough to download all of 4.0 and they didn't want to bother with an upgrade just yet. This makes them vulnerable to the bug pointed out in the l0pht advisory. - When I informed one of the guinea pigs of the recovered password, his response was "Now I'll have to change my login password" (the others generally restricted themselves to some variation of "Oops"). This comment confirms that users do indeed sometimes use their login password to protect their private keys, so that a successful attack recovers not only their private keys but their login password as well. - One respondent commented that most of the code they downloaded from the net was unsigned, but they ran it anyway. This is probably typical of the average user. Although I've only been back for two days, I haven't yet managed to find anyone who has applied all the latest patches and kludges to their system which makes them immune to these problems. This includes at least one person who has a code signing key which could be used to sign malicious ActiveX controls. Therefore all of the guinea pigs could in theory have their private keys stolen. >Attacks against Authenticode signing keys > >[...] > >However, it is extremely unlikely anyone could be successful with a simplistic >strategy for stealing Authenticode signing keys and then using them. See my comments about about this. I could, right now, obtain at least one Authenticode signing key with which I could create a malicious ActiveX control. I'm sure that if I were serious about this I could obtain a number of others. >Second, anyone signing code using Authenticode technology is extremely >unlikely to leave their key material sitting on an end user machine routinely >used for browsing the Internet. I see no basis for this claim. Every developer I know uses the same machine for both code development and web browsing (in fact a number of users keep a copy of MSIE or Netscape permantly running on their machine so that they'll have something to do between compiles). Microsoft's statement seems to imply that users will be running two machines, one dedicated entirely to web browsing and the other to code signing. I find this extremely unlikely. >Attacks on Encrypted Key material > >There is some confusion over the algorithms and methods that Microsoft uses to >provide protection of encrypted key material in Internet Explorer when using >the standard Microsoft base CSPs. There were changes between Internet Explorer >3.0x and Internet Explorer 4.x specifically to address any possible concern. And the astounding thing was that, despite a complete rewrite of the code, the newer version offers no extra security at all, as my article points out. Both are equally weak, you just need to attack them in slightly different ways. >Key export attacks > >The original Internet posting raises concern about the CryptoAPI interface >CryptExportKey(). This function is fully documented and does indeed export >private key material in an encrypted format. The statement from Microsoft omits one important point here. Myself and another security researcher have been trying to tell Microsoft for more than four months (probably a lot longer, I didn't log the earlier mail) that this is a very serious security flaw. In all cases Microsoft's response was some variation of "We don't see this as a flaw". It wasn't until my warning was published that they finally addressed the problem, and even in this case (the program to set the CRYPT_USER_PROTECTED flag) it's only a quick hack to plaster over the cracks and allow them to declare the problem fixed. In fact it doesn't fix the problem at all. I'll post details in a fortnight or so when I've had time to test things, please don't ask me about this until then. >The presence of the CryptExportKey() function is to support functionality such >as migrating key material between machines for a user or creating a backup >copy of a key. It should be noted however, that many CSPs, including most >hardware based CSPs, do not allow exportable private keys and will return and >error in response to a CryptExportKey() request. However the CSP's installed by default on every recent system do allow the export. The fact that there may exist, somewhere, an implementation which doesn't exhibit this flaw really doesn't help the majority of users. >The posting also asserts that an ActiveX control could be downloaded from a >web page, simply ask for the current users key, ship the key off for >collection by an unscrupulous person, and then delete itself without a trace. > >If users run unsigned code, or code from an unknown origin, a number of >unpleasant things can happen. This could indeed occur if the key as been >marked exportable and the CRYPT_USER_PROTECTED flag is not set. Which was, until my warning, the automatic default action for Verisign, and is still the automatic default for many other CA's. This means that keys generated right up until a few days ago (and in some cases keys being generated right now) have, by default, no protection whatsoever. In addition I've just been sent mail to say that CRYPT_USER_PROTECTED still isn't the default with Verisign, you have to click a box asking for extra security or you get the usual default of no protection. To add to the confusion, a lot of documentation (including the Microsoft Developer Network (MSDN) online documentation on Microsofts web site) describes the CRYPT_USER_PROTECTED flag with "The Microsoft RSA Base Provider ignores this flag", which can cause programmers to leave it out when it is *essential* it is always included. Incidentally, MSDN also claims that Microsoft are "supporting" PFX, which is in direct contrast with the claims in their press release. >There was also discussion of 16 dialog boxes appearing to the user for their >password if the CRYPT_USER_PROTECTED flag is set. Certainly asking the user >too many times would be better than too few times, however in our tests, under >extreme (and uncommon cases), a user might be asked for their password at most >four times when a key is used with the Microsoft base CSPs. Perhaps the claim >came from an early beta release. The 16 dialog boxes problem was present in 4.0, and it's been confirmed as still being present in 4.01. This was apparently verified on Microsoft's own CryptoAPI mailing list (the claimed "beta" version was actually MSIE 4.0 final). >Microsoft is constantly working to improve the security of our products. Myself and another person had been trying to convince Microsoft for more than four months that things like CryptExportKey() are a major security hole. Their response each time has been some variation of "We don't see this as a problem". It simply wasn't possible to get them to acknowledge these flaws, therefore my posting of the details wasn't "irresponsible" (as some have claimed) but a necessity in order to get them fixed. When I pointed out several months ago that Microsoft were using, in their pre-4.x products, an exported key format which was identical to the one which I broke more than 1 1/2 years ago, their response was "What's the problem with this?". I would have liked to have included URL's for the CryptoAPI mailing list archives to prove that Microsoft were warned of these problems some time ago, but the CryptoAPI archive seems to be temporarily offline. Risks of a Private Key Compromise --------------------------------- One or two respondents have tried to play down the seriousness of a private key compromise, saying that I exaggerated the dangers in my original message. What I wanted to point out was how extremely valuable a users private key is, and how disappointingly little concern Microsoft seem to have for protecting this valuable resource. For example Garfinkel and Spaffords "Web Security and Commerce" (O'Reilly, 1997) contains the warning: "Today's PC's are no better at storing private keys once they have been generated. Even though both Navigator and Internet Explorer can store keys encrypted, they have to be decrypted to be used. All an attacker has to do is write a program that manages to get itself run on the users computer (for example by using [...] Microsoft's ActiveX technology), waits for the key to be decrypted, and then sends the key out over the network" (p.120). Including a function like CryptExportKey() (which hands over a users private key) makes this very attack possible. The potential damage which can be caused with a misappropriated private key is enormous. Consider the relative risks in the compromise of a logon password and a private key. With a logon password, the worst an attacker can do (apart from stealing possibly valuable data) is to trash the victims hard drive, which involves reinstalling the operating system (an action which many users are intimately familiar with). In contrast an attacker who obtains a private key can potentially drain the victims credit card, clean out their bank account (if the victim uses one of the emerging online banking services), sign documents in their name, and so on. The implications of that last point can be quite serious. Take for example the Utah digital signature act, which was used as a model by a number of other states who implemented or are implementing digital signature legislation. Under the Utah act, digitally signed documents are given the same evidentiary weight as notarised documents, and someone trying to overcome this has to provide "clear and convincing evidence" that the document is fraudulent, which is difficult since it bears a valid signature from the users key (this fact has been used in the past to criticise digital signature laws based on this act). In addition, under the Utah act and derived acts, anyone who loses their private key bears unlimited liability for the loss (in contrast, consumer liability for credit card loss is limited to $50). This leads to the spectre of a malicious attacker who has the ability to issue notarised documents in your name for which you carry unlimited liability. This is a lot more important than someone reformatting your hard drive, or stealing last months sales figures. Peter.

2 1

INFO-RUSS: Israel Issues Iraq Warning (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From INFO-RUSS-request(a)smarty.ece.jhu.edu Mon Feb 2 19:00:52 1998 Message-Id: <9802022059.AA22808(a)smarty.ece.jhu.edu> Errors-To: INFO-RUSS-request(a)smarty.ece.jhu.edu Sender: INFO-RUSS-request(a)smarty.ece.jhu.edu Date: Sun, 1 Feb 1998 19:32:58 +0200 (IST) To: info-russ(a)smarty.ece.jhu.edu From: info-russ(a)smarty.ece.jhu.edu Subject: INFO-RUSS: Israel Issues Iraq Warning --------------------------------------------------------------------- This is INFO-RUSS broadcast (1200+ subscribers). Home page, information, and archives: http://psi.ece.jhu.edu/~kaplan/IRUSS/inforuss.html To post, or to subscribe/unsubscribe, mail to info-russ(a)smarty.ece.jhu.edu INFO-RUSS assumes no responsibility for the information/views of its users. --------------------------------------------------------------------- Reuters, Sunday February 1 3:34 PM EST Israel Issues Iraq Warning JERUSALEM (Reuters) - Prime Minister Benjamin Netanyahu Sunday reserved the option of retaliating for any Iraqi missile attack on Israel, despite assurances the United States would step in quickly to punish Iraq. "The only ones who will make decisions, the only ones who make decisions, are us and us alone," Netanyahu said in remarks on the Iraq crisis in a speech to visiting American Jews. During the 1991 Gulf war, Israel held its fire in the face of 39 Iraqi Scud missile attacks, bowing to U.S. pressure not to take action that could push Arab states out of a U.S.-led alliance to drive Iraq out of Kuwait. On a visit to Israel Sunday, U.S. Secretary of State Madeleine Albright spoke of a U.S. "iron-clad commitment" to Israel's security and gave notice any Iraqi threat to countries in the region in the current crisis would not go unpunished. "If they do threaten their neighbors or do damage to them our response to it will be swift and forceful," she said. But in apparent reply, Netanyahu said in his speech: "One thing has to be understood -- that we will do whatever is necessary to defend Israel and strengthen Israel's national security." He said Israelis should view the Iraqi crisis "calmly because there is a government here that handles matters professionally and with reason." Netanyahu spoke after convening cabinet ministers to discuss the possibility that a U.S. assault on Iraq would push Baghdad to launch missiles against Israel tipped with biological weapons. After the session, Deputy Defense Minister Silvan Shalom declined to comment on the deliberations but he said earlier that Israelis were thronging to army distribution centers to exchange old gas masks. Israel's Ha'aretz newspaper reported Sunday the United States had agreed in principle to send Israel vaccines against anthrax and other biological agents Iraq is believed to possess. The newspaper report, attributed to U.S. sources, said Israeli leaders asked Washington to store hundreds of thousands of doses of the vaccines in Israel. Asked if Israel had ordered the vaccines, Defense Minister Yitzhak Mordechai told reporters: "Some things are done in coordination between us and the United States to be able to defend ourselves today and in the future against the possibility that non-conventional weapons will be possessed by someone who wants to endanger us." Israeli officials have said the probability was low that Iraq would launch a strike but authorities have made clear they are preparing for the worst. The United States is rallying support from allies for a possible attack on Iraq to punish President Saddam Hussein for not complying with U.N. arms inspectors searching for documents and materials related to its weapons programs. Iraq says it has no nuclear, chemical or biological weapons or ballistic missiles -- banned under terms of the cease-fire that ended the Gulf War in which U.S.-led forces drove Iraqi troops out of Kuwait. ----------------------------------------------------------------------------

1 0

VMM question - reply (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Mon, 02 Feb 1998 01:39:47 -0600 > From: Lenny Blumberg <lenny(a)bga.com> > Subject: VMM question - reply > Hmmmm..... > I would imagine that the OS would keep a disk map in memory and > mark it with a flag to indicate if it's been paged into memory. This is a function of the "Look Aside Buffer" and the actual operation is a bit more complicated. The vmm must keep up with which processes have it mapped, where in their indipendant memory maps it shows up at, what the status is in each of those maps, whether it's sharable or not (though the Linux vmm doesn't seem to do any write locking), and probably some functions that I've missed. > At > that point, instead of updating the disk drive - It looks up the page in > memory and updates that copy. There are two ways to do this in general... Write-through: means the vmm goes ahead and not only updates the vmm copy but the copy on the drive. Note that this may or may not actualy update other copies if a process has one that isn't sharable (ie has its own private copy). This has a lot of over-head in that there is lots of i/o. Write-back: means that the data in the individual pages doesn't get written to the drive until the page is either swapped out of active memory (and written to swap) or is closed. This is a form of 'lazy propogation'. Again, this doesn't address how other processes may have their images effected. > The only problem is that at that point, > you're now running into a mess of lock problems that carry their own > overhead. One easy way, at least on a Unix machine, is to keep the system clock setting when the page is created. Then close them in chronological sequence. This obviously has it's problems. The first person to open isn't guaranteed to be the first person done. Another method would be to select via a PRNG the 'first' process to update the page. Then each following would take their turn according to the spin of the wheel. This leaves us with two options, as each process closes it only writes the changes that it has made; which could overwrite the previous user if they edited the same part of the file. The alternative would be to force each user to create a different file with some filename convention to differentiate them. Then leave it up to some unknown method to arbitrate the file propogations at that point by some 'compare and share' method perhaps. > Another alternative would be to track the disk map and force a > write for a page that is pending a read. How do you know ahead of a read that a process is going to read that page? Or are you saying that before another process can open a file we force the first process to go ahead and write its changes? What happens once two or more have the page mapped and begin editing? How do you propose to manage the file closure writes that will occur? ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0