Derive strong name key pairs deterministically from a seed instead of a static .snk

[Copilot]

Previously Snek shipped a single static Snek.snk, giving every consuming assembly the exact same public key token. This replaces it with a key pair generated deterministically from a seed at build time — same seed always yields the same key, different seeds yield different keys.

Usage

<PropertyGroup>
  <AssemblyOriginatorKeySeed>my-custom-seed</AssemblyOriginatorKeySeed>
</PropertyGroup>

[Tyrrrz]

@copilot some review comments

[Tyrrrz]

@copilot

[Tyrrrz]

@copilot

[Copilot]

Copilot review overview

🔵 Needs a closer look

Key generation can hang, produce undersized moduli, and vary across runtime byte orders.

Review effort: Balanced
Findings: None

What changed in this PR

Replaces Snek’s shared static signing key with keys derived deterministically from a configurable seed.

Changes:

• Adds deterministic RSA key generation and build-time caching.
• Integrates key generation into MSBuild and the demo.
• Documents seed configuration and removes the static-key workflow.

File	Description
Snek/​StrongNameTask.cs	Generates and caches key files.
Snek/​StrongNameKeyPair.cs	Implements seeded RSA key generation.
Snek/​Snek.targets	Resolves seeds and invokes generation.
Snek/​Snek.props	Registers the signing task.
Snek/​Snek.Local.props	Configures local task assembly paths.
Snek/​Snek.csproj	Packages targets instead of the static key.
Snek/​SeededRandom.cs	Adds a hash-based deterministic byte generator.
Snek.Demo/​Snek.Demo.csproj	Imports local signing integration.
Readme.md	Documents derived keys and custom seeds.
Directory.Packages.props	Updates PolyShim.
.github/​workflows/​snk.yml	Removes manual static-key generation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Tyrrrz]

@copilot is the modulus issue an easy fix? And how likely that it's going to manifest in a real environment?

As for endianess, BinaryPrimitives has methods with explicit endianess, can we use that?

[Copilot]

@copilot is the modulus issue an easy fix? And how likely that it's going to manifest in a real environment?

As for endianess, BinaryPrimitives has methods with explicit endianess, can we use tha...

Yes, it’s a small fix: for the big-endian input, set bytes[0] |= 0b1100_0000; for oddness, set bytes[^1] |= 1. With the current code, each generated prime is about equally likely to be 511 or 512 bits, and the resulting modulus is 1024 bits only about 15% of the time; most are 1022–1023 bits. It will still generally function, but it doesn’t meet the stated 1024-bit size. BinaryPrimitives.WriteInt64BigEndian is the right way to make the counter encoding explicit; for netstandard2.0/net472, it may require a compatible System.Memory compile reference if one isn’t already available. Either fix changes derived keys, so it’s best to settle it before release.

[Tyrrrz]

@copilot let's do that. The BinaryPrimitives method should be available uniformly via PolyShim.

[Copilot]

@copilot let's do that. The BinaryPrimitives method should be available uniformly via PolyShim.

Implemented in commit $(git rev-parse --short HEAD): corrected the prime byte masks and used BinaryPrimitives.WriteInt64BigEndian for the seed counter. Both target frameworks and the demo build pass.