Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Perry E. Metzger wrote: Have a look, for example, at http://www.americanexpress.com/ which encourages users to type in their credentials, in the clear, into a form that came from lord knows where and sends the information lord knows where. Spoof the site, and who would notice? Every company should be telling its users never to type in their credentials on a web page downloaded in the clear, but American Express and lots of other companies train their users to get raped, and why do they do it? Not because they made some high level decision to screw their users. Not because they can't afford to do things right. It happens because some idiot web designer thought it was a nice look, and their security people are too ignorant or too powerless to stop it, that's why. Why is it bad for the page to be downloaded clear? What matters is the destination is encrypted, surely? Which, as it happens, it is on the above site. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Amir Herzberg [EMAIL PROTECTED] writes: Perry makes a lot of good points, but then gives a wrong example re Amex site (see below). Amex is indeed one of the unprotected login sites (see my `I-NFL Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of the few companies that actually responded seriously to my warning on this matter. In fact, I think they are the _only_ company that responded seriously - but failed to fix their site... [...] I'm surprised that they responded to you. I tried to get to respond to my inquiries about it for weeks without any success. I did get a nice letter from JP Morgan Chase telling me I was crazy and that there is no security problem on their site (which suffers from the same problem). I probably should publish it to assure the dismissal of the people responsible for sending it to me. 2. They have a serious problem in using SSL in their homepage, and for business reasons, they don't want to put the login on a different page. Well, those business reasons are pretty obviously an incorrect balance of security and convenience, as I'm sure you would agree. The inconvenience of having to click one more button to get to your account is minimal -- almost unmeasurably small. The inconvenience of the company having to explain to tens of thousands of people that they've screwed them badly, along with all of the money lost, is substantially higher. One day they'll be paying that second inconvenience. Many other financial institutions get this right, by the way. Citigroup gets this right. If their customers can click onto another page, so can customers of American Express, Chase, etc. below are the relevant parts of Perry's message... I think you'll agree you picked wrong example. I don't agree. I think this is still a case of human frailty causing a security problem, rather than some sort of technological issue. If you know what the problem is and you decide not to do anything about it because you believe that for business reasons you shouldn't put the login on a separate page, you've got nothing to blame for your future security problems other than yourself. My point is simple. We have enough protocols, software, etc. to avoid most of the security issues we have to deal with at this point. Most of the remaining problem tends to be human beings. In this case, the human beings security people who know better but give in when management decides for what amounts to aesthetic reasons that it needs a login on the front page that isn't protected by SSL. As I said, I agree with the above (and most of the removed stuff). But below you jumped to the wrong conclusions. I disagree. I'll stand by most of what I said. Every company should be telling its users never to type in their credentials on a web page downloaded in the clear, but American Express and lots of other companies train their users to get raped, And they are indeed training their users to enter in security credentials on unsecure pages. and why do they do it? Not because they made some high level decision to screw their users. Not because they can't afford to do things right. It happens because some idiot web designer thought it was a And if in this one case it turns out that they did indeed make a high level decision to screw their users, so much the worse. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Steven M. Bellovin wrote: The bigger issue, though, is more subtle: keeping track of the keys is non-trivial. These need to be backed up, too, and kept separate from (but synchronized with) the tapes. Worse yet, they need to be kept secure. That may mean storing the keys with a different escrow company. A loss of either piece,the tape or the key, renders the backup useless. This is correct. It is not that nobody ever thought of encrypting tapes, it is that there has been no uptake on the idea because the management overhead costs outweighed the perceived benefit. The big vendors didn't bother offering it because they didn't think they could make money, and the start-ups who have been trying to fill the gap found the market to be small. Now it is becoming clear that the perceived benefit has been underestimated. There are a number of small companies making products that can encrypt data in a storage infrastructure, including tape backups (full disclosure: I work for one of those companies). The solutions all involve appliances priced in the tens of thousands. The costs come not from encryption (how much does an FPGA cost these days?), but from solving the problems you listed, plus some others you didn't. Now that the benefit of storage encryption is clearer, tape vendors (StorageTek, HP, IBM, etc) are almost certainly looking at adding encryption capability into their offerings. There is an IEEE working group developing interoperability standards for storage encryption, including tape: http://www.siswg.org And in case anyone is really interested in this subject, Networking Computing magazine did a round-up of all the storage infrastructure security solutions currently on the market: http://www.networkcomputing.com/showitem.jhtml?docid=1607f2 Ken - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes
Ben Laurie [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Have a look, for example, at http://www.americanexpress.com/ which encourages users to type in their credentials, in the clear, into a form that came from lord knows where and sends the information lord knows where. Spoof the site, and who would notice? Every company should be telling its users never to type in their credentials on a web page downloaded in the clear, but American Express and lots of other companies train their users to get raped, and why do they do it? Not because they made some high level decision to screw their users. Not because they can't afford to do things right. It happens because some idiot web designer thought it was a nice look, and their security people are too ignorant or too powerless to stop it, that's why. Why is it bad for the page to be downloaded clear? What matters is the destination is encrypted, surely? Why is it a problem? Because the http post method you're relying on could have come from anyone -- you're just assuming that it posts to Amex's site. How often do users hit ^U and read the source on the front page of a site like this? Never, for practical purposes. Unless you're looking at the code every time, you have no idea where your form data gets posted. It could be a server in Moldova instead of Manhattan. You have no idea where the page came from, and thus you have no idea where the post method will send your data. You assume it came from American Express, but it may very well have come from people attempting to crack your account who used DNS cache contamination or other techniques to get you to talk to their server. Even plain old man-in-the-middle interception and modification would work for this, though it is harder to do unless, say, the victim is using the wireless at Starbucks or an airport or what have you, in which case it is trivial. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes
james hughes [EMAIL PROTECTED] writes: There are large institution with 1000s of tape drives and 1,000,000 or more cartridges. Even simple solutions are huge to implement. This is a non-trivial matter. The technical solutions are possible, there are vendors out there that are already doing this. Getting from here it there, even if the solutions were available for free is still a very expensive challenge. It isn't much of a challenge. In several cases, the cost of implementing backup encryption was much cheaper for my customers than the cost of the time it took me to explain to them that they needed it -- i.e. ignorable. There are plenty of reasonable ways to handle the key management problem, and even using a well known (at least if you have the key to the safe deposit box) conventional key for all your backups in a given month or six months is a whole lot better than leaving the data in the clear. (Sure that isn't ideal, but now you've raised the bar a whole lot, and you can implement better methods if you have the will.) Some people claim that the data rates you are dealing with are too high to permit doing the encryption without hardware, but that's usually because they imagine having all the compression and encryption done on the machine managing the tape robot. Even in that case, though, extra processors are often a whole lot cheaper than the labor cost of the meeting needed to discuss the problem. Bottom line, this issue is here to stay and will take years to solve. Since several of my customers have solved this problem already, and since it didn't take them years, I have to dispute that claim pretty strongly. The most important thing it requires is the will to do it. Cost isn't a real issue, technology isn't a real issue. Human beings are the issue. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout Algorithm hiding ?)
Amir Herzberg wrote: 3. They did not actually spell out the problem in using SSL in the homepage (like eTrade, for instance). But I think I know the reason (they didn't confirm or deny). I think the reason is that they host their site; in particlar, when I tried accessing it via https, I got an Akamai certificate... [I don't think they liked this observation; now you are led to the unprotected site] This would appear to be an artefact. If you fetch the page you are redirected to (http://home.americanexpress.com/home/mt_personal.shtml) over HTTPS you'll find it is still an akamai server. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Perry wrote: In case you think the answer is regulation, by the way, let me note that most of the regulatory pressure I've seen on security policy results in people finding extremely well documented ways to do exactly what the regulators ask, to no actual effect. This is generally because the regulators are almost uniformly as dumb or dumber than the people they regulate. One thing that irritates me is that most security audits (that verify compliance with regulations) are done by accountants. No disrespect for accountants here, they are smart people, but most of them lack the security knowledge needed to really help with the security posture of a company, and often they don't work with a security expert. I saw allot of requirements by security auditors that looked pretty silly. I believe a mix of accountants with security experts should be used for security audits --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Ben Laurie [EMAIL PROTECTED] writes: Anne Lynn Wheeler wrote: Peter Gutmann wrote: That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. this was one of the big issues in the asn.1 encoding vis-a-vis xml encoding wars. asn.1 encoding provided deterministic encoding for signed material, You mean it _would_ have done if anyone could implement it correctly. Sadly, experience shows that no-one can. Right, but that's lead to a de-facto encoding rule of The originator encodes it however they like, and everyone else re-encodes it (if required) using memcpy(). The advantage of the format is that it's never tried to be anything other than a pure binary-only format, so moving it over text-only channels is handled at the next layer down (usually base64), rather than trying to make the encoding itself text-only-capable and then finding yourself in a world of pain when half the systems the stuff passes through mangle the text. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes
[EMAIL PROTECTED] writes: One thing that irritates me is that most security audits (that verify compliance with regulations) are done by accountants. No disrespect for accountants here, they are smart people, but most of them lack the security knowledge needed to really help with the security posture of a company, and often they don't work with a security expert. I saw allot of requirements by security auditors that looked pretty silly. I believe a mix of accountants with security experts should be used for security audits It is worse than that. At least one large accounting company sends new recruits to a boot camp where they learn how to conduct security audits by rote. They then send these brand new 23 year old security auditors out to conduct security audits, with minimal supervision from a partner or two. The audits are inevitably of the lowest possible quality -- they run automated security scanners no better than open source ones you could download on your own, and they run through checklists. If an automated tool doesn't say there is a problem, or if you obey the mindless checklist items, you pass. Of course, for all the good such an audit does, you would as well roll dice and claim that the output was somehow correlated with the quality of your security infrastructure. Such an audit is totally worthless except as a bureaucratic dodge. We hired a world class accounting company to check our security! the executives can cry, so these security problems aren't our fault! (Would that fiduciary responsibility was not so often equated with make sure there is enough window dressing that we can't be blamed.) By the way, selling such audits is extremely profitable, given the discrepancy between the pay for the kids doing the audits and the price the customer is charged. What is pathetic is not that companies would try to foist such worthless services upon their customers, but that their customers would willingly buy. Incidently, my understanding is that at least some accounting companies use similar techniques for doing audits of the bookkeeping practices at their customers, which makes them at least somewhat consistent, if nearly useless to relying parties. When you hear things to the effect that accounting audits can only detect unintended bad process and not deliberate malfeasance, that's part of the reason why. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout Algorithm hiding ?)
| Perry makes a lot of good points, but then gives a wrong example re Amex site | (see below). Amex is indeed one of the unprotected login sites (see my `I-NFL | Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of | the few companies that actually responded seriously to my warning on this | matter. In fact, I think they are the _only_ company that responded seriously | - but failed to fix their site... I had an interesting discussion with their | security and web folks, and my conclusions are: | | 1. These are serious people who understand technology and security | reasonably well. They are aware of many attacks, including much more | advanced spoofing attacks (that can foil even an expert user of a `regular` | browser - by regular I mean without improved security indicators like | provided by TrustBar). Unfortunately, they use this awareness to justify to | themselves the lack of protection (`why should I put a lock when some people | know how to break it?`) | | 4. Ultimately, what we have here is simply the `usability beats security` | rule... If you look at their site now, they *claim* to have fixed it: The login box has a little lock symbol on it. Click on that, and you get a pop-up window discussing the security of the page. It says that although the page itself isn't protected, your information is transmitted via a secure environment. No clue as to what exactly they are doing, hence if it really is secure. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Jerrold Leichter [EMAIL PROTECTED] writes: If you look at their site now, they *claim* to have fixed it: The login box has a little lock symbol on it. Click on that, and you get a pop-up window discussing the security of the page. It says that although the page itself isn't protected, your information is transmitted via a secure environment. No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Wed, Jun 08, 2005 at 01:33:45PM -0400, [EMAIL PROTECTED] wrote: | | Ken Buchanan wrote: | There are a number of small companies making products that can encrypt | data in a storage infrastructure, including tape backups (full disclosure: | I work for one of those companies). The solutions all involve appliances | priced in the tens of thousands. The costs come not from encryption (how | much does an FPGA cost these days?), but from solving the problems you | listed, plus some others you didn't. | | Now that the benefit of storage encryption is clearer, tape vendors | (StorageTek, HP, IBM, etc) are almost certainly looking at adding | encryption capability into their offerings. | | Another area where I predict vendors will (should) offer built in | solutions is with database encryption. Allot of laws require need-to-know | based access control, and with DBA's being able to see all entries that is | a problem. Also backups of db data can be a risk. | Oracle, for example, provides encryption functions, but the real problem | is the key handling (how to make sure the DBA can't get the key, cannot | call functions that decrypt the data, key not copied with the backup, | etc.). | There are several solutions for the key management, but the vendors should | start offering them. I would argue that the real problem is that encryption slows large searches (is percieved to slow large searches, anyway.) Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
2) The cost in question is so small as to be unmeasurable. Yes, because key management is easy or free. Also, reliability of encrypted backups is problematic: CBC modes render a single fault destructive to the entire dataset. Counter mode is sufficiently new that it's not supported by existing code. --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: AmEx unprotected login site
Protected or not, AmericanExpress.com has multiple web vulnerabilities - I wouldn't log into it with a ten-foot pole :) -Lance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry E. Metzger Sent: Wednesday, June 08, 2005 12:16 PM To: Jerrold Leichter Cc: Amir Herzberg; cryptography@metzdowd.com Subject: Re: AmEx unprotected login site Jerrold Leichter [EMAIL PROTECTED] writes: If you look at their site now, they *claim* to have fixed it: The login box has a little lock symbol on it. Click on that, and you get a pop-up window discussing the security of the page. It says that although the page itself isn't protected, your information is transmitted via a secure environment. No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
de-identification
Ladies and Gentlemen, I'd like to come up to speed on the state of the art in de-identification (~=anonymization) of data especially monitoring data (firewall/hids logs, say). A little googling suggests that this is an academic subspeciality as well as a word with many interpretations. If someone here can point me at the mother lode of insight, I would be most grateful. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The encrypt everything problem
On Wednesday 08 June 2005 18:33, [EMAIL PROTECTED] wrote: Ken Buchanan wrote: Another area where I predict vendors will (should) offer built in solutions is with database encryption. Allot of laws require need-to-know based access control, and with DBA's being able to see all entries that is a problem. Also backups of db data can be a risk. Oracle, for example, provides encryption functions, but the real problem is the key handling (how to make sure the DBA can't get the key, cannot call functions that decrypt the data, key not copied with the backup, etc.). There are several solutions for the key management, but the vendors should start offering them. Yes, this is a perfect example of where we need tools that can make this use of crypto more transparent. Of course, anyone who's worked on big database projects must have realised that they've drifted somewhat away from the idealistic vision of the relational story (as told by Coase? Date? some other guys no doubt) and adding encryption and key handling to that is just like throwing sand into the machine. I'd suspect most of us here could have a fair stab at the encrypted tapes problem. But we'd not get nearly as far with the encrypted database problem. I think this is one area where databases are going to continue to create more noise than value, and things like capabilities are more likely to advance, simply as they are looking more clearly at the underlying data and the connections and authorisations that need to be protected. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
| Oracle, for example, provides encryption functions, but the real problem | is the key handling (how to make sure the DBA can't get the key, cannot | call functions that decrypt the data, key not copied with the backup, | etc.). | There are several solutions for the key management, but the vendors should | start offering them. I would argue that the real problem is that encryption slows large searches (is percieved to slow large searches, anyway.) Adam Yes, encrypting indexed columns for example is a problem. But if you limit yourself to encrypting sensitive information (I'm talking about stuff like SIN, bank account numbers, data that serves as an index to external databases and are sensitive with respect to identity theft), these sensitive information should not be the bases of searches. If they are not he basis of searches, there will be no performance problems related to encrypting them. So my answer to people that have the perception you mentioned is that if you want to encrypt sensitive information and that would cause performance problems, then there are problems with your data architecture privacy wise (you should re-structure your data, use it differently, etc.). --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
In message [EMAIL PROTECTED], Perry E. Metzger writes: Jerrold Leichter [EMAIL PROTECTED] writes: If you look at their site now, they *claim* to have fixed it: The login box has a little lock symbol on it. Click on that, and you get a pop-up window discussing the security of the page. It says that although the page itself isn't protected, your information is transmitted via a secure environment. No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. A few years ago, I talked with someone who was setting up a system that really needed security. Given how few pages people would visit on the site, though, he estimated that it would increase his costs by a factor of about 15. (I didn't verify the numbers; I know from experience that he's competent and has his hear in the right place re security). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Steven M. Bellovin [EMAIL PROTECTED] writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. The other major offender are organizations (such as portions of Verizon) that subcontract payment systems to third parties. They are training their users to expect to be directed to a site they don't recognize to enter in their credit card information. Really! This is your vendor's payment site! Pay no attention to the URL and certificate! That one in particular takes amazing brains... Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
In message [EMAIL PROTECTED], Perry E. Metzger writes: Steven M. Bellovin [EMAIL PROTECTED] writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. There's an attack there, too -- one can divert the link to the login screen. The other major offender are organizations (such as portions of Verizon) that subcontract payment systems to third parties. They are training their users to expect to be directed to a site they don't recognize to enter in their credit card information. Really! This is your vendor's payment site! Pay no attention to the URL and certificate! That one in particular takes amazing brains... It's a tough problem: they want to outsource the payment processing, but don't have the infrastructure to do so properly. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
encrypted tapes (was Re: Papers about Algorithm hiding ?)
Ben Laurie writes: Why is it bad for the page to be downloaded clear? What matters is the destination is encrypted, surely? Because the page you downloaded in the clear contains the https: URL in the post method. How do you know that this is the right URL? If you got the page in the clear, you don't. An attacker who can provide a spoofed page (by DNS cache poisoning, pharming, MITM attacks, or any other method) could substitute a post URL that sends your sensitive data to hackers-r-us.com. That said, I don't see how adding an extra login page to click on helps. If the front page is unencrypted, then a spoofed version of that page can send you to the wrong place. Sure, if users were to check SSL certificates extremely carefully, they might be able to detect the funny business -- but we know that users don't do this in practice. Dan Bernstein has been warning of this risk for many years. http://cr.yp.to/djbdns/bugtraq/[EMAIL PROTECTED] http://cr.yp.to/dnscache/bugtraq/[EMAIL PROTECTED] As far as I can tell, if the front page is unencrypted, and if the attacker can mount DNS cache poisoning, pharming, or other web spoofing attacks -- then you're hosed. Did I get something wrong? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes
Dan Kaminsky [EMAIL PROTECTED] writes: 2) The cost in question is so small as to be unmeasurable. Yes, because key management is easy or free. In this case it is. As I've said, even having all your tapes for six months at a time use the same key is better than putting the tapes in the clear. If you have no other choice, pick keys for the next five years, changing every six months, print them on a piece of paper, and put it in several safe deposit boxes. Hardcode the keys in the backup scripts. When your building burns to the ground, you can get the tapes back from Iron Mountain and the keys from the safe deposit box. No, it isn't ideal, or even very good, but it is a whole lot better than what most people do now. You aren't safe from a real attacker, but you're safe from someone that gets their hands on a box of tapes, and that's way better than nothing. Good requires a lot more work, but stupid and better than nothing takes very little. There is little excuse for not doing *something*. Also, reliability of encrypted backups is problematic: CBC modes render a single fault destructive to the entire dataset. Er, no. An error in CBC wipes out only the following block. Errors do not propagate past that in CBC. This is not especially worse than the situation right now. However, all of that is immaterial if you're using a tape drive that compresses, because then you really are screwed if you lose a block, encryption or not. Most backups are currently done compressed (which I have to say I think is a bit of a mistake, even if it does save money...) Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
