The State of Cryptography

Cryptographic library adoption across 11 package ecosystems

Updated October 6, 2026Package scan collected August 3, 2026 (85 days ago).DOI 10.5281/zenodo.21791658MethodologyResearch dataset

Summary

184:1downloads of weak-classed libraries for every 1 download of a post-quantum library

Monthly downloads of libraries the catalogue classes as weak against downloads of catalogued post-quantum libraries, in the six registries whose download counts are measured or rescaled. The weak figure includes libraries that the corrected classes do not class as weak. The note in the Weak / Deprecated card, in the Downloads by class section, gives the size.

Weak / Deprecated

985.5M
downloads / month
15.4%

Modern / Current-Gen

5.4B
downloads / month
84.5%

Post-Quantum

5.3M
downloads / month
0.083%

The PQC gap

Shares of monthly downloads by class, in the six registries whose download counts are measured or rescaled. Select a segment for details.

Modelled figures, 768,854,764 downloads a month, are not in the bar.

At least 259,647,142 of the 985,475,954 monthly downloads counted as weak are of libraries that the corrected classes, not yet applied to these figures, do not class as weak.

1,527
Days until the end of 2030
112-bit classical public-key algorithms deprecated in the draft
3,353
Days until the end of 2035
Classical public-key algorithms disallowed in the draft

From NIST IR 8547 (initial public draft, November 2024), which can change before it is final.

355
Crypto libraries tracked
6.4B
Measured downloads / month
+ 768.9M modelled
11
Ecosystems
2.17M
Packages listed
at least 37,242 not read
How we classify
Weak
Modern
PQC
More
Weak / Deprecated

Libraries the catalogue classes as weak. The class mixes libraries that implement broken algorithms with libraries that are deprecated or unmaintained, and it holds libraries that the corrected classes do not class as weak. The corrected classes are not yet applied to the figures on this page.

e.g. broken algorithms such as MD5, SHA-1, DES, 3DES, RC4, Blowfish

Modern / Current-Gen

Actively maintained cryptographic libraries using current-generation algorithms. Includes both quantum-safe symmetric crypto (AES-256, SHA-256, ChaCha20) and quantum-vulnerable asymmetric crypto (RSA, ECDSA, Ed25519). The public-key algorithms in this tier are the ones NIST's draft IR 8547 would deprecate, at 112 bits of security strength, and then disallow.

e.g. AES-GCM, SHA-256, ECDSA, Ed25519, Argon2, bcrypt

Post-Quantum

Implementations of NIST-standardized post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) that resist both classical and quantum attacks. NIST's draft IR 8547 names them as the algorithms to migrate to.

e.g. ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+)

Note: The "Modern" tier includes both quantum-safe symmetric crypto (AES-256, SHA-256) and quantum-vulnerable asymmetric crypto (RSA, ECDSA). The dates in NIST's draft IR 8547 apply to the public-key algorithms only. The draft gives no such date for symmetric ciphers and hash functions that provide at least 128 bits of security.

Downloads by class

Weak / Deprecated

Libraries the catalogue classes as weak (broken algorithms such as MD5, SHA-1, DES, 3DES, RC4, Blowfish)
985.5M
downloads / month
+ 63.6M modelled
15.4%
of downloads in the six measured and rescaled registries

At least 259,647,142 of the 985,475,954 monthly downloads counted in the weak class, in the registries whose download counts are measured or rescaled, are of libraries that the corrected classes, not yet applied to these figures, do not class as weak or take out of the count; node-forge is the largest.

What stays of the present weak class is therefore at most about 11.3% of the 6,412,637,885 downloads in those registries, not 15.4%. That bounds the present class and is not the weak share under the corrected classes: the catalogue's other 263 entries have not been checked against them. Over all registries, modelled counts included, the bound is about 10.9%, against 14.6%.

Every figure computed from weak downloads inherits this, including the weak-to-post-quantum ratio.

Modern / Current-Gen

Current-generation, maintained implementations (AES-GCM, SHA-256, ECDSA, Ed25519, Argon2, bcrypt)
5.4B
downloads / month
+ 703.2M modelled
84.5%
of downloads in the six measured and rescaled registries

Post-Quantum

Quantum-resistant per NIST FIPS 203/204/205 (ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+))
5.3M
downloads / month
+ 2.0M modelled
0.083%
of downloads in the six measured and rescaled registries

Research insights

Findings

Weak to post-quantum download ratio

184:1

In the six registries whose download counts are measured or rescaled, there are 184 downloads of libraries the catalogue classes as weak for every download of a catalogued post-quantum library. The two classes are not substitutes: post-quantum algorithms replace public-key algorithms such as RSA and ECDSA, not symmetric ciphers or hashes. The weak figure includes libraries that the corrected classes do not class as weak. The note in the Weak / Deprecated card, in the Downloads by class section, gives the size.

Downloads of weak-classed libraries

15.4%

15.4% of the monthly downloads in the six registries whose download counts are measured or rescaled, 985,475,954 of 6,412,637,885, are downloads of libraries the catalogue classes as weak.

At least 259,647,142 of the 985,475,954 monthly downloads counted in the weak class, in the registries whose download counts are measured or rescaled, are of libraries that the corrected classes, not yet applied to these figures, do not class as weak or take out of the count; node-forge is the largest.

What stays of the present weak class is therefore at most about 11.3% of the 6,412,637,885 downloads in those registries, not 15.4%. That bounds the present class and is not the weak share under the corrected classes: the catalogue's other 263 entries have not been checked against them. Over all registries, modelled counts included, the bound is about 10.9%, against 14.6%.

Every figure computed from weak downloads inherits this, including the weak-to-post-quantum ratio.

Downloads of post-quantum libraries

0.083%

Libraries dedicated to post-quantum algorithms account for 5,346,766 of 6,412,637,885 monthly downloads (0.083%) in the 6 registries whose download counts are measured or rescaled. 5 of those registries record any.

Security advisory severity distribution

3 of 2,000 reviewed

Of 3 crypto-related advisories among the 2,000 most recently reviewed GitHub advisories: 1 critical, 0 high, 2 medium, 0 low.

Largest modern-classed package by downloads

1.1B/mo

cryptography (PyPI) has the largest download count among modern-classed packages with a measured or rescaled count: 1.1B a month.

Downloads by registry

Monthly downloads of catalogued libraries in the 10 registries with a download figure; none exists for CocoaPods. A modelled or rescaled figure is marked beside its registry. Shares by class are withheld until the corrected classes are applied.

npm
2.9B
downloads / month
View npm packages
jose578.6M
@noble/hashes374.2M
jsonwebtoken243.0M
node-forge167.6M
tweetnacl158.0M
@noble/ciphers140.4M
@noble/curves138.3M
sha.js93.3M
PyPI
2.5B
downloads / month
View PyPI packages
cryptography1.1B
PyJWT564.9M
rsa186.8M
pynacl160.1M
bcrypt149.4M
paramiko102.2M
pycryptodome67.7M
argon2-cffi59.5M
Go Modules(modelled)
231.7M
downloads / month
View Go Modules packages
crypto/tls38.0M
crypto/rand25.0M
crypto/aes22.0M
crypto/sha25618.0M
crypto/cipher16.0M
crypto/x50915.0M
crypto/hmac14.0M
crypto/ecdsa12.0M
Maven Central(modelled)
183.2M
downloads / month
View Maven Central packages
software.amazon.awssdk:kms89.0M
com.nimbusds:nimbus-jose-jwt14.7M
org.springframework.security:spring-security-crypto11.5M
io.netty:netty-handler11.4M
com.google.cloud:google-cloud-kms10.1M
org.signal:libsignal-client5.8M
com.squareup.okhttp3:okhttp4.8M
com.azure:azure-security-keyvault-keys4.3M
crates.io(rescaled)
947.2M
downloads / month
View crates.io packages
sha294.1M
rustls73.0M
zeroize64.1M
subtle58.3M
ring56.9M
hmac55.6M
sha153.8M
chacha2044.4M
Packagist
82.0M
downloads / month
View Packagist packages
firebase/php-jwt15.1M
paragonie/random_compat13.8M
phpseclib/phpseclib13.4M
lcobucci/jwt10.4M
spomky-labs/pki-framework7.6M
defuse/php-encryption6.4M
symfony/password-hasher6.1M
paragonie/sodium_compat4.3M
NuGet(modelled)
332.8M
downloads / month
View NuGet packages
Microsoft.IdentityModel.Tokens124.0M
System.IdentityModel.Tokens.Jwt112.7M
Microsoft.AspNetCore.DataProtection31.5M
Portable.BouncyCastle14.5M
BouncyCastle.Cryptography12.7M
MimeKit9.0M
Microsoft.Azure.KeyVault5.9M
Azure.Security.KeyVault.Keys3.4M
RubyGems(modelled)
21.2M
downloads / month
View RubyGems packages
jwt6.8M
bcrypt3.5M
net-ssh3.3M
rotp1.2M
ed255191.1M
encryptor1.0M
json-jwt921.2K
openssl822.9K
Hex(rescaled)
6.2M
downloads / month
View Hex packages
plug_crypto2.0M
jose1.1M
joken675.4K
comeonin643.6K
bcrypt_elixir478.5K
cloak296.1K
cloak_ecto242.4K
guardian219.2K
pub.dev
8.2M
downloads / month
View pub.dev packages
pointycastle4.0M
dart_jsonwebtoken1.9M
cryptography864.5K
encrypt789.8K
basic_utils249.3K
pinenacl212.6K
hashlib62.1K
cryptography_flutter61.1K

Package scan by ecosystem

2,170,994 packages were listed in the scan of August 3, 2026. 65,686 of them are counted as matching a catalogued cryptographic library. Three processing steps removed 19,287 other packages that matched before the counts were made. Counts by ecosystem follow. 11 of 11 rows carry known issues, shown when a row is selected.

In seven rows (npm, Go Modules, Maven Central, NuGet, RubyGems, Hex and pub.dev) the packages scanned are the first part of the registry's list, not a sample of the registry. Each of those rows states the order of its list.

Each class total is low by its part of the 19,287 packages the processing steps removed. The weak total also includes packages counted as weak only through libraries the corrected classes do not class as weak: re-aggregated under those classes, its 12,465 become between 10,749 and 10,809.

8 notes on these totals

The packages listed include at least 37,242 that were not read. crates.io counts only crates it read, and Hex only packages it read. RubyGems and pub.dev count every failed request. Hex, RubyGems and pub.dev report none. Whether any pub.dev answer came without a pubspec, which its scanner does not count as a failure, has not been verified.

De-duplication, first of three processing steps, kept one package per registry and normalized name: @a/utils and @b/utils would count as one. It dropped 13,081 of the 84,973 that matched, itself no corrected count; whether each is a separate project is not verified.

The second removed 439 by name alone, such as names ending in -test or under three characters.

The third kept one of any three or more packages in a registry sharing a class and a namespace, so Go modules of one class under github.com/hashicorp became one. It dropped 5,767.

By class, the 19,287 removed were 3,525 counted as weak, 15,702 modern-classed only and 60 post-quantum, so each of the three class totals is low by its part. The split is from the run's output, which is not public.

The weak class mixes libraries that implement broken algorithms with libraries that are deprecated or unmaintained, and holds libraries that the corrected classes do not class as weak. Re-aggregated under those classes, the 12,465 packages counted as depending on a weak library become between 10,749 and 10,809; the 60 between are counted as weak only through libraries whose status is not verified.

2,018 of the 65,686 packages counted as matching a catalogued library are counted only through catalogue entries that are being taken out of the count or through a path-prefix match.

The totals add rows scanned to different limits, so a share of a total is a mixture weighted by those limits and describes no registry: crates.io is 44.5% of the 65,686 packages counted as matching a catalogued library, and the seven rows whose packages are the first part of a registry's list hold 60.8% of the 12,465 counted as weak. The dataset's two shares, weakShareOfCryptoUsing and pqcShareOfCryptoUsing, are such mixtures and are not printed on the page.

12,465
packages counted as depending on a weak-classed library
52,868
packages matching modern-classed libraries only
353
packages counted as declaring a post-quantum library
crates.ioknown issue29,204 packages
crates.io
Listed
scanned
302,477
Weak-classed
weakExposed
4,460
Modern-classed only
modernOnly
24,485
Post-quantum
pqcReady
259
Known issues with these figures

Overstated: weakExposed, modernOnly, pqcReady.

A dependency was counted however it is declared, including optional, development, build and platform-specific ones. Re-read on 2026-10-05 at each crate's newest version as of the scan date: of the 259 crates counted as post-quantum, 157 require the library unconditionally, 84 optionally, 12 for development only and 1 for one platform only; 5 could not be re-read.

Counting only unconditional dependencies in the re-read of 2026-10-05, weak 4,460 becomes 3,740 and modern-only 24,485 becomes 20,935; 285 of the 29,204 crates could not be re-read and are in none of these figures.

Under the corrected weak classes, the weak count of 4,460 becomes 4,266. This correction and the one for unconditional dependencies have not been combined.

Corrections are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 440 of the 29,776 packages that matched a catalogued library, the name-pattern step 132 and the namespace step 0, leaving the 29,204 counted here.

Go Modulesknown issue13,343 packages
Go Modules
Listed
scanned
200,117
Weak-classed
weakExposed
3,244
Modern-classed only
modernOnly
10,094
Post-quantum
pqcReady
5
Known issues with these figures

Overstated: scanned. Not established: weakExposed, modernOnly, pqcReady.

The modules scanned are the first part of the registry's list, oldest first, not a sample of the registry.

Each module was read at its first indexed version. The published entries that a reconstruction made on 2026-10-05 could locate (13,141 of 13,343) were first indexed between 2019-04-10 and 2020-07-30, so this row describes manifests of that period.

Names were matched by path prefix: 937 entries are counted only through two cloud SDK entries.

Requirements marked // indirect were counted as direct: of the 13,045 published entries the reconstruction could re-read, 4,720 required the matched library only as // indirect.

113,638 of the 200,895 go.mod files the reconstruction read hold only a module line and were counted as using no cryptography.

76 of the 200,117 modules counted as scanned were not read, so scanned overstates the modules read.

Under the corrected weak classes, the weak count of 3,244 becomes 3,227.

Corrections are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 883 of the 16,060 packages that matched a catalogued library, the name-pattern step 114 and the namespace step 1,720, leaving the 13,343 counted here.

npmknown issue10,249 packages
npm
Listed
scanned
1,000,000
Weak-classed
weakExposed
3,146
Modern-classed only
modernOnly
7,035
Post-quantum
pqcReady
68
Known issues with these figures

Overstated: scanned. Understated: modernOnly, pqcReady. Not established: weakExposed.

The packages scanned are the first part of the registry's list in key order, not a sample of the registry. In that order scoped names come before names that begin with a letter: 10,102 of the 10,249 matched packages are scoped.

5,374 of the 1,000,000 packages counted as scanned were not read (fetchErrors in the dataset's npm file) and were counted as using no cryptography, so scanned overstates the packages read and the modern-only and post-quantum counts are floors.

Under the corrected weak classes, the 3,146 packages counted as depending on a weak library become 2,655; the unread packages would raise that count by an unmeasured amount, so its direction is not established.

3 packages are counted only through a catalogue entry that is being taken out of the count.

Corrections to the scanner and to the catalogue are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 11,708 of the 24,187 packages that matched a catalogued library, the name-pattern step 115 and the namespace step 2,115, leaving the 10,249 counted here.

PyPIknown issue5,019 packages
PyPI
Listed
scanned
150,000
Weak-classed
weakExposed
201
Modern-classed only
modernOnly
4,799
Post-quantum
pqcReady
19
Known issues with these figures

Overstated: scanned. Not established: weakExposed, modernOnly, pqcReady.

Requirements behind an extra or an environment marker were counted as dependencies. Of the 5,019 published entries, 3,768 have had no upload since the scan; read on 2026-10-05, 380 of those match a catalogued library only behind an extra or a marker, and their post-quantum count falls from 13 to 4.

4,084 of the 150,000 packages counted as scanned could not be read (fetchErrors in the dataset's PyPI file) and were counted as using no cryptography, so scanned overstates the packages read.

Under the corrected weak classes, the 201 packages counted as depending on a weak library become 173, or 174 if one library whose status is not verified is weak. Across the issues in this note, the effects run in both directions; their net has not been measured.

Corrections are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 11 of the 5,066 packages that matched a catalogued library, the name-pattern step 36 and the namespace step 0, leaving the 5,019 counted here.

Maven Centralknown issue1,957 packages
Maven Central
Listed
scanned
103,400
Weak-classed
weakExposed
895
Modern-classed only
modernOnly
1,062
Post-quantum
pqcReady
0
Known issues with these figures

Overstated: scanned. Not established: weakExposed, modernOnly, pqcReady.

The artifacts scanned are the first part of the registry's list, newest first, not a sample of the registry.

The scanner that produced this row read the first <dependencies> element in each POM wherever it sat, which is not always the project's own dependency list. On a hand-assembled set of 393 POMs from Maven Central (not a random sample), an XML parser finds a catalogued library in 23; the scanner flagged 26, of which 9 declare none, and missed 6.

1,000 of the 1,957 entries counted here match only commons-codec, OkHttp or ESAPI, which are being taken out of the count.

Under the corrected weak classes, the weak count of 895 becomes 152.

The catalogue's two post-quantum entries for Maven name artifacts Maven Central does not have, so the post-quantum zero is not a measurement.

26 of the 103,400 artifacts counted as scanned were not read, so scanned overstates the artifacts read.

scripts/scan-maven.mjs was corrected on 2026-10-05 to read project-level dependencies only; no scan has been published with it. The catalogue corrections are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 16 of the 3,942 packages that matched a catalogued library, the name-pattern step 37 and the namespace step 1,932, leaving the 1,957 counted here.

NuGetknown issue1,911 packages
NuGet
Listed
scanned
100,000
Weak-classed
weakExposed
204
Modern-classed only
modernOnly
1,707
Post-quantum
pqcReady
0
Known issues with these figures

Overstated: scanned. Understated: pqcReady. Not established: weakExposed, modernOnly.

The packages scanned are the first part of the registry's list, newest first, not a sample of the registry.

6,855 of the 100,000 packages counted as scanned were counted as using no cryptography although the metadata request for them failed (fetchErrors in the dataset's NuGet file), so scanned overstates the packages read and the three match counts miss those packages; the cause has not been verified.

The scanner counted a library that a package declares for only some of its target frameworks: re-read on 2026-10-05 at current versions, that is 57 of the 200 re-read packages still weak-classed under the corrected classes (42 of the 57 from one family of packages) and 36 of the 1,702 re-read packages counted as modern-classed only. 6 matched packages could not be re-read: 1 of the 204 counted as weak and 5 of the 1,707 counted as modern-classed only.

The scanner counted packages that have no listed version: of the packages re-read on 2026-10-05, 99 have none, 81 of them since before the scan, so against packages with a listed version the weak and modern-only counts are together too high by between 81 and 99. Another 38 were read at an unlisted version although an earlier version is listed; the effect of that is not established.

Under the corrected weak classes, the weak count of 204 becomes 201. Across the issues in this note, the effects on the weak and modern-only counts run in both directions; their net has not been measured.

Corrections to the scanner and to the catalogue are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 7 of the 1,918 packages that matched a catalogued library, the name-pattern step 0 and the namespace step 0, leaving the 1,911 counted here.

RubyGemsknown issue1,314 packages
RubyGems
Listed
scanned
100,000
Weak-classed
weakExposed
83
Modern-classed only
modernOnly
1,231
Post-quantum
pqcReady
0
Known issues with these figures

Overstated: weakExposed. Understated: modernOnly.

The gems scanned are the first 100,000 the registry's search returned, letter by letter from a, not a sample of the registry.

Under the corrected weak classes, between 4 and 37 of the 83 gems counted as depending on a weak library remain. The others are counted as weak only through libraries those classes do not class as weak, and would be counted as modern-classed only. The range is 33 gems counted as weak only through three libraries for which no end-of-life statement was found either way, so their status is not verified.

The scanner counted every failed request as an unread gem and reported none.

Corrections to the scanner and to the catalogue are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 10 of the 1,326 packages that matched a catalogued library, the name-pattern step 2 and the namespace step 0, leaving the 1,314 counted here.

Packagistknown issue1,153 packages
Packagist
Listed
scanned
100,000
Weak-classed
weakExposed
177
Modern-classed only
modernOnly
976
Post-quantum
pqcReady
0
Known issues with these figures

Overstated: scanned. Understated: modernOnly, pqcReady. Not established: weakExposed.

20,826 of the 100,000 packages counted as scanned were never read (fetchErrors in the dataset's Packagist file) and were counted as using no cryptography, so scanned overstates the packages read and the modern-only and post-quantum counts are floors.

Under the corrected weak classes, the 177 packages counted as depending on a weak library become between 61 and 86: 78 of the 177 are counted only through catalogue entries that are being taken out of the count, and 25 are counted as weak only through two libraries whose status is not verified. The unread packages would raise the weak count by an unmeasured amount, so its direction is not established.

Corrections to the scanner and to the catalogue are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 0 of the 1,154 packages that matched a catalogued library, the name-pattern step 1 and the namespace step 0, leaving the 1,153 counted here.

pub.devknown issue862 packages
pub.dev
Listed
scanned
50,000
Weak-classed
weakExposed
0
Modern-classed only
modernOnly
860
Post-quantum
pqcReady
2
Known issues with these figures

Not established: weakExposed, modernOnly, pqcReady.

The packages scanned are the first part of the registry's list, in alphabetical order, not a sample of the registry.

Under the corrected weak classes, the weak count of 0 does not change.

The scanner counted every failed request as an unread package and reported none. Whether any answer came without a pubspec, which it counted as scanned and not as a failure, has not been verified.

The packages of this row have not been re-read from the registry, so whether its three match counts are off, and which way, is not established.

Corrections are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 4 of the 866 packages that matched a catalogued library, the name-pattern step 0 and the namespace step 0, leaving the 862 counted here.

CocoaPodsknown issue357 packages
CocoaPods
Listed
scanned
50,000
Weak-classed
weakExposed
52
Modern-classed only
modernOnly
305
Post-quantum
pqcReady
0
Known issues with these figures

Overstated: scanned, weakExposed. Understated: modernOnly. Not established: pqcReady.

The catalogue's one post-quantum entry for CocoaPods names a pod the registry does not have, so no pod could be counted as post-quantum and the zero is not a measurement.

Under the corrected weak classes, 7 or 8 of the 52 pods counted as depending on a weak library remain, depending on one library whose status is not verified; the others would be counted as modern-classed only.

The scanner counted a library that a pod declares only in a subspec outside its default subspecs, which is not installed unless asked for: re-read on 2026-10-05, 5 of the 357 matched pods match only that way, 2 of them weak-classed.

1 of the 50,000 pods counted as scanned was not read, so scanned overstates the pods read.

Corrections to the scanner and to the catalogue are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Hexknown issue317 packages
Hex
Listed
scanned
15,000
Weak-classed
weakExposed
3
Modern-classed only
modernOnly
314
Post-quantum
pqcReady
0
Known issues with these figures

Not established: weakExposed, modernOnly, pqcReady.

The packages scanned are the first part of the registry's list, most downloaded first, not a sample of the registry.

Under the corrected weak classes, the weak count of 3 does not change.

The scanner counted a package as scanned only once it had read it, and reported none it could not read.

The packages of this row have not been re-read from the registry, so whether its three match counts are off, and which way, is not established.

Corrections are planned and not yet built. Corrected figures can only come from a new scan, published as a new dated dataset. No date is set.

Before counting, de-duplication dropped 2 of the 321 packages that matched a catalogued library, the name-pattern step 2 and the namespace step 0, leaving the 317 counted here.

Top packages by downloads

Monthly or 30-day counts that registries report, and 90-day counts divided by 3. Modelled figures are not ranked.

Largest modelled figures, not ranked above

These registries publish no monthly download counts. Each figure is modelled, as the methodology table lists. They are shown for scale and are not comparable with the measured counts above.

Microsoft.IdentityModel.Tokensnuget
~124.0M
System.IdentityModel.Tokens.Jwtnuget
~112.7M
software.amazon.awssdk:kmsmaven
~89.0M
crypto/tlsgo
~38.0M
Microsoft.AspNetCore.DataProtectionnuget
~31.5M
crypto/randgo
~25.0M

Quantum threat & migration

Algorithm vulnerability timeline and PQC implementation availability

AlgorithmTransition status
RSA-2048Draft NIST IR 8547: deprecated after 2030, disallowed after 2035
Threat: A cryptographically relevant quantum computer (CRQC) running Shor's algorithm would break it.
ECDSA P-256Draft NIST IR 8547: disallowed after 2035
Threat: A cryptographically relevant quantum computer (CRQC) running Shor's algorithm would break it.
AES-128No practical quantum threat; CNSA 2.0 recommends AES-256 for defense systems
Threat: Grover's algorithm needs about 2^64 sequential AES evaluations. NIST expects AES-128 to remain secure for decades, and draft NIST IR 8547 places it in Category 1.
AES-256N/A: quantum-resistant at current key sizes
Threat: Grover's algorithm needs about 2^128 sequential AES evaluations. Draft NIST IR 8547 places AES-256 in Category 5.
SHA-256N/A: not considered quantum-vulnerable by NIST
Threat: Grover's algorithm cuts a preimage search to about 2^128 SHA-256 evaluations. Draft NIST IR 8547 places SHA-256 in Category 5 for preimages and Category 2 for collisions.
ML-KEM (Kyber)N/A
Threat: FIPS 203 states that ML-KEM is, at present, believed secure even against adversaries who possess a quantum computer.
ChaCha20-Poly1305N/A: quantum-resistant at current key sizes
Threat: An AEAD with a 256-bit key. Grover's algorithm needs about 2^128 sequential ChaCha20 evaluations to find the key.

Dates in NIST's draft transition plan

NIST IR 8547 (initial public draft, November 2024) lists when classical public-key algorithms would be deprecated and when they would be disallowed. It is a draft and can change before it is final.

1,527
Days until the end of 2030
112-bit classical public-key algorithms deprecated in the draft

The draft lists digital signature and key-establishment algorithms that provide 112 bits of security strength as deprecated after 2030. RSA with a 2048-bit key is at that strength. Deprecated means the algorithm may still be used, with some security risk that the owner of the data has to weigh.

3,353
Days until the end of 2035
Classical public-key algorithms disallowed in the draft

The draft lists RSA, ECDSA, EdDSA, Diffie-Hellman and MQV as disallowed after 2035 at every security strength. Disallowed means no longer allowed for the stated purpose. The draft gives no such date for AES or for hash functions that provide at least 128 bits of security.

Downloads by category

Monthly downloads of catalogued libraries in each category of cryptographic function, modelled counts included. The line under each figure is a floor on its modelled part. 36,538,244 modelled downloads are of packages the data lists in no row and are in no floor; if all of them belonged to one category, its modelled part would be 1.7 to 13.8 percentage points higher, depending on the category. Shares by class are withheld until they are computed with the corrected classes over measured registries.

CategoryMonthly downloads
General purpose
2.1B
at least 9% modelled
JWT
1.8B
at least 16% modelled
Hashing
1.3B
at least 3% modelled
Signing and key exchange
617.0M
at least 6% modelled
Encryption
579.1M
at least 12% modelled
KDF / Password hashing
460.6M
at least 3% modelled
TLS, SSH and other protocols
263.9M
at least 28% modelled

Vulnerability landscape

NVD records by CWE id
NVD records under each CWE id, for every product and year, in the collection of October 5, 2026.
CWEDescriptionCount
CWE-327Use of a Broken or Risky Cryptographic Algorithm416
CWE-326Inadequate Encryption Strength341
CWE-328Use of Weak Hash1

Click a row for details

GitHub advisories by severity
3 of 2,000 reviewed

Click an arc or badge for details

Package entries in these advisories, by ecosystem
Maven Central
3
crates.io
1
Go Modules
1

Recommendations

Leadership

Begin PQC migration planning

NIST's draft IR 8547 would deprecate classical public-key algorithms at 112 bits of security strength after 2030 and disallow classical public-key algorithms after 2035. An inventory of cryptographic dependencies is the first step of a migration plan. The draft says a migration may at first include hybrid solutions that combine a classical and a post-quantum algorithm.

Action

Conduct a cryptographic inventory using CBOM tools, prioritize quantum-vulnerable algorithms (RSA, ECDSA), and allocate engineering resources for migration.

Establish cryptographic governance policy

Define an organizational approved-algorithms list aligned with NIST SP 800-131A Rev. 2 and the dates in NIST's draft IR 8547, covering key sizes, algorithm selection and deprecation schedules. The Rev. 3 draft of SP 800-131A (October 2024) proposes moving from 112-bit to 128-bit security strength and retiring SHA-1 and the 224-bit hash functions.

Action

Draft a cryptographic standards policy document, get security team sign-off, and integrate approved-algorithm checks into procurement and development workflows.

Security teams

Scan for weak cryptography in CI

A check on each pull request can catch weak cryptography before it is merged.

Action

Run CryptoScan (github.com/csnp/cryptoscan) on each pull request with --fail-on set to the lowest severity that should block a merge; otherwise it fails only on critical findings.

Monitor quantum computing progress for threat timeline updates

A cryptographically relevant quantum computer (CRQC) capable of breaking RSA/ECDSA does not yet exist.

Action

Subscribe to NIST PQC mailing list, monitor quantum computing milestones, and update risk assessments quarterly.

Developers

Adopt FIPS 203/204/205 implementations

NIST-standardized PQC algorithms (ML-KEM, ML-DSA, SLH-DSA) are implemented in @noble/post-quantum (npm) and in liboqs, which liboqs-python (PyPI) wraps. Unless liboqs is already installed, liboqs-python builds it on first import, which needs git, CMake and a C compiler. liboqs is meant for research and prototyping, and its SLH-DSA support is community-tier and best effort. Early adoption builds organizational expertise and surfaces integration challenges.

Action

Install @noble/post-quantum, or liboqs-python with its build tools, and prototype key encapsulation and digital signature workflows in non-critical paths.

Deprecate MD5 and SHA-1 across all codebases

MD5 has been collision-broken since 2004 and SHA-1 since 2017 (SHAttered). NIST says SHA-1 should be phased out by December 31, 2030, in favor of SHA-2 and SHA-3. Replace MD5 and SHA-1 with a SHA-2 or SHA-3 hash of at least 256 bits, such as SHA-256.

Action

Search codebases for MD5/SHA-1 usage (including transitive dependencies), replace with SHA-256+ equivalents, and add linter rules to prevent reintroduction.

Scan your own project

The package counts above come from declared dependencies. CryptoScan reads a project's source code and lists the cryptography it finds.

  1. Install CryptoScan (needs Go, with $(go env GOPATH)/bin on your PATH)

    go install github.com/csnp/cryptoscan/cmd/cryptoscan@latest
    Release binaries for Linux, Windows and macOS

    checksums.txt on that page lists a checksum for every file. On macOS, use step 1: macOS rejects these binaries when they are downloaded in a browser.

  2. Scan the current directory (exits 1 on a critical finding)

    cryptoscan scan .
  3. Write the findings to crypto-bom.json as a CycloneDX 1.6 CBOM; nothing is printed

    cryptoscan scan . --format cbom --output crypto-bom.json

CryptoScan on GitHub

Research dataset

The HTML report is a single file with the data embedded; its charts load Chart.js from jsDelivr. The JSON is the /api/census response, open to cross-origin requests from any site.

Aggregate summary of the March 2026 scan, for independent verification: 2,809,479 packages across 11 ecosystems, collected March 18, 2026. Per-package rows are not included.

Scan summary (JSON)

Its download counts came from collectors that recorded a failed request as a count of zero, so they are understated, and the Hex and pub.dev scans behind its package totals were both defective.

This archive carries known errors

Every affected field is listed in the file's corrections block, with the direction of each error. The package-level figures in this file are outside these corrections and cannot be recounted, because the raw output of that scan no longer exists.

On 2026-03-18 the Go, crates.io, PyPI, Packagist and NuGet scanners in the repository were identical to the ones that produced the scan of August 3, 2026, and the catalogue held the same post-quantum entries that Maven Central and CocoaPods do not have. Which commit the March run used was not recorded and its raw output no longer exists, so whether the known issues of the August 3, 2026 scan apply to the March figures, and by how much, is not established.

The JSON above carries the scan of August 3, 2026 with its known issues.