4 ms·
I probably should have added: the backends used in the post are 3-ish years old and missing some of the latest features. We're working on integrating newer back
by j2kun 4y ago
I probably should have added: the backends used in the post are 3-ish years old and missing some of the latest features. We're working on integrating newer backends and taking advantage of the new techniques! The performance story is better than it seems from my article. Plus this doesn't have any hardware acceleration, another big topic on my agenda :)
- aliqot 4y agoHey no need to justify it here, this is really cool! The first few runs are always slow and ready for optimization. I am very optimistic for what this tech may do for medical records and similar industries.
- fnordpiglet 4y agoYeah I’ve always wondered if FHE would benefit from asic level acceleration, or at least FPGA
- DesiLurker 4y agoIf you are going to do an asic (w/o data going to memory IO) then why not use regular encryption with codec on the SoC itself (like DRM content). that works just fine. IMO the main value here would be trust between unknown parties over untrusted medium.
- fnordpiglet 4y agoThe typical perceived use case is FHE in cloud providers providing highly sensitive compute in a multi tenant platform. In something like that full on hardware acceleration is key
- DesiLurker 4y agojust noticed the response.. Not really, even in those cases you need to understand that bits in memory (ie.. everything past (&including) the SoC's IO pins would never see the data unencrypted. any decryption is handled within working cache on soc with secure context (typically on a secure OS vm). I dont see why a bunch of compute code wont work there. in fact you could go a step further and encrypt compute instructions too. then assuming you know what you are doing and dont crash the compute node will have no idea what ops you are actually doing on what data. btw thats how DRM works (sans the last part).
- fnordpiglet 4y agoGreat article btw