Blog

This article was revisited and updated in August 2018. In modern client-server applications, most of the sensitive data is stored (and consequently leaked) on the backend. At Cossack Labs, we’re working on novel techniques to protect the data within modern infrastructures. We talk to engineers across industries about these techniques quite a lot too. However, it is still not uncommon to see infrastructures without even the basic classic database defence patterns.

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?

Perimeter security: looking back Over the years, the Internet has evolved, and complex systems facing the Internet have evolved too.  Traditional security methodology to defend these systems was to build strong walls around your most valuable assets: build a castle and hope it stands against the external adversary. We’ve invested into firewalls, data leakage prevention systems, intrusion detection of all sorts. And what’s behind these walls? Whatever it is, it’s protected, we’ve thought for a long time.

More than half of the year has passed since the last release and we have done a lot to make Themis better. Here is what we have updated: Infrastructure: Lots of new high-level language wrappers Enhanced documentation We have added lots of various demo projects Updated Themis Server Better make system verbosity (now you can see what succeeded and what didn't) Infrastructure to build Java on all platforms. Code:  iOS wrapper now has umbrella header.

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

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.

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.

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.

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.