I've seen a number of people mention the S/MIME hooks in Outlook and Outlook Express (I use both S/MIME and PGP at home). My company has been using these everyday for about a year now, despite the poor UI and all the bugs. Frankly, if it were not for special circumstances, we would have stopped using it quite a while ago.
Here are some of the UI issues:
* The built-in routine to acquire a certificate is not too bad, but the UI changes all the time (Win98, Win NT, Win 2K; multiplied by Outlook and Outlook Express; multiplied by IE 5 and IE 5.5).
* Encrypted messages require knowing the recipients cert, and getting that is a major pain. For our small company we do it manually, since we don't want to use Exchange. Unless you have a directory or Exchange "yellow pages", there is no easy way to add internal users. External users are even worse (see below).
* We have new users send out a signed message, which when received Outlook Express will automatically add to it's internal contacts. But guess what, Outlook requires a manual process (Outlook 2000 - open message, right-click on sender, add-to-contacts, save-and-close, OK-to-update-contact).
* Another method we tried was to exchange "contacts" (in VCARD format) by using Outlook folders or mail messages, but it turns out that these don't contain the certificates.
* Downloading the certs directly from the CA sounds like the logical solution, but the process is really cumbersome and only processes one cert at a time in a 1-2 minute process (search the CA, download an individual cert to a file, import the cert into the system).
* There are many reasons why the outgoing mail message will be encrypted with poor encryption (RC2-40), left-over from the former US encryption policy. IE, which supplies the cryptography for Outlook and Outlook Express, needs to have the high encryption package. We have a also run into a number of other obscure settings that cause the use of RC2-40.
* There is no warning when the outgoing mail message is only going to be encrypted with RC2-40. At least Outlook Express has a "warning feature" for incoming messages using inferior cryptography (Outlook does not).
* The poor certificate distribution results in users with laptops or telecommute systems often are missing some of the certificates.
The bugs are really annoying too, here are some of the one we have experienced:
* Occasionally, an encrypted message will be unreadable. This is not usually a consistent problem, but when it is, re-importing certs can help.
* Occasionally signed messages will arrive with invalid signatures. We suspect this might have something to do with the mail process, but have not figured what is happening (visual inspection seems identical, have not gotten around to a detailed binary comparison yet).
* Outlook 98 combined with IE 5.5 has a bug that makes it unable to open a signed message. This is the only problem I've seen with S/MIME signed messages - most mailers either recognize the S/MIME attachment, or open the message with a warning.
* The outgoing message encryption will occasionally drop to RC2-40 for unknown reasons. This will even occur when previous messages were properly encrypted.
* Occasionally, Outlook will "loose" the cert. The contact remains there, but the cert is no longer in the system. I suspect this might have to do with a Palm sync, but I have not been able reliably produce the problem (not observed in Outlook Express).
* Occasionally a personal cert will not "import" correctly (sharing with laptop or home system). It seems to be installed, but things just don't work. Work around is to erase and try again.
* We also use personal certificates on smartcards/tokens, but there are some problems there too. My personal bug-a-boo happens when I try to send an encrypted message without the Rainbow iKey 2000 Token inserted - you get an uninformative error message, and have to restart the system before it will recognize the token again (true of both Outlook, and Outlook Express, as well as IE when using client authenticated SSL).
I should mention that we have installed all the service packs and bug fixes. I've also tried to report some of these problems to Microsoft, but the "free" technical support channels seem to be ignored. Personally, I decided not to pay Microsoft for the privilege of reporting bugs to them.
In conclusion, I can't really recommend using Outlook 2000 or Outlook Express with S/MIME. It is not ready for prime time, especially because of the numerous bugs. The experience might be better for a pure Microsoft shop with Exchange (improved certificate handling for internal use at least), but even then I'm willing to bet they will get a number of the same bugs we experienced. The main reason we have kept using it is because we are a security company, and want to make a statement. It should not have to be this painful!
My understanding of the double stash side comes from some Blizzard promotional literature. The green "unique" set of items now get additional powers if you have more than one of the same set. One of the primary reasons for increasing the stash size was to allow you to save these items on the off-chance you can find another in the same set.
I wish I could find the link to the CSS anaylsis. The summary was that due to poor design the CSS algorithm had an effective bit strength of approx. 23-bits (despite 40-bits keys). I think that qualifies as "bad".
Why are all Hollywood encryption schemes so vulnerable to hacking, while Slashdot fav's such as SSH and PGP/GPG immune?
There are a number of differences. The first and foremost has to do with what is being accomplished by the algorithm. In most cases, the recording industry is trying to protect something that has to show up in the "clear". This means they are vulnerable to recording after they have been decrypted. It also means that "authorized" devices can be used as an oracle to assist in the attack against them. There are also issues that can occur when devices allow mixed modes (playback MP3 and SDMI work). SSH and PGP are used for different, and ultimately much simpler tasks.
Another big issue is key management. Ignore the fact the CSS is a really horrible encryption algorithm for a moment. The DeCSS break exploited a key management issue. Furthermore, once the key was broken, they did not have any recovery scheme. Take another example, satellite receivers. The basic method of breaking this scheme is "cloning a valid box". They can get away with this because of two reasons: the information is universally broadcast, and the de-scrambler does not communicate information back to the host.
The watermarking used by the SDMI had another classic weakness... security by obscurity. A particularly fun quote from the "leaked" SDMI crack paper went to the effect that security by obscurity is a really poor idea when the technique has been patented! Essentially the watermark, as used by the SDMI, relies purely upon obscurity. If the contents of the watermark were encrypted using a good cryptographic key, they might be more useful for other purposes (such as tracking who originally bought the song, if the watermark was not removed).
Another issue is the concept of trusted hardware and checking in with a trusted host. Early smartcards were easy to break into, but it is getting more difficult all the time. I never heard of a DIVX crack, which I'm sure were made much more difficult by the requirement to dial-in and "check-up" on a regular basis.
Just to summarize the list of weaknesses, I believe a fairly difficult to crack system could be designed, if we just give up some of those pesky [real-world] requirements. Give me high-quality trusted hardware, use unique keys and format feeds for each device, require playback to interactively check with a centralized host (probably at the speaker level), OK to sacrifice sound/video quality to resistant watermarks in the system, and finally remove all devices that don't have these features. OK, it is a bit of a stretch, but this is what the recording industry is trying to accomplish. Luckily, they are not doing a very good job of it (CSS, SDMI so far), but I don't want to trust that they will keep on messing up.
A few observations and quotes from Prof. Felten's speech at Stanford. As mentioned in the article, the hall was packed. People were sitting in the isles, and there were even 15-20 people sitting in the front of the hall (where professors normally get to walk). I'd estimate there were 30-40 people listening in the hallway, which is where I was. As a result, I never saw the slides (and Prof. Felten explicitly said he was not going to publish the slides).
Thanks to/. and a variety of other sources I already knew most of the information presented by the speech. There were a number of interesting quotes (from memory). He said the paper leaked to the internet was part of the peer review process, and the final paper was better (no details were discussed). He refused to discuss future strategy, but said he had not given up.
Perhaps the most important clarification to me was explaining exactly why the RIAA could make this threat. The DMCA encryption research exception only applied to researching, not to publishing (i.e. disseminating). Prof. Felten made some excellent points about the value of analyzing existing systems in security research, which is not generally recognized by the legal system. He also repeated several times that analysis is an important tool in many types of research. Although this is currently a computer security issue, he predicts the DMCA as it stands now will have a dramatic impact on many other areas of science and academia.
One of my favorite quotes, which did not make it into the Salon story went to the effect of "They made the threat, and once it was effective, tried to withdraw it". He also mentioned that there were some verbal communications from the RIAA, which made the threat even more clear.
John Gilmore (of DES Cracking fame) was also part of the hallway crowd. He was wearing his mind-bending shirt (a very brightly colored tie-died t-shirt with the NSA seal on it). After most of the crowd had dispersed, we went into the hall, and John wondered when "they" would be coming after him for his part in producing the contraband (he was waiving his co-authored book around Cracking DES: Secrets of Encryption Research, Wiretap Politics and Chip Design).
Indeed, one might almost think this is a government plot, as well as the more obvious RIAA/MPAA plot. Got any encryption research you want to discourage? Just use it in a copyright protection scheme, and now you have the ability to suppress any information about that technology.
I guess you would have to ask R, S, or A to find out. Actually, I notice with amusement that while the RSA patent is much hated, most people don't realize Diffe-Hellman was patented too (I know that Cylink ended up with it toward the end of it's life).
The big difference was the enforcement and terms imposed by RSA. Having been involved (but only slightly) with negotiating licenses for RSA, my opinion is that the RSA patent was leveraged in every possible way.
Some might call that a good business feat (RSA is one of the few businesses to make money directly off a cryptographic patent). I find myself agreeing that it help-up the industry at large (along with governmental interference).
On a related subject, Prof. Felten is speaking at Stanford today (Thurs May 17). I'll be there. Details follow:
Reading Between the Lines: Lessons from the SDMI Challenge and its
Aftermath - Prof. Edward Felten, Dept of Computer Science Princeton University
Date: Thursday, May 17; Time: 2:15 - 4:00; Location: Math (Building 380) Room 380 Stanford University
The music industry has proposed a range of "security technologies" designed to prevent the unauthorized copying of recorded music. Recently a group of researchers, including the speaker Prof. Edward Felten, was forced to withdraw from publication a paper analyzing several of these technologies, due to threats of litigation by the music industry.
This talk will discuss what happened:
- the status of anti-copying technology,
- how the music industry is trying to prevent copying
- an overview of the technical analysis
- how and why the authors were threatened,
- and the effect of the Digital Millennium Copyright Act on computer security researchers.
DIRECTIONS: You can locate the building by going to http://www.stanford.edu/home/map/search_map.html and clicking on Bldg. 380 Mathematics in the list of Academic and Administrative Buildings. Parking info can be found at http://www-facilities.stanford.edu/maps/download/. Please allow extra time for parking.
Questions? Please respond to Barbara Simons at: simons@acm.org
The duplications and 'time-shifts' (read: piracy) are simply copying without the authorization. It's the same situation as illegally copying mp3s or downloading movies off of gnutella. It's illegal...
Hmm, been reading RIAA and MPAA propaganda? Not only is time shifting recognized as a legal activity (Supreme Court "Sony vs. Universal"), it is also explicitly allowed by the DMCA.
Actually that was a another case where the recording industry screwed congress and the consumers. Time-shifting was already legal, so the DMCA did not really have to address it. But congress wanted to make this trade-off: formal recognition for time-shifting in exchange for protecting rental videos against copying. Thus the DMCA required VCR manufactures to recognize Macrovision/Copyguard as a trade-off in formalizing the ability to time-shift. How does this screw us - two ways:
* Read the top of this thread. The industry is adding content control measures to eliminate time-shifting. Of course the same DMCA makes circumventing the protection illegal (even if it is for a legal non-infringing use).
* The MPAA puts Macrovision/Copyguard on all video produced, not just the rentals. Thus they screw the average consumer out of their fair-use rights (to take a real world example, my 2 year-old is on a mission to wear-out his favorite VHS recordings, and macrovision prevents me from taking a perfectly legal step of making a back-up copy).
A few eons ago (in internet time), I recommended AOL to my unsophisticated relatives. I decided to get an AOL account too, more for familiarity to help out my relatives (back when my work had no problem with personal emails). Than my company got sold, and the new company had a "no personal email" policy.
Has anyone tried to use the AOL mail client for "normal" amounts of mail (Slashdot normal anyway)? It is very painful, I recommend trying something else for fun, like being dragged behind a car.
The first and most obvious problem is the lack of filtering. All 200+ messages a day come right into the same folder. The address book is really lousy, and has no easy "import" or "export" methods (forget sync with a PDA). Perhaps even worse are the games AOL plays with attachments. Incoming attachments get downloaded into a separate folder, and some files get transformed (into the dreaded ART format). Outgoing files get mangled in unexpected ways too. Just horrible!
At it happens, they have an adequate mail client within the corporate empire. The Netscape mail client has never been my favorite, but I've used it a number of times and it is at least reasonable. It does most of the things I want (including pda sync, calendar functions, and support for SMIME emails).
Infoworld has a column about this (http://www.infoworld.com/articles/op/xml/01/04/30/010430opfoster.xml). It went up $72 last year, and this year is now up to $129. The one mitigating factor, appearently Quickbooks 2001 will store the tax table (for one year), so you won't have to be online to do a payroll.
My advice, show your displeasure with your feet, Quickbooks is not the only accounting software package.
This is the letter I've sent to the RIAA. I'm still composing the congressional letter, but will post it here upon completion. Before they were messing with my principles, now there are messing with my profession!
As an expert in applied cryptography and hardware security systems, I am greatly concerned by the tactics used by the SDMI and the RIAA concerning the Princeton research paper. It is quite clear to me that even if SDMI used conventional cryptographic algorithms, there would still have been an attempt to stifle the academic research, under the pretense of it being a "copyright circumvention device prohibited by the DMCA".
This type of action would certainly cause me to think twice about publishing security issues, even if it was only vaguely related to copy protection schemes. Since I deal with banking level security, these actions may ultimately effect the safety of your personal bank accounts. This is not an exaggeration, as I have already discovered and help correct two severe flaws in smartcard wallet protocols (VisaCash used in the Atlanta Olympics and EMV used by several million users in Europe).
This prior restraint may be (and probably is) exactly what the RIAA, MPAA, and SDMI want; but it is unconstitutional and should be illegal. I will be informing my local congressional representatives and appropriate congressional committee members of the impact toward my profession.
You can get Electrostats to have good bass, they just have to be large! I recall one company that produced an Electrostatic Woofer in the late 80's (might have been Audio-Labs). I have no idea if they sold any, but the reviews were fairly decent. I suspect it was more an engineering stunt, than an actual product (they were very expensive, and hard to position).
I have heard full range electrostatics that can satisfy all but the most bass loving rocker. The Accoustat model 6, while not as good as the newer Quads or older KLH 9 in the traditional electrostat areas (midrange, transparenecy), had very good bass.
I have discovered, much to my anger and regret, that having a Time-Base-Correlater in a VCR does not mean that it will ignore Macrovision/Copyguard. I have a JVC HRS-76000U, which is otherwise a very nice VCR. The good folks at JVC has sabotaged the machine to respond to the MacroVision signal.
Nowhere in the VCR documents or manuals does it state that the VCR has built-in copy protection! There is a small note on the JVC website FAQ ("Q:Why does my copy look fuzzy?..."), but I don't think that is an adequate notice. I still have not decided what I plan to do, but I am thinking of demanding my money back, or filing a suit for deceptive advertising. I wonder how much cost it added to the unit to make it respond to MacroVision signal despite the built-in TBC?
PS: I discovered this problem when it stopped me from making a fair-use media transfer form DVD to VHS so that the movie could be viewed in a room that does not have a DVD (since I learned how much copy protection DVD players have, I have pretty stopped purchasing both the players and the discs).
Another reason why DVD worked is that the copy controls were not that appearent. You don't find out how crippled it is until later (for instance, when you can't fast forward past the commercial, or make a VHS dub).
I would not have purchased a DVD player, if I knew then what I know now. I have pretty much stopped purchasing DVDs.
This was actually the first time I've hard about Macrovision being mandated. What I find interesting is that this was supposed to be a narrow exception - quid pro quo. Trade macrovision copy protection in exchange for fair-use time shifting.
The gotcha comes in with DVD players. They put macrovision into DVD players, and it automatically gets protected. And the consumers get nothing in return. Where is the quid pro quo? This is another example of the the MPAA "playing the system", and getting far more out of it than the consumers do.
Frankly mandating Macrovision in the VCR was a bad bargin. The basic reasons, as said elsewhere, is that copy protection does know or care about why it is doing copy protection. Even after the proudcut goes into the public domain (a century or three from now), the copy protection will continue to do it's job.
Since I have not seen it mentioned, and as an ex-Tandem employee, don't forget about the Compaq/Tandem NonStop SQL database. It is used for the largest "active" db I'm aware. The Compaq ZLE demo contains 111TB, and ran 24/7 for more than a year (http://zle.himalaya.compaq.com/).
Yes it is a demo system, but it runs real applications and a full support load (simulated customer service requests, live data warehousing, etc.). It was originally setup as a Telco ZLE, and operates continuously with a simulated load (90 days of up to 5 times the current number of phone calls made world wide). To quote from the website:
The benchmark implementation retains 100 billion Call-Data-Records (CDRs). At peak operation, it accepts up to 50,000 random transactional inserts per second through the CORBA-based application and handles more than 100,000 customer service agents performing more than 3,000 transactions per second in the TUXEDO environment. It also processes 100 customer profile updates per second, physical defragmentation of CDR tables, trickle feed to the data mart, and batch extracts to the mining cluster and the massive ad hoc parallel query.
I would be interested in hearing about other large databases (business, not scientific which tends to have a very different set of db requirements). I know it was quite tricky designing a database that can handle data of this size, and still deliver acceptable performance while mixing inserts, searches, and parallel queries.
I ended up with a CS degree, but I took a lot of CE courses. My senior thesis was designing a logic analyzer, and writing an interface/control program for it. The biggest differences between the two degrees seemed to be in the "support" classes (lower division required courses).
The CS major required math like statistics and number theory. The CE major required generic engineering courses like physics, chemistry, etc. The CE major, like other engineering majors, seemed to have more requirements, and therefore less chance to take off-track courses.
The upper division courses for CE contained more electrical theory, and more math (Fourier transforms, etc.). The upper division CS courses contained more CS theory and practice; compilers, graphics, AI, Turing Machines, etc. I really enjoyed some of the middle ground used by both majors, such as micro-code design, Shannon-Switching theory, Karnaugh diagrams, etc.
I think it really comes down to finding areas that you like, and taking courses in them. As someone who is in a hiring position now, I don't see much difference between the majors after a couple of years. The one exception is doing something tricky like real-time embedded systems. I tend to think that certain aspects of these projects benefit from the CE/EE background, which is harder to pick-up on the job. Of course, one my first jobs was working with real-time embedded systems, and there were a few CE courses that I wished I had taken.
I thought one of the most relevant Slashdot subjects was Hanssen's use of the FBI's Automated Case Support System (ACS). The ACS contains information on all active FBI cases. The affidavit describes this starting on page 87. Hanssen, or someone logged in with his user-ID, performed periodic searches for key phrases, including: "Hanssen", "Dead Drop", "KGB", and various dates and locations ("Washington", "WhiteCedar Court", "9414 Talisman", etc.).
As a security system designer, I've always found one of the most the interesting parts is dealing with insider collusion/fraud. We don't know much about the FBI ACS system, but we can draw some conclusions. First, the FBI kept a good audit trail, and recorded information about all searches. This proved to be very useful after the fact (to help convict).
Second, it appears this logged information was not used pro-actively, or if it was, it was not successful in catching Hanssen. I'd like to know if the FBI reviews these logs on a regular basis, and what type of analysis methods they use (but I don't expect to see this information become public anytime soon;-) Actually, I can't see an automated tool, or even a human reviewer, flagging many of these searches. I mean, you might expect a counter-intelligence agent to periodically look for cases that involve dead drops.
The major exception was the search for his own name and address ( "9414 Talisman"). I expect someone might ego-surf once in a while, but doing this several times per year look suspicious. Actually, "searching for yourself" is the type of thing that the FBI probably has a [written] policy against (I know the IRS has similar regulations). It should be pretty easy to enforce this type of policy by periodically reviewing the audit logs (did user-a search for their own name, address, etc.).
The third conclusion is that Hanssen did not detect the case that was being built against him. The investigation had taken over a year, and they did not know it was an FBI agent at first (according to a NPR report on All-things-considered). I wonder if the FBI avoided using the ACS altogether, or if they were just lucky (before they suspected an FBI agent, they could have entered one of the dead drop locations). I'm sure there are some very interesting stories, that we will probably never hear.
I'm aware of the traditional definition for a zero-sum game, and agree that most classic games fall into this category. Like others, I feel that Role-Playing-Games are the best example of true non-zero-sum games.
But there are some hybrid games. It is hard to classify them. My favorite example is Chaosium's Arkham Horror board game. The players do keep score, and there is a possible winner at the end of the game. That said, the real purpose of the game is to save the world. If the players don't cooperate, it won't happen (even if they do cooperate, it might happen anyway). Nobody wins if Cuthulu takes over the world!
It is interesting to figure out why this game does not feel like a zero-sum game, compared to something like Trivial Pursuit (where answering the question does not really "take-away" from the other players). I think this is because of the strong mutual requirement (saving the world) is enough to override some of the normal competitiveness of the game.
Compaq has a product that has achieved better than five nines throughout it's entire installed customer base. A recent audit of the Compaq/Tandem Himalaya system showed that they achieved almost six nines of reliability, including "minimal" systems. Of course the minimal system is fully fault tolerant, including 2 CPU units, each unit using multiple CPUs.
As a former Tandem employee, what I find interesting is the wide range of HA technology being used by Compaq. In addition to the Nonstop Guardian systems (Tandem), they have DEC Tru-Clusters, Microsoft HA clustering, and now the LifeKeeper solution (this thread). They also recently announced they were licensing unspecified "stuff" from Stratus (formerly the 2nd banana in the Fault-Tolerant market behind Tandem). I know that no one technology works best for all situations, but this is getting ridiculous.
I guess Communism is beginning to look alot more appealing, eh?
The article paints this as a "leftest" goverment proposal. They have a quote from the right wing about taxes being the mother's milk of the left. Sounds like pretty much the standard rhetoric from the US Democrat/Republican sterotypes. I suspect this type of tax is much closer to Communism than Libertarianism.
The IBM Portable XT used a 4.7Mhz 8088, not the 8086 (I owned one, helped when IBM fire saled it to the employees because it was not selling very well in 1984). The AT&T (6300?) was the only 8086 "mostly IBM compatible" PC that I know of. The NEC V20, mentioned elsewhere, was a great deal. It dropped the power-on memory check from 1:45 to 1:15 (as in one minute 15 seconds to check 640K of RAM, I don't miss those days).
The reason that IBM picked the 8088 is that its pinout was designed to be more closely compatible with the Z80, which was the CPU used in IBM's early engineering prototypes for the IBM PC. Those early designs were basically formulaic 8-bit CP/M machines.
No, the Z80 had nothing to do with the decision to use the 8088. There were two key reasons:
* The 8088 had an 8-bit bus, while the 8086 used a 16-bit bus. The 8088 had less pins, and was considerably cheaper.
* In addition to the CPU cost advantage, the use of an 8-bit bus made it easier for manufactures to convert their existing 8-bit bus add-on cards for use with the IBM PC.
It was not until the IBM AT, using a 80286, that the 16-bit ISA bus was introduced in a "IBM compatible" family of PCs.
I was unable to find a description of the JAWS algorithm on the JAWZ website (JAWS Home Page), now that they have become a security consulting firm. The best I could find was a small redaction of the original JAWS claims here: 4comm DataEncryptor.
I wonder if anybody still has a copy of the original JAWZ claims (quite a hoot).
The website does not contain a lot of details, but the basic philosophy seems to be sound. Assuming they got the details correct (the methods of handling cookies, Java, JavaScript, etc.), they should be able to prevent many covert methods of identification.
The major issue I have is that SafeWeb works as a SSL man-in-the-middle. This dramatically changes my scope of trust. At first you might think you just have to trust them to keep you anonymous. But this SSL issue means you also have to trust that they do not view or modify any SSL traffic from the target site. I'm not sure about how to still keep your location private, but I would much prefer some method of doing end-to-end encryption with the target site.
Here are a few other thoughts about the technical details. One area of concern is how through are they about redirecting web requests, for example I was thinking this currently would not foil a web-bug. There is also little SafeWeb can do for you when you voluntarily breach your anonymous veil, except for the cookie management. Don't expect this site to work as a means of getting past censorware, because you can bet they will block it under every category!
I wonder what type of servers they are using. Sounds like they need lots of SSL processing (fair disclosure, I've helped design commercial SSL Accelerators). That will probably make this website a bit more expensive to run. I also wonder about internal security, both because of the SSL issue, and the fact you would expect spies to be interested in knowing more about anyone who wants to be anonymous. In particular, obtaining the SafeWeb SSL private key could be potentially quite valuable.
Finally, you should consider the trust and business models. As mentioned above, you have to trust SafeWeb, as a company, not to store or reveal your information. I'm a little cynical about advertising supported businesses, because I think they have lots of motivation to increase the amount of information they know about you. Still, their privacy statement as it stands now looks good. If you plan on using SafeWeb (for non-SSL transactions), I'd keep a careful eye on the privacy statement to make sure it remains good.
Slashdot Mirror
Here are some of the UI issues:
* The built-in routine to acquire a certificate is not too bad, but the UI changes all the time (Win98, Win NT, Win 2K; multiplied by Outlook and Outlook Express; multiplied by IE 5 and IE 5.5).
* Encrypted messages require knowing the recipients cert, and getting that is a major pain. For our small company we do it manually, since we don't want to use Exchange. Unless you have a directory or Exchange "yellow pages", there is no easy way to add internal users. External users are even worse (see below).
* We have new users send out a signed message, which when received Outlook Express will automatically add to it's internal contacts. But guess what, Outlook requires a manual process (Outlook 2000 - open message, right-click on sender, add-to-contacts, save-and-close, OK-to-update-contact).
* Another method we tried was to exchange "contacts" (in VCARD format) by using Outlook folders or mail messages, but it turns out that these don't contain the certificates.
* Downloading the certs directly from the CA sounds like the logical solution, but the process is really cumbersome and only processes one cert at a time in a 1-2 minute process (search the CA, download an individual cert to a file, import the cert into the system).
* There are many reasons why the outgoing mail message will be encrypted with poor encryption (RC2-40), left-over from the former US encryption policy. IE, which supplies the cryptography for Outlook and Outlook Express, needs to have the high encryption package. We have a also run into a number of other obscure settings that cause the use of RC2-40.
* There is no warning when the outgoing mail message is only going to be encrypted with RC2-40. At least Outlook Express has a "warning feature" for incoming messages using inferior cryptography (Outlook does not).
* The poor certificate distribution results in users with laptops or telecommute systems often are missing some of the certificates.
The bugs are really annoying too, here are some of the one we have experienced:
* Occasionally, an encrypted message will be unreadable. This is not usually a consistent problem, but when it is, re-importing certs can help.
* Occasionally signed messages will arrive with invalid signatures. We suspect this might have something to do with the mail process, but have not figured what is happening (visual inspection seems identical, have not gotten around to a detailed binary comparison yet).
* Outlook 98 combined with IE 5.5 has a bug that makes it unable to open a signed message. This is the only problem I've seen with S/MIME signed messages - most mailers either recognize the S/MIME attachment, or open the message with a warning.
* The outgoing message encryption will occasionally drop to RC2-40 for unknown reasons. This will even occur when previous messages were properly encrypted.
* Occasionally, Outlook will "loose" the cert. The contact remains there, but the cert is no longer in the system. I suspect this might have to do with a Palm sync, but I have not been able reliably produce the problem (not observed in Outlook Express).
* Occasionally a personal cert will not "import" correctly (sharing with laptop or home system). It seems to be installed, but things just don't work. Work around is to erase and try again.
* We also use personal certificates on smartcards/tokens, but there are some problems there too. My personal bug-a-boo happens when I try to send an encrypted message without the Rainbow iKey 2000 Token inserted - you get an uninformative error message, and have to restart the system before it will recognize the token again (true of both Outlook, and Outlook Express, as well as IE when using client authenticated SSL).
I should mention that we have installed all the service packs and bug fixes. I've also tried to report some of these problems to Microsoft, but the "free" technical support channels seem to be ignored. Personally, I decided not to pay Microsoft for the privilege of reporting bugs to them.
In conclusion, I can't really recommend using Outlook 2000 or Outlook Express with S/MIME. It is not ready for prime time, especially because of the numerous bugs. The experience might be better for a pure Microsoft shop with Exchange (improved certificate handling for internal use at least), but even then I'm willing to bet they will get a number of the same bugs we experienced. The main reason we have kept using it is because we are a security company, and want to make a statement. It should not have to be this painful!
My understanding of the double stash side comes from some Blizzard promotional literature. The green "unique" set of items now get additional powers if you have more than one of the same set. One of the primary reasons for increasing the stash size was to allow you to save these items on the off-chance you can find another in the same set.
I wish I could find the link to the CSS anaylsis. The summary was that due to poor design the CSS algorithm had an effective bit strength of approx. 23-bits (despite 40-bits keys). I think that qualifies as "bad".
There are a number of differences. The first and foremost has to do with what is being accomplished by the algorithm. In most cases, the recording industry is trying to protect something that has to show up in the "clear". This means they are vulnerable to recording after they have been decrypted. It also means that "authorized" devices can be used as an oracle to assist in the attack against them. There are also issues that can occur when devices allow mixed modes (playback MP3 and SDMI work). SSH and PGP are used for different, and ultimately much simpler tasks.
Another big issue is key management. Ignore the fact the CSS is a really horrible encryption algorithm for a moment. The DeCSS break exploited a key management issue. Furthermore, once the key was broken, they did not have any recovery scheme. Take another example, satellite receivers. The basic method of breaking this scheme is "cloning a valid box". They can get away with this because of two reasons: the information is universally broadcast, and the de-scrambler does not communicate information back to the host.
The watermarking used by the SDMI had another classic weakness... security by obscurity. A particularly fun quote from the "leaked" SDMI crack paper went to the effect that security by obscurity is a really poor idea when the technique has been patented! Essentially the watermark, as used by the SDMI, relies purely upon obscurity. If the contents of the watermark were encrypted using a good cryptographic key, they might be more useful for other purposes (such as tracking who originally bought the song, if the watermark was not removed).
Another issue is the concept of trusted hardware and checking in with a trusted host. Early smartcards were easy to break into, but it is getting more difficult all the time. I never heard of a DIVX crack, which I'm sure were made much more difficult by the requirement to dial-in and "check-up" on a regular basis.
Just to summarize the list of weaknesses, I believe a fairly difficult to crack system could be designed, if we just give up some of those pesky [real-world] requirements. Give me high-quality trusted hardware, use unique keys and format feeds for each device, require playback to interactively check with a centralized host (probably at the speaker level), OK to sacrifice sound/video quality to resistant watermarks in the system, and finally remove all devices that don't have these features. OK, it is a bit of a stretch, but this is what the recording industry is trying to accomplish. Luckily, they are not doing a very good job of it (CSS, SDMI so far), but I don't want to trust that they will keep on messing up.
Thanks to /. and a variety of other sources I already knew most of the information presented by the speech. There were a number of interesting quotes (from memory). He said the paper leaked to the internet was part of the peer review process, and the final paper was better (no details were discussed). He refused to discuss future strategy, but said he had not given up.
Perhaps the most important clarification to me was explaining exactly why the RIAA could make this threat. The DMCA encryption research exception only applied to researching, not to publishing (i.e. disseminating). Prof. Felten made some excellent points about the value of analyzing existing systems in security research, which is not generally recognized by the legal system. He also repeated several times that analysis is an important tool in many types of research. Although this is currently a computer security issue, he predicts the DMCA as it stands now will have a dramatic impact on many other areas of science and academia.
One of my favorite quotes, which did not make it into the Salon story went to the effect of "They made the threat, and once it was effective, tried to withdraw it". He also mentioned that there were some verbal communications from the RIAA, which made the threat even more clear.
John Gilmore (of DES Cracking fame) was also part of the hallway crowd. He was wearing his mind-bending shirt (a very brightly colored tie-died t-shirt with the NSA seal on it). After most of the crowd had dispersed, we went into the hall, and John wondered when "they" would be coming after him for his part in producing the contraband (he was waiving his co-authored book around Cracking DES: Secrets of Encryption Research, Wiretap Politics and Chip Design).
Indeed, one might almost think this is a government plot, as well as the more obvious RIAA/MPAA plot. Got any encryption research you want to discourage? Just use it in a copyright protection scheme, and now you have the ability to suppress any information about that technology.
The big difference was the enforcement and terms imposed by RSA. Having been involved (but only slightly) with negotiating licenses for RSA, my opinion is that the RSA patent was leveraged in every possible way.
Some might call that a good business feat (RSA is one of the few businesses to make money directly off a cryptographic patent). I find myself agreeing that it help-up the industry at large (along with governmental interference).
Reading Between the Lines: Lessons from the SDMI Challenge and its
Aftermath - Prof. Edward Felten, Dept of Computer Science Princeton University
Date: Thursday, May 17; Time: 2:15 - 4:00; Location: Math (Building 380) Room 380 Stanford University
The music industry has proposed a range of "security technologies" designed to prevent the unauthorized copying of recorded music. Recently a group of researchers, including the speaker Prof. Edward Felten, was forced to withdraw from publication a paper analyzing several of these technologies, due to threats of litigation by the music industry.
This talk will discuss what happened:
- the status of anti-copying technology,
- how the music industry is trying to prevent copying
- an overview of the technical analysis
- how and why the authors were threatened,
- and the effect of the Digital Millennium Copyright Act on computer security researchers.
DIRECTIONS: You can locate the building by going to http://www.stanford.edu/home/map/search_map.html and clicking on Bldg. 380 Mathematics in the list of Academic and Administrative Buildings. Parking info can be found at http://www-facilities.stanford.edu/maps/download/. Please allow extra time for parking.
Questions? Please respond to Barbara Simons at: simons@acm.org
Hmm, been reading RIAA and MPAA propaganda? Not only is time shifting recognized as a legal activity (Supreme Court "Sony vs. Universal"), it is also explicitly allowed by the DMCA.
Actually that was a another case where the recording industry screwed congress and the consumers. Time-shifting was already legal, so the DMCA did not really have to address it. But congress wanted to make this trade-off: formal recognition for time-shifting in exchange for protecting rental videos against copying. Thus the DMCA required VCR manufactures to recognize Macrovision/Copyguard as a trade-off in formalizing the ability to time-shift. How does this screw us - two ways:
* Read the top of this thread. The industry is adding content control measures to eliminate time-shifting. Of course the same DMCA makes circumventing the protection illegal (even if it is for a legal non-infringing use).
* The MPAA puts Macrovision/Copyguard on all video produced, not just the rentals. Thus they screw the average consumer out of their fair-use rights (to take a real world example, my 2 year-old is on a mission to wear-out his favorite VHS recordings, and macrovision prevents me from taking a perfectly legal step of making a back-up copy).
Has anyone tried to use the AOL mail client for "normal" amounts of mail (Slashdot normal anyway)? It is very painful, I recommend trying something else for fun, like being dragged behind a car.
The first and most obvious problem is the lack of filtering. All 200+ messages a day come right into the same folder. The address book is really lousy, and has no easy "import" or "export" methods (forget sync with a PDA). Perhaps even worse are the games AOL plays with attachments. Incoming attachments get downloaded into a separate folder, and some files get transformed (into the dreaded ART format). Outgoing files get mangled in unexpected ways too. Just horrible!
At it happens, they have an adequate mail client within the corporate empire. The Netscape mail client has never been my favorite, but I've used it a number of times and it is at least reasonable. It does most of the things I want (including pda sync, calendar functions, and support for SMIME emails).
My advice, show your displeasure with your feet, Quickbooks is not the only accounting software package.
As an expert in applied cryptography and hardware security systems, I am greatly concerned by the tactics used by the SDMI and the RIAA concerning the Princeton research paper. It is quite clear to me that even if SDMI used conventional cryptographic algorithms, there would still have been an attempt to stifle the academic research, under the pretense of it being a "copyright circumvention device prohibited by the DMCA".
This type of action would certainly cause me to think twice about publishing security issues, even if it was only vaguely related to copy protection schemes. Since I deal with banking level security, these actions may ultimately effect the safety of your personal bank accounts. This is not an exaggeration, as I have already discovered and help correct two severe flaws in smartcard wallet protocols (VisaCash used in the Atlanta Olympics and EMV used by several million users in Europe).
This prior restraint may be (and probably is) exactly what the RIAA, MPAA, and SDMI want; but it is unconstitutional and should be illegal. I will be informing my local congressional representatives and appropriate congressional committee members of the impact toward my profession.
I have heard full range electrostatics that can satisfy all but the most bass loving rocker. The Accoustat model 6, while not as good as the newer Quads or older KLH 9 in the traditional electrostat areas (midrange, transparenecy), had very good bass.
I have discovered, much to my anger and regret, that having a Time-Base-Correlater in a VCR does not mean that it will ignore Macrovision/Copyguard. I have a JVC HRS-76000U, which is otherwise a very nice VCR. The good folks at JVC has sabotaged the machine to respond to the MacroVision signal. Nowhere in the VCR documents or manuals does it state that the VCR has built-in copy protection! There is a small note on the JVC website FAQ ("Q:Why does my copy look fuzzy? ..."), but I don't think that is an adequate notice. I still have not decided what I plan to do, but I am thinking of demanding my money back, or filing a suit for deceptive advertising. I wonder how much cost it added to the unit to make it respond to MacroVision signal despite the built-in TBC?
PS: I discovered this problem when it stopped me from making a fair-use media transfer form DVD to VHS so that the movie could be viewed in a room that does not have a DVD (since I learned how much copy protection DVD players have, I have pretty stopped purchasing both the players and the discs).
I would not have purchased a DVD player, if I knew then what I know now. I have pretty much stopped purchasing DVDs.
The gotcha comes in with DVD players. They put macrovision into DVD players, and it automatically gets protected. And the consumers get nothing in return. Where is the quid pro quo? This is another example of the the MPAA "playing the system", and getting far more out of it than the consumers do.
Frankly mandating Macrovision in the VCR was a bad bargin. The basic reasons, as said elsewhere, is that copy protection does know or care about why it is doing copy protection. Even after the proudcut goes into the public domain (a century or three from now), the copy protection will continue to do it's job.
Yes it is a demo system, but it runs real applications and a full support load (simulated customer service requests, live data warehousing, etc.). It was originally setup as a Telco ZLE, and operates continuously with a simulated load (90 days of up to 5 times the current number of phone calls made world wide). To quote from the website:
The benchmark implementation retains 100 billion Call-Data-Records (CDRs). At peak operation, it accepts up to 50,000 random transactional inserts per second through the CORBA-based application and handles more than 100,000 customer service agents performing more than 3,000 transactions per second in the TUXEDO environment. It also processes 100 customer profile updates per second, physical defragmentation of CDR tables, trickle feed to the data mart, and batch extracts to the mining cluster and the massive ad hoc parallel query.
I would be interested in hearing about other large databases (business, not scientific which tends to have a very different set of db requirements). I know it was quite tricky designing a database that can handle data of this size, and still deliver acceptable performance while mixing inserts, searches, and parallel queries.
Still, I can see an argument for doing this, something along the same reason you do an occasional credit check on yourself.
The CS major required math like statistics and number theory. The CE major required generic engineering courses like physics, chemistry, etc. The CE major, like other engineering majors, seemed to have more requirements, and therefore less chance to take off-track courses.
The upper division courses for CE contained more electrical theory, and more math (Fourier transforms, etc.). The upper division CS courses contained more CS theory and practice; compilers, graphics, AI, Turing Machines, etc. I really enjoyed some of the middle ground used by both majors, such as micro-code design, Shannon-Switching theory, Karnaugh diagrams, etc.
I think it really comes down to finding areas that you like, and taking courses in them. As someone who is in a hiring position now, I don't see much difference between the majors after a couple of years. The one exception is doing something tricky like real-time embedded systems. I tend to think that certain aspects of these projects benefit from the CE/EE background, which is harder to pick-up on the job. Of course, one my first jobs was working with real-time embedded systems, and there were a few CE courses that I wished I had taken.
As a security system designer, I've always found one of the most the interesting parts is dealing with insider collusion/fraud. We don't know much about the FBI ACS system, but we can draw some conclusions. First, the FBI kept a good audit trail, and recorded information about all searches. This proved to be very useful after the fact (to help convict).
Second, it appears this logged information was not used pro-actively, or if it was, it was not successful in catching Hanssen. I'd like to know if the FBI reviews these logs on a regular basis, and what type of analysis methods they use (but I don't expect to see this information become public anytime soon ;-) Actually, I can't see an automated tool, or even a human reviewer, flagging many of these searches. I mean, you might expect a counter-intelligence agent to periodically look for cases that involve dead drops.
The major exception was the search for his own name and address ( "9414 Talisman"). I expect someone might ego-surf once in a while, but doing this several times per year look suspicious. Actually, "searching for yourself" is the type of thing that the FBI probably has a [written] policy against (I know the IRS has similar regulations). It should be pretty easy to enforce this type of policy by periodically reviewing the audit logs (did user-a search for their own name, address, etc.).
The third conclusion is that Hanssen did not detect the case that was being built against him. The investigation had taken over a year, and they did not know it was an FBI agent at first (according to a NPR report on All-things-considered). I wonder if the FBI avoided using the ACS altogether, or if they were just lucky (before they suspected an FBI agent, they could have entered one of the dead drop locations). I'm sure there are some very interesting stories, that we will probably never hear.
But there are some hybrid games. It is hard to classify them. My favorite example is Chaosium's Arkham Horror board game. The players do keep score, and there is a possible winner at the end of the game. That said, the real purpose of the game is to save the world. If the players don't cooperate, it won't happen (even if they do cooperate, it might happen anyway). Nobody wins if Cuthulu takes over the world!
It is interesting to figure out why this game does not feel like a zero-sum game, compared to something like Trivial Pursuit (where answering the question does not really "take-away" from the other players). I think this is because of the strong mutual requirement (saving the world) is enough to override some of the normal competitiveness of the game.
As a former Tandem employee, what I find interesting is the wide range of HA technology being used by Compaq. In addition to the Nonstop Guardian systems (Tandem), they have DEC Tru-Clusters, Microsoft HA clustering, and now the LifeKeeper solution (this thread). They also recently announced they were licensing unspecified "stuff" from Stratus (formerly the 2nd banana in the Fault-Tolerant market behind Tandem). I know that no one technology works best for all situations, but this is getting ridiculous.
The article paints this as a "leftest" goverment proposal. They have a quote from the right wing about taxes being the mother's milk of the left. Sounds like pretty much the standard rhetoric from the US Democrat/Republican sterotypes. I suspect this type of tax is much closer to Communism than Libertarianism.
The reason that IBM picked the 8088 is that its pinout was designed to be more closely compatible with the Z80, which was the CPU used in IBM's early engineering prototypes for the IBM PC. Those early designs were basically formulaic 8-bit CP/M machines.
No, the Z80 had nothing to do with the decision to use the 8088. There were two key reasons:
* The 8088 had an 8-bit bus, while the 8086 used a 16-bit bus. The 8088 had less pins, and was considerably cheaper.
* In addition to the CPU cost advantage, the use of an 8-bit bus made it easier for manufactures to convert their existing 8-bit bus add-on cards for use with the IBM PC.
It was not until the IBM AT, using a 80286, that the 16-bit ISA bus was introduced in a "IBM compatible" family of PCs.
Snake Oil FAQ
Counterpane Cryptogram Article
I was unable to find a description of the JAWS algorithm on the JAWZ website (JAWS Home Page), now that they have become a security consulting firm. The best I could find was a small redaction of the original JAWS claims here: 4comm DataEncryptor.
I wonder if anybody still has a copy of the original JAWZ claims (quite a hoot).
The major issue I have is that SafeWeb works as a SSL man-in-the-middle. This dramatically changes my scope of trust. At first you might think you just have to trust them to keep you anonymous. But this SSL issue means you also have to trust that they do not view or modify any SSL traffic from the target site. I'm not sure about how to still keep your location private, but I would much prefer some method of doing end-to-end encryption with the target site.
Here are a few other thoughts about the technical details. One area of concern is how through are they about redirecting web requests, for example I was thinking this currently would not foil a web-bug. There is also little SafeWeb can do for you when you voluntarily breach your anonymous veil, except for the cookie management. Don't expect this site to work as a means of getting past censorware, because you can bet they will block it under every category!
I wonder what type of servers they are using. Sounds like they need lots of SSL processing (fair disclosure, I've helped design commercial SSL Accelerators). That will probably make this website a bit more expensive to run. I also wonder about internal security, both because of the SSL issue, and the fact you would expect spies to be interested in knowing more about anyone who wants to be anonymous. In particular, obtaining the SafeWeb SSL private key could be potentially quite valuable.
Finally, you should consider the trust and business models. As mentioned above, you have to trust SafeWeb, as a company, not to store or reveal your information. I'm a little cynical about advertising supported businesses, because I think they have lots of motivation to increase the amount of information they know about you. Still, their privacy statement as it stands now looks good. If you plan on using SafeWeb (for non-SSL transactions), I'd keep a careful eye on the privacy statement to make sure it remains good.