Why a 202-Character License Key Uses ECDSA P-256 Instead of Ed25519 or RSA

A developer building offline license verification for a .NET desktop application evaluated Ed25519, RSA, and ECDSA P-256 before selecting the last option. The decision was driven by the requirement for zero external dependencies, keys short enough for manual entry from email, and support for key rotation without breaking existing licenses. Although Ed25519 offers faster verification and a smaller public key, it is absent from System.Security.Cryptography in both .NET 8 and .NET 10, with API approval only targeted for version 11. RSA-2048 produces signatures too long for practical use, resulting in a 571-character Base32 string that users would find cumbersome. ECDSA P-256 with SHA-256 delivers a fixed 64-byte signature that becomes a manageable 202-character key when encoded in Base32, while remaining fully available in the runtime. The article also covers performance measurements, the risks of ECDSA nonce generation, and the deliberate choice of the IEEE P1363 signature format to guarantee fixed-length output.

HabrJuly 28, 2026Translated from Russian

Read at source

A developer needed to implement offline license key verification for a desktop application written in .NET. The license string had to work without an internet connection, contain no third-party dependencies, remain short enough for manual typing from an email, and support key rotation if the private key were ever compromised.

The first choice was Ed25519 because of its compact size, speed, and deterministic signatures. However, reflection over System.Security.Cryptography in both .NET 8.0.28 and .NET 10.0.9 showed that no Ed25519 or Curve25519 types are exposed. The only asymmetric primitives available are DSA, ECDsa, ECDiffieHellman, and RSA, together with the NIST P-256, P-384, P-521, and Brainpool named curves. Post-quantum algorithms such as ML-DSA and SLH-DSA appear only in .NET 10.

Attempts to create an Ed25519 curve with ECDsa.Create(ECCurve.CreateFromFriendlyName("Ed25519")) throw a PlatformNotSupportedException. An open GitHub issue requesting Ed25519 support has been open since 2015, with the approved API now scheduled for .NET 11.

Adding external libraries was considered next. BouncyCastle 2.6.2 adds a single 4.7 MB managed assembly, while NSec 24.4.0 brings a 92 KB wrapper plus native libsodium binaries. The latest NSec release refuses to install on .NET 8, illustrating the risk that a dependency’s platform support schedule may diverge from the application’s own lifecycle.

Benchmarks on an AMD Ryzen 7 5800H running .NET 8 Release showed the following verification times for a 39-byte payload: ECDSA P-256 at 191 µs, Ed25519 via BouncyCastle at 77 µs, and Ed25519 via NSec at 91 µs. RSA-2048 verification was fastest at 16 µs, yet its 256-byte signature expands to 571 Base32 characters—far too long for comfortable manual entry.

Encoding the 64-byte ECDSA signature plus payload in Base32 with groups of five characters separated by hyphens produces a 202-character key. This length is the shortest mathematically possible for an offline scheme that must embed both the license data and a cryptographically strong signature.

ECDSA signatures were recorded in IEEE P1363 format (r‖s) to guarantee a fixed 64-byte length; the DER format produces variable lengths between 69 and 72 bytes. The public key is stored inside the application as raw 64-byte coordinates rather than the full 91-byte SubjectPublicKeyInfo structure, reducing the embedded constant to 88 characters.

The chosen algorithm carries two acknowledged drawbacks. ECDSA signature generation depends on a high-quality random nonce; reuse or predictability can leak the private key. In addition, the same license data signed twice yields different strings, requiring the license registry to tolerate duplicates. These risks were accepted because signing occurs on a single offline machine using the operating system’s RNG, and the threat model is limited to protecting a commercial desktop application rather than high-value secrets.

BouncyCastle NSec libsodium ECDSA P-256 ML-DSA NIST P-256

ShareX Facebook LinkedIn Reddit

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Other

Other

Mail.ru Reduces Lifetime 1TB Cloud Storage Promo to Standard 8GB Quota for Select Users

Mail.ru has begun notifying a small group of long-term Cloud Mail users that their complimentary 1TB storage, originally granted through a 2013-2014 app installation promotion, will be reduced to the standard 8GB free tier. Affected users receive personalized deadlines, with some facing storage limits starting 30 October and final deletion of excess files scheduled for 30 January 2027. The company confirmed the change impacts fewer than 0.5 percent of Cloud Mail users and stated that core free features remain available. Once the 8GB limit is exceeded, uploads, edits, and sharing are blocked while users have three months to download data or purchase additional space before files move to the trash for 14 days prior to permanent removal. This follows a similar reduction of lifetime 100GB storage performed by the service in 2024.

AntiMalwareOct 29, 2026Translated from Russian

Other

Kimi K3 Open Model Surpasses Closed AI Leaders with Million-Token Context and 896 Experts

Kimi K3 is an open-weights model that outperforms closed systems from GPT and Anthropic on several independent benchmarks. Developers achieved this by scaling three dimensions simultaneously: one million tokens of context, deeper layers, and 896 Mixture-of-Experts specialists. The team replaced the standard KV-cache with a fixed-size state matrix updated via the delta-rule, solving numerical instability by clamping the forgetting coefficient alpha between e^-5 and 1. Sequential state updates were parallelized across chips, GPUs, and multi-GPU nodes using the open-source FlashKDA kernel built on CUTLASS. Inter-layer information flow was preserved through learned pseudo-queries that selectively retrieve relevant outputs from prior blocks rather than passing full activations. Load balancing across 896 routed experts uses per-expert quantile thresholds and a distributed histogram method to guarantee fair token allocation without full sorting.

HabrOct 29, 2026Translated from Russian

Other

Innostage Completes Functional Testing of PT NGFW 1.10.3 Across 156 Criteria

Innostage has published the second part of its evaluation of PT NGFW version 1.10.3, focusing on functional capabilities rather than raw performance. The testing covered 156 individual checks grouped into categories such as basic technical features, firewalling, IDS/IPS, web filtering, malware protection, logging, routing, deployment, cryptographic controls and access management. Out of the total, 136 checks passed fully, seven passed with remarks, and 13 did not meet the predefined criteria. Key confirmed functions include high-availability clustering, centralized management via PT-MNGT, AD-based rule application, Site-to-Site VPN, TLS inspection, and Syslog integration with external security systems. Several advanced scenarios, including custom block pages, application risk classification, and centralized software distribution, were not confirmed under the test conditions. The report provides detailed protocol notes that help organizations map product capabilities against their specific infrastructure and regulatory requirements.

HabrOct 29, 2026Translated from Russian