Skip to content

Commit 8d61c1b

Browse files
save file
1 parent c208ccf commit 8d61c1b

1 file changed

Lines changed: 161 additions & 1 deletion

File tree

blog/26-04-26/x509-certificates-in-js---encrypt-decrypt-data/x509-certificates-in-js---encrypt-decrypt-data.html

Lines changed: 161 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,19 @@ <h4>
139139
<li>
140140
node.js supports the entire certificate in pem format
141141
</li>
142+
</ul>
143+
144+
<p>
145+
So the rule of thumb:
146+
</p>
147+
<ul>
148+
<li>
149+
If you want browser compatibility, always use PKCS#8.
150+
</li>
151+
<li>
152+
If you’re in Node, you can use either.
153+
</li>
154+
</ul>
142155
</div>
143156

144157
<div>
@@ -182,10 +195,157 @@ <h4>
182195

183196

184197

198+
<div class=blog-text>
199+
<h3 class=blog-hdr>
200+
PKCS#8
201+
</h3>
202+
203+
<p>
204+
PKCS#8 is a standard format for storing private keys, regardless of the algorithm (RSA, EC, Ed25519, etc.).
205+
It’s defined in RFC 5208 and RFC 5958.
206+
<br>
207+
Think of it as:
208+
<br>
209+
A universal container format for private keys.
210+
<br>
211+
It wraps the private key with metadata describing:
212+
</p>
213+
<ul>
214+
<li>
215+
the algorithm (RSA, EC, etc.)
216+
</li>
217+
<li>
218+
parameters (curve, padding, etc.)
219+
</li>
220+
<li>
221+
the key material itself
222+
</li>
223+
</ul>
224+
<p>
225+
This makes PKCS#8 algorithm‑agnostic, unlike PKCS#1.
226+
</p>
227+
</div>
185228

186229

230+
<div class=blog-text>
231+
<h3 class=blog-hdr>
232+
PKCS#1 vs PKCS#8 (the important difference)
233+
</h3>
234+
235+
<h4>
236+
PKCS#1
237+
</h4>
238+
<ul>
239+
<li>
240+
Only for RSA keys
241+
</li>
242+
<li>
243+
Contains just the RSA private key integers
244+
</li>
245+
<li>
246+
PEM header:
247+
<code>
248+
-----BEGIN RSA PRIVATE KEY-----
249+
</code>
250+
</li>
251+
</ul>
252+
253+
<h4>
254+
PKCS#8
255+
</h4>
256+
<ul>
257+
<li>
258+
Works for any key type (RSA, EC, Ed25519, etc.)
259+
</li>
260+
<li>
261+
Contains:
262+
<ul>
263+
<li>
264+
algorithm identifier
265+
</li>
266+
<li>
267+
private key data
268+
</li>
269+
</ul>
270+
</li>
271+
<li>
272+
PEM headers :
273+
<code>
274+
-----BEGIN PRIVATE KEY-----
275+
</code>
276+
<code>
277+
-----BEGIN ENCRYPTED PRIVATE KEY-----
278+
</code>
279+
</li>
280+
</ul>
281+
282+
<h4>
283+
Why PKCS#8 is preferred today
284+
</h4>
285+
<ul>
286+
<li>
287+
It’s universal
288+
</li>
289+
<li>
290+
It’s compatible with modern crypto APIs
291+
</li>
292+
<li>
293+
It supports encryption natively
294+
</li>
295+
<li>
296+
It’s required by WebCrypto
297+
</li>
298+
</ul>
299+
300+
<h4>
301+
Why Node.js supports both PKCS#1 and PKCS#8
302+
</h4>
303+
<p>
304+
Node’s crypto module uses OpenSSL, which understands both formats. Node doesn’t care — OpenSSL parses it.
305+
</p>
306+
307+
<h4>
308+
Why browsers only support PKCS#8
309+
</h4>
310+
<p>
311+
WebCrypto is intentionally strict and minimal.
312+
<br>
313+
It only accepts:
314+
</p>
315+
<ul>
316+
<li>
317+
PKCS#8 for private keys
318+
</li>
319+
<li>
320+
SPKI for public keys
321+
</li>
322+
<li>
323+
JWK for JSON keys
324+
</li>
325+
</ul>
326+
327+
</div>
328+
187329

188-
<divv class=blog-text>
330+
<div class=blog-text>
331+
<h3 class=blog-hdr>
332+
Converting PKCS#1 → PKCS#8 (OpenSSL)
333+
</h3>
334+
<p>
335+
If you have ( pcks#1 ) :
336+
<code>
337+
-----BEGIN RSA PRIVATE KEY-----
338+
</code>
339+
340+
Convert it for use in browsers :
341+
</p>
342+
343+
<code>
344+
openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem
345+
</code>
346+
347+
348+
<div class=blog-text>
189349
<h3 class=blog-hdr>
190350
SPKI
191351
</h3>

0 commit comments

Comments
 (0)