4 ms·

> The main threat to encrypting health information is actually dishonest cryptographers. Wow, okay, you have me hooked. > instead of searching for user Michae

> The main threat to encrypting health information is actually dishonest cryptographers. Wow, okay, you have me hooked. > instead of searching for user Michael Knight in a database of cancer patients, you hash the name, use a bloom filter to determine if the hash exists in the protected data set or not The protocol you loosely described here could be either totally fine or horrendously broken depending on the implementation details and architecture of the application. Not to mention the universal cryptography concerns; i.e., key management. > and then tell your regulators and the public that the foreign jurisdiction research assistants hired from fiverr don't have access to your health information because everything is encrypted and we only compare hashes. You've said "hashes" twice now, so I have to ask: 1. Are they only hashing, or are they using a keyed hash (e.g., HMAC)? 2. Are they doing something ridiculous like using MD5? If you're familiar with cryptography at all, passing around MD5(data) is vastly different from truncating HMAC-SHA384(data, staticKey) to a few bits and protecting staticKey with an HSM. Without more detail, I can't tell if your assertion that cryptographers are being dishonest is warranted. It's sort of like simplifying RSA encryption to "multiplying integers". Yes, that's what's happening on some level, but some essential information was omitted.

motohagiography 2y ago
in your hmac example you have a separate key to manage, whereas in my example, it's implied it's sha256 or a variant that provides a layer of obfuscation in the lookup, and may even implement a "standard" to fool regulators. most regulations and standards say what tools to use (key bits, algos, etc) , and not that the implementations need to be approved by a professional. my example is that the scheme uses tools in a way that is meaningless because I can just take a phone book, hash the names, and check to see if they are in the cancer database as though it were an cleartext database. to say the data subject's data is private in this case because it is hashed (or often, inaccurately, "encrypted") is to mislead people who make decisions about it. I'm saying the designers of such systems represent themselves as cryptography and security experts who build weakened systems like this to mislead regulators on behalf of their bosses and users who just want the cleartext data. most protocols are a shell game where if you don't know where the root of trust secret is managed you're the sucker at the table. my experience has been that working cryptographers (protocol designers) in government, health, and financial institutions in general are a very refined class of bullshitters who pound the table whenever you ask them about details, and that one should not be intimidated by their theatrics. Hence in PHI management, dishonest cryptographers working on behalf of anti-privacy interests are the main threat.
- CiPHPerCoder 2y ago
  Thanks for clarifying, and confirming at least one of my suspicions. All I can say here is, "Yikes." If you (or, well, anyone) ever need an honest third party to audit a cryptography design--whether it's because you suspect bullshit or just want assurance that it's actually a good design--talk to the Crypto team at Trail of Bits. https://www.trailofbits.com/services/software-assurance/cryptography/ https://www.trailofbits.com/services/software-assurance/cryp...
throwaway81523 2y ago
> dishonest cryptographers There is a book about that, "Malicious Cryptography" by Adam Young and Moti Yung. Not about dishonest cryptographers per se, but about various sneaky tricks that could be used in crypto systems. Anyway I'm sure you remember the notorious Dual EC DRBG.

motohagiography 2y ago

in your hmac example you have a separate key to manage, whereas in my example, it's implied it's sha256 or a variant that provides a layer of obfuscation in the lookup, and may even implement a "standard" to fool regulators. most regulations and standards say what tools to use (key bits, algos, etc) , and not that the implementations need to be approved by a professional. my example is that the scheme uses tools in a way that is meaningless because I can just take a phone book, hash the names, and check to see if they are in the cancer database as though it were an cleartext database. to say the data subject's data is private in this case because it is hashed (or often, inaccurately, "encrypted") is to mislead people who make decisions about it. I'm saying the designers of such systems represent themselves as cryptography and security experts who build weakened systems like this to mislead regulators on behalf of their bosses and users who just want the cleartext data. most protocols are a shell game where if you don't know where the root of trust secret is managed you're the sucker at the table. my experience has been that working cryptographers (protocol designers) in government, health, and financial institutions in general are a very refined class of bullshitters who pound the table whenever you ask them about details, and that one should not be intimidated by their theatrics. Hence in PHI management, dishonest cryptographers working on behalf of anti-privacy interests are the main threat.

CiPHPerCoder 2y ago
Thanks for clarifying, and confirming at least one of my suspicions. All I can say here is, "Yikes." If you (or, well, anyone) ever need an honest third party to audit a cryptography design--whether it's because you suspect bullshit or just want assurance that it's actually a good design--talk to the Crypto team at Trail of Bits. https://www.trailofbits.com/services/software-assurance/cryptography/ https://www.trailofbits.com/services/software-assurance/cryp...

throwaway81523 2y ago

> dishonest cryptographers There is a book about that, "Malicious Cryptography" by Adam Young and Moti Yung. Not about dishonest cryptographers per se, but about various sneaky tricks that could be used in crypto systems. Anyway I'm sure you remember the notorious Dual EC DRBG.