raw ed25519 keys

[devsnek]

do we have a way to do crypto with raw keys, like how libsodium works? for example, createPublicKey won't accept the raw key as far as I can tell.

cc @nodejs/crypto

[mildsunrise]

Sorry, I posted #3000 (comment) before noticing this. What does "raw key" mean in a generic context? For EdDSA specifically it does make sense (since the private key is just a bit string), but other algorithms have multiple parameters so not sure what "raw key" would mean there...

[devsnek]

@mildsunrise Yeah I just mean in the context of EdDSA. If you use something like libsodium's crypto_sign_verify_detached you can just pass in the raw bytes of the key, so I'm curious if node's crypto (openssl?) supports that.

[mildsunrise]

But libsodium's API works specifically with ed25519, right? Our API is generic, so I'm not sure how we'd do that...
In fact I'm not even sure you can do that with libsodium at all, isn't pk supposed to be opaque to the user?

We could add an ed25519-specific format in addition to pem and der which would only work with ed25519 keys, i.e.:

const k = privateKey.export({ format: 'ed25519_raw' }) // returns 32-byte buffer
createPrivateKey({ key: k, format: 'ed25519_raw' })

But that looks hacky... and we'd need to do that for every EdDSA algorithm.

[rumkin]

IMO It shouldn't be ed25519_raw, it should be just raw. Because ed25519 is a name of the curve, while pem, der, spki is a name of format/container. In the case of raw key the info about curve name could be added by developers after key export. And It should be so for any key which could be exported as a sequence of bytes. For example:

const u8a = privateKey.export({ format: 'raw' })
createPrivateKey({ key: u8a, format: 'raw', type: 'ed25519' })

I'd also suggest to export object format to let exported key be presented as JS values. Something like this:

const {key, type, curveOptions} = privateKey.export({ format: 'object' })
key // Uint8Array
type // String "ed25519" or "rsa"
curveOptions // Object

[jasnell]

Currently no, in fact there's a TODO comment in the native code that asks if we should support raw curves. I think it's a good idea but we'd certainly need someone to do the implementation (I can add it to my list but it would be a while)

[devsnek]

@jasnell In that case I'll open a tracking issue 👍

[rumkin]

It seems like there is no issue for that, is this task still relevant?

[RaisinTen]

createPublicKey won't accept the raw key as far as I can tell

@devsnek I'm not sure I understand what you mean. This works:

const { generateKeyPairSync, createPublicKey } = require('crypto');
const { publicKey, privateKey } = generateKeyPairSync('rsa', {
  modulusLength: 4096,
  publicKeyEncoding: {
    type: 'spki',
    format: 'pem'
  },
  privateKeyEncoding: {
    type: 'pkcs8',
    format: 'pem',
    cipher: 'aes-256-cbc',
    passphrase: 'top secret'
  }
});

const publicKeyObject = createPublicKey(publicKey);

right?

[markg85]

Is there an update on this?
I'm communicating with different apps in these keys and all of them have an (perhaps annoying) tendency to use RAW keys.
Only nodejs has - when raw is used - headache causing issues to make it work there.
An approach is to convert the raw key into the JWK format as the contents of that is raw too... But that just feels ugly.

[markg85]

Just thought i'd leave an update here for either my future self or someone else hitting this issue again.
This article describes how to use RAW keys in nodejs: https://keygen.sh/blog/how-to-use-hexadecimal-ed25519-keys-in-node/ it essentially makes the DER wrapper.

And in case the article is offline. Here's the quick version + code.

function toDER(hex) {
  const key = Buffer.from(hex, 'hex')
 
  // Ed25519's OID
  const oid = Buffer.from([0x06, 0x03, 0x2B, 0x65, 0x70])
 
  // Create a byte sequence containing the OID and key
  const elements = Buffer.concat([
    Buffer.concat([
      Buffer.from([0x30]), // Sequence tag
      Buffer.from([oid.length]),
      oid,
    ]),
    Buffer.concat([
      Buffer.from([0x03]), // Bit tag
      Buffer.from([key.length + 1]),
      Buffer.from([0x00]), // Zero bit
      key,
    ]),
  ])
 
  // Wrap up by creating a sequence of elements
  const der = Buffer.concat([
    Buffer.from([0x30]), // Sequence tag
    Buffer.from([elements.length]),
    elements,
  ])
 
  return der
}

Put that function in your code and use it with:

toDER(your_32_byte_key_as_string);

And all is happy :)

My own addition, as i needed it for X25519, is to replace:

const oid = Buffer.from([0x06, 0x03, 0x2B, 0x65, 0x70])

with

const oid = Buffer.from([0x06, 0x03, 0x2B, 0x65, 0x6E])

It's only the last 0x70 replaced by the 0x6E. And those values come from the nodejs documentation itself: https://nodejs.org/api/crypto.html#keyobjectasymmetrickeytype

Hope this helps someone out.

[devsnek]

ed25519 and such can be used directly with node's subtlecrypto api: https://nodejs.org/api/webcrypto.html#ed25519ed448x25519x448-key-pairs

[panva]

FYI nodejs/node#62240

[markg85]

Wow, so it took nodejs ~6 years (probably longer if you look at other reports) to catch up. Great!
It's not like this cryptography standard is brand new. It started ~11 years ago.
Meanwhile every other remotely serious language has support and had it for years.

[panva]

Open source moves at the speed of contribution, and Node.js is a volunteer-driven project. If this was critical for 6 years and nobody stepped up to implement it, it probably says more about its criticality than about Node.js.

Contributions are always welcome, that way the next feature you need won't have to wait for someone else's volunteer time.

[markg85]

I get your opinion and in general that is true! But it's not in this case.

I'm well aware of implementations made years ago to a working shape but the w3c or whatever standard that was voting on the web SubtleCrypto API was being a pain in the ass in accepting it. And apple's deviation (or rather more strict standard implementation) didn't help either. Nodejs is affected by that too as it follows these standards. Implementing a non-standard path is understandably not recommended (and blocked) as it means your nodejs code can't be "compiled" to work on the web. And that path delayed it a lot. It's only since ~may 2025 that it became supported enough and that's the point where nodejs can jump in.

[omghante]

Great to see raw key format support (raw-public, raw-private, raw-seed) finally landing via nodejs/node#62240! This was a long-awaited improvement no more manually wrapping raw bytes in DER containers.

While exploring the crypto internals around this area, I noticed a related (but separate) issue worth flagging — the cachedResult() mechanism used by crypto.getCiphers(), crypto.getHashes(), and crypto.getCurves() doesn't invalidate when OpenSSL state changes (e.g., via crypto.setFips() or crypto.setEngine()).

This means if new algorithms become available after an engine/provider is loaded (which could be relevant for custom EdDSA providers), the cached lists won't reflect them.

I've opened a separate discussion about this here: https://github.com/orgs/nodejs/discussions/5148

Curious if anyone who worked on raw key support ran into the same caching behavior during development?

[panva]

• setFips() / setEngine do not evict ciphers cache node#62982
• crypto: evict getCiphers/getHashes cache on setFips/setEngine node#62985