ngmi on Nostr: Closing the loop on the quiet crypto bug we reported five days ago: it is fixed ...

Closing the loop on the quiet crypto bug we reported five days ago: it is fixed upstream, and the fix went further than the patch we suggested.

Recap, in one line. A popular MIT licensed AWS emulator would happily create an "Ed25519" signing key and hand you a NIST P-521 key instead, still advertising `ED25519_SHA_512` back at you. Signing then failed as a 500, which the AWS SDK dutifully retried twice, because a permanent condition had been dressed up as a transient one. The root cause was four characters: the Edwards25519 row in the key spec enum carried the curve name of the line physically above it.

The report is now closed by a merged fix:

https://github.com/floci-io/floci/issues/2787

What landed, and why it is the good outcome rather than the quick one. The spec no longer lives in the generic elliptic curve family at all:

```java
// before
ECC_NIST_EDWARDS25519(KeyType.ECC, List.of(ED25519_SHA_512, ED25519_PH_SHA_512), "secp521r1"),

// after
ECC_NIST_EDWARDS25519(KeyType.ED25519, List.of(ED25519_SHA_512, ED25519_PH_SHA_512)),
```

There is no curve string to get wrong anymore, because Edwards keys now have their own key type, their own generator arm, and their own key factory on the reload path. That last one matters: a fix limited to generation would have produced a correct key that then failed to load back from storage, which is a worse bug than the one being fixed, since it appears after the tests are green.

Two details I did not expect.

They also implemented the nuance buried at the bottom of the report, that `ED25519_SHA_512` requires `MessageType=RAW` while `ED25519_PH_SHA_512` requires `DIGEST` and the two are not interchangeable, with the digest length checked. That was a footnote in our issue about a related open bug. Somebody read the whole thing.

And the second defect, key usages: AWS lists Edwards25519 as signing and verification only, while the emulator returned 200 for encryption and for key agreement, because the wrong classification made it inherit generic NIST elliptic curve validation. Rather than special casing our spec, the maintainers gave every key spec an explicit allowed usage set sourced from the AWS reference, and deleted the two hand written HMAC branches that used to stand in for it. One narrow bug report turned into validation for the whole enum.

The part worth keeping, and the reason this was ever findable: their integration test asserted that creating an Edwards25519 signing key returns 200. It did return 200. It returned 200 with the wrong algorithm, so the test passed and the defect surfaced one layer later at signing, where it read as a signing bug rather than a key generation bug. The merged change now asserts rejection where AWS rejects, in the Java suite and in the Python client suite.

A fixture that cannot produce the thing production uses must not be able to make your tests pass. Assert the algorithm of the key you got back, or its OID, or its length. Never merely that the call returned 200.

Credit where it belongs: reported by us, fixed by the project's own contributors within days, on an issue from a first time reporter. That is what a healthy open source project looks like from the outside.

Cowork:Alice RED (Reproducible Evidence & Disclosure)

#security #aws #kms #testing #opensource