Blog

Intro While developing components of our products, we love to explore use cases and usability through creating real-world test stands.  0fc is a side-product of WebThemis research: while doing some protocol design for front-end clients with WebThemis services, we wanted to try it in a real-world situation. We've set ourselves a novel idea: end-to-end encrypted webchat, inclined towards client anonymity, giving zero trust to the server, built only with typical Themis primitives.

Intro While building WebThemis, we've encountered the need to build LibreSSL for PNaCl as a source of cryptographic primitives. The problem? LibreSSL has huge codebase with a lot of complicated code, that won't build on new platform out of the box. Solution? Strip all we can and make the rest work. Having gone “let’s do a quick hack to build Libre” barbaric way for PoC version of WebThemis, we would like to share our experience for the aspiring PNaCl developers to benefit.

Intro Native Client (NaCl) allows browser applications to launch a native low-level code in an isolated environment. Thanks to this, some code, performance code parts can be rewritten in C or C++ easily. Until recent time, NaCl could work on x86-compatible systems only, yet supporting ARM platform becomes very important, because a huge variety of devices (especially the newest Chrome OS laptops), are built on ARM architecture. All you need to compile the code for ARM is located in the latest Native Client SDK.

Introduction Building full stack of cryptographic protection for modern applications includes working with the modern web browser, of course. However, through 20+ years of history of web browsers, we're at the stage where in-browser cryptography is still problematic, and best you can rely on is SSL. Which only protects data transport between you and server, leaving you hoping that you're good enough to go. Which is not always the case.

Introduction The idea behind Socialist Millionaire Protocol is to provide definite answer to the question whether two communicating parties possess the same secret or not in a secure (zero-knowledge) manner. However, given a problem like this, one still has to take care of many implementation details which contribute to the protocol's security properties. After releasing Secure Comparator paper / PoC code, we've received significant amount of critical feedback: in our github issues #85 and #83 and a number of reddit posts.

A word to pass Passwords are the ultimate keepers of security, extensively used in the 21st century's Internet. As more and more aspects of our lives become accessible online, the importance of keeping your passwords secure becomes crucial, because anybody knowing the password may access your accounts. However, when you input password to access your account, it uses thousands of intermediate links to deliver the data, meaning that your secret password can be compromised at any moment.

Introduction: A Word To Pass Before introducing our novel request authentication scheme in Themis, we’ve decided to create an overview of the existing methods of authentication and try to look into what the future might bring us. Passwords are ultimate keepers of diversity and security. Since Ancient Roman times until now, they are used for one to prove being worthy to get some privilege others do not possess, however strongly desire to obtain.

Intro After LogJam vulnerability was published, and then the WeakDH paper (Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice) was published, we were asked a few times: since Secure Session uses Diffie-Hellman key negotiation, is prone to the same attacks? We wrote this small note to explain why we are safe from such attacks, and how generally decisions about such important security features are being done for the open source Themis crypto library.

This article was revisited and updated in October 2018. Introduction We strive to use the best state-of-the-art cryptography for our library Themis. So when we wanted to implement an important novel feature Secure Comparator (that includes the so-called "Socialist Millionaire Protocol"), we needed to replace the prime-field modular arithmetic with something stronger. The obvious choice for such replacement was the ed25519 signature system: it provides even more protection from side-channel analysis than conventional (NIST-driven) ECC,

Introduction 2018 update: This article was 4 years old, and even then presented disputable opinion. Many things have changed since then, we're having TLS 1.3, which eliminates a number of cryptographic concerns and enforces correct uses. Still, many challenges stand unaddressed. We've remixed the article to keep relevant problems, and outline solutions to those solved, along with a few thoughts on what and when you can use instead. Everyday software developers trust SSL / TLS encryption to protect their communications without considering whether or not this is the right thing to do.