Building LibreSSL for PNaCl
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.
Building and Using Themis in PNaCl
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.
What's wrong with Web Cryptography
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.
Fixing Secure Comparator
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.
Introducing Secure Comparator
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.
Why we need novel authentication schemes?
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.
WeakDH/LogJam vs Secure Session
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.
Armoring ed25519 to meet extended security challenges
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,
Why you should avoid SSL for your next application
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.
Building encrypted chat service with Themis and mobile websocket example
Introduction Imagine you'd like to build your own chat server, which allows clients to exchange messages safely. You have a simple infrastructure consisting of a server written in Ruby and clients for iOS and Android. This is exactly what the famous Mobile websocket example provides. We have modified it to illustrate how simple it is to add security features using Themis. In this tutorial, we'll try to preserve as much of it's simplicity and architecture as possible, but add cryptographic protection.