boringssl

780 Commits

61 Branches

23 Tags

511 MiB

Tag: Branch: Tree: 8bbefbfeee

Commit Graph

Author	SHA1	Message	Date
Adam Langley	8bbefbfeee	Document that \|EC_KEY_generate_fips\| works for both cases. Our FIPS module only claims support for RSA signing/verification, and \|RSA_generate_key_fips\| already performs a sign/verify pair-wise consistency test (PCT). For ECDSA, \|EC_KEY_generate_fips\| performs a sign/verify PCT too. But when \|EC_KEY_generate_fips\| is used for key agreement a sign/verify PCT may not be correct. The FIPS IG[1], page 60, says: > Though not a CAST, a pairwise consistency test (PCT) shall be > conducted for every generated public and private key pair for the > applicable approved algorithm (per ISO/IEC 19790:2012 Section > 7.10.3.3). To further clarify, at minimum, the PCT that is required by > the underlying algorithm standard (e.g. SP 800- 56Arev3 or SP > 800-56Brev2) shall be performed. SP 800-56Ar3, page 36, says: > For an ECC key pair (d, Q): Use the private key, d, along with the > generator G and other domain parameters associated with the key pair, > to compute dG (according to the rules of elliptic-curve arithmetic). > Compare the result to the public key, Q. If dG is not equal to Q, then > the pair-wise consistency test fails But \|EC_KEY_generate_fips\| has always done that via \|EC_KEY_check_key\|. So I believe that \|EC_KEY_generate_fips\| works for either case. This change documents that. [1] FIPS 140-3 IG dated 2022-03-14 and with SHA-256 2f232f7f5839e3263284d71c35771c9fdf2e505b02813be999377030c56b37e4 Change-Id: I4b4e2ed92ae3d59e2f2404c41694abeb3eb283f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51988 Reviewed-by: David Benjamin <davidben@google.com>	3 years ago
David Benjamin	cfafcd454f	Deduplicate d2i and i2d documentation. There are a lot of d2i and i2d functions, and there will be even more once asn1.h and x509.h are properly documented. We currently replicate the text in each, but as a result a miss a few points: - The i2d outp != NULL, outp == NULL case isn't documented at all. - We should call out what to do with inp after d2i. - Unlike our rewritten functions, object reuse is still quite rampant with the asn1.h functions. I hope we can get rid of that but, until we can, it would be nice to describe it in one place. While I'm here, update a few references to the latest PKCS#1 RFC, and try to align how we reference ASN.1 structures a bit. The d2i/i2d functions say "ASN.1, DER-encoded RSA private key" while the CBS/CBB functions say "DER-encoded RSAPrivateKey structure". Bug: 426 Change-Id: I8d9a7b0aef3d6d9c8240136053c3b1704b09fd41 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49906 Reviewed-by: Adam Langley <agl@google.com>	3 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago

Author

SHA1

Message

Date

Adam Langley

8bbefbfeee

Document that |EC_KEY_generate_fips| works for both cases.

Our FIPS module only claims support for RSA signing/verification, and
|RSA_generate_key_fips| already performs a sign/verify pair-wise
consistency test (PCT). For ECDSA, |EC_KEY_generate_fips| performs a
sign/verify PCT too. But when |EC_KEY_generate_fips| is used for key
agreement a sign/verify PCT may not be correct.

The FIPS IG[1], page 60, says:

> Though not a CAST, a pairwise consistency test (PCT) shall be
> conducted for every generated public and private key pair for the
> applicable approved algorithm (per ISO/IEC 19790:2012 Section
> 7.10.3.3). To further clarify, at minimum, the PCT that is required by
> the underlying algorithm standard (e.g. SP 800- 56Arev3 or SP
> 800-56Brev2) shall be performed.

SP 800-56Ar3, page 36, says:

> For an ECC key pair (d, Q): Use the private key, d, along with the
> generator G and other domain parameters associated with the key pair,
> to compute dG (according to the rules of elliptic-curve arithmetic).
> Compare the result to the public key, Q. If dG is not equal to Q, then
> the pair-wise consistency test fails

But |EC_KEY_generate_fips| has always done that via
|EC_KEY_check_key|. So I believe that |EC_KEY_generate_fips| works for
either case.

This change documents that.

[1] FIPS 140-3 IG dated 2022-03-14 and with SHA-256
2f232f7f5839e3263284d71c35771c9fdf2e505b02813be999377030c56b37e4

Change-Id: I4b4e2ed92ae3d59e2f2404c41694abeb3eb283f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51988
Reviewed-by: David Benjamin <davidben@google.com>

3 years ago

David Benjamin

cfafcd454f

Deduplicate d2i and i2d documentation.

There are a lot of d2i and i2d functions, and there will be even more
once asn1.h and x509.h are properly documented. We currently replicate
the text in each, but as a result a miss a few points:

- The i2d outp != NULL, *outp == NULL case isn't documented at all.

- We should call out what to do with *inp after d2i.

- Unlike our rewritten functions, object reuse is still quite rampant
  with the asn1.h functions. I hope we can get rid of that but, until we
  can, it would be nice to describe it in one place.

While I'm here, update a few references to the latest PKCS#1 RFC, and
try to align how we reference ASN.1 structures a bit. The d2i/i2d
functions say "ASN.1, DER-encoded RSA private key" while the CBS/CBB
functions say "DER-encoded RSAPrivateKey structure".

Bug: 426
Change-Id: I8d9a7b0aef3d6d9c8240136053c3b1704b09fd41
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49906
Reviewed-by: Adam Langley <agl@google.com>

3 years ago

Adam Langley

fb0c05cac2

acvp: add CMAC-AES support.

Change by Dan Janni.

Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

5 years ago

3 Commits (8bbefbfeee609b17622deedd100163c12f5c95dc)