How to generate Stellar keys

Francesco Ceccon — Thu, 14 Jan 2021 17:41:55 +0000

What is a key pair?

Stellar keys are used to authenticate and identify users on the network. Stellar accounts are uniquely identified by their public key, also known as account id. A Stellar account id is a string that starts with the letter G, this key is safe to share with others. Accounts are controlled using a secret key seed, a string starting with S, and they should never be shared with other people or applications. The secret key seed is used to derive the private key. A private key and a public key together are known as a key pair. The private key is used to sign operations that modify the Stellar account state on the ledger.

Generate key pairs with one of the SDKs

Now that we know what is a key pair and what it is used for, we can see how to generate it using four different SDKs.

Javascript

The stellar-base package is officially maintained by the Stellar Development Foundation and is available on npm.

import { Keypair } from "stellar-base";

// Generate random key pair
Keypair.random();

// Generate key pair from secret
Keypair.fromSecret("SA6KO...PRET");

// Generate key pair from account id
Keypair.fromPublicKey("GBMZ...ZPJK");

Rust

The stellar-base crate provides low-level Stellar types, including key pairs. You can fetch it directly from crates.io. The Rust SDK provides a KeyPair type that contains both the private and public keys, and a PublicKey type that contains only the public key. With this API design, it’s impossible to accidentally sign a transaction with a key pair that was constructed from the public key only.

use stellar_base::crypto::{KeyPair, PublicKey};

// Generate random key pair
KeyPair::random()?;

// Generate key pair from secret
KeyPair.from_secret_seed("SA6KO...PRET")?;

// Generate public key from account id
PublicKey::from_account_id("GBMZ...ZPJK")?;

C

The dotnet-stellar-sdk is a C# library to interact witth the Stellar ecosystem. It can be used in any language that targets .NET Standard 2.0 or above.

using stellar_dotnet_sdk;

// Generate random key pair
KeyPair.Random();

// Generate key pair from secret
KeyPair.FromSecretSeed("SA6KO...PRET");

// Generate key pair from account id
KeyPair.FromAccountId("GBMZ...ZPJK");

Python

The Python stellar-sdk is available on PyPi and can be installed with pip.

from stellar_sdk import Keypair

# Generate random key pair
Keypair.random();

# Generate key pair from secret
Keypair.from_secret("SA6KO...PRET");

# Generate key pair from account id
Keypair.from_public_key("GBMZ...ZPJK");

What’s happening behind the scenes?

Stellar uses the EdDSA signature scheme for its transactions. A private key starts its life as a 32 bytes seed that is then used to generate the private key itself. The public key can be derived from the private key or created directly from a buffer of 32 bytes. I’m not going into too much detail how the private and public keys are derived, if you’re interested you can find more in this excellent blog post by Brian Warner.

Going from a Stellar account id to a public key is very simple, you start by decoding the account id (a string starting with G) as base32 and obtaining a buffer of 35 bytes. The first byte contains information about the type of key (secret seed, account id, pre-authorized transaction, or hash(x)), the next 32 bytes contain the key itself (or the secret key seed), finally the last 2 bytes contain the key checksum. Stellar uses CRC-16 XMODEM for the checksum of bytes 1 to 32.

The process to compute a Stellar account id from a public key is similar, we concatenate the version byte with the public key bytes to obtain a 33 byte long payload. We then compute the 16 bit CRC of the payload. Finally, we concatenate the payload and its checksum and encode it using base32.

Pulumi first impression

Francesco Ceccon — Fri, 01 Jan 2021 15:41:42 +0000

Pulumi changed how I approach infrastructure and how I build web applications.

Pulumi is a tool for Infrastructure as Code, its selling point is that it uses a real programming language to describe infrastructure.

With Pulumi, you build cloud environments by specifying the resources you need and combining them together. Because Pulumi uses Typescript (or Python or any .NET language), you can create your own abstractions and use that to reduce the amount of code needed to describe your infrastructure.
Pulumi is not limited to cloud resources, you can use it to describe Kubernetes resources. This means that you can use the same language to describe the resources outside the control of Kubernetes (the Kubernetes cluster itself, but also managed databases, and pub/sub queues) and the Kubernetes resources such as deployments, services, and even custom resources.
Once you described what you need, the Pulumi engine will process your requirements and present you with a change plan, which you can accept and apply to your project. By default, Pulumi stores its state on the Pulumi Service backend. However, this behavior can be changed and you can store the state on the usual suspects (Amazon S3, Google Cloud Storage, Azure Blob Storage) or your local file system.

Infrastructure as Code is a way to encode your knowledge about infrastructure in code. This means that when you come back to a project months later, you can see at a glance what resources it uses and any non default settings.
Because resources are linked to each other by their inputs and outputs, you can also see which resources are dependent on other resources. Pulumi even provides a web interface where you can visually see this dependency graph between resources.

Pulumi is not the only project that aims to describe infrastructure as code, the most prominent project is HashiCorp Terraform. There are some (many) differences between Terraform and Pulumi, and depending on your preferences you may like one or the other more (or none, IaC is not everyone's thing!).
The most noticeable difference is that Terraform uses its own Domain Specific Language (DSL) to describe resources, while Pulumi uses Typescript. The trade-off in using a general purpose language is that, while you gain in expressiveness, you introduce the ability to generate non-deterministic resource graphs, which will result in broken deployments. This is solved by using Pulumi provided libraries to generate, for example, pseudo random data.

Pulumi real killer feature is, however, being able to generate Kubernetes configuration directly together with the rest of infrastructure. This is a much superior approach than what is available for Terraform, which is using a separate tool to generate Kubernetes templates and deploying them.

Since discovering Pulumi I changed how I build applications completely, before that I was not sold on serverless since deploying the functions and managing the API gateway requires a lot of configuration. Pulumi makes this completely manageable, to make it even simpler they provide packages containing common abstractions used when building serverless applications.

After using Pulumi for just over one year it already changed how I approach building applications: I'm no longer reluctant to introduce dependencies on cloud resources since I know I can spin them up with a single command, and serverless has become my go-to tool when I need to create simple web services.

DEV Community: Francesco Ceccon