Repository navigation
Feature Request: Safe/reliable crypto.KeyObject and webcrypto.CryptoKey detection in userland #38611
Description
Activity
Re
KeyObject: When I designed the new APIs, I intentionally did not expose that class directly. The only reason we did so eventually is such that users can rely oninstanceof KeyObject.I still think it would be a good idea to expose static
.is*()methods in case the method of detection should change in the future (e.g.instanceofto symbol check) as withBuffer.isBuffer()(where the detection method did change over time).Both
instanceof crypto.KeyObjectandinstanceof crypto.webcrypto.CryptoKeywork so long as the code doesn't run e.g. in avmcontext.I think exposing a symbol check function would be better.
CryptoKey.isCryptoKey()is problematic because it extends the standard API in a non-standard way. As I suggest in @panva's PR, we could add both checks toKeyObject:KeyObject.isKeyObject() KeyObject.isCryptoKey()
Alternatively, we could add both to
util/typesconst { isKeyObject, isCryptoKey } = require('util/types'); isKeyObject(obj) isCryptoKey(obj)If the Node.js binary is built without crypto support, these would still exist but would always return
false.I don't have a strong preference where the functions live, just that they're available in some sensible place.
- added a commit that references this issue
on May 18, 2021 - added a commit that references this issue
on May 22, 2026
Currently there are no public methods for checking for
KeyObjectandCryptoKeyobjects. Having reliable checks for these would be very nice to have for userland code that wants to support these types of objects in their code.It seems there are already internal methods for achieving this, but I'm not sure why they are not currently exposed to userland. I was thinking maybe something like how
Bufferhandles this:KeyObject.isKeyObject()andCryptoKey.isCryptoKey(). The former is currently pretty easy to do in userland since it's just doing aninstanceofcheck, but the latter checks "private" symbols, which is not as easy/ideal for userland (although I guess at least currentlyinstanceof CryptoKeywould work?). Either way, having these encapsulated in helper methods would help insulate changes to the checking logic, should it ever change.