The challenges I found with FHE in practice (where I have been asked to anticipate its availability as part of system architecture) are that even with demo code available, without some certification body acknowledging proofs of its security, and blessed by a risk nullifying entity like NIST, it wasn't going to get traction.
I like this article's crypto wallet use case, and it may be worth codifying transactions that FHE protects. The {who, what, when, where, why, how} of a transaction has a lot of data, and what this SpiralDB does is protect {what}, although {who, when, where, why, how} are available, so you need to articulate the use case.
The one I worked on was for health information, but that case is essentially nullified now, as the pandemic was leveraged to squeeze the data toothpaste out of the tube in major jurisdictions, and so the data sets FHE was going to be a big solution for have been accessed using a political/process solution without the limitations of a technical one. The main use case for FHE was to faciliate individual privacy, which is essentially a limit on state discretion and powers that facilitated data access through strict legal frameworks, but a lot of data governance was completely compromised and gutted over the pandemic, so I no longer foresee demand for FHE in this new era of aggressively technocratic policy where the reason to use FHE isn't enforced. The tech is inseperable from the policy in this domain, and the rug has been pulled out from under the policy, imo.
It's a pretty niche field. I would recommend reading privacy legislation in your state or country, and/or the syllabus for the CIPP certifications, which are for privacy professionals.
Yeah, there is a a bit of cold-start problem with respect to standards / certification. People kinda have to widely use something before it seems worthwhile to standards bodies to write standards, but often folks are sensibly cautious about using non-standardized cryptography. The solution is to get lots of eyeballs on it, get large organizations to really want to use it, and use that push to get standards rolling.
Personally, I think highly regulated fields like health care etc will adopt this technology extremely slowly. Academic cryptographers really like health care applications but, as you said, in practice, compliance is the main objective of health care organizations.
We are more interested in applications where privacy is actually a value add or a liability minimizer. For example, a VPN using our service could differentiate or charge more to users for offering a completely private DNS option. A crypto wallet could actually advertise (and perhaps even prefer!) that it doesn't spy on you.
Comments
The challenges I found with FHE in practice (where I have been asked to anticipate its availability as part of system architecture) are that even with demo code available, without some certification body acknowledging proofs of its security, and blessed by a risk nullifying entity like NIST, it wasn't going to get traction.
I like this article's crypto wallet use case, and it may be worth codifying transactions that FHE protects. The {who, what, when, where, why, how} of a transaction has a lot of data, and what this SpiralDB does is protect {what}, although {who, when, where, why, how} are available, so you need to articulate the use case.
The one I worked on was for health information, but that case is essentially nullified now, as the pandemic was leveraged to squeeze the data toothpaste out of the tube in major jurisdictions, and so the data sets FHE was going to be a big solution for have been accessed using a political/process solution without the limitations of a technical one. The main use case for FHE was to faciliate individual privacy, which is essentially a limit on state discretion and powers that facilitated data access through strict legal frameworks, but a lot of data governance was completely compromised and gutted over the pandemic, so I no longer foresee demand for FHE in this new era of aggressively technocratic policy where the reason to use FHE isn't enforced. The tech is inseperable from the policy in this domain, and the rug has been pulled out from under the policy, imo.
Can you provide more information for those of us who are interested in the intersection of health and data privacy but don't work in the space?
It's a pretty niche field. I would recommend reading privacy legislation in your state or country, and/or the syllabus for the CIPP certifications, which are for privacy professionals.
Yeah, there is a a bit of cold-start problem with respect to standards / certification. People kinda have to widely use something before it seems worthwhile to standards bodies to write standards, but often folks are sensibly cautious about using non-standardized cryptography. The solution is to get lots of eyeballs on it, get large organizations to really want to use it, and use that push to get standards rolling.
Personally, I think highly regulated fields like health care etc will adopt this technology extremely slowly. Academic cryptographers really like health care applications but, as you said, in practice, compliance is the main objective of health care organizations.
We are more interested in applications where privacy is actually a value add or a liability minimizer. For example, a VPN using our service could differentiate or charge more to users for offering a completely private DNS option. A crypto wallet could actually advertise (and perhaps even prefer!) that it doesn't spy on you.