@@ -338,30 +338,6 @@ <h2 id="library">Core library</h2>
338
338
TODO: complete the Core library section
339
339
</ p >
340
340
341
- < h3 id ="crypto/tls "> < a href ="/pkg/crypto/tls "> crypto/tls</ a > </ h3 >
342
-
343
- < p > <!-- CL 295370 -->
344
- < a href ="/pkg/crypto/tls#Conn.HandshakeContext "> (*Conn).HandshakeContext</ a > was added to
345
- allow the user to control cancellation of an in-progress TLS Handshake.
346
- The context provided is propagated into the
347
- < a href ="/pkg/crypto/tls#ClientHelloInfo "> ClientHelloInfo</ a >
348
- and < a href ="/pkg/crypto/tls#CertificateRequestInfo "> CertificateRequestInfo</ a >
349
- structs and accessible through the new
350
- < a href ="/pkg/crypto/tls#ClientHelloInfo.Context "> (*ClientHelloInfo).Context</ a >
351
- and
352
- < a href ="/pkg/crypto/tls#CertificateRequestInfo.Context ">
353
- (*CertificateRequestInfo).Context
354
- </ a > methods respectively. Canceling the context after the handshake has finished
355
- has no effect.
356
- </ p >
357
-
358
- < p > <!-- CL 289209 -->
359
- When < a href ="/pkg/crypto/tls#Config "> Config.NextProtos</ a > is set, servers now
360
- enforce that there is an overlap between the configured protocols and the protocols
361
- advertised by the client, if any. If there is no overlap the connection is closed
362
- with the < code > no_application_protocol</ code > alert, as required by RFC 7301.
363
- </ p >
364
-
365
341
< h3 id ="runtime/cgo "> < a href ="/pkg/runtime/cgo "> Cgo</ a > </ h3 >
366
342
367
343
< p >
@@ -424,13 +400,117 @@ <h3 id="minor_library_changes">Minor changes to the library</h3>
424
400
</ dd >
425
401
</ dl > <!-- compress/lzw -->
426
402
427
- < dl id ="crypto/rsa "> < dt > < a href ="/pkg/crypto/rsa/ "> crypto/rsa</ a > </ dt >
403
+ < dl id ="crypto/ed25519 "> < dt > < a href ="/pkg/crypto/ed25519/ "> crypto/ed25519</ a > </ dt >
404
+ < dd >
405
+ < p > <!-- CL 276272 -->
406
+ The < code > crypto/ed25519</ code > package has been rewritten, and all
407
+ operations are now approximately twice as fast on amd64 and arm64.
408
+ The observable behavior has not otherwise changed.
409
+ </ p >
410
+ </ dd >
411
+ </ dl > <!-- crypto/ed25519 -->
412
+
413
+ < dl id ="crypto/elliptic "> < dt > < a href ="/pkg/crypto/elliptic/ "> crypto/elliptic</ a > </ dt >
414
+ < dd >
415
+ < p > <!-- CL 233939 -->
416
+ < a href ="/pkg/crypto/elliptic#CurveParams "> < code > CurveParams</ code > </ a >
417
+ methods now automatically invoke faster and safer dedicated
418
+ implementations for known curves (P-224, P-256, and P-521) when
419
+ available. Note that this is a best-effort approach and applications
420
+ should avoid using the generic, not constant-time < code > CurveParams</ code >
421
+ methods and instead use dedicated
422
+ < a href ="/pkg/crypto/elliptic#Curve "> < code > Curve</ code > </ a > implementations
423
+ such as < a href ="/pkg/crypto/elliptic#P256 "> < code > P256</ code > </ a > .
424
+ </ p >
425
+
426
+ < p > <!-- CL 315271, CL 315274 -->
427
+ The < a href ="/pkg/crypto/elliptic#P521 "> < code > P521</ code > </ a > curve
428
+ implementation has been rewritten using code generated by the
429
+ < a href ="https://github.com/mit-plv/fiat-crypto "> fiat-crypto project</ a > ,
430
+ which is based on a formally-verified model of the arithmetic
431
+ operations. It is now constant-time and three times faster on amd64 and
432
+ arm64. The observable behavior has not otherwise changed.
433
+ </ p >
434
+ </ dd >
435
+ </ dl > <!-- crypto/elliptic -->
436
+
437
+ < dl id ="crypto/rand "> < dt > < a href ="/pkg/crypto/rand/ "> crypto/rand</ a > </ dt >
438
+ < dd >
439
+ < p > <!-- CL 302489, CL 299134, CL 269999 -->
440
+ The < code > crypto/rand</ code > package now uses the < code > getentropy</ code >
441
+ syscall on macOS and the < code > getrandom</ code > syscall on Solaris,
442
+ Illumos, and DragonFlyBSD.
443
+ </ p >
444
+ </ dd >
445
+ </ dl > <!-- crypto/rand -->
446
+
447
+ < dl id ="crypto/tls "> < dt > < a href ="/pkg/crypto/tls/ "> crypto/tls</ a > </ dt >
428
448
< dd >
429
- < p > <!-- CL 302230 -->
430
- TODO: < a href ="https://golang.org/cl/302230 "> https://golang.org/cl/302230</ a > : fix salt length calculation with PSSSaltLengthAuto
449
+ < p > <!-- CL 295370 -->
450
+ The new < a href ="/pkg/crypto/tls#Conn.HandshakeContext "> < code > Conn.HandshakeContext</ code > </ a >
451
+ method allows the user to control cancellation of an in-progress TLS
452
+ handshake. The provided context is accessible from various callbacks through the new
453
+ < a href ="/pkg/crypto/tls#ClientHelloInfo.Context "> < code > ClientHelloInfo.Context</ code > </ a > and
454
+ < a href ="/pkg/crypto/tls#CertificateRequestInfo.Context "> < code > CertificateRequestInfo.Context</ code > </ a >
455
+ methods. Canceling the context after the handshake has finished has no effect.
456
+ </ p >
457
+
458
+ < p > <!-- CL 289209 -->
459
+ When < a href ="/pkg/crypto/tls#Config.NextProtos "> < code > Config.NextProtos</ code > </ a >
460
+ is set, servers now enforce that there is an overlap between the
461
+ configured protocols and the protocols advertised by the client, if any.
462
+ If there is no overlap the connection is closed with the
463
+ < code > no_application_protocol</ code > alert, as required by RFC 7301.
464
+ </ p >
465
+
466
+ < p > <!-- CL 314609 -->
467
+ Cipher suite ordering is now handled entirely by the
468
+ < code > crypto/tls</ code > package. Currently, cipher suites are sorted based
469
+ on their security, performance, and hardware support taking into account
470
+ both the local and peer's hardware. The order of the
471
+ < a href ="/pkg/crypto/tls#Config.CipherSuites "> < code > Config.CipherSuites</ code > </ a >
472
+ field is now ignored, as well as the
473
+ < a href ="/pkg/crypto/tls#Config.PreferServerCipherSuites "> < code > Config.PreferServerCipherSuites</ code > </ a >
474
+ field. Note that < code > Config.CipherSuites</ code > still allows
475
+ applications to choose what TLS 1.0–1.2 cipher suites to enable.
476
+ </ p >
477
+
478
+ < p >
479
+ The 3DES cipher suites have been moved to
480
+ < a href ="/pkg/crypto/tls#InsecureCipherSuites "> < code > InsecureCipherSuites</ code > </ a >
481
+ due to < a href ="https://sweet32.info/ "> fundamental block size-related
482
+ weakness</ a > . They are still enabled by default but only as a last resort,
483
+ thanks to the cipher suite ordering change above.
484
+ </ p >
485
+ </ dd >
486
+ </ dl > <!-- crypto/tls -->
487
+
488
+ < dl id ="crypto/x509 "> < dt > < a href ="/pkg/crypto/x509/ "> crypto/x509</ a > </ dt >
489
+ < dd >
490
+ < p > <!-- CL 224157 -->
491
+ < a href ="/pkg/crypto/x509/#CreateCertificate "> < code > CreateCertificate</ code > </ a >
492
+ now returns an error if the provided private key doesn't match the
493
+ parent's public key, if any. The resulting certificate would have failed
494
+ to verify.
495
+ </ p >
496
+
497
+ < p > <!-- CL 315209 -->
498
+ The temporary < code > GODEBUG=x509ignoreCN=0</ code > flag has been removed.
499
+ </ p >
500
+
501
+ < p > <!-- CL 274234 -->
502
+ < a href ="/pkg/crypto/x509/#ParseCertificate "> < code > ParseCertificate</ code > </ a >
503
+ has been rewritten, and now consumes ~70% fewer resources. The observable
504
+ behavior has not otherwise changed, except for error messages.
505
+ </ p >
506
+
507
+ < p > <!-- CL 321190 -->
508
+ On BSD systems, < code > /etc/ssl/certs</ code > is now searched for trusted
509
+ roots. This adds support for the new system trusted certificate store in
510
+ FreeBSD 12.2+.
431
511
</ p >
432
512
</ dd >
433
- </ dl > <!-- crypto/rsa -->
513
+ </ dl > <!-- crypto/x509 -->
434
514
435
515
< dl id ="database/sql "> < dt > < a href ="/pkg/database/sql/ "> database/sql</ a > </ dt >
436
516
< dd >
0 commit comments