After Criticism, Signal Agrees to Secure Plain-Text Encryption Keys for Users’ Message Databases

“Signal is finally tightening its desktop client’s security,” reports BleepingComputer — by changing the way it stores plain text encryption keys for the SQLite database where users’ messages are stored:

When BleepingComputer contacted Signal about the flaw in 2018, we never received a response. Instead, a Signal Support Manager responded to a user’s concerns in the Signal forum, stating that the security of its database was never something it claimed to provide. “The database key was never intended to be a secret. At-rest encryption is not something that Signal Desktop is currently trying to provide or has ever claimed to provide,” responded the Signal employee…

[L]ast week, mobile security researchers Talal Haj Bakry and Tommy Mysk of Mysk Inc warned on X not to use Signal Desktop because of the same security weakness we reported on in 2018… In April, an independent developer, Tom Plant, created a request to merge code that uses Electron’s SafeStorage API “…to opportunistically encrypt the key with platform APIs like DPAPI on Windows and Keychain on macOS,” Plant explained in the merge request… When used, encryption keys are generated and stored using an operating system’s cryptography system and secure key stores. For example, on Macs, the encryption key would be stored in the Keychain, and on Linux, it would use the windows manager’s secret store, such as kwallet, kwallet5, kwallet6, and gnome-libsecret… While the solution would provide additional security for all Signal desktop users, the request lay dormant until last week’s X drama.

Two days ago, a Signal developer finally replied that they implemented support for Electron’s safeStorage, which would be available soon in an upcoming Beta version. While the new safeStorage implementation is tested, Signal also included a fallback mechanism that allows the program to decrypt the database using the legacy database decryption key…

Signal says that the legacy key will be removed once the new feature is tested.

“To be fair to Signal, encrypting local databases without a user-supplied password is a problem for all applications…” the article acknowledges.
“However, as a company that prides itself on its security and privacy, it was strange that the organization dismissed the issue and did not attempt to provide a solution…”

Read more of this story at Slashdot.

Signal’s New Usernames Help Keep Cops Out of Your Data

Longtime Slashdot reader SonicSpike shares a report from The Intercept: With the new version of Signal, you will no longer broadcast your phone number to everyone you send messages to by default, though you can choose to if you want. Your phone number will still be displayed to contacts who already have it stored in their phones. Going forward, however, when you start a new conversation on Signal, your number won’t be shared at all: Contacts will just see the name you use when you set up your Signal profile. So even if your contact is using a custom Signal client, for example, they still won’t be able to discover your phone number since the service will never tell it to them.

You also now have the option to set a username, which Signal lets you change whenever you want and delete when you don’t want it anymore. Rather than directly storing your username as part of your account details, Signal stores a cryptographic hash of your username instead; Signal uses the Ristretto 25519 hashing algorithm, essentially storing a random block of data instead of usernames themselves. This is like how online services can confirm a user’s password is valid without storing a copy of the actual password itself. “As far as we’re aware, we’re the only messaging platform that now has support for usernames that doesn’t know everyone’s usernames by default,” said Josh Lund, a senior technologist at Signal. The move is yet another piece of the Signal ethos to keep as little data on hand as it can, lest the authorities try to intrude on the company. Whittaker explained, “We don’t want to be forced to enumerate a directory of usernames.” […]

If Signal receives a subpoena demanding that they hand over all account data related to a user with a specific username that is currently active at the time that Signal looks it up, they would be able to link it to an account. That means Signal would turn over that user’s phone number, along with the account creation date and the last connection date. Whittaker stressed that this is “a pretty narrow pipeline that is guarded viciously by ACLU lawyers,” just to obtain a phone number based on a username. Signal, though, can’t confirm how long a given username has been in use, how many other accounts have used it in the past, or anything else about it. If the Signal user briefly used a username and then deleted it, Signal wouldn’t even be able to confirm that it was ever in use to begin with, much less which accounts had used it before.

In short, if you’re worried about Signal handing over your phone number to law enforcement based on your username, you should only set a username when you want someone to contact you, and then delete it afterward. And each time, always set a different username. Likewise, if you want someone to contact you securely, you can send them your Signal link, and, as soon as they make contact, you can reset the link. If Signal receives a subpoena based on a link that was already reset, it will be impossible for them to look up which account it was associated with. If the subpoena demands that Signal turn over account information based on a phone number, rather than a username, Signal could be forced to hand over the cryptographic hash of the account’s username, if a username is set. It would be difficult, however, for law enforcement to learn the actual username itself based on its hash. If they already suspect a username, they could use the hash to confirm that it’s real. Otherwise, they would have to guess the username using password cracking techniques like dictionary attacks or rainbow tables.

Read more of this story at Slashdot.

Indian Government Moves To Ban ProtonMail After Bomb Threat

Following a hoax bomb threat sent via ProtonMail to schools in Chennai, India, police in the state of Tamil Nadu put in a request to block the encrypted email service in the region since they have been unable to identify the sender. According to Hindustan Times, that request was granted today. From the report: The decision to block Proton Mail was taken at a meeting of the 69A blocking committee on Wednesday afternoon. Under Section 69A of the IT Act, the designated officer, on approval by the IT Secretary and at the recommendation of the 69A blocking committee, can issue orders to any intermediary or a government agency to block any content for national security, public order and allied reasons. HT could not ascertain if a blocking order will be issued to Apple and Google to block the Proton Mail app. The final order to block the website has not yet been sent to the Department of Telecommunications but the MeitY has flagged the issue with the DoT.

During the meeting, the nodal officer representing the Tamil Nadu government submitted that a bomb threat was sent to multiple schools using ProtonMail, HT has learnt. The police attempted to trace the IP address of the sender but to no avail. They also tried to seek help from the Interpol but that did not materialise either, the nodal officer said. During the meeting, HT has learnt, MeitY representatives noted that getting information from Proton Mail, on other criminal matters, not necessarily linked to Section 69A related issues, is a recurrent problem.

Although Proton Mail is end-to-end encrypted, which means the content of the emails cannot be intercepted and can only be seen by the sender and recipient if both are using Proton Mail, its privacy policy states that due to the nature of the SMTP protocol, certain email metadata — including sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times — is available with the company. “We condemn a potential block as a misguided measure that only serves to harm ordinary people. Blocking access to Proton is an ineffective and inappropriate response to the reported threats. It will not prevent cybercriminals from sending threats with another email service and will not be effective if the perpetrators are located outside of India,” said ProtonMail in a statement.

“We are currently working to resolve this situation and are investigating how we can best work together with the Indian authorities to do so. We understand the urgency of the situation and are completely clear that our services are not to be used for illegal purposes. We routinely remove users who are found to be doing so and are willing to cooperate wherever possible within international cooperation agreements.”

Read more of this story at Slashdot.

Linux Foundation Forms Post-Quantum Cryptography Alliance

Jakub Lewkowicz reports via SD Times: The Linux Foundation has recently launched the Post-Quantum Cryptography Alliance (PQCA), a collaborative effort aimed at advancing and facilitating the adoption of post-quantum cryptography in response to the emerging threats of quantum computing. This alliance assembles diverse stakeholders, including industry leaders, researchers, and developers, focusing on creating high-assurance software implementations of standardized algorithms. The initiative is also dedicated to supporting the development and standardization of new post-quantum cryptographic methods, aligning with U.S. National Security Agency’s guidelines to ensure cryptographic security against quantum computing threats.

The PQCA endeavors to serve as a pivotal resource for organizations and open-source projects in search of production-ready libraries and packages, fostering cryptographic agility in anticipation of future quantum computing capabilities. Founding members include AWS, Cisco, Google, IBM, IntellectEU, Keyfactor, Kudelski IoT, NVIDIA, QuSecure, SandboxAQ, and the University of Waterloo. […] [T]he PQCA plans to launch the PQ Code Package Project aimed at creating high-assurance, production-ready software implementations of upcoming post-quantum cryptography standards, beginning with the ML-KEM algorithm. By inviting organizations and individuals to participate, the PQCA is poised to play a critical role in the transition to and standardization of post-quantum cryptography, ensuring enhanced security measures in the face of advancing quantum computing technology. You can learn more about the PQCA on its website or GitHub.

Read more of this story at Slashdot.

Post-Quantum Encryption Algorithm KyberSlash Patched After Side-Channel Attack Discovered

jd (Slashdot reader #1,658) shared this story from BleepingComputer. The article notes that “Multiple implementations of the Kyber key encapsulation mechanism for quantum-safe encryption, are vulnerable to a set of flaws collectively referred to as KyberSlash, which could allow the recovery of secret keys.”

jd explains that Crystals-Kyber “was chosen to be the U.S. government’s post-quantum cryptography system of choice last year, but a side-channel attack has been identified. But in the article, NIST says that this is an implementation-specific attack (the reference implementation) and not a vulnerability in Kyber itself.”
From the article:
CRYSTALS-Kyber is the official implementation of the Kyber key encapsulation mechanism (KEM) for quantum-safe algorithm (QSA) and part of the CRYSTALS (Cryptographic Suite for Algebraic Lattices) suite of algorithms. It is designed for general encryption… The KyberSlash flaws are timing-based attacks arising from how Kyber performs certain division operations in the decapsulation process, allowing attackers to analyze the execution time and derive secrets that could compromise the encryption. If a service implementing Kyber allows multiple operation requests towards the same key pair, an attacker can measure timing differences and gradually compute the secret key…

In a KyberSlash1 demo on a Raspberry Pi system, the researchers recovered Kyber’s secret key from decryption timings in two out of three attempts…
On December 30, KyberSlash2 was patched following its discovery and responsible reporting by Prasanna Ravi, a researcher at the Nanyang Technological University in Singapore, and Matthias Kannwischer, who works at the Quantum Safe Migration Center.

Read more of this story at Slashdot.

Will Quantum Computing Bring a Cryptopocalypse?

“The waiting time for general purpose quantum computers is getting shorter, but they are still probably decades away,” notes Security Week.

But “The arrival of cryptanalytically-relevant quantum computers that will herald the cryptopocalypse will be much sooner — possibly less than a decade.”

It is important to note that all PKI-encrypted data that has already been harvested by adversaries is already lost. We can do nothing about the past; we can only attempt to protect the future…. [T]his is not a threat for the future — the threat exists today. Adversaries are known to be stealing and storing encrypted data with the knowledge that within a few years they will be able to access the raw data. This is known as the ‘harvest now, decrypt later’ threat. Intellectual property and commercial plans — not to mention military secrets — will still be valuable to adversaries when the cryptopocalypse happens.

The one thing we can say with certainty is that it definitely won’t happen in 2023 — probably. That probably comes from not knowing for certain what stage in the journey to quantum computing has been achieved by foreign nations or their intelligence agencies — and they’re not likely to tell us. Nevertheless, it is assumed that nobody yet has a quantum computer powerful enough to run Shor’s algorithm and crack PKI encryption in a meaningful timeframe. It is likely that such computers may become available as soon as three to five years. Most predictions suggest ten years.

Note that a specialized quantum computer designed specifically for Shor does not need to be as powerful as a general-purpose quantum computer — which is more likely to be 20 to 30 years away…. “Quantum computing is not, yet, to the point of rendering conventional encryption useless, at least that we know of, but it is heading that way,” comments Mike Parkin, senior technical engineer at Vulcan Cyber. Skip Sanzeri, co-founder and COO at QuSecure, warns that the threat to current encryption is not limited to quantum decryption. “New approaches are being developed promising the same post-quantum cybersecurity threats as a cryptographically relevant quantum computer, only much sooner,” he said. “It is also believed that quantum advancements don’t have to directly decrypt today’s encryption. If they weaken it by suggesting or probabilistically finding some better seeds for a classical algorithm (like the sieve) and make that more efficient, that can result in a successful attack. And it’s no stretch to predict, speaking of predictions, that people are going to find ways to hack our encryption that we don’t even know about yet.”

Steve Weston, co-founder and CTO at Incrypteon, offers a possible illustration. “Where is the threat in 2023 and beyond?” he asks. “Is it the threat from quantum computers, or is the bigger threat from AI? An analysis of cryptoanalysis and code breaking over the last 40 years shows how AI is used now, and will be more so in the future.”

The article warns that “the coming cryptopocalypse requires organizations to transition from known quantum-vulnerable encryption (such as current PKI standards) to something that is at least quantum safe if not quantum secure.” (The chief revenue officer at Quintessence Labs tells the site that symmetric encryption like AES-256 “is theorized to be quantum safe, but one can speculate that key sizes will soon double.”)

“The only quantum secure cryptography known is the one-time pad.”

Thanks to Slashdot reader wiredmikey for sharing the article.

Read more of this story at Slashdot.

US NIST Unveils Winning Encryption Algorithm For IoT Data Protection

The National Institute of Standards and Technology (NIST) announced that ASCON is the winning bid for the “lightweight cryptography” program to find the best algorithm to protect small IoT (Internet of Things) devices with limited hardware resources. BleepingComputer reports: ASCON was selected as the best of the 57 proposals submitted to NIST, several rounds of security analysis by leading cryptographers, implementation and benchmarking results, and feedback received during workshops. The whole program lasted for four years, having started in 2019. NIST says all ten finalists exhibited exceptional performance that surpassed the set standards without raising security concerns, making the final selection very hard.

ASCON was eventually picked as the winner for being flexible, encompassing seven families, energy efficient, speedy on weak hardware, and having low overhead for short messages. NIST also considered that the algorithm had withstood the test of time, having been developed in 2014 by a team of cryptographers from Graz University of Technology, Infineon Technologies, Lamarr Security Research, and Radboud University, and winning the CAESAR cryptographic competition’s “lightweight encryption” category in 2019.

Two of ASCON’s native features highlighted in NIST’s announcement are AEAD (Authenticated Encryption with Associated Data) and hashing. AEAD is an encryption mode that provides confidentiality and authenticity for transmitted or stored data, combining symmetric encryption and MAC (message authentication code) to prevent unauthorized access or tampering. Hashing is a data integrity verification mechanism that creates a string of characters (hash) from unique inputs, allowing two data exchange points to validate that the encrypted message has not been tampered with. Despite ASCON’s lightweight nature, NIST says the scheme is powerful enough to offer some resistance to attacks from powerful quantum computers at its standard 128-bit nonce. However, this is not the goal or purpose of this standard, and lightweight cryptography algorithms should only be used for protecting ephemeral secrets. For more details on ASCON, check the algorithm’s website, or read the technical paper (PDF) submitted to NIST in May 2021.

Read more of this story at Slashdot.

iOS 16.3 Expands Advanced Data Protection Option For iCloud Encryption Globally

Apple today announced that Advanced Data Protection is expanding beyond the United States. MacRumors reports: Starting with iOS 16.3, the security feature will be available globally, giving users to option to enable end-to-end encryption for many additional iCloud data categories, including Photos, Notes, Voice Memos, Messages backups, device backups, and more. iOS 16.3 is currently in beta and expected to be released to the public next week.

By default, Apple stores encryption keys for some iCloud data types on its servers to ensure that users can recover their data if they lose access to their Apple ID account. If a user enables Advanced Data Protection, the encryption keys are deleted from Apple’s servers and stored on a user’s devices only, preventing Apple, law enforcement, or anyone else from accessing the data, even if iCloud servers were to be breached.

iCloud already provides end-to-end encryption for 14 data categories without Advanced Data Protection turned on, including Messages (excluding backups), passwords stored in iCloud Keychain, Health data, Apple Maps search history, Apple Card transactions, and more. Advanced Data Protection expands this protection to the vast majority of iCloud categories, with major exceptions including the Mail, Contacts, and Calendar apps. For more information, you can read Apple’s Advanced Data Protection support document.

Read more of this story at Slashdot.