Essential Cryptography for JavaScript Developers. E-Book

Alessandro Segala

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 299

Veröffentlichungsjahr: 2022

Beschreibung

If you’re a software developer, this book will give you an introduction to cryptography, helping you understand how to make the most of it for your applications. The book contains extensive code samples in JavaScript, both for Node.js and for frontend apps running in a web browser, although the core concepts can be used by developers working with any programming language and framework.
With a purely hands-on approach that is focused on sharing actionable knowledge, you’ll learn about the common categories of cryptographic operations that you can leverage in all apps you’re developing, including hashing, encryption with symmetric, asymmetric and hybrid ciphers, and digital signatures. You’ll learn when to use these operations and how to choose and implement the most popular algorithms to perform them, including SHA-2, Argon2, AES, ChaCha20-Poly1305, RSA, and Elliptic Curve Cryptography. Later, you’ll learn how to deal with password and key management. All code in this book is written in JavaScript and designed to run in Node.js or as part of frontend apps for web browsers.
By the end of this book, you'll be able to build solutions that leverage cryptography to protect user privacy, offer better security against an expanding and more complex threat landscape, help meet data protection requirements, and unlock new opportunities.

Leseprobe

Essential Cryptography for JavaScript Developers

A practical guide to leveraging common cryptographic operations in Node.js and the browser

Alessandro Segala

BIRMINGHAM—MUMBAI

Essential Cryptography for JavaScript Developers

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Associate Group Product Manager: Rohit Rajkumar

Senior Editor: Keagan Carneiro

Content Development Editor: Divya Vijayan

Technical Editor: Simran Udasi

Copy Editor: Safis Editing

Project Coordinator: Rashika Ba

Proofreader: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Shyam Sundar Korumilli

Marketing Coordinator: Anamika Singh

First published: February 2022

Production reference: 1140122

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-533-6

www.packt.com

To my family and dearest friends; my girlfriend, Clare; my parents, Maria Grazia and Francesco; and my brother, Christian, who, even during these challenging times, have shown love and continued support to each other.

– Alessandro Segala

Contributors

About the author

Alessandro Segala is a product manager at Microsoft working on developer tools. A software engineer at heart, he has over a decade of experience building full stack web applications, having worked as a professional developer as well as contributing to and maintaining various open source projects. In addition to writing about software development on his blog, Alessandro had his first book, Svelte 3 Up and Running, published by Packt in 2020.

About the reviewers

Deepal Jayasekara is a staff software engineer who is experienced in building large-scale, secure applications for payments, infrastructure as a service (IaaS), and financial services industries. He writes and speaks about topics including JavaScript/Node.js, information security, and networking. He is also the founder of bibliocircle.com.

Justin Boyer is a tech enthusiast, self-proclaimed proud geek, and writer. He spent over 8 years in software development, focusing on CRM and web development technologies. He piloted the adoption of Node.js in his company and grew to appreciate its unique strengths. He later transitioned to application security, gaining his CSSLP and Security+ certifications and authoring several Pluralsight courses on appsec topics. He now works for himself, providing writing services to tech and cybersecurity companies, while keeping his tech chops current by volunteering his security expertise for a nonprofit and authoring more courses.

Josh Robinson is a code craftsman who thrives on cutting-edge technology. His love for coding began with the blue glow of a second hand Commodore 64 and has continued into his career building the future.

He can be stalked at JoshRobinson on Twitter and found creating new decentralized tech at bproto.io, where he is a founder.

Table of Contents

Preface

Part 1 – Getting Started

Chapter 1: Cryptography for Developers

What is cryptography and why should a developer care?

Protecting secrets…

…and the other uses of modern cryptography

Why this matters to developers

What this book is about – and what it's not

Rules of engagement

Defining "safe"

Types and "layers" of encryption

Summary

Chapter 2: Dealing with Binary and Random Data

Encoding and representing binary data

A brief word on character encodings and why we encode binary data

Buffers in Node.js

Hex encoding

Base64

Generating cryptographically secure random byte sequences

The importance of randomness

Using crypto.randomBytes

Summary

Part 2 – Using Common Cryptographic Operations with Node.js

Chapter 3: File and Password Hashing with Node.js

Technical requirements

An overview of hashing functions

Properties of hashing functions, and how they differ from encryption

Uses for hashing functions

Calculating digests and generating identifiers

Hashing a short message or string

Hashing large files and streams

How to "break" a hash

Fast hashing functions and low-entropy inputs

Rainbow tables

Hashing passwords and deriving keys

Argon2

Scrypt

Older hashing functions

Collisions

Summary

Chapter 4: Symmetric Encryption in Node.js

Technical requirements

Symmetric and asymmetric encryption

Symmetric encryption with AES

Key length

Mode of operation

Initialization vector

Using AES with Node.js

Symmetric encryption with ChaCha20-Poly1305

Example usage with Node.js

When to use ChaCha20-Poly1305 or AES-GCM

Key derivation

Reusing keys

Wrapping keys and best practices for encrypting large documents

AES Key Wrap

Wrapping user keys

Summary

Chapter 5: Using Asymmetric and Hybrid Encryption in Node.js

Technical requirements

Understanding public-key and hybrid cryptosystems

The need for public-key cryptography

Hybrid cryptosystems

Loading, exporting, and encoding public and private keys

Encoding keys as PEM

Reading and exporting keys

Using RSA with Node.js

Generating an RSA key pair

Using RSA for encryption and decryption

Hybrid encryption with RSA and AES

Key agreements with Elliptic-Curve Diffie-Hellman

Picking a curve

Generating EC key pairs

Diffie-Hellman key agreements and Perfect Forward Secrecy

Performing an ECDH key agreement

Data encryption with ECIES

Summary

Chapter 6: Digital Signatures with Node.js and Trust

Technical requirements

The what, how, and why of digital signatures

Hashes and digital signatures

Properties of digital signatures

How digital signatures work

Digital signatures and encryption

How developers use digital signatures

Calculating and verifying digital signatures with Node.js

Using RSA

Using elliptic curves

Trust and certificates

The problem of trusting keys

Public keys and certificates

Public Key Infrastructure

Alternative approaches

Summary

Part 3 – Cryptography in the Browser

Chapter 7: Introduction to Cryptography in the Browser

Technical requirements

Playground

In Node.js

About cryptography in the browser – uses and challenges

Challenges of cryptography in the browser

Building browser-based apps that use cryptography

Binary data in the browser

Buffers and typed arrays in the browser

Generating random data

Keys in Web Crypto

The CryptoKey object

Generating keys

Importing keys

Exporting keys

Summary

Chapter 8: Performing Common Cryptographic Operations in the Browser

Technical requirements

Hashing and key derivation

Calculating checksums

Hashing passwords

Deriving encryption keys

Symmetric encryption

Encrypting and decrypting messages with AES

Asymmetric and hybrid cryptography

Encrypting and decrypting short messages with RSA

Hybrid encryption with RSA and AES

Using elliptic curves for ECDH key agreements and ECIES hybrid encryption

Digital signatures

Digital signatures with the WebCrypto APIs

Calculating and verifying RSA signatures

Calculating and verifying ECDSA signatures

Summary

Other Books You May Enjoy

Part 1 – Getting Started

In this first section, we will begin with an overview of the main topics covered in this book, the various operations we're covering, and the core principles that will guide the rest of the book. We will then proceed to learn about how to work with binary and random data in Node.js, two common occurrences while working with cryptography.

This section comprises the following chapters:

Chapter 1,Cryptography for DevelopersChapter 2,Dealing with Binary and Random Data

Chapter 1: Cryptography for Developers

"Dance like no one's watching. Encrypt like everyone is."

– Anonymous

Few things are as important for application security as cryptography. Done properly, it can make data unreadable to attackers even if you suffer a breach. But do it wrong, and it can actually amplify the impact of other vulnerabilities.

While cryptography is incredibly accessible to developers nowadays, many still have questions around how to use it, when to use it, and which of the many options or algorithms to pick.

This book will try to answer those questions without going into formal, academic explanations, and without complex mathematical formulas or diagrams, in a way that is friendly to developers. Unlike many other books on the topic, our goal won't be to train you to become a cryptographer. Instead, by the end of this book, you'll hopefully have enough knowledge of the most important algorithms to be able to use them in your code confidently.

All code samples in this book are written in JavaScript and assume a Node.js execution environment, with the exception of Part 3, Cryptography in the browser, in which we'll look at the Web Crypto APIs for usage in a web browser. However, even if you code in a different programming language, you will be able to follow along to learn the core concepts, and then replicate them in your preferred stack using one of the many libraries that are available to you.

In this first chapter, we're going to introduce the book and cover the following topics:

An overview of what cryptography is and why it matters to developersA definition of "safe" in the context of cryptographyTypes and "layers" of encryption

What is cryptography and why should a developer care?

Cryptography is everywhere around us and it impacts directly or indirectly on every aspect of our lives, every day, even when you don't notice it.

Cryptography is used to protect the information we share on the internet. You'll also find it when you're authenticating yourself to use your phone or laptop, or swiping the badge to get into your office. Cryptography is used to secure every digital payment transaction and to guarantee contracts that are signed digitally. It is also used to protect data we store on our devices, both from unauthorized access and from accidental corruption.

Protecting secrets…

Most people, even those who are not particularly tech-savvy, know that cryptography as the science and practice of protecting messages, files, and data, such as by encrypting and decrypting them.

In fact, this use of cryptography, to shield messages from adversaries, is thousands of years old. A common example is the Caesar cipher (a cipher is an algorithm used for encryption or decryption), which is named after the Roman emperor Julius Caesar; this is a classic example of a "substitution cipher," in which letters of the alphabet are substituted with one another. In the case of the Caesar cipher, each letter was shifted by three, so the letter A became D, B became E, Z became C, and so on.

Other famous historical ciphers include the Vigenère cipher, which in the 16th century first introduced the concept of an "encryption key," and then mechanical ones such as the Enigma machine, used by Nazi Germany during World War II and eventually broken by Polish and English researchers (this was also the topic of the 2014 movie The Imitation Game, which depicted the work of Alan Turing and the other researchers at Bletchley Park).

While the history of cryptography can be an interesting topic per se, and it provides invaluable lessons on common types of attacks against cryptography, all those historical ciphers are considered broken and so are not useful to modern application developers. As such, we won't be spending more time talking about them in this book, but nevertheless, I encourage curious readers to learn more about them!

…and the other uses of modern cryptography

Despite the strong association with ensuring confidentiality and hiding secrets, modern cryptography is used for much more than that.

In fact, throughout this book, we'll be using cryptographic functions for a variety of purposes, some of which are meant to be shared with the public rather than kept as secrets:

In Chapter 3, File and Password Hashing with Node.js, we'll learn about hashing, which is a one-way cryptographic operation that allows you to derive a fixed-length digest for any message. This is used for purposes including checking the integrity of files or messages, generating identifiers and encryption keys, and protecting passwords. In Chapter 4, Symmetric Encryption in Node.js, and Chapter 5, UsingAsymmetric and Hybrid Encryption in Node.js, we'll look at data encryption and decryption using various kinds of ciphers.In Chapter 6, Digital Signatures with Node.js and Trust, we'll learn how cryptography can be used to create and validate digital signatures, which can be used (among other things) to authenticate the author of a message, certifying its provenance, or preventing repudiation.

Why this matters to developers

As a software developer, understanding the practices presented above can help you build applications that implement cryptographic operations safely, using the most appropriate solutions. There are many possible uses of cryptography, and the aforementioned list contains only some examples.

Not all the operations we're going to learn about in this book will be useful or even relevant for every application you might be working on. However, the topics presented in the next chapters are possibly the most common ones, which developers can leverage to solve frequent real-world problems.

In fact, given the current state of application development, nowadays you could argue that knowing how to safely implement the solutions described in this book should be a skill most developers need to be at least somehow familiar with, without the need to consult with expert cryptographers.

Globally, cyberattacks have been getting more and more frequent every year and are carried out by increasingly more sophisticated adversaries, sometimes including state-sponsored actors. Just as attacks have increased in both quantity and quality, thanks to the pervasiveness of digital systems in our businesses and lives, the impact of breaches has grown costlier, with damage that can be in the range of millions of dollars and, in certain cases, catastrophic or fatal.

Whereas security used to be an afterthought in the software development life cycle, at times relegated to an issue for operations specialists only, teams are now tasked with considering it during every stage of the development process. Many organizations are also adopting practices such as DevSecOps and "shift left security," in which the security needs of an entire solution are included in the entire software development life cycle, from planning and development to operations.

DevOps and DevSecOps

DevOps is a set of principles and practices, aided by specialized tools, to enable the continuous delivery of value to end users. DevOps is built around practices such as Continuous Integration (CI) and Continuous Delivery (CD), agile software development, and continuous monitoring that are meant to bring the development and operations teams closer together and allow faster application release cycles, and continuous learning and improvement.

To learn more about DevOps, visit https://bit.ly/crypto-devops

Building on DevOps, DevSecOps requires the integration of security practices and thinking into every stage of the DevOps process – planning, building, delivering, and operating. Organizations that adopt DevSecOps believe that security is a shared responsibility among every person and team that has any dealing with an application.

To learn more about DevSecOps, visit https://bit.ly/crypto-devsecops

For example, whereas corporate or Local Networks (LANs) were traditionally considered safe, it's now common practice to assume your systems have been breached and practice defense in depth or add multiple layers of protection. So, an application that encrypts data in transit prevents an eavesdropper (called a Man-in-the-Middle or MitM) from potentially stealing secrets, even inside a LAN.

It should go without saying that while adding cryptography to your applications is often necessary to make them safe, it's almost always not sufficient. For example, protecting your users' data with strong encryption will help limit the impact of breaches but will be useless against account takeovers through social engineering.

Nevertheless, cryptography does play an important role in the process of protecting data; for example, it secures the data your application uses (both at rest and in transit), ensuring the integrity of the information stored or exchanged, authenticating end users or other services, preventing tampering, and so on.

In addition to learning about the different classes of cryptographic operations that you can take advantage of, with this book I also hope you will be equipped to understand when to use each one in the safest way possible.

In fact, just as not using cryptography can lead to serious consequences, implementing cryptography in the wrong way can be equally as bad. This can happen when developers use broken algorithms (for this reason, we'll be sticking to a few tried-and-tested ones in this book) or buggy implementations of good algorithms, such as libraries containing security vulnerabilities (which is why we're going to recommend built-in standard libraries whenever possible). In other cases, issues could be caused by developers picking the wrong cryptographic operations; one too-common example is storing passwords in databases that have been encrypted with a symmetric cipher rather than hashed, as we'll see later in the book.

Lastly, I would like to point out that the five classes of cryptographic operations we're covering in this book do not represent all the different algorithms and protocols that can be used by modern applications, nor all the possible different uses of cryptography.

For example, end-to-end encrypted messaging apps or VPNs often need to implement special key exchange algorithms, or full-disk encryption apps may leverage different algorithms or modes of operation than the ones we'll be looking at. Such problems tend to be more specific to a certain domain or type of application, and if you are building a solution that requires them, you might need to perform some additional research or work with a cryptographer.

What this book is about – and what it's not

This book is about the practical uses of common cryptographic operations that software developers without a background in cryptography can leverage.

In each chapter, we'll present a specific class of cryptographic operations, and for each, we'll then look at the following:

What it's used for and what it should not be used for.What the most common algorithms are that developers should use.Considerations on what parameters to set for using the algorithms safely, when appropriate.Lastly, we'll look at sample code implementing the specific algorithms, written in JavaScript for execution on Node.js (with a nod to cryptography in the browser in the last two chapters).

Just as we have covered what this book is about, it's important to also mention what this book is not about, listing four things that you will not be learning in the following chapters:

First, this book is not about how cryptographic algorithms work, or a description of the algorithms themselves.

As we've mentioned many times already, our book's goal is not to train cryptographers but rather to help developers build better applications leveraging common cryptographic algorithms. In this book, you will not encounter formal descriptions of the algorithms and their flows, the mathematical models behind them, and so on.

Second, following on from the previous point, we will be looking at how to use cryptographic algorithms and not at how to implement them.

The latter not only requires a deep understanding of how algorithms work but is also a dangerous minefield because of the risks associated with poor implementations. At the risk of sounding hyperbolic, an entire class of attacks could be made possible by doing things as common as using if statements in code implementing a cryptographic algorithm.

In short, we'll leave the implementation to the experts, and we'll stick to using pre-built libraries. Whenever possible, that will be the built-in standard library of Node.js.

Third, as mentioned previously, this book is about strong, modern cryptography only. We'll focus on a limited set of widely adopted algorithms and functions that have been "battle-tested" and are generally deemed safe by cryptographers (more on what "safe" means in the next section). Simple or historical ciphers, codes, and so on might be interesting to those wanting to learn the science of cryptography or looking for brain-teasers, but are of little practical relevance for our goal.Fourth, we will not be talking about the other kind of "crypto", that is, cryptocurrencies. While Bitcoin, Ethereum, and the like are indeed based on the blockchain technology, which makes extensive use of cryptography (especially hashing and digital signatures), that's where the commonality ends. Nevertheless, should you be interested in learning about how blockchains work in the future, the concepts you'll learn from this book will likely be of use to you.

Rules of engagement

Lastly, before we begin, it's important to point out that cryptography is hard; making mistakes is surprisingly easy, and finding them can be really challenging. This is true even for expert cryptographers!

You'll often hear two very strong recommendations that are meant to keep you and the applications you're building safe. If you allow me, I propose that we turn them into a kind of "Hippocratic oath," which I invite you to repeat after me:

I will not invent my own cryptographic algorithms.I will not roll my own implementation of cryptographic algorithms.

Thankfully for us, a lot of very brilliant cryptographers have worked for decades to design strong algorithms and implement them correctly and safely. As developers, the best thing we can do is to stick to proven, tested algorithms, and leverage existing, audited libraries to adopt them. Normally, that means using whatever is available on the standard library of the language you're using, the APIs exposed by the operating system or runtime environment, or leveraging well-known, audited libraries.

As we've now introduced the topic and the goals of this book, and hopefully convinced you of the importance of adopting cryptography in your applications, we're now ready to get started with our learning, starting with setting some shared understanding.

Defining "safe"

An important concept when we deal with cryptography is to define what "safe" means in this context.

As a rule of thumb, possibly every cryptographic algorithm can be broken, given a sufficient amount of computing power and time.

For simplicity, we'll focus the next examples on data encryption, although the same would apply to all other classes of cryptographic operations.

The goal of using cryptography is to make sure that the effort (computing power multiplied by time) is too big for an attacker to attempt to break your encryption. Assuming that the algorithms you use do not have flaws in their design or backdoors that can be exploited, the only way attackers can crack your encryption is by doing a brute-force attack.

A brute-force attack works by trying every single combination possible until you find the right one. For example, if you were trying to break a padlock with 3 digits, each from 0 to 9, you'd have 1,000 different combinations (000, 001, 002… until 999), and the correct one would be one of those. On average, it would take you 500 attempts before you could find the right one (the number of possible permutations divided by 2). If every attempt takes you 3 seconds to try, then you can expect to be done in 1,500 seconds on average, or 25 minutes.

In theory, brute force can break any encryption. The goal is to use encryption that is strong enough to make it impractical to break it using a brute-force attack.

For example, AES-128 (a symmetric cipher) uses a 128-bit key, which means that there are 2128 possible combinations, or 340,282,366,920,938,463,463,374,607,431,768,211,456;that is, approximately 3.4 x 1038. That is a very large number that ought to be put into perspective.

Getting Perspective

One of the largest computing grids in the world today, if perhaps not the largest, is the network of all the Bitcoin mining grids. In 2021, the Bitcoin network reached an estimated peak hash rate of 180 million terahashes per second, which would translate to being able to compute about 292 hashes per year. This is a metric that is commonly used to indicate how much compute power is being used by the network.

Imagine a hypothetical scenario in which all Bitcoin miners agreed to get together and convert the entire grid to brute-force a 128-bit key. If they managed to attempt 292 keys per year, it would still take them an average of 235 years, or over 1010 years, to complete the attack (2128 possible keys, divided by 292 keys attempted per year, divided by 2 to get the average time). That's roughly the same as the age of the universe, which is estimated to be around 14 billion years old, or about 1010.

Of course, computing power increases constantly, so the time it will take to break cryptography in the future will be less.

Quantum computing will also make it easier to break certain kinds of cryptography, although those systems are still experimental today and not yet powerful enough for most practical applications (nevertheless, cryptographers are already preparing for that future today, by designing stronger "post-quantum" algorithms).

That said, our goal should always be to choose algorithms that are guaranteed to protect our data for at least as long as it's necessary. For example, let's say you encrypt a document containing the password of your online banking account today; if technological innovation allowed an attacker to crack it in "only" 100 years from now, it might not matter to you at that point, as you'll most likely be dead by then.

Given the aforementioned context, an algorithm should be considered "broken" when it's possible to crack it in a way that is significantly faster than using a brute-force attack.

Most cryptographic algorithms that we use today are safe in this sense because the only possible attacks against them are brute-force ones, which as we've seen are just not practical.

How Cryptography Is Broken – the Example of Frequency Analysis

At the beginning of this chapter, we looked at some historical ciphers and explained that they were broken. Substitution ciphers are among the oldest and simplest ones, and they rely on replacing every letter of the alphabet with another one. For example, in the Caesar cipher, letters are shifted by three, so A is replaced with D, B with E, and so on. While this may have been effective to protect messages from the illiterate enemy soldiers of the era, it looks trivial today.

Substitution ciphers that rely on the shifting of letters can be broken in a fairly simple way with brute-force attacks, even manually (assuming, of course, that the attacker knows that the cipher works by shifting letters). With only 26 letters in the English alphabet, it takes at most 25 attempts to find the number by which characters are shifted.

A more complex substitution cipher could instead create a new alphabet in which letters are randomly shuffled. So, the letter A may be replaced with X, B with C, and D with P. With the English alphabet, there are 26! (26 factorial) possible combinations, or about 1026, offering a decent amount of protection against brute-force attacks, even against an adversary that can use modern computers.

However, through cryptanalysis (the science of studying cryptographic systems looking for weaknesses), even those more "advanced" substitution ciphers have been broken, through a technique called frequency analysis. This works by looking at the frequency of letters (and pairs of letters) in the encrypted text and comparing that with the average frequency of letters in English writing. For example, "E" is the most frequently used letter in English text, so whatever letter is the most used in the encrypted text will likely correspond to "E."

While cryptanalysis is certainly not something we'll focus on in this book, this mention will hopefully provide an insight into one of the (many) ways algorithms can be broken.

With an understanding of how encryption helps protect data and a contextualization of what it means for data to be "safe," we now need to look at the multiple ways that data can be encrypted.

Types and "layers" of encryption

Before we begin talking about data encryption throughout this book, we should clarify the various types of data encryption and the layers at which data can be encrypted.

First, with regards to types, it's useful to distinguish between these three:

Encryption at rest