I am looking for an example in the real world where only a portion of the entire data set is encrypted even though the entire data set is considered sensitive. Specifically the portion that gives context to the rest.

For example (maybe a weak example). If you had sets of data on personnel, some of the raw data associated with each person may not be encrypted, because its easier to transfer if it isn't, but the identity of the person or any other critical context-providing data is encrypted.

The purpose of this would be to make manageable the transfer of the majority of the data across unsecured platforms easy. The encrypted context data could be carried separately and married back only when needed.


You are a doctor, and you want to use data from patients in a research project (Hospital research, not academic...). Part of the work is showing and comparing data with other doctors. This means you email ppt and excel spreadsheets with patient data. Most of the time the other doctors don't care about who the patient is (identity+more complete records) while they look at the data sets (maybe at the end, when they need to decide next steps). When they do, you want them to use their own access to get further patient records. But in order to do that, they need to have keys for each patient. These keys would be carried with the decrypted data.

You can't send and share the data encrypted. It doesn't work. one guy has a ipad, another has a windows netbook. And the engineer turned doctor has a linux distro running on an old mac laptop which he takes great pains to tell everyone works much faster than it did with OSX.

Excel is not secure. Even if you could deliver it encrypted, as soon as it is readable, it is copyable.

  • 2
    A common case (which I know too little about to write a proper answer) is statistical data, especially medical statistics, where you want to reveal that 2% of the population have disease X and 20% have an income below Y without revealing who those people are. Properly anonymizing such data (except, sometimes, to law enforcement or medical personnel) is a thorny problem. Commented Nov 29, 2011 at 17:38
  • I still don't understand the example. Patient data is pretty sensitive stuff, and there are many concerns, so the details matter. Perhaps you might be interested in learning about anonymization and de-identification techniques? Also, I'm mildly concerned any time it sounds like someone may have a pet scheme in mind and are now looking for some way to retroactively justify it. Finally, I'm puzzled about statements like "keys would be carried with the decrypted data" - I'm not sure how to make sense of that.
    – D.W.
    Commented Dec 7, 2011 at 3:53
  • Its certainly not being done right now. What is being done right now is providing doctors with access to sensitive information through secure portals. Once they have the data, they abuse it (security wise). They have to, otherwise they could not get done what they are expected to.
    – michael
    Commented Dec 7, 2011 at 23:54
  • The key with decrypted data refers to a token that can be used to reference secured data not with the doctor. it does not imply access rights in itself.
    – michael
    Commented Dec 7, 2011 at 23:55
  • I think anonymization and de-identification correctly identifies what I am getting at.
    – michael
    Commented Dec 7, 2011 at 23:56

1 Answer 1


Generally speaking, encrypting only part of the data can potentially be a security risk, because (depending upon the situation) it may be difficult to be certain that the part you leave unencrypted is completely free of anything sensitive. I am sure examples exist, but that doesn't mean they are necessarily the best practice to follow in every setting.

Why do you want an example where some of the data is left unencrypted? If you tell us more about why you are seeking such an example and what problem you are trying to solve, maybe we can help you with the real problem you have.

P.S. You seem to believe that unencrypted data is "easier to transfer" than encrypted data. I am puzzled by that belief. Data is data. It is just bits. It doesn't matter whether it is encrypted or not; either way, you are just copying bits and bytes. Doing a file transfer of an encrypted file is no harder than of an unencrypted file; it is exactly the same command (e.g., scp, or whatever).

  • If you include the distribution of the keys, then distributing encrypted data is harder. If you have a mixture of private and public data, you may want to distributed the public data in plain text and the private data encrypted for the intended recipients' eyes only. Commented Nov 30, 2011 at 12:09
  • 1
    @Gilles: You have to solve the key distribution problem anyway to transmit the sensitive data. Why not encrypt it all? (I suppose if the entire data set is very large, but the sensitive part is relatively small?)
    – bstpierre
    Commented Nov 30, 2011 at 14:42
  • @Gilles, OK. However, I'd say: it's not the transfer of the encrypted data that's hard, it is the key management. Key management can be hard, for many of the same reasons that policy is hard: you have to decide who ought to be allowed/authorized to view the data, and manage that list. That's a task you'll need to take on whether you're encrypting all the data or only part of the data; encrypting just part of the data doesn't exempt you from the need to tackle the key management problem.
    – D.W.
    Commented Dec 1, 2011 at 4:26
  • hmm true. Just seems that since the key is a small slice of data, it could be added to any chart/ppt or whatever along side the unencrypted data without much hassle. It would be out of the way while people are trying to digest the data in discussions, but then easily accessible if the investigation of a specific patient is escalated. If the key is lost, it only hinders the immediate access to the further data. And with the key, the doctor would still need permissions to access the archive.
    – michael
    Commented Dec 6, 2011 at 20:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .