lotobo/crypto-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Release Crypto Tools 0.2.0
Verify / verify (push) Canceled after 0s
Details

Browse Source
This commit is contained in:
zemion
2026-09-02 10:40:23 +02:00
parent 4b75f819e2
commit 82bb01b13f
37 changed files with 3673 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files
public/docs/ARCHITECTURE.md
+9 -3
View File
@@ -1,7 +1,13 @@
# Architecture
Crypto Tools is a static React/Vite inspection application wrapped in the shared Toolbox shell. `crypto/inspection.ts` accepts a bounded string or byte buffer, separates PEM blocks or JSON, and produces one plain report model. It uses `@peculiar/x509` for X.509/PKCS #10/CRL parsing and signature primitives, and browser WebCrypto for SHA-256 fingerprints and RFC 7638 thumbprints.
Crypto Tools is a static React/Vite application wrapped in the shared Toolbox shell. `crypto/inspection.ts` accepts a bounded string or byte buffer, separates PEM blocks or JSON, and produces one plain report model. It uses `@peculiar/x509` for X.509/PKCS #10/CRL parsing and signature primitives, strict `asn1js` DER parsing for the supported PKCS containers, and browser WebCrypto for fingerprints, key import and operations.
Certificate linking is deliberately explicit and shallow: certificates in the same input are matched by issuer/subject and the child signature is checked with that candidate. The app does not build a trust path, load platform roots, fetch intermediates or revocation data, or infer trust from a valid signature. DNS SAN matching is an isolated syntax check against a user-entered host name.
Certificate paths are built only from the bounded explicit input. Issuer names select candidates, AKI/SKI disambiguates when available, and each link checks its signature, Basic Constraints, keyCertSign, path-length and inspection-time validity. Ambiguous, missing and looping paths stop rather than guess. A self-signed terminus is labelled as present but never trusted. The app does not load platform roots, fetch intermediates/revocation data or infer trust from a valid signature. DNS SAN matching remains an isolated syntax check against a user-entered host name.
The 8 MiB/256-PEM-block bounds are checked before expensive parsing. Version 0.1 does not use a worker, persistence, or a server API. Relative entry and asset URLs keep the build relocatable below a nested portal path.
`crypto/pbes2.ts` accepts DER EncryptedPrivateKeyInfo and reusable AlgorithmIdentifier/ciphertext pairs using PBES2 + PBKDF2, bounded iterations/salts, supported HMAC PRFs and WebCrypto AES-CBC/AES-GCM schemes. Successful private-key decryption must produce a structurally valid PKCS #8 PrivateKeyInfo. Passwords and plaintext key bytes are not returned in reports.
`crypto/pkcs12.ts` parses a version-3 PFX, its CMS-data AuthenticatedSafe, bounded `data`/`encryptedData` ContentInfos, SafeContents and at most 512 bags across four nested levels. It inventories attributes, unencrypted and shrouded PKCS #8 keys, X.509 certificate bags and nested SafeContents; CRL, secret and unknown bag values are identified without being decoded. MacData is verified before password-based decryption when SHA-1/SHA-256/SHA-384/SHA-512 is declared, using the RFC 7292 PKCS #12 MAC KDF with at most 50,000 iterations. Modern PBES2/PBKDF2 AES content is decrypted through the shared WebCrypto path. Legacy PKCS #12 PBE, non-data CMS content, unknown certificate types, wrong passwords and malformed or excessive nesting fail closed with contextual diagnostics. Plaintext SafeContents and private-key buffers are overwritten after extracting metadata; certificates are retained as public inputs for the existing path analyzer.
`crypto/operations.ts` exposes fixed algorithm profiles rather than parameter auto-detection. It imports PKCS #8/SPKI/certificate/JWK keys, rejects implicit legacy conversions, enforces RSA/AES/curve bounds, and overwrites temporary decoded/decrypted private-key buffers after WebCrypto import on both success and failure. It generates a fresh 96-bit IV for each AES-GCM encryption and releases no plaintext after an authenticated-decryption failure. The AES JSON envelope and asymmetric signatures/ciphertexts use explicit unpadded Base64url encodings.
The 8 MiB/256-PEM-block bounds are checked before expensive parsing. Encrypted PEM blocks are processed sequentially; PBKDF2 is capped at 10,000,000 iterations per object and 20,000,000 aggregate iterations per inspection, including encrypted PKCS #12 content and shrouded key bags. PKCS #12 MAC iterations are capped at 50,000 and explicit PKCS #12 passwords at 4,096 UTF-16 units. The app does not use persistence or a server API. Relative entry and asset URLs keep the build relocatable below a nested portal path.