Stories with Tag Encryption

• AES and ChaCha

  permalink

  Posted: 2025-04-14 15:28:07

  Verbose tl;dr

  The blog post "AES and ChaCha" compares two popular symmetric encryption algorithms, highlighting ChaCha's simplicity and speed advantages, particularly in software implementations and resource-constrained environments. While AES, the Advanced Encryption Standard, is widely adopted and hardware-accelerated, its complex structure makes it more challenging to implement securely in software. ChaCha, designed with software in mind, offers easier implementation, potentially leading to fewer vulnerabilities. The post concludes that while both algorithms are considered secure, ChaCha's streamlined design and performance benefits make it a compelling alternative to AES, especially in situations where hardware acceleration isn't available or software implementation is paramount.

  The blog post "AES and ChaCha: Simplicity in Cryptography" explores the nuances of two prominent symmetric encryption algorithms: the Advanced Encryption Standard (AES) and ChaCha. It begins by acknowledging the critical role of cryptography in securing digital information, highlighting the importance of choosing appropriate encryption methods. The post then delves into the intricacies of AES, a block cipher renowned for its widespread adoption and robust security. It explains that AES operates on fixed-size blocks of data, employing multiple rounds of substitution and permutation operations to transform plaintext into ciphertext. The post notes AES's reliance on the substitution-permutation network (SPN) structure, emphasizing its strength against various cryptanalytic attacks. It also touches upon the different key sizes supported by AES (128, 192, and 256 bits), acknowledging the trade-off between security and performance.

  The narrative then shifts to ChaCha, a stream cipher gaining popularity, particularly in software implementations. The post contrasts ChaCha's stream cipher approach with AES's block cipher design, explaining how ChaCha generates a keystream that is XORed with the plaintext to produce the ciphertext. It emphasizes the simplicity and efficiency of ChaCha's design, particularly on platforms lacking hardware acceleration for AES. The discussion includes a breakdown of ChaCha's core operations, highlighting its use of additions, rotations, and XORs, which contribute to its speed and ease of implementation. The post also mentions the related Poly1305 message authentication code, often used in conjunction with ChaCha for authenticated encryption, ensuring both confidentiality and integrity.

  The comparison between AES and ChaCha extends to considerations beyond just their core algorithms. The post discusses the role of hardware acceleration in influencing performance, noting that while AES often benefits from specialized hardware support, ChaCha can excel in environments where such acceleration is unavailable. The post also touches upon the resistance of both ciphers to side-channel attacks, which exploit implementation vulnerabilities rather than weaknesses in the algorithms themselves. Finally, the post concludes by summarizing the strengths and weaknesses of each cipher, suggesting that while AES remains a dominant force in many applications, ChaCha offers a compelling alternative, especially where simplicity, speed, and software implementation are paramount. The overall tone suggests that the choice between AES and ChaCha depends heavily on the specific context and requirements of the application.

  • AES
  • ChaCha
  • Cryptography
  • Encryption
  • Security
  • Symmetric-key encryption
  • Stream cipher
  • Block Cipher
  • performance
  • Software
  • Hardware
  • Implementation
  • Simplicity

  Summary of Comments ( 1 )
  https://news.ycombinator.com/item?id=43682369

  Verbose tl;dr

  HN commenters generally praised the article for its clear and concise explanation of ChaCha and AES, particularly appreciating the accessible language and lack of jargon. Some discussed the practical implications of choosing one cipher over the other, highlighting ChaCha's performance advantages on devices lacking AES hardware acceleration and its resistance to timing attacks. Others pointed out that while simplicity is desirable, security and correctness are paramount in cryptography, emphasizing the rigorous scrutiny both ciphers have undergone. A few commenters delved into more technical aspects, such as the internal workings of the algorithms and the role of different cipher modes. One commenter offered a cautionary note, reminding readers that even well-regarded ciphers can be vulnerable if implemented incorrectly.

  The Hacker News post titled "AES and ChaCha" linking to a blog post about the simplicity of ChaCha and AES sparked a moderately active discussion with 17 comments. Several commenters focused on the performance aspects of ChaCha20-Poly1305, particularly its advantages on devices lacking AES hardware acceleration. One commenter highlighted its suitability for mobile devices and routers, where dedicated AES hardware might not be present, leading to improved performance compared to AES software implementations. This thread also explored the implications for power consumption, suggesting ChaCha20 could be more energy-efficient in these scenarios.

  Another commenter appreciated the original blog post's focus on the internal structure of the algorithms, contrasting it with other resources that primarily delve into mathematical proofs. They valued the author's approach of explaining the algorithms through visuals and understandable language.

  There was some discussion about the security of both algorithms. One commenter mentioned the "Sweet32" birthday attack against 3DES, but clarified that it doesn't affect ChaCha20 or AES due to their larger block size. Another commenter discussed the relative merits of block ciphers and stream ciphers, noting ChaCha20's position as a performant stream cipher and AES as a robust block cipher. A related comment touched on the need for authenticated encryption modes like AES-GCM and ChaCha20-Poly1305.

  A couple of comments mentioned the real-world usage of ChaCha20-Poly1305, citing its adoption in protocols like TLS 1.3 and WireGuard. One commenter speculated that its increased use in TLS 1.3 might be influenced by Google's promotion of the cipher, possibly due to its performance benefits on their Android platform.

  Finally, one commenter praised the blog post's clarity, accessibility, and helpful visuals, stating that it provided a good overview of the subject.

• Akira ransomware can be cracked with sixteen RTX 4090 GPUs in around ten hours

  permalink

  Posted: 2025-03-17 11:06:24

  Verbose tl;dr

  Researchers have demonstrated a method for cracking the Akira ransomware's encryption using sixteen RTX 4090 GPUs. By exploiting a vulnerability in Akira's implementation of the ChaCha20 encryption algorithm, they were able to brute-force the 256-bit encryption key in approximately ten hours. This breakthrough signifies a potential weakness in the ransomware and offers a possible recovery route for victims, though the required hardware is expensive and not readily accessible to most. The attack relies on Akira's flawed use of a 16-byte (128-bit) nonce, effectively reducing the key space and making it susceptible to this brute-force approach.

  A recent report by Tom's Hardware details a significant breakthrough in combating the Akira ransomware, a malicious software that encrypts victims' files and demands payment for their release. Researchers at Sophos, a cybersecurity firm, have discovered a vulnerability in Akira's encryption implementation that allows for the recovery of encrypted data without paying the ransom. This vulnerability stems from Akira's usage of a relatively weak encryption key generation process. While Akira nominally uses a 256-bit encryption key, providing a theoretically immense number of possible combinations, the actual key generation method produces keys significantly weaker than a true 256-bit key would suggest.

  This weakness allows for a brute-force attack, a method of systematically trying all possible keys until the correct one is found, to become a feasible decryption strategy. Sophos researchers leveraged the immense computational power of sixteen Nvidia RTX 4090 GPUs, high-end graphics cards renowned for their parallel processing capabilities, to perform this brute-force attack. Utilizing these GPUs, they were able to successfully crack the Akira encryption and recover the encrypted data in approximately ten hours.

  This timeframe represents a substantial reduction in decryption time compared to traditional methods, and it highlights the potential of utilizing powerful hardware for breaking relatively weak encryption. While ten hours might still be considered a significant duration in some scenarios, it is substantially faster than the potentially weeks or even months required by other methods or the alternative of succumbing to the ransom demands. The discovery of this vulnerability and the successful demonstration of its exploitability offers a glimmer of hope for victims of Akira ransomware attacks, providing a potential pathway to data recovery without financially supporting criminal enterprises. This breakthrough also underscores the importance of robust encryption key generation in ransomware development, and serves as a reminder of the ongoing cat-and-mouse game between cybersecurity professionals and malicious actors. The research by Sophos has significantly weakened the Akira ransomware's effectiveness and could potentially lead to future developments in combating similar threats.

  • ransomware
  • akira
  • Cybersecurity
  • GPU
  • RTX 4090
  • Encryption
  • Decryption
  • brute-force
  • cracking
  • Exploit
  • information security
  • Computer Security
  • Hardware Acceleration
  • Nvidia
  • parallel processing

  Summary of Comments ( 11 )
  https://news.ycombinator.com/item?id=43387188

  Verbose tl;dr

  Hacker News commenters discuss the practicality and implications of using RTX 4090 GPUs to crack Akira ransomware. Some express skepticism about the real-world applicability, pointing out that the specific vulnerability exploited in the article is likely already patched and that criminals will adapt. Others highlight the increasing importance of strong, long passwords given the demonstrated power of brute-force attacks with readily available hardware. The cost-benefit analysis of such attacks is debated, with some suggesting the expense of the hardware may be prohibitive for many victims, while others counter that high-value targets could justify the cost. A few commenters also note the ethical considerations of making such cracking tools publicly available. Finally, some discuss the broader implications for password security and the need for stronger encryption methods in the future.

  The Hacker News post titled "Akira ransomware can be cracked with sixteen RTX 4090 GPUs in around ten hours" has generated several comments discussing the implications of using powerful GPUs like the RTX 4090 for cracking encryption.

  Some users express skepticism about the practicality of this approach. One commenter questions the feasibility for average users, pointing out the significant cost of acquiring sixteen RTX 4090 GPUs. They suggest that while technically possible, the financial barrier makes it unlikely for most victims of ransomware. Another user echoes this sentiment, highlighting that the cost would likely exceed the ransom demand in many cases. They also raise the point that this method might only work for a specific vulnerability in Akira and wouldn't be a universal solution for all ransomware.

  Others discuss the broader implications of readily available GPU power. One comment points out the increasing accessibility of powerful hardware and its potential to empower both security researchers and malicious actors. They argue that this development underscores the ongoing "arms race" in cybersecurity, where advancements in technology benefit both sides. Another user suggests that this highlights the importance of robust encryption practices, as the increasing power of GPUs could eventually render weaker encryption methods vulnerable.

  A few comments delve into the technical aspects. One user questions the specific algorithm used by Akira and speculates on its susceptibility to brute-force attacks. Another user mentions the importance of key length and how it affects the time required for cracking, emphasizing that longer keys would significantly increase the difficulty even with powerful GPUs.

  One commenter points out the article's potentially misleading title. They clarify that the GPUs weren't cracking the encryption itself, but rather brute-forcing a password which was then used to decrypt the files. This distinction is important, as it implies a weakness in the implementation rather than the underlying encryption algorithm.

  Finally, a few users offer practical advice. One suggests using strong, unique passwords to protect against this type of attack, emphasizing the importance of basic security hygiene. Another user proposes that the best defense against ransomware remains regular backups, allowing victims to restore their data without paying the ransom.

  Overall, the comments reflect a mix of concerns about the practical implications of using GPUs for cracking ransomware, discussions about the broader cybersecurity landscape, and technical insights into the vulnerabilities highlighted by this specific case.

• Decrypting encrypted files from Akira ransomware using a bunch of GPUs

  permalink

  Posted: 2025-03-14 17:45:33

  Verbose tl;dr

  The blog post details a successful effort to decrypt files encrypted by the Akira ransomware, specifically the Linux/ESXi variant from 2024. The author achieved this by leveraging the power of multiple GPUs to significantly accelerate the brute-force cracking of the encryption key. The post outlines the process, which involved analyzing the ransomware's encryption scheme, identifying a weakness in its key generation (a 15-character password), and then using Hashcat with a custom mask attack on the GPUs to recover the decryption key. This allowed for the successful decryption of the encrypted files, offering a potential solution for victims of this particular Akira variant without paying the ransom.

  The blog post "Decrypting encrypted files from Akira ransomware (Linux/ESXi variant 2024) using a bunch of GPUs" details the author's successful attempt to break the encryption of the Akira ransomware, specifically the variant targeting Linux and ESXi systems that emerged in 2024. This variant employs a combination of AES and RSA encryption, rendering decryption a challenging endeavor. The author meticulously analyzed the ransomware's encryption process, discovering a vulnerability stemming from its implementation of the AES encryption key generation.

  Akira, like many ransomware strains, uses a symmetric encryption algorithm (AES) for encrypting the bulk of the files, ensuring speed. However, this AES key needs to be protected, so it is encrypted using an asymmetric algorithm (RSA) and stored with the encrypted files. The ransomware attackers hold the private RSA key, which is necessary to decrypt the AES key and subsequently the user's files. The author discovered that the Akira variant in question generated the AES encryption keys using predictable methods, deriving them from the current time. This predictable key generation created a limited keyspace, making it feasible to brute-force the AES key using sufficient computing power.

  Recognizing the computationally intensive nature of this brute-force attack, the author leveraged the parallel processing capabilities of GPUs. By implementing a decryption program optimized for GPU execution, they significantly accelerated the key search. The post details the specific GPUs used, emphasizing their hash rate capabilities and the overall speed improvement achieved through GPU acceleration.

  The author describes the iterative process of refining the decryption program and optimizing its performance on the GPUs. This involved testing various configurations and parameters to achieve the highest possible decryption speed. The post further explains the specific steps involved in cracking the encryption, including determining the time window within which the files were encrypted, which narrows down the potential AES keys generated from the timestamp.

  Ultimately, the author successfully decrypted the encrypted files, demonstrating the vulnerability of this particular Akira variant's encryption scheme. The post concludes with a call to action, urging other security researchers to investigate and expose vulnerabilities in ransomware, highlighting the importance of robust key generation practices in safeguarding against such attacks. While the success is tied to this specific variant and its flawed implementation, it serves as a valuable case study in ransomware analysis and the potential of utilizing GPU-accelerated computation for breaking encryption.

  • ransomware
  • akira
  • Decryption
  • GPU
  • Cybersecurity
  • Linux
  • esxi
  • file recovery
  • data recovery
  • Malware
  • information security
  • Encryption
  • parallel processing
  • accelerated computing

  Summary of Comments ( 44 )
  https://news.ycombinator.com/item?id=43365083

  Verbose tl;dr

  Several Hacker News commenters expressed skepticism about the practicality of the decryption method described in the linked article. Some doubted the claimed 30-minute decryption time with eight GPUs, suggesting it would likely take significantly longer, especially given the variance in GPU performance. Others questioned the cost-effectiveness of renting such GPU power, pointing out that it might exceed the ransom demand, particularly for individuals. The overall sentiment leaned towards prevention being a better strategy than relying on this computationally intensive decryption method. A few users also highlighted the importance of regular backups and offline storage as a primary defense against ransomware.

  The Hacker News post titled "Decrypting encrypted files from Akira ransomware using a bunch of GPUs" (linking to tinyhack.com/2025/03/13/...) generated several comments discussing the technical aspects and broader implications of the decryption process.

  Several commenters focused on the brute-force nature of the decryption, highlighting the significant computational resources required, specifically the use of multiple GPUs. They discussed the cost and time involved in such an undertaking, emphasizing that this approach is not a readily available solution for most victims. One commenter pointed out the importance of the relatively short key length (in this specific case) as crucial to the success of the brute-force method. They noted that longer keys would render this approach impractical due to the exponentially increasing computational demands.

  Another commenter questioned the practicality of the solution, suggesting that restoring from backups would be a more efficient approach in most scenarios. This spurred a discussion about the importance of robust backup strategies as a primary defense against ransomware attacks. Others countered that backups are not always foolproof, sometimes being targeted or unavailable, making decryption a viable option in certain situations.

  The conversation also touched upon the ethical implications of publishing decryption tools. One commenter expressed concern that publicly releasing such tools might incentivize ransomware developers to improve their encryption methods, making future attacks more difficult to counter. This sparked a debate about the balance between helping victims and potentially aiding future attackers.

  A few commenters delved into the technical details of the decryption process, discussing the specific algorithms and tools used. They also explored the limitations of the method, emphasizing its dependence on the specific characteristics of the Akira ransomware variant.

  Finally, some commenters expressed appreciation for the author's work, recognizing the effort involved in developing and sharing the decryption tool. They acknowledged the potential benefits for victims, while also acknowledging the complexities and limitations of the approach.

• Apple will soon support encrypted RCS messaging with Android users

  permalink

  Posted: 2025-03-14 12:07:06

  Verbose tl;dr

  Apple is reportedly planning to add support for encrypted Rich Communication Services (RCS) messaging between iPhones and Android devices. This means messages, photos, and videos sent between the two platforms will be end-to-end encrypted, providing significantly more privacy and security than the current SMS/MMS system. While no official timeline has been given, the implementation appears to be dependent on Google updating its Messages app to support encryption for group chats. This move would finally bring a modern, secure messaging experience to cross-platform communication, replacing the outdated SMS standard.

  In a significant development for cross-platform communication, Apple appears poised to finally address a long-standing grievance among Android users: the lack of seamless, secure messaging between iPhones and Android devices. The Verge reports that Apple is actively working to incorporate support for Rich Communication Services (RCS) messaging with end-to-end encryption (E2EE), potentially bridging the gap between the iMessage ecosystem and the Android world. This means that messages exchanged between iPhones and Android devices will be protected by robust encryption, preventing third-party interception and ensuring privacy for users on both platforms.

  Currently, messages sent between iPhones and Android phones rely on the antiquated SMS/MMS standard, which lacks modern features such as read receipts, high-quality image and video sharing, and, most importantly, end-to-end encryption. This has led to a fragmented and often frustrating user experience, particularly for Android users who are often subject to the "green bubble" stigma and experience diminished message quality. The implementation of RCS with E2EE by Apple would effectively modernize cross-platform communication, offering a comparable experience to iMessage conversations, complete with enhanced features and the crucial security of encryption. This would represent a substantial improvement over the existing system, alleviating the technical limitations and social implications associated with the current cross-platform messaging disparity.

  While Apple has not officially announced a timeline for this implementation, the reporting suggests it's a matter of "when," not "if." This move, if realized, could dramatically reshape the landscape of mobile messaging, providing a unified and secure communication platform for users regardless of their operating system. It signifies a potential shift in Apple's strategy, which has previously been perceived as leveraging iMessage's exclusivity as a competitive advantage. By embracing RCS with E2EE, Apple could foster a more interoperable messaging ecosystem, benefiting users across the mobile landscape.

  • Apple
  • Android
  • RCS
  • Messaging
  • Encryption
  • iMessage
  • SMS
  • End-to-End Encryption
  • iOS
  • Google
  • Mobile communication
  • Technology
  • privacy
  • Security

  Summary of Comments ( 15 )
  https://news.ycombinator.com/item?id=43361822

  Verbose tl;dr

  Hacker News commenters generally expressed skepticism about Apple's purported move towards supporting encrypted RCS messaging. Several doubted Apple's sincerity, suggesting it's a PR move to deflect criticism about iMessage lock-in, rather than a genuine commitment to interoperability. Some pointed out that Apple benefits from the "green bubble" effect, which pressures users to stay within the Apple ecosystem. Others questioned the technical details of Apple's implementation, highlighting the complexities of key management and potential vulnerabilities. A few commenters welcomed the move, though with reservations, hoping it's a genuine step toward better cross-platform messaging. Overall, the sentiment leaned towards cautious pessimism, with many anticipating further "Apple-style" limitations and caveats in their RCS implementation.

  The Hacker News post titled "Apple will soon support encrypted RCS messaging with Android users" generated a significant number of comments discussing various aspects of the news. Several commenters expressed skepticism about Apple's motivations, suggesting that they might be driven more by regulatory pressure, particularly in the EU, than a genuine desire to improve interoperability. Some pointed to Apple's business model, arguing that iMessage lock-in is a key factor in maintaining their ecosystem and that true interoperability could threaten that.

  A recurring theme in the discussion revolves around the technical details and potential limitations of Apple's implementation. Commenters debated whether Apple would fully embrace the RCS standard or implement a limited version that maintains some advantages for iMessage users. Concerns were raised about features like read receipts and typing indicators, and whether these would function seamlessly across platforms. The potential for Apple to utilize its own servers for relaying messages, rather than relying on Google's Jibe platform, was also discussed, along with the implications for privacy and security.

  Several comments highlighted the complexities of implementing end-to-end encryption (E2EE) in a cross-platform messaging system. Some users expressed concerns about the potential vulnerabilities and challenges of maintaining security across different operating systems and devices.

  Another thread of discussion focused on the broader implications of this change for the messaging landscape. Some commenters speculated on how this might affect other messaging platforms like WhatsApp and Signal, and whether it could lead to greater interoperability across the industry.

  Some users shared personal anecdotes about the frustrations of the current messaging situation between iOS and Android, expressing hope that this change would improve communication and eliminate the "green bubble" stigma. Others, however, remained pessimistic, believing that Apple would find ways to maintain the advantages of iMessage and prevent true parity with Android messaging.

  Finally, several comments delved into the history of messaging standards and the role of various companies in shaping the current landscape. Some blamed carriers for their resistance to adopting open standards, while others criticized Apple for their perceived reluctance to embrace interoperability.

• NIST selects HQC as fifth algorithm for post-quantum encryption

  permalink

  Posted: 2025-03-11 14:44:44

  Verbose tl;dr

  NIST has chosen HQC (Hamming Quasi-Cyclic) as the fifth and final public-key encryption algorithm to standardize for post-quantum cryptography. HQC, based on code-based cryptography, offers small public key and ciphertext sizes, making it suitable for resource-constrained environments. This selection concludes NIST's multi-year effort to standardize quantum-resistant algorithms, adding HQC alongside the previously announced CRYSTALS-Kyber for general encryption, CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures. These algorithms are designed to withstand attacks from both classical and quantum computers, ensuring long-term security in a future with widespread quantum computing capabilities.

  The National Institute of Standards and Technology (NIST) has announced the selection of a fifth and final public-key encryption algorithm to be standardized as part of its ongoing effort to prepare for the era of quantum computing. This newly chosen algorithm, called HQC (Hamming Quasi-Cyclic), will join four others previously selected in July 2022—CRYSTALS-Kyber, CRYSTALS-Dilithium, FALCON, and SPHINCS+—in providing robust cryptographic defenses against the potential threat posed by future quantum computers capable of breaking current encryption standards.

  HQC, developed by a multinational team of researchers, is a code-based cryptosystem that relies on the hardness of decoding random linear codes. It stands out for its comparatively small public key and ciphertext sizes, which are deemed advantageous for constrained environments with limited resources. This makes it particularly suitable for applications in devices with restricted memory or bandwidth, such as embedded systems or Internet of Things (IoT) devices.

  The selection of HQC rounds out NIST's post-quantum cryptography standardization project, covering both public-key encryption and digital signatures. CRYSTALS-Kyber, also chosen for public-key encryption, offers strong security and performance characteristics. The other three algorithms address digital signatures: CRYSTALS-Dilithium as the primary algorithm, FALCON for applications requiring smaller signatures, and SPHINCS+ as a backup based on different mathematical principles to diversify security in case unexpected vulnerabilities are discovered in the other algorithms.

  NIST emphasizes the importance of transitioning to these post-quantum cryptography algorithms as soon as practicable. While large-scale quantum computers capable of breaking current encryption are not yet a reality, the standardization process is a proactive measure to ensure a smooth and timely migration to quantum-resistant cryptography. NIST is developing draft standards for all five selected algorithms, with public comment periods planned. The final standards are expected to be published in 2027. This lengthy lead time is intended to give organizations ample opportunity to assess their cryptographic needs, select appropriate algorithms, and implement and test the new standards before any potential threat from quantum computers materializes. NIST encourages organizations to begin preparing for the transition now, including inventorying their cryptographic systems and developing migration plans.

  • NIST
  • Post-quantum cryptography
  • PQC
  • Encryption
  • HQC
  • Cryptography
  • Cybersecurity
  • Quantum Computing
  • Algorithm
  • standardization

  Summary of Comments ( 80 )
  https://news.ycombinator.com/item?id=43332944

  Verbose tl;dr

  HN commenters discuss NIST's selection of HQC, expressing surprise and skepticism. Several highlight HQC's vulnerability to side-channel attacks and question its suitability despite its speed advantages. Some suggest SPHINCS+ as a more robust, albeit slower, alternative. Others note the practical implications of the selection, including the need for hybrid approaches and the potential impact on existing systems. The relatively small key and ciphertext sizes of HQC are also mentioned as positive attributes. A few commenters delve into the technical details of HQC and its underlying mathematical principles. Overall, the sentiment leans towards cautious interest in HQC, acknowledging its strengths while emphasizing its vulnerabilities.

  The Hacker News post titled "NIST selects HQC as fifth algorithm for post-quantum encryption" has generated a moderate number of comments discussing various aspects of the announcement. Several compelling threads of conversation emerge.

  One key area of discussion revolves around the surprise selection of HQC, a code-based cryptosystem, given its perceived vulnerabilities to side-channel attacks. Commenters express concern about the practicality and security of deploying HQC in real-world scenarios where side-channel attacks are a significant threat. Some question NIST's decision-making process and wonder if the selection criteria adequately weighed these security concerns. Comparisons are made to other code-based systems, and the potential implications for the broader post-quantum cryptography landscape are debated.

  Another significant topic is the performance characteristics of HQC, particularly its relatively large public key size. Commenters discuss the challenges of managing and transmitting such large keys, especially in resource-constrained environments. The potential impact on network bandwidth and storage requirements is also considered. Some commenters speculate on the feasibility of optimizing HQC implementations to mitigate these performance limitations.

  The standardization process itself is also subject to scrutiny. Commenters discuss the complexities of evaluating and selecting post-quantum cryptographic algorithms, highlighting the inherent trade-offs between security, performance, and implementation complexity. The long-term implications of standardization are considered, with some expressing concerns about the potential for future vulnerabilities and the need for ongoing research and development in this area.

  Finally, some comments delve into the technical details of HQC, explaining its underlying principles and comparing it to other post-quantum cryptographic approaches. These comments provide valuable insights for those seeking a deeper understanding of the algorithm and its place within the broader field of post-quantum cryptography. There's also a discussion of the ongoing nature of security research, with some commenters emphasizing the need for continued vigilance and adaptation in the face of evolving threats.

• NCSC, GCHQ, UK Gov't expunge advice to "use Apple encryption"

  permalink

  Posted: 2025-03-05 19:34:23

  Verbose tl;dr

  The UK's National Cyber Security Centre (NCSC), along with GCHQ, quietly removed official advice recommending the use of Apple's device encryption for protecting sensitive information. While no official explanation was given, the change coincides with the UK government's ongoing push for legislation enabling access to encrypted communications, suggesting a conflict between promoting security best practices and pursuing surveillance capabilities. This removal raises concerns about the government's commitment to strong encryption and the potential chilling effect on individuals and organizations relying on such advice for data protection.

  In a comprehensive and meticulously detailed blog post titled "NCSC, GCHQ, UK Gov't expunge advice to 'use Apple encryption'," cybersecurity expert Alec Muffett meticulously documents the seemingly deliberate removal of previously published guidance from prominent UK government bodies, including the National Cyber Security Centre (NCSC) and the Government Communications Headquarters (GCHQ), recommending the utilization of Apple's robust encryption features. Muffett painstakingly traces the historical trajectory of this advice, referencing specific iterations of official documentation and web pages where the endorsement of Apple encryption was once clearly articulated. He presents compelling evidence, including archived snapshots of these web pages, demonstrating that the language promoting Apple's encryption capabilities has been systematically purged. This expungement, according to Muffett's analysis, appears to have occurred across multiple platforms and publications, suggesting a coordinated effort rather than an accidental omission.

  The post meticulously details the evolution of these official recommendations, showcasing how the phrasing around encryption gradually shifted from explicitly endorsing Apple's encryption solutions to a more generalized and ambiguous stance on encryption best practices. Muffett meticulously compares and contrasts different versions of the guidance, highlighting specific instances where references to Apple have been deleted or replaced. This comprehensive comparison lends credence to the argument that the changes were intentional and purposeful. The author elaborates on the potential ramifications of this alteration in official guidance, speculating on the possible motivations behind the removal of these specific recommendations. He carefully avoids making definitive pronouncements on the reasons for the change, but suggests several plausible explanations, all of which underscore the importance of transparency and public accountability from governmental organizations, particularly in the realm of cybersecurity and digital privacy.

  The blog post serves as a significant contribution to the ongoing public discourse surrounding encryption, government surveillance, and the delicate balance between national security and individual privacy rights. By meticulously documenting this seemingly deliberate act of historical revisionism, Muffett invites critical examination of the evolving relationship between technology companies, government agencies, and the general public. He underscores the vital role of independent researchers and journalists in holding powerful institutions accountable and ensuring that the public has access to accurate and unbiased information regarding crucial issues of digital security and privacy. The meticulous nature of Muffett's research and the comprehensive presentation of his findings contribute significantly to the understanding of this complex and evolving landscape.

  • NCSC
  • GCHQ
  • UK Government
  • Apple
  • Encryption
  • Security
  • privacy
  • surveillance
  • Cybersecurity
  • Technology
  • digital rights
  • End-to-End Encryption
  • Data Protection
  • online privacy
  • information security
  • Government Policy
  • Tech Policy
  • Alec Muffett

  Summary of Comments ( 160 )
  https://news.ycombinator.com/item?id=43271177

  Verbose tl;dr

  HN commenters discuss the UK government's removal of advice recommending Apple's encryption, speculating on the reasons. Some suggest it's due to Apple's upcoming changes to client-side scanning (now abandoned), fearing it weakens end-to-end encryption. Others point to the Online Safety Bill, which could mandate scanning of encrypted messages, making previous recommendations untenable. A few posit the change is related to legal challenges or simply outdated advice, with Apple no longer being the sole provider of strong encryption. The overall sentiment expresses concern and distrust towards the government's motives, with many suspecting a push towards weakening encryption for surveillance purposes. Some also criticize the lack of transparency surrounding the change.

  The Hacker News post titled "NCSC, GCHQ, UK Gov't expunge advice to 'use Apple encryption'" sparked a discussion with several insightful comments. Many commenters focused on the implications of the UK government's seemingly changed stance on end-to-end encryption.

  Several commenters speculated on the reasons behind the removal of the advice to use Apple's encryption. Some suggested it might be related to the UK's ongoing efforts to push through legislation that could potentially weaken end-to-end encryption, like the Online Safety Bill. The idea being that promoting specific encryption methods now could complicate later arguments in favor of breaking or bypassing that encryption. Others posited that the removal was less nefarious, perhaps simply a matter of avoiding the appearance of endorsing a specific commercial product or recognizing the evolving landscape of secure messaging where other platforms offer comparable security.

  A recurring theme was the inherent tension between government surveillance desires and individual privacy rights. Commenters debated the merits and drawbacks of end-to-end encryption, acknowledging its crucial role in protecting sensitive communications while also recognizing the challenges it poses for law enforcement.

  Some commenters highlighted the subtle language changes in the updated guidance, noting that while the specific mention of Apple encryption was removed, the general advice to use end-to-end encrypted services remained. This led to discussions about the nuances of security advice and the difficulty of providing clear, actionable recommendations to the public without inadvertently promoting specific products or overlooking potential vulnerabilities.

  A few technical comments delved into the specifics of different encryption implementations and their relative strengths and weaknesses. One commenter mentioned the potential issues related to metadata, even with end-to-end encrypted messages, and another discussed the importance of verifying the authenticity of encryption software.

  Overall, the comments section reflected a nuanced understanding of the complex issues surrounding encryption, government surveillance, and online privacy. Commenters generally expressed concern over the implications of the UK government's actions while also engaging in productive discussions about the technical and societal aspects of encryption technology.

• Apple takes UK to court over 'backdoor' order

  permalink

  Posted: 2025-03-05 18:07:06

  Verbose tl;dr

  Apple is challenging a UK court order demanding they create a "backdoor" into an encrypted iPhone belonging to a suspected terrorist. They argue that complying would compromise the security of all their devices and set a dangerous precedent globally, potentially forcing them to create similar backdoors for other governments. Apple claims the Investigatory Powers Act, under which the order was issued, doesn't authorize such demands and violates their human rights. They're seeking judicial review of the order, arguing existing tools are sufficient for the investigation.

  In a significant escalation of the ongoing tension between technology companies and governments regarding encryption and national security, Apple Inc. has reportedly initiated legal proceedings against the United Kingdom government. This legal challenge, as reported by The Register, centers around a recently issued order under the Investigatory Powers Act (commonly referred to as the "Snoopers' Charter"), which compels Apple to create and implement a "backdoor" into its iMessage and FaceTime communication platforms. Apple contends that such an order constitutes an overreach of governmental authority and poses a profound threat to the privacy and security of its users globally.

  The crux of Apple's argument revolves around the fundamental principles of end-to-end encryption. This encryption method ensures that only the sender and recipient of a message can decrypt and read its contents, effectively rendering the message unreadable to any intermediary, including Apple itself. By mandating the creation of a backdoor, the UK government is essentially requiring Apple to compromise this foundational security measure. Such a compromise, Apple argues, would not only weaken the security of iMessage and FaceTime for all users but also establish a dangerous precedent that could embolden other governments to make similar demands, potentially leading to a global erosion of digital privacy.

  The legal filing reportedly elucidates the potential ramifications of complying with the UK's order. Creating a backdoor, Apple asserts, would necessitate fundamental alterations to the architecture of its encryption systems. This, in turn, could introduce vulnerabilities that could be exploited by malicious actors, placing users' sensitive data at risk. Furthermore, Apple argues that the very existence of a backdoor, even if intended for legitimate law enforcement purposes, could fall into the wrong hands, becoming a tool for surveillance and censorship by authoritarian regimes.

  This legal challenge marks the latest chapter in a long-standing debate regarding the balance between national security and individual privacy. Apple has consistently maintained its commitment to protecting user data and has resisted previous attempts by governments to compel access to encrypted communications. The outcome of this legal battle will undoubtedly have far-reaching implications for the future of digital privacy and the relationship between technology companies and governments worldwide. The case is expected to be complex and protracted, involving intricate legal arguments concerning human rights, national security, and the technical intricacies of encryption technology. The decision rendered by the court will ultimately shape the legal landscape regarding government access to encrypted communications and will undoubtedly influence policy debates in other jurisdictions grappling with similar issues.

  • Apple
  • UK
  • United Kingdom
  • court
  • legal
  • Lawsuit
  • Backdoor
  • Encryption
  • Security
  • privacy
  • surveillance
  • Government
  • Technology
  • IPT
  • Investigatory Powers Tribunal
  • information security

  Summary of Comments ( 210 )
  https://news.ycombinator.com/item?id=43270079

  Verbose tl;dr

  HN commenters are largely skeptical of Apple's claims, pointing out that Apple already complies with lawful intercept requests in other countries and questioning whether this case is truly about a "backdoor" or simply about the scope and process of existing surveillance capabilities. Some suspect Apple is using this lawsuit as a PR move to bolster its privacy image, especially given the lack of technical details provided. Others suggest Apple is trying to establish legal precedent to push back against increasing government surveillance overreach. A few commenters express concern over the UK's Investigatory Powers Act and its implications for privacy and security. Several highlight the inherent conflict between national security and individual privacy, with no easy answers in sight. There's also discussion about the technical feasibility and potential risks of implementing such a system, including the possibility of it being exploited by malicious actors.

  The Hacker News post "Apple takes UK to court over 'backdoor' order" (https://news.ycombinator.com/item?id=43270079) has a modest number of comments, generating a discussion primarily focused on the technical and legal challenges of implementing and enforcing client-side scanning.

  Several commenters express skepticism about the practicality of client-side scanning, arguing that it's inherently insecure and easily bypassed by determined attackers. One commenter highlights the "cat and mouse game" nature of such security measures, pointing out that criminals will inevitably find ways to circumvent these systems. Another commenter questions the effectiveness of these measures in preventing terrorism, suggesting that terrorists are likely to use alternative, more secure communication methods. The potential for false positives and the erosion of privacy are also raised as significant concerns.

  There's a discussion about the legal and ethical implications of compelling companies to build backdoors into their products. One commenter argues that such orders set a dangerous precedent, potentially opening the door for authoritarian governments to demand access to encrypted communications. The conflict between national security and individual privacy is a recurring theme, with commenters debating the appropriate balance between these competing interests. Some commenters suggest that the focus should be on improving existing investigative techniques rather than compromising the security of all users.

  Technical details of implementing client-side scanning are also discussed, with commenters speculating about the potential methods Apple could employ and their limitations. The possibility of using on-device machine learning models to detect illegal content is mentioned, along with the challenges of maintaining accuracy and preventing manipulation of these models.

  One commenter raises the issue of jurisdiction and the potential for conflicts between different countries' laws, noting the complexities of enforcing such orders in a globalized world.

  While there isn't a single, overwhelmingly compelling comment that dominates the discussion, the collective thread highlights the significant technical, legal, and ethical concerns surrounding client-side scanning and government-mandated backdoors. The commenters generally express skepticism about the efficacy and safety of such measures, emphasizing the potential for abuse and the negative impact on privacy and security.

• Delta Chat – Email Based PGP Encrypted Chat

  permalink

  Posted: 2025-03-05 03:50:21

  Verbose tl;dr

  Delta Chat is a free and open-source messaging app that leverages existing email infrastructure for communication. Instead of relying on centralized servers, messages are sent and received as encrypted emails, ensuring end-to-end encryption through automatic PGP key management. This means users can communicate securely using their existing email addresses and providers, without needing to create new accounts or convince contacts to join a specific platform. Delta Chat offers a familiar chat interface with features like group chats, file sharing, and voice messages, all while maintaining the decentralized and private nature of email communication. Essentially, it transforms email into a modern messaging experience without compromising user control or security.

  Delta Chat presents itself as a novel approach to secure messaging by leveraging the existing, globally ubiquitous infrastructure of email. Instead of relying on centralized servers and proprietary protocols, Delta Chat functions as an email client with an integrated end-to-end encryption layer powered by Autocrypt, an open standard for PGP key management. This allows users to communicate securely with anyone who has an email address, regardless of whether they are also using Delta Chat. If the recipient is also a Delta Chat user, the experience resembles a traditional instant messaging application, offering features like read receipts, typing indicators, and group chats. However, even if the recipient is using a standard email client, the message content remains encrypted, ensuring confidentiality.

  The key advantage of this approach is its decentralized nature. There is no single point of control or failure. Messages are simply emails, transmitted and stored within the existing email infrastructure. This eliminates the need for users to create new accounts or convince their contacts to join a specific platform. Delta Chat merely adds a layer of encryption and a streamlined user interface to pre-existing email accounts. It aims to simplify secure communication by removing the technical hurdles often associated with PGP, such as key exchange and management. Autocrypt handles this transparently in the background, automating the encryption and decryption process.

  Furthermore, Delta Chat promotes interoperability and user autonomy. Users retain full control over their data, as their messages reside within their chosen email provider. The application is open-source and available across various platforms, including desktop, mobile, and web. The project emphasizes simplicity and ease of use, striving to make secure messaging accessible to a wider audience without requiring specialized technical knowledge. By leveraging the familiarity and ubiquity of email, Delta Chat aims to offer a practical and secure alternative to centralized messaging platforms. It combines the benefits of established email infrastructure with the security of end-to-end encryption, presented in a user-friendly interface.

  • Delta Chat
  • Email
  • PGP
  • Encryption
  • Encrypted Chat
  • Secure Messaging
  • Messaging
  • privacy
  • Open Source
  • Decentralized
  • instant messaging
  • Chat App
  • End-to-End Encryption
  • E2EE
  • Autocrypt

  Summary of Comments ( 56 )
  https://news.ycombinator.com/item?id=43262510

  Verbose tl;dr

  Hacker News commenters generally expressed interest in Delta Chat's approach to secure messaging by leveraging existing email infrastructure. Some praised its simplicity and ease of use, particularly for non-technical users, highlighting the lack of needing to manage separate accounts or convince contacts to join a new platform. Several users discussed potential downsides, including metadata leakage inherent in the email protocol and the potential for spam. The reliance on Autocrypt for key exchange was also a point of discussion, with some expressing concerns about its discoverability and broader adoption. A few commenters mentioned alternative projects with similar aims, like Briar and Status. Overall, the sentiment leaned towards cautious optimism, acknowledging Delta Chat's unique advantages while recognizing the challenges of building a secure messaging system on top of email.

  The Hacker News post titled "Delta Chat – Email Based PGP Encrypted Chat" generated several interesting comments, focusing on the practicality, security, and adoption challenges of using email as a platform for encrypted messaging.

  Several commenters appreciated Delta Chat's approach of leveraging existing email infrastructure for encrypted communication. They highlighted the advantage of not requiring users to create new accounts or convince their contacts to join a new platform. The decentralized nature of email was seen as a plus, avoiding reliance on centralized servers controlled by specific entities. One commenter even praised the ability to self-host the email server for enhanced privacy.

  However, the metadata leakage inherent in email communication was a recurring concern. Commenters pointed out that while message content is encrypted, information like sender, recipient, and timestamp remains visible. Some discussed the possibility of using anonymous email services or mixing techniques to mitigate this issue, but acknowledged the added complexity and limitations.

  The usability of PGP encryption was also a topic of discussion. Some commenters expressed concern about the technical hurdles involved in setting up and managing PGP keys, which could hinder widespread adoption. The comment section mentioned Autocrypt as a simpler alternative for key management within Delta Chat, potentially addressing this challenge.

  Another thread of conversation revolved around the practical limitations of using email for real-time chat. Commenters acknowledged the asynchronous nature of email and questioned its suitability for instant messaging. However, proponents argued that Delta Chat's push notification functionality mitigates this issue to some extent, making it viable for less time-sensitive communication.

  The discussion also touched upon the social aspects of using email for chat. Some users pointed out the potential confusion for recipients unfamiliar with Delta Chat, who might receive unexpected encrypted messages in their inbox. Educating contacts about the system and its functionality was seen as a crucial step for successful adoption.

  Finally, several comments compared Delta Chat to other secure messaging apps like Signal and WhatsApp. While acknowledging the strengths of these established platforms, proponents of Delta Chat emphasized its unique advantages in terms of decentralization, leveraging existing infrastructure, and avoiding reliance on specific companies.

  Overall, the comments on Hacker News reflect a mix of enthusiasm and skepticism towards Delta Chat. While many appreciate its innovative approach and potential benefits, concerns remain regarding metadata leakage, usability, and the practical challenges of adapting email for chat. The discussion highlights the ongoing search for a secure and user-friendly messaging solution that balances privacy with practicality.

• Learn How to Break AES

  permalink

  Posted: 2025-03-04 17:25:51

  Verbose tl;dr

  The post "Learn How to Break AES" details a hands-on educational tool for exploring vulnerabilities in simplified versions of the AES block cipher. It provides a series of interactive challenges where users can experiment with various attack techniques, like differential and linear cryptanalysis, against weakened AES implementations. By manipulating parameters like the number of rounds and key size, users can observe how these changes affect the cipher's security and practice applying cryptanalytic methods to recover the encryption key. The tool aims to demystify advanced cryptanalysis concepts by providing a visual and interactive learning experience, allowing users to understand the underlying principles of these attacks and the importance of a full-strength AES implementation.

  The blog post, "Learn How to Break AES," by David Wong, presents a comprehensive, interactive tutorial demonstrating various cryptanalytic attacks against simplified versions of the Advanced Encryption Standard (AES). The tutorial is aimed at beginners and intermediate learners interested in practical cryptography, offering a hands-on approach to understanding the vulnerabilities of weakened cipher implementations.

  Wong begins by introducing the core concepts of AES, including its structure as a block cipher, the use of substitution-permutation networks (SPNs), and the different operations within each round: SubBytes (substitution using an S-box), ShiftRows (permutation of bytes within the state), MixColumns (mixing of columns within the state), and AddRoundKey (XORing the state with the round key).

  However, instead of tackling the full AES algorithm immediately, the tutorial uses progressively more complex, reduced-round variants of AES. This pedagogical approach allows learners to grasp the fundamentals of cryptanalysis before confronting the complexity of the full cipher. Each simplified version retains essential AES characteristics, making the learned techniques relevant to understanding the security of the full AES.

  The initial exercises focus on differential cryptanalysis, a powerful technique that exploits the propagation of differences between pairs of plaintexts and their corresponding ciphertexts. Through interactive challenges, users are guided to discover differential characteristics – specific input differences that lead to predictable output differences with a high probability. These characteristics are then leveraged to recover the secret key. The tutorial begins with a 1-round AES variant and progressively increases the number of rounds, illustrating how the complexity of differential cryptanalysis increases with the number of rounds.

  Following differential cryptanalysis, the tutorial delves into linear cryptanalysis. This attack exploits linear approximations of the cipher's operations to deduce information about the key. Similar to the differential cryptanalysis section, interactive exercises guide users through building linear approximations, evaluating their biases, and using these biases to retrieve key bits. Again, simplified AES versions are used to incrementally introduce the concepts and challenges associated with linear cryptanalysis.

  Throughout the tutorial, Wong emphasizes the importance of understanding the mathematical principles underlying each attack. Visualizations and interactive elements help users grasp the complex interactions between the different AES operations and how they contribute to the cipher's security. By breaking down the attacks into manageable steps and providing clear explanations, the tutorial enables learners to develop a practical understanding of cryptanalytic techniques and the strengths and weaknesses of simplified AES versions. While not directly addressing the full AES cipher, the tutorial builds a strong foundation for understanding the principles that contribute to the security of the full algorithm and the challenges involved in attempting to break it.

  • AES
  • Cryptography
  • Cryptanalysis
  • Block Cipher
  • Security
  • Breaking AES
  • Advanced Encryption Standard
  • Cipher
  • Decryption
  • Encryption
  • Computer Security
  • Cybersecurity

  Summary of Comments ( 24 )
  https://news.ycombinator.com/item?id=43257583

  Verbose tl;dr

  HN commenters discuss the practicality and limitations of the "block breaker" attack described in the article. Some express skepticism, pointing out that the attack requires specific circumstances and doesn't represent a practical break of AES. Others highlight the importance of proper key derivation and randomness, reinforcing that the attack exploits weaknesses in implementation rather than the AES algorithm itself. Several comments delve into the technical details, discussing the difference between a chosen-plaintext attack and a known-plaintext attack, as well as the specific conditions under which the attack could be successful. The overall consensus seems to be that while interesting, the "block breaker" is not a significant threat to AES security when implemented correctly. Some appreciate the visualization and explanation provided by the article, finding it helpful for understanding block cipher vulnerabilities in general.

  The Hacker News post "Learn How to Break AES" (linking to an article about breaking weak AES implementations) generated several comments discussing various aspects of AES security and the article's content.

  Several commenters focused on clarifying the nuances of the article's title, emphasizing that the article wasn't about breaking AES itself, but rather exploiting weaknesses in implementations of AES. They pointed out that AES as a cryptographic standard remains strong, and the attacks described targeted specific vulnerabilities in how the algorithm was used, like poor key generation, weak modes of operation, or side-channel attacks. One commenter specifically called out the importance of distinguishing between theoretical and practical attacks, noting that the article's focus was on practically exploitable weaknesses.

  There's discussion about the different types of vulnerabilities exploited, including the use of ECB mode and its inherent insecurity due to leaking information about block patterns. Commenters highlighted how ECB mode should be avoided and recommended safer alternatives like CBC or CTR mode. Related to this, a commenter pointed out the susceptibility of some encryption implementations to padding oracle attacks, where the attacker can deduce information about the plaintext by observing how the system handles padding in encrypted blocks.

  Some comments delve into specific techniques mentioned in the article, such as using known plaintext to break the encryption. One commenter details the process of cribbing, where an attacker with access to both ciphertext and plaintext can potentially recover the key or decrypt other messages.

  Another line of discussion explored the real-world implications of these attacks, with examples like exploiting vulnerabilities in embedded systems or insecure web applications. A commenter highlighted the importance of proper key management and secure random number generation to prevent these types of exploits.

  Finally, a few comments offered additional resources for learning more about cryptography and AES security, including links to books, articles, and tools for analyzing cryptographic implementations.

• Apple pulls data protection tool after UK government security row

  permalink

  Posted: 2025-02-21 15:05:24

  Verbose tl;dr

  Apple has removed its iCloud Advanced Data Protection feature, which offers end-to-end encryption for almost all iCloud data, from its beta software in the UK. This follows reported concerns from the UK's National Cyber Security Centre (NCSC) that the enhanced security measures would hinder law enforcement's ability to access data for investigations. Apple maintains that the feature will be available to UK users eventually, but hasn't provided a clear timeline for its reintroduction. While the feature remains available in other countries, this move raises questions about the balance between privacy and government access to data.

  In a recent development concerning data security and governmental oversight, Apple Inc. has withdrawn its iCloud Advanced Data Protection feature from availability in the United Kingdom. This feature, which provides end-to-end encryption for a wider range of iCloud data including backups, photos, and notes, was slated for release in the UK but has been unexpectedly halted. Apple cites concerns stemming from a disagreement with the UK government over the implications of this enhanced encryption for law enforcement access as the reason for the withdrawal.

  The UK government, particularly the Home Office, has been a vocal proponent of the Online Safety Bill, a piece of legislation aimed at combating online child sexual abuse material (CSAM). This bill includes provisions that would require technology companies, including Apple, to provide access to encrypted data when legally mandated. Apple contends that the implementation of Advanced Data Protection in the UK would render them unable to comply with such requests, effectively creating a conflict between user privacy and law enforcement requirements.

  While Apple maintains its commitment to user privacy and the importance of strong encryption for protecting sensitive data, the UK government expresses concern that end-to-end encryption hinders their ability to investigate and prosecute serious crimes, including those involving CSAM. This disagreement highlights the ongoing tension between technology companies prioritizing user privacy and governments seeking access to data for law enforcement purposes.

  The withdrawal of Advanced Data Protection in the UK represents a significant setback for users seeking enhanced privacy protections for their iCloud data. The future availability of the feature in the UK remains uncertain, pending further discussions and potential revisions to the Online Safety Bill or Apple's approach to encryption. This situation underscores the complex interplay between technological advancements, individual privacy rights, and national security interests in the digital age, raising important questions about the balance between these competing priorities. The decision also leaves UK users with a less robust level of data protection compared to their counterparts in other regions where Advanced Data Protection is available, furthering the debate on the global standardization and implementation of privacy-enhancing technologies.

  • Apple
  • Data Protection
  • privacy
  • Security
  • UK Government
  • Software
  • Technology
  • Cybersecurity
  • Encryption
  • surveillance
  • online safety
  • digital rights
  • Censorship
  • Child Safety
  • law enforcement

  Summary of Comments ( 376 )
  https://news.ycombinator.com/item?id=43128253

  Verbose tl;dr

  HN commenters largely agree that Apple's decision to pull its child safety features, specifically the client-side scanning of photos, is a positive outcome. Some believe Apple was pressured by the UK government's proposed changes to the Investigatory Powers Act, which would compel companies to disable security features if deemed a national security risk. Others suggest Apple abandoned the plan due to widespread criticism and technical challenges. A few express disappointment, feeling the feature had potential if implemented carefully, and worry about the implications for future child safety initiatives. The prevalence of false positives and the potential for governments to abuse the system were cited as major concerns. Some skepticism towards the UK government's motivations is also evident.

  The Hacker News post titled "Apple pulls data protection tool after UK government security row" (https://news.ycombinator.com/item?id=43128253) has generated a moderate amount of discussion, with a number of commenters weighing in on the implications of Apple's decision.

  Several commenters express skepticism towards the UK government's claims that the data protection tool could hinder law enforcement efforts. They argue that this is a common tactic used by governments to push for backdoors in encryption, under the guise of national security. Some suggest that the government's true motive is to gain access to encrypted data for surveillance purposes, and that the "child safety" argument is a convenient pretext.

  Others point out the technical limitations and potential risks of client-side scanning, echoing Apple's own concerns about the potential for misuse and the erosion of user privacy. They argue that any system designed to detect illegal content on users' devices could be exploited by malicious actors or even authoritarian governments.

  A recurring theme in the comments is the tension between privacy and security. While acknowledging the importance of law enforcement, many commenters express a strong preference for robust end-to-end encryption, even if it means that some criminals might evade detection. They believe that the potential downsides of weakening encryption outweigh the benefits.

  Some commenters question the timing of this controversy, suggesting it might be related to the ongoing debate about online safety legislation and the broader push for greater government access to encrypted communications. They speculate about the political pressures that might have influenced Apple's decision to withdraw the tool.

  A few users also discuss the technical details of the now-withdrawn data protection tool, comparing it to other approaches and highlighting the challenges of implementing such a system without compromising user privacy.

  While there's no single "most compelling" comment, the overall sentiment appears to be one of caution and skepticism towards the UK government's claims. Many commenters support Apple's decision to prioritize user privacy, even if it means facing criticism from law enforcement agencies. The discussion reflects a broader concern about the increasing pressure on tech companies to compromise encryption in the name of national security and child safety.

• U.K. demand for a back door to Apple data threatens Americans, lawmakers say

  permalink

  Posted: 2025-02-13 14:53:46

  Verbose tl;dr

  Bipartisan U.S. lawmakers are expressing concern over a proposed U.K. surveillance law that would compel tech companies like Apple to compromise the security of their encrypted messaging systems. They argue that creating a "back door" for U.K. law enforcement would weaken security globally, putting Americans' data at risk and setting a dangerous precedent for other countries to demand similar access. This, they claim, would ultimately undermine encryption, a crucial tool for protecting sensitive information from criminals and hostile governments, and empower authoritarian regimes.

  A burgeoning controversy is brewing across the Atlantic, with significant implications for the digital privacy of individuals not only in the United Kingdom but also, as several United States lawmakers contend, in America. The heart of the matter lies in proposed legislation in the U.K., referred to as the Investigatory Powers Act or "Snooper's Charter" by its detractors, which would compel technology companies like Apple to provide British authorities with access to encrypted data. This access would effectively circumvent the robust security measures currently in place, creating what is commonly termed a "back door."

  American legislators are expressing grave concerns that this proposed mandate sets a dangerous precedent, jeopardizing the privacy and security of American citizens. Their argument rests on the potential for the U.K.'s actions to embolden other nations to enact similar legislation, thus creating a domino effect where governments around the globe demand access to encrypted communications. This, they argue, would erode the foundational principles of digital security and privacy that many technology companies, including Apple, have championed.

  The crux of the American lawmakers' apprehension centers on the belief that any weakening of encryption standards in one jurisdiction inherently weakens them globally. If Apple is forced to create a mechanism to bypass its own security measures for the U.K. government, the fear is that this same mechanism could be exploited by malicious actors, including hostile governments or cybercriminals, to access sensitive information belonging to Americans. Furthermore, these lawmakers argue that such a precedent could undermine American technology companies' competitive advantage in the global market, as international customers may lose trust in the security of their products and services if they are perceived as susceptible to government surveillance.

  The situation is further complicated by the delicate balance between national security interests and individual privacy rights. While the U.K. government justifies its proposed legislation as necessary for combating terrorism and serious crime, American lawmakers counter that this approach sacrifices crucial privacy protections for a potentially negligible gain in security. They posit that weakening encryption will not deter determined criminals or terrorists, who will simply migrate to alternative, more secure communication platforms. Instead, it will leave ordinary citizens, businesses, and critical infrastructure vulnerable to a wider range of cyber threats. This transatlantic disagreement underscores the complex and multifaceted challenges posed by the rapidly evolving digital landscape and the ongoing debate regarding the appropriate balance between security and privacy in the 21st century.

  • Apple
  • privacy
  • Security
  • Encryption
  • UK
  • United Kingdom
  • law enforcement
  • surveillance
  • Data Access
  • Cybersecurity
  • Technology
  • Government
  • Legislation
  • Data Protection
  • National Security
  • Backdoor
  • American Civil Liberties
  • US Politics

  Summary of Comments ( 36 )
  https://news.ycombinator.com/item?id=43036434

  Verbose tl;dr

  HN commenters are skeptical of the "threat to Americans" angle, pointing out that the UK and US already share significant intelligence data, and that a UK backdoor would likely be accessible to the US as well. Some suggest the real issue is Apple resisting government access to data, and that the article frames this as a UK vs. US issue to garner more attention. Others question the technical feasibility and security implications of such a backdoor, arguing it would create a significant vulnerability exploitable by malicious actors. Several highlight the hypocrisy of US lawmakers complaining about a UK backdoor while simultaneously pushing for similar capabilities themselves. Finally, some commenters express broader concerns about the erosion of privacy and the increasing surveillance powers of governments.

  The Hacker News comments section for the linked article contains a robust discussion with various viewpoints on the UK's proposed legislation demanding a back door to Apple data. Many commenters express concern about the implications for security and privacy, not just for UK citizens but also for Americans and others globally.

  A recurring theme is the "slippery slope" argument. Several users posit that if the UK successfully compels Apple to create a backdoor, other countries will inevitably follow suit, creating a fragmented and weakened security landscape. This would effectively nullify end-to-end encryption, rendering everyone vulnerable to surveillance and malicious actors. One commenter highlighted the potential for authoritarian regimes to exploit such backdoors, suppressing dissent and violating human rights.

  Some commenters discuss the technical feasibility and implications of implementing such a backdoor. They argue that a truly secure backdoor is impossible to create, as any mechanism designed for law enforcement access could also be exploited by hackers. The discussion delves into the potential for "client-side scanning" and its inherent flaws, including the possibility of false positives and the erosion of trust in technology.

  Several comments also question the motivations behind the UK's proposal, speculating about the government's desire for greater surveillance capabilities. Some express skepticism about the claimed need for backdoors to combat terrorism and child exploitation, arguing that existing investigative methods are sufficient. They also highlight the potential for abuse of power and the chilling effect on free speech.

  A few commenters offer alternative solutions, such as focusing on improving international cooperation and information sharing among law enforcement agencies. They suggest that these methods would be more effective in combating crime while preserving privacy and security.

  There's also a thread discussing the legal and jurisdictional challenges associated with compelling a US company to comply with UK law. Some commenters predict a protracted legal battle between Apple and the UK government, with uncertain outcomes.

  Finally, a smaller number of comments express support for the UK's proposal, arguing that law enforcement needs access to encrypted data to effectively investigate serious crimes. These comments often focus on the need to balance privacy with security, though they are generally met with counterarguments about the technical impracticality and potential dangers of backdoors. The discussion overall demonstrates a significant level of concern about the potential ramifications of the UK's proposed legislation.

• U.K. orders Apple to let it spy on users’ encrypted accounts

  permalink

  Posted: 2025-02-07 07:45:05

  Verbose tl;dr

  The UK government is pushing for a new law, the Investigatory Powers Act, that would compel tech companies like Apple to remove security features, including end-to-end encryption, if deemed necessary for national security investigations. This would effectively create a backdoor, allowing government access to user data without their knowledge or consent. Apple argues that this undermines user privacy and security, making everyone more vulnerable to hackers and authoritarian regimes. The law faces strong opposition from privacy advocates and tech experts who warn of its potential for abuse and chilling effects on free speech.

  In a move that has sparked significant controversy and has the potential to reshape the landscape of digital privacy and security, the United Kingdom government has issued a directive mandating that Apple Inc., the prominent technology giant, incorporate a mechanism within its software that would effectively grant government agencies access to the encrypted communications of its users. This mandate, stemming from the newly enacted Investigatory Powers Act, colloquially referred to as the "Snoopers' Charter," compels technology companies operating within the U.K. to provide law enforcement and intelligence agencies with a "backdoor" into encrypted services, thereby circumventing the robust security measures designed to protect user data from unauthorized access.

  The government argues that this measure is essential for national security and the effective investigation of criminal activity, asserting that encrypted communication platforms are increasingly utilized by terrorists and criminals to evade detection. They claim that this capability would enable law enforcement to intercept and decipher encrypted messages, facilitating the prevention of terrorist attacks and the apprehension of criminals.

  Apple, however, staunchly opposes the government's demands, arguing that creating such a backdoor poses a grave threat to the privacy and security of all its users, not just those suspected of wrongdoing. The company contends that any backdoor, once created, could potentially be exploited by malicious actors, including foreign governments and cybercriminals, thereby jeopardizing the sensitive data of millions of individuals. They further maintain that such a measure would undermine the fundamental principles of encryption, which serves as a crucial safeguard against unauthorized surveillance and data breaches.

  This directive presents a complex dilemma, pitting the government's national security interests against the individual right to privacy. Critics of the mandate argue that it represents an overreach of government power, infringing upon fundamental civil liberties and setting a dangerous precedent for government surveillance. They express concern that this measure could erode public trust in technology companies and stifle innovation in the field of encryption. Furthermore, they argue that the effectiveness of such a backdoor in combating terrorism and crime is questionable, as sophisticated criminals and terrorists could potentially find alternative means of encrypted communication. The debate over this controversial measure is likely to continue as Apple and other technology companies grapple with the implications of complying with government demands that they believe compromise the security and privacy of their users. The outcome of this confrontation could have far-reaching consequences for the future of digital privacy and security worldwide.

  • Apple
  • Encryption
  • privacy
  • Security
  • surveillance
  • United Kingdom
  • UK Government
  • Technology
  • Cybersecurity
  • law enforcement
  • Data Protection
  • online safety
  • digital rights
  • End-to-End Encryption
  • Backdoor

  Summary of Comments ( 958 )
  https://news.ycombinator.com/item?id=42970412

  Verbose tl;dr

  HN commenters express skepticism about the UK government's claims regarding the necessity of this order for national security, with several pointing out the hypocrisy of demanding backdoors while simultaneously promoting end-to-end encryption for their own communications. Some suggest this move is a dangerous precedent that could embolden other authoritarian regimes. Technical feasibility is also questioned, with some arguing that creating such a backdoor is impossible without compromising security for everyone. Others discuss the potential legal challenges Apple might pursue and the broader implications for user privacy globally. A few commenters raise concerns about the chilling effect this could have on whistleblowers and journalists.

  The Hacker News discussion on the article "U.K. orders Apple to let it spy on users’ encrypted accounts" contains a variety of viewpoints on the implications of the proposed UK legislation. Many commenters express serious concerns about the potential for government overreach and the erosion of privacy.

  One recurring theme is the technical impossibility of creating a "backdoor" exclusively for law enforcement. Commenters argue that any such vulnerability, once created, could be exploited by malicious actors. This point is often illustrated with analogies like a master key that, if discovered, could unlock any door. The consensus among technically inclined commenters seems to be that a truly secure "backdoor" is a paradoxical concept.

  Several commenters draw parallels to historical attempts at government surveillance and the repeated failures of such initiatives to remain contained. They express skepticism about the government's ability to responsibly use these powers and predict a slippery slope towards increased surveillance and censorship. The potential for abuse of power, particularly against political dissidents or vulnerable populations, is a major concern.

  Some commenters question the efficacy of such measures in combating crime, arguing that determined criminals will find alternative methods of communication. They suggest that the focus should be on other investigative techniques rather than compromising the security of everyone's data.

  Another thread of discussion revolves around the economic implications of the proposed legislation. Commenters suggest that weakening encryption could damage the tech industry and undermine trust in online services. They argue that this could have a chilling effect on innovation and international competitiveness.

  A few commenters express a degree of understanding for the government's desire to access encrypted data for law enforcement purposes. However, even these commenters acknowledge the significant privacy concerns and the need for strong safeguards against abuse.

  The overall sentiment in the comments section is overwhelmingly negative towards the UK's proposed legislation. Commenters express deep concerns about the potential for abuse, the technical impracticality of secure backdoors, and the negative impact on privacy, security, and the tech industry as a whole. There is a strong sense of skepticism regarding the government's motivations and a general lack of trust in their ability to wield such power responsibly.

• Windows BitLocker – Screwed Without a Screwdriver

  permalink

  Posted: 2025-01-18 12:31:20

  Verbose tl;dr

  The blog post details how the author lost access to a BitLocker-encrypted drive due to a Secure Boot policy change, even with the correct password. The TPM chip, responsible for storing the BitLocker recovery key, perceived the modified Secure Boot state as a potential security breach and refused to release the key. This highlighted a vulnerability in relying solely on the TPM for BitLocker recovery, especially when dual-booting or making system configuration changes. The author emphasizes the importance of backing up recovery keys outside the TPM, as recovery through Microsoft's account proved difficult and unhelpful in this specific scenario. Ultimately, the data remained inaccessible despite possessing the password and knowing the modifications made to the system.

  The blog post "Windows BitLocker – Screwed Without a Screwdriver" details a frustrating and potentially data-loss-inducing scenario involving Windows BitLocker encryption and a Secure Boot configuration change. The author recounts how they inadvertently triggered a BitLocker recovery key prompt after updating their computer's firmware. This seemingly innocuous update modified the Secure Boot configuration, specifically by enabling the Platform Key (PK) protection. BitLocker, designed with robust security in mind, interpreted this change as a potential security compromise, suspecting that an unauthorized actor might have tampered with the boot process. As a safeguard against potential malicious activity, BitLocker locked the drive and demanded the recovery key.

  The author emphasizes the surprising nature of this event. There were no explicit warnings about the potential impact of a firmware update on BitLocker. The firmware update process itself didn't highlight the Secure Boot modification in a way that would alert the user to the potential consequences. This lack of clear communication created a situation where a routine update turned into a scramble for the BitLocker recovery key.

  The post underscores the importance of securely storing the BitLocker recovery key. Without access to this key, the encrypted data on the drive becomes inaccessible, effectively resulting in data loss. The author highlights the potential severity of this situation, especially for users who may not have readily available access to their recovery key.

  Furthermore, the post subtly criticizes the design of BitLocker and its interaction with Secure Boot. The author argues that triggering a recovery key prompt for a legitimate firmware update, especially one initiated by the user themselves, is an overreaction. A more nuanced approach, perhaps involving a warning or a less drastic security measure, would have been preferable. The author suggests that the current implementation creates unnecessary anxiety and potential data loss risks for users who perform routine system updates.

  Finally, the post serves as a cautionary tale for other Windows users who utilize BitLocker. It stresses the necessity of understanding the implications of Secure Boot changes and the critical role of the BitLocker recovery key. It encourages proactive measures to ensure the recovery key is safely stored and accessible, mitigating the risk of data loss in similar scenarios. The author implies that better communication and more user-friendly design choices regarding BitLocker and Secure Boot interactions would significantly improve the user experience and reduce the risk of unintended data loss.

  • BitLocker
  • Windows
  • Encryption
  • data recovery
  • TPM
  • Trusted Platform Module
  • Secure Boot
  • UEFI
  • BIOS
  • data loss
  • Troubleshooting
  • Recovery Key
  • Password Recovery
  • Data Security
  • Operating System

  Summary of Comments ( 57 )
  https://news.ycombinator.com/item?id=42747877

  Verbose tl;dr

  HN commenters generally concur with the article's premise that relying solely on BitLocker without additional security measures like a TPM or Secure Boot can be risky. Several point out how easy it is to modify boot order or boot from external media to bypass BitLocker, effectively rendering it useless against a physically present attacker. Some commenters discuss alternative full-disk encryption solutions like Veracrypt, emphasizing its open-source nature and stronger security features. The discussion also touches upon the importance of pre-boot authentication, the limitations of relying solely on software-based security, and the practical considerations for different threat models. A few commenters share personal anecdotes of BitLocker failures or vulnerabilities they've encountered, further reinforcing the author's points. Overall, the prevailing sentiment suggests a healthy skepticism towards BitLocker's security when used without supporting hardware protections.

  The Hacker News post "Windows BitLocker – Screwed Without a Screwdriver" generated a moderate amount of discussion, with several commenters sharing their perspectives and experiences related to BitLocker and disk encryption.

  Several commenters discuss alternative full-disk encryption solutions they consider more robust or user-friendly than BitLocker. Veracrypt is mentioned multiple times as a preferred open-source alternative. One commenter specifically highlights its support for multiple bootloaders and ease of recovery. Others bring up LUKS on Linux as another open-source full-disk encryption option they favor.

  The reliance on closed-source solutions for critical security measures like disk encryption is a concern raised by some. They emphasize the importance of transparency and the ability to inspect the code, particularly when dealing with potential vulnerabilities or backdoors. In contrast, one user expressed confidence in Microsoft's security practices, suggesting that the closed-source nature doesn't necessarily imply lower security.

  A few commenters shared personal anecdotes of BitLocker issues, including problems recovering data after hardware failures. These stories highlighted the real-world implications of relying on a system that can become inaccessible due to unforeseen circumstances.

  There's a discussion about the potential dangers of relying solely on TPM for key protection. The susceptibility of TPMs to vulnerabilities or physical attacks is raised as a concern. One user suggests storing the recovery key offline, independent of the TPM, to mitigate this risk. Another points out the importance of physically securing the machine itself, as a stolen laptop with BitLocker enabled but dependent on TPM could be potentially vulnerable to attack.

  Some users questioned the specific scenario described in the original blog post, with one suggesting that the inability to boot may have been due to a Secure Boot issue unrelated to BitLocker. They also highlighted the importance of carefully documenting the recovery key to prevent data loss.

  Finally, one commenter mentions encountering similar issues with FileVault on macOS, illustrating that the challenges and complexities of disk encryption are not unique to Windows. They note that while these solutions are designed to protect data, they can sometimes hinder access, especially in non-standard scenarios like hardware failures or OS upgrades.

• Homomorphic encryption in iOS 18

  permalink

  Posted: 2025-01-11 16:35:00

  Verbose tl;dr

  iOS 18 introduces homomorphic encryption for some Siri features, allowing on-device processing of encrypted audio requests without decrypting them first. This enhances privacy by preventing Apple from accessing the raw audio data. Specifically, it uses a fully homomorphic encryption scheme to transform audio into a numerical representation amenable to encrypted computations. These computations generate an encrypted Siri response, which is then sent to Apple servers for decryption and delivery back to the user. While promising improved privacy, the post raises concerns about potential performance impacts and the specific details of the implementation, which Apple hasn't fully disclosed.

  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.

  • Homomorphic Encryption
  • iOS 18
  • iOS Security
  • Cryptography
  • privacy
  • Mobile Security
  • Data Security
  • Encryption
  • Apple
  • iOS Development
  • Data Privacy
  • App Security
  • Fully Homomorphic Encryption
  • FHE
  • Partially Homomorphic Encryption
  • PHE
  • Client-Side Encryption

  Summary of Comments ( 121 )
  https://news.ycombinator.com/item?id=42666959

  Verbose tl;dr

  Hacker News users discussed the practical implications and limitations of homomorphic encryption in iOS 18. Several commenters expressed skepticism about Apple's actual implementation and its effectiveness, questioning whether it's fully homomorphic encryption or a more limited form. Performance overhead and restricted use cases were also highlighted as potential drawbacks. Some pointed out that the touted benefits, like encrypted search and image classification, might be achievable with existing techniques, raising doubts about the necessity of homomorphic encryption for these tasks. A few users noted the potential security benefits, particularly regarding protecting user data from cloud providers, but the overall sentiment leaned towards cautious optimism pending further details and independent analysis. Some commenters linked to additional resources explaining the complexities and current state of homomorphic encryption research.

  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.