Make Confide great again? No, we cannot

In recent weeks, Confide, a secure instant messaging application, has gained popularity in some circles. This article presents a quick assessment of the security of this application. The official website boasts the confidentiality provided by the product through three qualifiers: encrypted, ephemeral and screenshot protected. Each of these aspects will be studied.

The encryption protocol will be particularly detailed because it is tagged as battle tested, military grade cryptography. We already knew about military grade cryptography, which seems to be a synonym of put AES-256 somewhere, no matter how you use it in many applications, but we had never heard of battle tested cryptography. This article is an opportunity to present this technology.

Developing properly end-to-end communication systems is complex. As we have seen in the past with iMessage, even if cryptographic primitives are correctly implemented and encryption keys are correctly generated and protected, the design is critical to forbid the service operator from being able to eavesdrop messages.

Differential Fault Analysis on White-box AES Implementations

With the Differential Computation Analysis (DCA) presented at CHES 2016, we have shown that side-channel techniques developed to break hardware cryptographic implementations can be adapted successfully to break white-box implementations. In this post, we will explore another class of hardware attacks: fault injections and how to apply them on white-box implementations.

Security Assessment of VeraCrypt: fixes and evolutions from TrueCrypt

Quarkslab made a security assessment of VeraCrypt 1.18. The audit was funded by OSTIF and was performed by two Quarkslab engineers between Aug. 16 and Sep. 14, 2016 for a total of 32 man-days of study. A critical vulnerability, related to cryptography, has been identified. It has been introduced in version 1.18, and will be fixed in version 1.19.

A brief survey of Fully Homomorphic Encryption, computing on encrypted data

When appointing computation of private data to a third party, privacy is an issue. How can one delegate computation without giving up one's secrets? This gets trickier when multiple parties are involved. Several works on Multi-Party Computation (MPC) addressed this issue, but a new approach has started to emerge: Fully Homomorphic Encryption (FHE).

A glimpse of ext4 filesystem-level encryption

Linux 4.1 has arrived with a new feature for its popular ext4 filesystem: filesystem-level encryption!

Have you ever played with Domino?

IBM Lotus Domino is an email client rather common in companies like Microsoft Outlook. This article proposes to observe a small part of the application engine, namely one method used to store the user's password. In a second step, we will conduct a brief analysis of all used algorithms then we will see how to implement a plugin for John The Ripper to bruteforce discovered digests.

iMessage Privacy

iMessage is probably one of the most trendy instant messaging systems. Apple presents it as very secure, with high cryptographic standards, including end-to-end encryption preventing even Apple from reading the messages. Is this true?

Unique random number set computation

In one of Quarkslab's projects, we came across the issue of randomizing a large set of integers, described as a list of disjoint intervals. These intervals can be represented as a sorted list of integers couples, like this one: $$[1, 4], [10, 15], [17, 19], \dots$$. The idea is to randomly and uniquely select numbers across these intervals, giving a shuffled list of numbers that belong to them. For instance, $$[1,10,18,4,3,11,15,17,19,12,14,13,2]$$ is a possible output. Moreover, each possible permutation of the integers set should have equal probability of appearance. If you're just interested in the final library that "do the job", go directly to the implementation section to download the leeloo C++ open-source library on Github !

Bradley, hash-and-decrypt, Gauss ... a brief history of armored malware and malicious crypto

What was really stunning about Stuxnet and its cousins was it was "open source". Once the sample was captured, it was big to analyze, but none of its embedded secrets could escape a malware analyst. And it had many secrets! From an engineering point of view, the architecture and design are clean and efficient, which makes Stuxnet a good example to learn how to design malware. From an intelligence point of view, knowing what is targeted is valuable. For a money point of view, considering how governments are racing to buy 0 days, Stuxnet was above expensive. And all this was wasted because the payload was unprotected!