Public and Private Keys in Precog

Overview

Public and private keys are used to secure many integrations in Precog, including destinations such as Snowflake that support key-pair authentication. Understanding what these keys are—and how they work together—helps you know which keys can be shared safely and which must remain confidential.

Public-key cryptography (also known as asymmetric encryption) is the foundation of this security model. It uses two mathematically linked keys that perform opposite but complementary functions.

The Key Pair Concept

A key pair consists of:

  • A public key, which can be shared openly and is used to verify identity or encrypt information.
  • A private key, which must remain secret and is used to prove identity or decrypt information.

Even though the two keys are related, the private key cannot be derived from the public key. This one-way relationship makes it possible to exchange information securely, even across untrusted networks.

How Key Pairs Secure a Connection

  1. When Precog connects to an external system that requires key-pair authentication, the public key is registered with that system in advance. The private key remains securely stored under your organization's control.

  2. When a secure connection begins, Precog uses the private key to prove its identity. The destination compares that identity against the stored public key. If they match, the connection is trusted—without ever exposing the private key itself.

This process ensures that authentication is both strong and confidential.

Why It Matters

  • Public keys are safe to share and are often required when setting up secure connections or registering applications.
  • Private keys must always remain confidential. If a private key is exposed, anyone could impersonate your system or decrypt your data.

Recognizing which key is which helps you:

  • Avoid sharing sensitive credentials by mistake.
  • Confirm that the correct key is used when configuring integrations.
  • Review screenshots or tickets without leaking confidential material.

Recognizing Key Formats

Most encryption keys follow consistent patterns in how they are stored and displayed. They may include header and footer lines, or appear as a long block of encoded text.

Common header phrases include:

  • BEGIN PUBLIC KEY — a general format for public keys
  • BEGIN PRIVATE KEY — a general format for private keys
  • BEGIN RSA PRIVATE KEY — an RSA-based key
  • BEGIN EC PRIVATE KEY — an elliptic-curve-based key

If you see RSA in the header, the key uses the RSA algorithm. If you see EC, it uses elliptic-curve cryptography. If it simply says PUBLIC KEY or PRIVATE KEY, it uses a general format that can contain any algorithm type.

Recognizing Keys Without Headers

Sometimes the surrounding header lines are removed, leaving only the encoded text. Even without those lines, the beginning characters can help you identify the key type:

  • RSA public keys often begin with MIIBI and are shorter.
  • RSA private keys often begin with MIIE and are much longer.
  • EC or Ed25519 keys are shorter and may begin with MFkwE, MCowB, MIGH, or MIGT.

These patterns come from how encryption data is structured internally. Over time, recognizing these visual cues becomes second nature.

Quick Visual Cues

  • Public keys are usually shorter and may include "PUBLIC" in their header.
  • Private keys are longer and may reference the algorithm, such as RSA or EC.
  • Elliptic-curve keys sometimes include the curve name (for example, P-256 or secp256r1).
  • If a key includes "PRIVATE," it should never be shared or attached to support tickets.

✅ Summary

Public–private key pairs form the foundation of secure communication. A public key identifies you to external systems; a private key proves that identity is authentic. Being able to recognize each type—especially when working with destinations that use key-pair authentication—helps you keep sensitive data protected while maintaining secure, reliable integrations in Precog.