Themis
How to build OpenSSL for Carthage iOS
Imagine your builds going red because of an outdated OpenSSL that is used by one of your Carthage dependencies. In this story, we share scripts, error messages, testing matrix, and a working solution we used for Themis to prevent such a situation.
OpenSSL for iOS: tricks of OpenSSL semver
OpenSSL complexity starts with its version string. Apple, Carthage, and some dependency analysis tools have different opinions about it. Here is how we dealt with them and submitted iOS app to the App Store. So, we decided to update OpenSSL in iOS app # Themis provides easy-to-use cryptography for multiple languages and platforms. We implement it on top of existing cryptography engines , such as OpenSSL or BoringSSL, which Themis uses as a source of the cryptographic primitives.
Implementing End-to-End encryption in Bear App
Bear with us! đ» # The latest release of a popular note-taking app Bear contains a new feature â end-to-end encryption of user notes. Cossack Labs team worked closely with the amazing Bear team to help deliver this feature. We are rarely allowed to disclose the details of our custom engineering work, but Bear team was awesome enough to let us highlight some important aspects of work done for them.
Thank You for Contributing and Using Themis in 2018
We believe that everyone should be able to create secure applications and protect usersâ privacy. Thatâs why our main cryptographic components are open source and developer-friendly. But open-source would be nothing without external contributions and feedback from users. We would like to publicly celebrate our open-source contributors and users who challenged us to make our open-source offerings more robust by asking hard questions, pointing out usability problems and potential usage patterns we were not aware of before.
Moving to OpenSSL 1.1.0 â How We Did It
This article was published in 2018 about R&D work, which resulted in stable production release of Themis that now uses OpenSSL 1.1.1g If youâre a developer and youâre dealing with cryptography for your app, consider using high-level cryptographic libraries like Themis instead of OpenSSL. No need to struggle with OpenSSL if your goal is to protect usersâ data. Moving to OpenSSL 1.1.0 Besides introducing breaking changes through abandoning backward compatibility on x64 systems, the recent version of Themis (Themis 0.
Auditable Macros in C Code
Intro Like death and taxes, one thing that you can be sure of is that using C macros in a modern software project will cause a debate. While for some macros remain a convenient and efficient way of achieving particular programming goals, for others they are opaque, introduce the unnecessary risk of coding errors, and reduce readability. The criticism of macros is particularly acute in the wider security community. Among Cossack Labsâ engineers and the core Themis crypto library contributors there are people who previously worked on auditing cryptographic implementations of critical code.
Replacing OpenSSL with Libsodium
This article was published in 2017 about R&D work, which resulted in stable production release of Themis. Intro In our ongoing effort to make Themis work with different cryptographic backends, we've decided to try something more challenging than just displacing similar primitives. This time we decided to make Themis work on Daniel J. Bernsteinâs cryptography, as it is introduced in NaCl. What if one day it turns out that Daniel Bernsteinâs assumptions about the rest of the world are correct, and everybody else is a lunatic?
Replacing OpenSSL with BoringSSL in a Complex Multi-Platform Layout
This article was published in 2017 about R&D work, which resulted in stable production release of Themis that uses BoringSSL as one of crypto-engines. If youâre a developer and youâre dealing with cryptography for your app, consider using high-level cryptographic libraries like Themis instead of BoringSSL. No need to struggle with BoringSSL if your goal is to protect usersâ data. Intro In Themis, we use industry-recognized implementations of cryptographic algorithms that come from OpenSSL/LibreSSL packages.
Importing with ctypes in Python: fighting overflows
Introduction On some cold winter night, we've decided to refactor a few examples and tests for Python wrapper in Themis, because things have to be not only efficient and useful, but elegant as well. One thing after another, and we ended up revamping Themis error codes a bit. Internal error and status flags sometimes get less attention than crypto-related code: they are internals for internal use. Problem is, when they fail, they might break something more crucial in a completely invisible way.
2016 at Cossack Labs
Bright and full of new 2016 year insensibly came to an end. Writing good software is hard: absorbed in developing our main products, closed a testing round of Acra (all hail the braves who dedicated an immense amount of time giving us feedback), we’ve spent most of the year undercover. Now that we’ve shown first cues to the open public, revelatory moments are closer than ever. This year we’ve put a lot of effort into helping Themis users understand how to better use Themis and how to build stronger apps:
Zero Knowledge Protocols without magic
When we’ve first released Secure Comparator to use in our Themis crypto library and started talking about novel authentication concepts, we’ve encountered a few common misconceptions and plenty of magical thinking about Zero-Knowledge Proofs as a phenomenon. In this post, we’ll talk about some of them, tie ZKP authentication to traditional security models, and help you gain a better understanding of how authentication, in general, should work. Understanding authentication and Zero-Knowledge Proof Protocols What is authentication, anyway?
Choose your Android crypto (Infographic)
Why do I even need to choose? Warning: This article borrows a lot from our original Choose your iOS Crypto publication, so if you've read that one, feel free to skip ahead to the libraries and ending notes about the actual Android specificities. When building your next app, you might realise that you need to encrypt the data. There are two main reasons for that: transmitting sensitive data to the server and back
Building Sesto, in-browser password manager
Intro: what is Sesto Sesto (abbreviation for Secret Store) is open source passwords (and general secrets) manager for web. What sets Sesto apart from many other password managers is: it's web password manager, e.g. you don't need local client to run it, only have compatible browser (Google Chrome with PNaCl modules enabled), the application is downloaded from Sesto server. for a clientless web password manager, it's strong security model: most web password managers are built either on JS crypto (which is bad), or rely on simply protecting your data via SSL and with some arbitrary keys on server side.
Benchmarking Secure Comparator
When we conceived Secure Comparator, we saw that it is going to be slightly slower than existing authentication methods, because: SMP requires much more rounds of data exchange each round involves expensive calculations our modification of ed25519 implementation involves blinding to avoid timing attacks, which makes overall performance even slower This is a consequence of different demands and different security guarantees Secure Comparator gives: let systems with zero shared information exchange requests to data, where request data itself is a leakage.
Crypto in iOS: Choose your destiny (Infographic)
Why do I even need to choose? When building your next app, you might realize that you need to encrypt the data. There are two main reasons for that: The need to transmit sensitive data to server and back; The need to store sensitive data. Even though there are multiple tools for doing just that, not all of those tools are equal. By just taking some random algorithm from CommonCrypto and using StackOverflow example to implement it, you'll fail.
Building secure end-to-end webchat with Themis
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.
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.
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,
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.
Notes on adding cutting edge features
As we've stated in the past, the Themis library grew out of our own needs for a secure, efficient and convenient cryptographic library. While providing abstracted high-level services, Themis uses trusted, well established implementations of cryptographic primitives such as those provided by LibreSSL/OpenSSL or platform native cryptography providers. With the upcoming v0.9.2 release of the Themis library, we will be announcing a new set of features called "Secure Comparator". As distinct from the current set of Themis functions, Secure Comparator not only uses existing implementations of cryptographic math but also our own in house developments - as we could find no suitable public implementations for some of operations with ECC curve ed25519.
Releasing Themis into public: usability testing
How we did usability testing for Themis when releasing the open source library into public. When we were ready to release Themis, we've gathered a few colleagues and decided to make a test run on unsuspecting developers - how would the library blend into their workflows? 1. Introduction While usability testing for user-centric applications has it's own distinct techniques, standards and frameworks, this is not so typical for a relatively complex and technical library aimed at developers and spanning multiple languages and platforms.