node-forge は JavaScript による TLS 実装として始まり、現在は主に PKI 関連の機能のために使われています。X.509 証明書と CSR の生成と解析、PKCS#12 バンドルの読み書き、RSA の暗号化と署名、ASN.1 パーサーです。ブラウザーでも Node.js でも同じように動作し、ネイティブコードは含みません。
Ed25519 以外に楕円曲線への対応はありません。forge.pki が公開しているのは rsa と ed25519 だけで、チェックではその結果を確認できました。ECDSA 証明書に certificateFromPem() を使うと Cannot read public key. OID is not RSA. がスローされ、EC 公開鍵に publicKeyFromPem() を使うと Cannot read public key. Unknown OID. がスローされます。同じバイト列は forge 自身の ASN.1 リーダーでは問題なく解析できるにもかかわらずです。実環境の証明書を調べるコードは ECDSA 鍵に頻繁に出会うため、それらには別のパーサーが必要です。node:crypto の X509Certificate や証明書デコーダーなら、どちらの種類の鍵も扱えます。
RSA では、パラメーターがそろえば問題なく相互運用できます。forge が作成した PKCS#1 v1.5 署名と PSS 署名は node:crypto で検証できました。PSS では、ダイジェスト、MGF1 のダイジェスト、ソルト長が両側で一致している必要があり、forge ではサンプルのように 3 つすべてを指定しなければなりません。公開鍵は SPKI、PKCS#1、証明書の PEM から、秘密鍵は PKCS#8、暗号化された PKCS#8、PKCS#1、PKCS#12 から読み込めます。バンドルの中身は PFX インスペクターで開いて確認してください。
同じシードに対して、forge による Ed25519 署名は node:crypto の署名とバイト単位で一致しました。forge の秘密鍵は 64 バイトの展開形式(シードの後に公開鍵が続く形)なので、32 バイトのシードを想定するライブラリには前半だけを渡せば済みます。
署名検証にはパーサーの寛容さに起因する問題の歴史があり、そのうち 1 件は現在も未解決です。2026年9月に公開され、修正版がリリースされていないアドバイザリ GHSA-86w9-cpqp-85rv(CVE-2026-85393)によると、1.4.0 までのバージョンの RSA PKCS#1 v1.5 検証は、DigestInfo のアルゴリズム識別子内にある余分な要素を無視します。そのため、3 のような小さい公開指数を持つ鍵では署名を偽造できてしまいます。チェックではこの寛容さを再現できました。正しくパディングされたブロックのその位置に余分な要素を入れると、forge では検証を通り、node:crypto では拒否されました。修正版がリリースされるまでは、PKCS#1 v1.5 署名を node:crypto か WebCrypto で検証し、指数が 3 の RSA 鍵は避けてください。1.4.0 自体は前回の一連の問題を修正しており(ダイジェストの後ろの余分なフィールドと、正規形でない Ed25519 署名はどちらも拒否されました)、1.3.0 より前のバージョンにはそれ以前の署名偽造のバグ(CVE-2022-24771、CVE-2022-24772)がありました。