Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: | 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. If they are indexes to external databases, then they are the basis of searches in those databases, by definition. My terminology might have been misleading. By indexes to external databases, I don't mean that the application that uses the database actually talks to the external databases (it doesn't use the info as a key to that external database) . Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. I have many other examples in mind, which I came across in the real world. 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.). Not a very satisfactory answer. No, of course I would sit down with the client and the software developers and examine their needs and constraints suggest how they can structure their data in a better way. I've done it several times over the years. There is no universal answer, but in my experience I found there is often good solutions. Let me throw back a precise question to you, to see if you disagree with what I said. Are you saying that it is often inevitable to index sensitive data? That is, are you saying that you often have to use sensitive data as the basis of searches? Yes. -- ApacheCon Europe http://www.apachecon.com/ 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 ?)
Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. No, they shouldn't! If you think they should, you are missinformed. At least in Canada, the Privacy Act protects the SIN, Equifax cannot demand it. See for example http://www.privcom.gc.ca/fs-fi/02_05_d_02_e.asp and http://www.guardmycreditfile.org/index.php/content/view/244/139/ which says the following: Even credit reporting companies cant demand a SIN to generate a credit report. Trans Union Canada and Equifax Canada both have the ability to generate such reports without a SIN. If you ask these same companies to generate a credit report in the United States, they both require a Social Security Number. And if Equifax Canada can generate reports without a SIN, I don't see why Equifax in any other country couldn't. Of course, they like to have the SIN, since it makes things more convenient, but they don't really need it! That is the problem in most cases. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. No, they shouldn't! If you think they should, you are missinformed. At least in Canada, the Privacy Act protects the SIN, Equifax cannot demand it. I am just reading what you've written: To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like -- ApacheCon Europe http://www.apachecon.com/ 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 ?)
On Fri, Jun 10, 2005 at 01:11:45PM -0400, [EMAIL PROTECTED] wrote: | Ben Laurie wrote | Sure, but Equifax should. | | No, they shouldn't! If you think they should, you are missinformed. At | least in Canada, the Privacy Act protects the SIN, Equifax cannot demand | it. | See for example | http://www.privcom.gc.ca/fs-fi/02_05_d_02_e.asp | and | http://www.guardmycreditfile.org/index.php/content/view/244/139/ | which says the following: | Even credit reporting companies cant demand a SIN to generate a credit | report. Trans Union Canada and Equifax Canada both have the ability to | generate such reports without a SIN. If you ask these same companies to | generate a credit report in the United States, they both require a Social | Security Number. | | And if Equifax Canada can generate reports without a SIN, I don't see why | Equifax in any other country couldn't. Of course, they like to have the | SIN, since it makes things more convenient, but they don't really need it! | That is the problem in most cases. Actually, there's a difference between theory and practice here. When I signed up for a mobile phone, they demanded a SIN, or would put me on the sucker plan. When I complained to the Quebec privacy commissioner, they told me that that was OK. There are so many examples of this sort of thing that I gave up sending complaint letters. Then you look at CIBC, and the lack of fines... Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like to see if the person has a good credit rating, if the rating is o.k. they cash the check. They keep all the information in the database, because if the client comes back 2 months later, they will send the same query to Equifax to see if the credit rating hasn't changed. These sensitive information are indexes to external databases (but Cash_Ur_check doesn't directly connect to these other databases). Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check can use first/middle/last name of person as an index, or attribute some random number to the person, or something else, they should not use the SIN to identify a person. They should not do searches on SIN to find a person given his SIN. Sure, but Equifax should. No, they shouldn't! If you think they should, you are missinformed. At least in Canada, the Privacy Act protects the SIN, Equifax cannot demand it. I am just reading what you've written: To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax or the like They'll ask for it, but you don't have to give it. They can collect it, but they don't have to do searches on it. It's the typical ask for SIN if the user gives it use it (as in Adam Shostack's example with cell phone), but if they don't then ask for 2 other identity cards. In most cases, I don't have to give my SIN, but almost everybody asks for it. Equifax will always ask for the SIN but they don't have the right to demand it. http://www.piac.ca/newpage91.htm Equifax suggests that to prevent these inaccuracies, consumers should always give their full name and SIN number on application forms (this facilitates updating of files and prevents confusion of two files). However, this solution to the problem does not take into account that consumers have a valid interest in protecting their privacy with respect to their SIN. The problem is with forms that make it look like you have to give your SIN, when in fact the law says you don't have to. Providing other identification can be troublesome, so allot of people just end up giving their SIN. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Jerrold Leichter [EMAIL PROTECTED] writes: They also sold a full solution for encrypted Ethernet - KDC, encrypting Ethernet adapters, associated software. None of this stuff went anywhere. People just weren't interested. That wasn't quite the case for the Ethernet encryption. What happened there was that they had a complete product ready to ship and quite a bit of interest when it was killed by marketing. The problem was that Ethernet at the time wasn't the forgone conclusion it is now, it was just one of a number of potential candidates for the foregone-conclusion role. By shipping an encrypting Ethernet adapter, marketing felt that DEC were saying that standard Ethernet wasn't safe. In contrast token ring didn't have an encryption adapter, so obviously token ring must be secure by default, whereas Ethernet clearly wasn't. As a result, the encryption adapter was never shipped. Strategy is not letting the enemy know you're out of bullets by continuing to fire. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote: 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. I can name at least one obvious case where sensitive data -- namely credit card numbers -- is in fact something you want to search on: credit card billing companies like CCbill and iBill. Without the ability to search by CC#, customers are pretty screwed. That said, I will never buy the only encrypt sensitive data argument. In my experience, you *always* end up leaking something that way. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Wed, 8 Jun 2005, David Wagner wrote: [...] 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? Well, yes. TLS guarantees that you're talking to the website listed in the location bar. Knowing what domain you *wanted* is up to you, and Dan handles that by suggesting that perhaps you have a paper brochure from the bank which lists their domain. So, it's fine to have http://amex.com link to https://amex.com (or whatever.com) for forms requesting anything sensitive as long as amex.com (or whatever.com) is what's printed in the brochure. As Dan points out, examination of the certificate is generally pointless as long as it's signed by a trusted CA, since the attacker can get a perfectly valid cert for hackers-r-us.com anyway. The big question is just whether the domain asking for your account info corresponds with the organization you trust with it. Of course, brochures aren't exactly hard to spoof (cf. Verisign's fraudulent domain renewal postcards). And then there are the dozens of CAs your browser accepts, the CA staff who issue microsoft.com certs to random passersby, international domain names that look identical to, er, national ones. All those gotchas apply even in the correct implementation outlined by Dan. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: | 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. If they are indexes to external databases, then they are the basis of searches in those databases, by definition. 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.). Not a very satisfactory answer. -- 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 ?)
From: Charles M. Hannum [EMAIL PROTECTED] I can name at least one obvious case where sensitive data -- namely credit card numbers -- is in fact something you want to search on: credit card billing companies like CCbill and iBill. Without the ability to search by CC#, customers are pretty screwed. Is there a good reason for not searching by the hash of a CC# ? http://www.wayner.org/books/td/ http://www.unixwiz.net/techtips/secure-cc.html I think the author is planning further work on this site and would be happy to receive constructive comments. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Thursday 09 June 2005 17:37, Charles M. Hannum wrote: If we assume that the last 4 digits have been exposed somewhere -- and they usually are -- then this gives you at most 38 bits -- i.e. 2^38 hashes to test -- to search (even a couple less if you know a priori which *brand* of card it is). How long do you suppose this would take? On reconsideration, given the presence of the check digit, I think you have at most 2^34 tests (or 2^32 if you know the brand of card). And this assumes there aren't additional limitations on the card numbering scheme, which there always are. I guess you could use a keyed hash. Remember, though, you can't use random padding if this is going to be searchable with a database index, so the amount of entropy you're putting in is pretty limited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote: 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. I can name at least one obvious case where sensitive data -- namely credit card numbers -- is in fact something you want to search on: credit card billing companies like CCbill and iBill. Without the ability to search by CC#, customers are pretty screwed. That said, I will never buy the only encrypt sensitive data argument. In my experience, you *always* end up leaking something that way. There are exceptions, I grant you that, but my hypothesis is that in most cases you can do without indexing on the sensitive data you have. Encrypting everything in your database, I say that will never work. If you do that, then you will have performance trouble, and nobody want's that. You can do stuff like encrypt everything at the OS level, but that doesn't help protect database backups and it doesn't prevent your DBA to look at data he's not supposed to. If you encrypt everthing at the DBMS level or at the application (client or middleware) level, than you cannot encrypt indexed data. --Anton --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] wrote: | 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. If they are indexes to external databases, then they are the basis of searches in those databases, by definition. My terminology might have been misleading. By indexes to external databases, I don't mean that the application that uses the database actually talks to the external databases (it doesn't use the info as a key to that external database) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
[EMAIL PROTECTED] writes: I saw allot of requirements by security auditors that looked pretty silly. Must use 128-bit RSA encryption has to be the all-time favourite. One I saw recently was a requirement for using X9.17 key management... in SSL. Peter. One of my favourites was that PINs had to be hashed (these were PINs for authentication in a proprietary application/system. The justification (given by the auditor) was that people who had access to the database, should not be able to see the PINs in clear. These where 4 digit PINs. So the developers just SHA-oned the PINs. Later on, the developers had to export the PINs into another application, that had its own way to protect the PINs, so they launched a brut force attack on all of the PINs, of course this was easy because the input space was very small and the hash function did not involve any secret key, no salt, no iterations... Talk about protection! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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: 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 (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: 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: 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]
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 (was Re: Papers about Algorithm hiding ?)
In message [EMAIL PROTECTED], Perry E. Metzger writes: The truth is, the likely reason no one encrypted the data on the tapes in transit was because no one thought to do it, or they were too lazy to bother to make even the simplest effort, or both. I don't completely agree. While I suspect that laziness or lack of thought are the primary problems, there are some real costs. The minor one is compression: most modern tape drives compress the data before writing, and you can't compress encrypted data. That means they'd need to compress in software before writing to the tape; that chews up CPU time that they may not have to spare on the machines in question. (Remember that we're talking about massive amounts of data here.) 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. Backups are not very reliable to start with. Too few companies do regular checks on the adequacy or quality of their backups. Most companies feel they can't afford lowering the reliability even further. ... The only thing that will fix this having enough people get so badly burned that CEOs start taking heads when people do dumb things. I imagine it can't be too many more years before that becomes the case. Bingo. Especially the CEO's head -- or the CFO's head, or the general counsel's -- for some of the mistakes we've seen. But there's no one cause. For those who subscribe to the Wall Street Journal online, see http://online.wsj.com/documents/info-idtheft0504.html?mod=technology_main_promo_left for a chart of recent failures to protect identity data. Of the 10 failures for which a cause is listed, though, 4 were loss of tapes in transit. (One was a shipment of tapes to a credit bureau.) 2 involved hacking, one was an inside job, one was a stolen laptop, and 2 were fraudulent use of logins and passwords. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
On Tue, Jun 07, 2005 at 07:48:22PM -0400, Perry E. Metzger wrote: 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. It has nothing to do with cost. The largest non-bank card issuer in the world can pay for the fifteen minutes of time it would take to fix it by putting the login on a separate SSL protected page. It has nothing to do with ease of use or tools that default safe. The problem is that they don't know there is anything to fix at a level of the firm that is capable of taking the decision to fix it. It may well be that, rather than the fault of the web designer, an explicit business requirement was presented to do this, because of perceived ease of use for the customer... and then the lack of knowing any better to kill the idea before it takes hold. At least, that's how it's happened in several places I've been involved, and it took more than a little effort to make them understand why it was a bad idea. Thankfully, they were paying for my time and advice, and *also* had the sense to listen to it when given - the two don't always go together - but in this sense security did cost them something. The customer ease-of-use argument is quite easy to see - and also quite easy to provide, if they want to, by putting the normal company homepage that contains the form on SSL too. I've had conversations about the cost of doing that with knowledgable web designers (largely centering on image caching concerns), and really, it isn't quite free, even if the costs come from unreasonable and annoying places. Those costs can have returns, even non-risk ones like being better able to track users' browsing patterns and site navigation, too - but just by virtue of having to have the conversation, its no longer free, especially if people bring organisational politics to the table. Security these days is usually bad not because good security is expensive, or because it is particularly hard. These are the things that make the difference between middling-fair and somewhat-decent security (let alone good security, which requires many other things to be Done Right, more operational than technical). The irony is that bad IT security (just like any other bad IT) is expensive, often much more expensive - even without considering the potential costs involved if the risks are realised. It is bad because even people at giant multinational corporations with enough budget to spare are too dumb to implement it. Worse than that: people at the giant multinational corporations who provide the outsourced IT services to those other corporations - and who sell their services based on 'economies of scale' and 'industry expertise' and 'best practice', and who are thus charged with the responsibility of knowing better - are too dumb to implement it. And then they're too dumb to implement it at other customer sites even when that one rare customer comes along who knows better (or at least knows to ask for independent outside help), and has fought hard to convinve their outsource provider of the need and economic sense of not being dumb on their behalf. Most organisations just let them get away with it, and think they're getting a good deal, while the very basis on which that deal was sold is defeated. If it weren't for all the other people that get hurt by the schrapnel, it would be very hard to continue trying to help people who seem to like walking around with bullet holes in their shoes. -- Dan. pgpj1TA56flkt.pgp Description: PGP signature
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. Basically, expensive or not, security is very hard to get right. When you look at Choicepoint, Bank of America, and Citigroup (not to mention universities and smaller businesses) they have little to no incentive to keep your personal data secure. YOU bear the cost of data compromise, not them. The worst they get is some bad publicity and only if it affects CA residents, otherwise it can be kept quiet. The threat of bad publicity does not mean much when next week your compromise due to bad security will be forgotten as the media switches to the next one. As it stands today, the cost/benefit analysis easily directs them away from taking strong measures to protect customer's financial data. Doing so is time consuming, opens up potential for problems, and gets them next to nothing in return. -- Mark Allen Earnest Lead Systems Programmer Emerging Technologies The Pennsylvania State University Lt Commander Centre County Sheriff's Office Search and Rescue KB3LYB smime.p7s Description: S/MIME Cryptographic Signature
