The blog post "Let's talk about AI and end-to-end encryption" by Matthew Green on cryptographyengineering.com delves into the complex relationship between artificial intelligence and end-to-end encryption (E2EE), exploring the perceived conflict between allowing AI access to user data for training and maintaining the privacy guarantees provided by E2EE. The author begins by acknowledging the increasing calls to allow AI models access to encrypted data, driven by the desire to leverage this data for training more powerful and capable AI systems. This desire stems from the inherent limitations of training AI on solely public data, which often results in less accurate and less useful models compared to those trained on a broader dataset, including private user data.
Green meticulously dissects several proposed solutions to this dilemma, outlining their technical intricacies and inherent limitations. He starts by examining the concept of training AI models directly on encrypted data, a technically challenging feat that, while theoretically possible in limited contexts, remains largely impractical and computationally expensive for the scale required by modern AI development. He elaborates on the nuances of homomorphic encryption and secure multi-party computation, explaining why these techniques, while promising, are not currently viable solutions for practical, large-scale AI training on encrypted datasets.
The post then transitions into discussing proposals involving client-side scanning, often framed as a means to detect illegal content, such as child sexual abuse material (CSAM). Green details how these proposals, while potentially well-intentioned, fundamentally undermine the core principles of end-to-end encryption, effectively creating backdoors that could be exploited by malicious actors or governments. He meticulously outlines the technical mechanisms by which client-side scanning operates, highlighting the potential for false positives, abuse, and the erosion of trust in secure communication systems. He emphasizes that introducing any form of client-side scanning necessitates a shift away from true end-to-end encryption, transforming it into something closer to client-to-server encryption with client-side pre-decryption scanning, thereby compromising the very essence of E2EE's privacy guarantees.
Furthermore, Green underscores the slippery slope argument, cautioning against the potential for expanding the scope of such scanning beyond CSAM to encompass other types of content deemed undesirable by governing bodies. This expansion, he argues, could lead to censorship and surveillance, significantly impacting freedom of expression and privacy. The author concludes by reiterating the importance of preserving end-to-end encryption as a crucial tool for protecting privacy and security in the digital age. He emphasizes that the perceived tension between AI advancement and E2EE necessitates careful consideration and a nuanced approach that prioritizes user privacy and security without stifling innovation. He suggests that focusing on alternative approaches, such as federated learning and differential privacy, may offer more promising avenues for developing robust AI models without compromising the integrity of end-to-end encrypted communication.
The blog post "Homomorphic Encryption in iOS 18" by Bastian Bohm details the introduction of homomorphic encryption capabilities within Apple's iOS 18 operating system, specifically focusing on the newly available APIs for performing calculations on encrypted data without requiring decryption. The author expresses excitement about this development, highlighting the potential for enhanced privacy and security in various applications.
The post begins by explaining the concept of homomorphic encryption, emphasizing its ability to process encrypted information directly, thus preserving the confidentiality of sensitive data. It distinguishes between Fully Homomorphic Encryption (FHE), which supports arbitrary computations, and Partially Homomorphic Encryption (PHE), which is limited to specific operations like addition or multiplication. The post clarifies that iOS 18 implements PHE, specifically focusing on additive homomorphic encryption.
The core of the post revolves around the newly introduced SecKeyEncryptedData class and its associated methods. The author provides a concise code example demonstrating how to create encrypted integers using this class and how to perform homomorphic addition on these encrypted values. The resulting sum remains encrypted, and only the holder of the decryption key can reveal its true value. The author meticulously breaks down the code snippet, explaining the role of each function and parameter. For instance, the post elucidates the process of generating a public key specifically designated for encrypted data operations and how this key is subsequently used to encrypt integer values. It also explains the significance of the perform method in executing homomorphic operations on these encrypted integers.
Furthermore, the post discusses the underlying cryptographic scheme employed by Apple, revealing that it leverages a variant of the Paillier cryptosystem. This choice is deemed suitable for integer additions and is acknowledged for its established security properties. The post also touches upon the practical limitations of PHE, specifically noting the inability to perform other operations like multiplication or comparison directly on the encrypted data without decryption.
Finally, the author speculates on the potential applications of this technology within the Apple ecosystem. The example given is privacy-preserving data collection, suggesting how homomorphic encryption could enable the aggregation of user statistics without compromising individual data privacy. This could be useful for applications like collecting usage metrics or accumulating health data while ensuring that the individual contributions remain confidential. The author concludes with an optimistic outlook on the future implications of homomorphic encryption within the iOS environment and expresses anticipation for further advancements in this field.
The Hacker News post titled "Homomorphic encryption in iOS 18" spawned a modest discussion with a handful of comments focusing on the practicalities and limitations of the technology, rather than the announcement itself. No one expressed outright excitement or skepticism about the announcement, instead offering pragmatic observations.
One commenter pointed out that the homomorphic encryption being utilized is limited to integer addition and multiplication, and thus isn't fully homomorphic encryption (FHE) in the broader, more powerful sense. They clarified that true FHE allows arbitrary computation on encrypted data, which is not what Apple is implementing. This comment served as an important clarification to distinguish the specific type of homomorphic encryption being employed.
Another user expanded on this by mentioning that the specific technique used is called "additive homomorphic encryption" and likely leverages the Paillier cryptosystem. This added technical depth to the discussion, providing a potential underlying mechanism for Apple's implementation. They then speculated about its use case, suggesting it could be applied to scenarios like federated learning or aggregated metrics collection.
A subsequent comment explored the performance limitations of homomorphic encryption. The commenter noted the significant computational overhead associated with these techniques, which makes them unsuitable for many real-time or performance-sensitive applications. This comment highlighted the trade-offs involved in using homomorphic encryption, emphasizing that while it offers enhanced privacy, it comes at the cost of performance.
Finally, one commenter linked to a related project called "Concrete," further adding context to the types of operations and optimizations possible within the homomorphic encryption space. This provides an avenue for those interested in learning more about practical implementations and advancements in the field.
Overall, the comments section offers a concise and informed discussion focusing on the technical nuances of Apple's implementation rather than broad speculation or hype. They provide valuable context and clarification regarding the specific type of homomorphic encryption being used and its inherent limitations.
Summary of Comments ( 98 )
https://news.ycombinator.com/item?id=42734478
Hacker News users discussed the feasibility and implications of client-side scanning for CSAM in end-to-end encrypted systems. Some commenters expressed skepticism about the technical challenges and potential for false positives, highlighting the difficulty of distinguishing between illegal content and legitimate material like educational resources or artwork. Others debated the privacy implications and potential for abuse by governments or malicious actors. The "slippery slope" argument was raised, with concerns that seemingly narrow use cases for client-side scanning could expand to encompass other types of content. The discussion also touched on the limitations of hashing as a detection method and the possibility of adversarial attacks designed to circumvent these systems. Several commenters expressed strong opposition to client-side scanning, arguing that it fundamentally undermines the purpose of end-to-end encryption.
The Hacker News post "Let's talk about AI and end-to-end encryption" has generated a robust discussion with several compelling comments. Many commenters grapple with the inherent tension between the benefits of AI-powered features and the preservation of end-to-end encryption (E2EE).
One recurring theme is the practicality and potential misuse of client-side scanning. Some commenters express skepticism about the feasibility of truly secure client-side scanning, arguing that any client-side processing inherently weakens E2EE and creates vulnerabilities for malicious actors or governments to exploit. They also voice concerns about the potential for function creep, where systems designed for specific purposes (like detecting CSAM) could be expanded to encompass broader surveillance. The chilling effect on free speech and privacy is a significant concern.
Several comments discuss the potential for alternative approaches, such as federated learning, where AI models are trained on decentralized data without compromising individual privacy. This is presented as a potential avenue for leveraging the benefits of AI without sacrificing E2EE. However, the technical challenges and potential limitations of federated learning in this context are also acknowledged.
The "slippery slope" argument is prominent, with commenters expressing worry that any compromise to E2EE, even for seemingly noble purposes, sets a dangerous precedent. They argue that once the principle of E2EE is weakened, it becomes increasingly difficult to resist further encroachments on privacy.
Some commenters take a more pragmatic stance, suggesting that the debate isn't necessarily about absolute E2EE versus no E2EE, but rather about finding a balance that allows for some beneficial AI features while mitigating the risks. They suggest exploring technical solutions that could potentially offer a degree of compromise, though skepticism about the feasibility of such solutions remains prevalent.
The ethical implications of using AI to scan personal communications are also a significant point of discussion. Commenters raise concerns about false positives, the potential for bias in AI algorithms, and the lack of transparency and accountability in automated surveillance systems. The potential for abuse and the erosion of trust are recurring themes.
Finally, several commenters express a strong defense of E2EE as a fundamental right, emphasizing its crucial role in protecting privacy and security in an increasingly digital world. They argue that any attempt to weaken E2EE, regardless of the intended purpose, represents a serious threat to individual liberties.