Conclusionįor now, homomorphic encryption is in the realm of cryptographers. For example, it does not guarantee indistinguishability under a chosen ciphertext attack, which means if an attacker can force a decryption of a ciphertext of their choice, they can recover your private key. One of the issues that was pointed out in the talk is that homomorphic encryption does not currently have some of the security guarantees we are used to having from other encryption schemes. While there are libraries that implement homomorphic encryption and that have made great strides in recent years in terms of performance, they are not turnkey solutions to many problems the way a well-developed cryptography library might be. Homomorphic encryption is not ready for prime time. As part of a more full solution, a homomorphic encryption scheme would remove the Mattermost application server as a single point of failure in your communication system. Then the Mattermost server could perform whatever operations it needs to on the encrypted data. Ignoring the problems with key exchange and channel join/leave (which deserve blog posts of their own), a user could encrypt their messages using a homomorphic scheme before passing them to the Mattermost server. Implementing a homomorphic encryption scheme for Mattermost could theoretically allow for a zero trust Mattermost server without loss of features. However, if the service client used homomorphic encryption, the service would be able to edit, search and even perform machine learning on the image data. If the service client used regular encryption, it would not be able to perform many useful operations you might want it to do like editing and searching. In case the service is compromised, it could not see the contents of the user’s data as the plaintext was never sent to it. The service could then perform whatever operations the user has requested on the data and return the data, still encrypted, to the user. A user of such a service would not have to reveal the contents of the data to the service, as they will encrypt the contents before sending them to the service. One interesting application of this is zero trust computation services. The use of homomorphic encryption allows a receiving party that does not have a decryption key to perform operation on the ciphertext. If we used a homomorphic encryption scheme and a multiplication operation, then the plaintext corresponding ciphertext “z” would be “35” after decryption. We then perform a multiplication operation on ciphertexts “x” and “y” to get ciphertext “z”. For example, let’s say we have plaintext “5” and “7” and we encrypted them to ciphertexts “x” and “y”. Homomorphic encryption is defined as an encryption scheme which allows computations to be performed on ciphertext that, when decrypted, match the result of the operation as if it was applied to the plain text. This post gives a high level overview and avoids giving too much technical detail. There were plenty of interesting talks, but this post focuses on a talk by Zhiniang Peng and Minrui Yang on the dangers of homomorphic encryption. Like any security conference, it was full of exploits and interesting anecdotes. This year I had the opportunity to attend the security conference CanSecWest in Vancouver, BC.
0 Comments
Leave a Reply. |