Skip to main content
Cryptographic keys are fundamental to blockchain security. hive-tx provides complete implementations of Hive’s key system through the PrivateKey, PublicKey, and Signature classes.

Key Hierarchy

Hive uses ECDSA (secp256k1) keys, the same cryptographic system as Bitcoin. Each account has multiple key types with different permission levels:
1

Owner Key

Highest authority. Used to change all other keys and recover accounts. Keep this offline and secure.
2

Active Key

Financial authority. Required for transfers, powering up/down, and account updates.
3

Posting Key

Content authority. Used for voting, posting, following, and other social actions. Safe for apps.
4

Memo Key

Encryption authority. Used to encrypt/decrypt transfer memos. Not used for signing transactions.
Never share your private keys with untrusted applications. Posting keys are safer for apps since they can’t access funds.

PrivateKey Class

The PrivateKey class handles all private key operations: creation, signing, and key derivation.

Creating Private Keys

From WIF String

Wallet Import Format (WIF) is the standard way to store and transmit private keys:
src/helpers/PrivateKey.ts:57

Generate Random Key

Create a cryptographically secure random key:
src/helpers/PrivateKey.ts:179
Random key generation may take up to 250ms due to secure entropy collection. This is normal and ensures cryptographic security.

From Seed

Derive a key from a seed string or bytes:
src/helpers/PrivateKey.ts:83
The seed is hashed with SHA256 to produce the 32-byte private key.

From Login Credentials

Generate keys from username and password using Hive’s standard derivation:
src/helpers/PrivateKey.ts:105
This uses the formula: SHA256(username + role + password)
Login-based keys match what Hive wallets generate. This is perfect for apps that authenticate with username/password instead of storing WIF keys.

Signing Messages

Sign a 32-byte hash to create a recoverable signature:
src/helpers/PrivateKey.ts:117
The sign() method expects a 32-byte hash, not the raw message. Always hash your message first with SHA256.

Deriving Public Keys

Every private key has a corresponding public key:
src/helpers/PrivateKey.ts:133
Optionally specify a custom address prefix:

Exporting Private Keys

As WIF String

src/helpers/PrivateKey.ts:143

Safe Logging

For debugging without exposing the full key:
src/helpers/PrivateKey.ts:154
Only the first and last 6 characters are shown.

Shared Secrets for Encryption

Compute ECDH shared secrets for memo encryption:
src/helpers/PrivateKey.ts:166
Both parties derive the same shared secret:
  • Alice: alicePrivate.getSharedSecret(bobPublic)
  • Bob: bobPrivate.getSharedSecret(alicePublic)
This enables encrypted memos that only the sender and receiver can read.
The shared secret is SHA512(ECDH(privateKey, publicKey)). The parity byte is stripped before hashing.

PublicKey Class

Public keys are derived from private keys and used for signature verification and encryption.

Creating Public Keys

From String

src/helpers/PublicKey.ts:30

From Private Key

Verifying Signatures

Check if a signature is valid for a given message:
src/helpers/PublicKey.ts:54
You can pass either a Signature object or a hex string:

Exporting Public Keys

src/helpers/PublicKey.ts:68

Signature Class

Signatures prove that a message was signed by a specific private key.

Creating Signatures

From Signing

From Hex String

src/helpers/Signature.ts:28
Signatures are 130 hex characters (65 bytes):
  • 1 byte: Recovery ID (allows public key recovery)
  • 64 bytes: ECDSA signature (r, s values)

Signature Format

As Hex String

src/helpers/Signature.ts:65

As Buffer

src/helpers/Signature.ts:50

Recovering Public Keys

Signatures are “recoverable” - you can extract the public key that created them:
src/helpers/Signature.ts:75
You can pass either a Uint8Array hash or a 64-character hex string:
Signature recovery is how Hive nodes verify transactions without storing public keys separately. The signature itself contains enough information to derive the signer’s public key.

Key Formats

Private Key (WIF)

Wallet Import Format includes network ID and checksum:
Encoding: base58(0x80 + 32-byte-key + 4-byte-checksum)

Public Key

Includes address prefix and checksum:
Encoding: prefix + base58(33-byte-compressed-key + 4-byte-checksum)

Signature

130-character hex string:

Security Best Practices

  • Never hardcode private keys in source code
  • Use environment variables or secure key management systems
  • Encrypt keys at rest with strong passwords
  • Use hardware wallets for owner/active keys when possible
  • Use posting keys for apps when possible (can’t access funds)
  • Never send private keys over unencrypted connections
  • Validate key formats before using them
  • Clear key data from memory after use in sensitive contexts
  • Keep owner keys offline and secure (paper wallet, hardware wallet)
  • Use active keys only for financial operations
  • Share posting keys with trusted apps for convenience
  • Rotate keys periodically, especially if compromised
  • Use testnet accounts for development
  • Never commit real keys to version control
  • Use .env files with .gitignore for local development
  • Audit dependencies that handle keys

Complete Example

Here’s a complete workflow showing key generation, signing, and verification:

Next Steps

Transactions

Use keys to sign transactions

Operations

Learn which operations need which keys

Memo Encryption

Encrypt transfer memos

PrivateKey API

Full API reference