openslx-ng/ipxe.git/src/crypto/mishmash, branch openslx

[build] Mark MD4 and MD5 as forbidden for UEFI Secure Boot

2026-01-14T16:10:29+00:00

A past security review identified MD4 and MD5 support as features that ought to be disabled by default. (There is zero impact on UEFI Secure Boot itself from having these algorithms enabled: this was just a side comment in the review.) As noted in the resulting commit 7f2006a ("[crypto] Disable MD5 as an OID-identifiable algorithm by default"), the actual MD5 code will almost certainly still be present in the binary due to its implicit use by various features. Disabling MD5 support via config/crypto.h simply removes the OID-identified algorithm, which prevents it from being used as an explicitly identified algorithm (e.g. in an X.509 certificate digest). Match the intent of this review comment by marking the OID-identified algorithms for MD4 and MD5 as forbidden for UEFI Secure Boot. Extend this to also disable the "md4sum" command and the use of the md5WithRSAEncryption OID-identified algorithm. (The "md5sum" command is left enabled for historical reasons, and we have no definition for md4WithRSAEncryption anyway.) Signed-off-by: Michael Brown

[build] Mark known reviewed files as permitted for UEFI Secure Boot

2026-01-14T16:10:29+00:00

Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown

[crypto] Add ECDSA-based TLS cipher suites

2025-12-19T18:18:45+00:00

Signed-off-by: Michael Brown

[crypto] Add OID-identified algorithms for ECDSA with SHA2 hash family

2025-12-19T15:26:29+00:00

Signed-off-by: Michael Brown

[cmdline] Show commands in alphabetical order

2025-08-06T15:34:45+00:00

Commands were originally ordered by functional group (e.g. keeping the image management commands together), with arrays used to impose a functionally meaningful order within the group. As the number of commands and functional groups has expanded over the years, this has become essentially useless as an organising principle. Switch to sorting commands alphabetically (using the linker table mechanism). Signed-off-by: Michael Brown

[digest] Add commands for all enabled digest algorithms

2025-08-06T12:17:25+00:00

Add "sha256sum", "sha512sum", and similar commands. Include these new commands only when DIGEST_CMD is enabled in config/general.h and the corresponding algorithm is enabled in config/crypto.h. Leave "mdsum" and "sha1sum" included whenever only DIGEST_CMD is enabled, to avoid potentially breaking backwards compatibility with builds that disabled MD5 or SHA-1 as a TLS or X.509 digest algorithm, but would still have expected those commands to be present. Signed-off-by: Michael Brown

[crypto] Add definitions and tests for the NIST P-384 elliptic curve

2025-01-30T15:35:34+00:00

Signed-off-by: Michael Brown

[crypto] Add definitions and tests for the NIST P-256 elliptic curve

2025-01-28T16:57:40+00:00

Signed-off-by: Michael Brown

[tls] Allow for NIST elliptic curve point formats

2025-01-21T15:55:33+00:00

The elliptic curve point representation for the x25519 curve includes only the X value, since the curve is designed such that the Montgomery ladder does not need to ever know or calculate a Y value. There is no curve point format byte: the public key data is simply the X value. The pre-master secret is also simply the X value of the shared secret curve point. The point representation for the NIST curves includes both X and Y values, and a single curve point format byte that must indicate that the format is uncompressed. The pre-master secret for the NIST curves does not include both X and Y values: only the X value is used. Extend the definition of an elliptic curve to allow the point size to be specified separately from the key size, and extend the definition of a TLS named curve to include an optional curve point format byte and a pre-master secret length. Signed-off-by: Michael Brown

[crypto] Allow for extraction of ASN.1 algorithm parameters

2024-08-28T12:03:55+00:00

Some ASN.1 OID-identified algorithms require additional parameters, such as an initialisation vector for a block cipher. The structure of the parameters is defined by the individual algorithm. Extend asn1_algorithm() to allow these additional parameters to be returned via a separate ASN.1 cursor. Signed-off-by: Michael Brown