Blog

Responsibility is yours, mine, and that developer's in the office nearby. Open any tech news aggregator and chances are, one-third of all news will be security-related. What we are seeing right now is insane raise of awareness to cyber security, dictated by security threats suddenly turning looming on the horizon to dangerously close to anybody on the Internet. It is not your typical buzzword market fad, where everyone suddenly gets interested in next exciting topic in the development of modern tech, looking for ‘wild opportunities’.

Key management in security system Frequently overlooked, much less hyped than quantum computers breaking trapdoor functions, managing keys is actually the most important part of building a security system. Secret keys, public-private key pairs, passwords and other factors of authentication are the control vessels within security system. In this article, we will go through basic key management concepts, explain some important ideas for next articles and provide some practical advice you can start implementing within your application tomorrow.

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.

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.