You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I can't use poly1305 separately from chacha20-poly1305. Some algorithms (e.g. chacha20-poly1305 in OpenSSH) require the operations to be separate due to limitations/restrictions of chacha20-poly1305 as defined in RFC 7539.
Describe the solution you'd like
To be able to use poly1305 as efficiently as possible, whether it's via crypto.createHmac() or crypto.sign() or something else.
Describe alternatives you've considered
Unfortunately there are none, except doing poly1305 in pure javascript, which I assume is going to be pretty slow in comparison.
Ah, your mention of crypto.createHmac() threw me off.
crypto.sign(null, data, privateKeyObject) in theory supports poly1305 out of the box but there's currently no way to construct an EVP_PKEY that's acceptable to EVP_DigestSignInit().
We'd need to slot in a call to EVP_PKEY_new_raw_private_key(EVP_PKEY_POLY1305, key, len) somewhere but I'm not sure where.
I closed the PR and I'll take the liberty of closing this issue because it's about poly1305 only, whereas exposing EVP_MAC is a more general way forward.
If you're interested in that, can you open a new issue to hash out1 the details?
Activity
bnoordhuis commentedon Mar 23, 2020
I'm not 100% sure but I don't think openssl currently supports this, at least not directly.
There might be a way around that by registering a custom digest:
But whether extending openssl like that is something we should do, is a separate question. You should probably file an upstream issue.
mscdex commentedon Mar 23, 2020
Supposedly it's already supported via the EVP_PKEY API, so maybe it just requires some minor changes on the node side?
bnoordhuis commentedon Mar 23, 2020
Ah, your mention of
crypto.createHmac()threw me off.crypto.sign(null, data, privateKeyObject)in theory supports poly1305 out of the box but there's currently no way to construct anEVP_PKEYthat's acceptable toEVP_DigestSignInit().We'd need to slot in a call to
EVP_PKEY_new_raw_private_key(EVP_PKEY_POLY1305, key, len)somewhere but I'm not sure where.I'll open a conversation starter PR.
crypto: make crypto.sign() support poly1305 mac
bnoordhuis commentedon Mar 23, 2020
#32448
github-actions commentedon Mar 8, 2022
[-]crypto: poly1305 not supported as hmac[/-][+]crypto: poly1305 message authentication code[/+]bnoordhuis commentedon Jul 11, 2022
@mscdex is this still someone you want to see? I have an old open PR but updating it is probably quite a bit of work.
mscdex commentedon Jul 11, 2022
Yes it is still something I'd like to see. Right now I'm having to use a WASM-based implementation, which I'm not really fond of for various reasons.
bnoordhuis commentedon Dec 7, 2022
I closed the PR and I'll take the liberty of closing this issue because it's about poly1305 only, whereas exposing EVP_MAC is a more general way forward.
If you're interested in that, can you open a new issue to hash out1 the details?
1 mac out?
crypto: add a generic MAC API
test: use native builder for legacy SEA tests
crypto: add a generic MAC API
crypto: add a generic MAC API
crypto: add a generic MAC API
crypto: add a generic MAC API
crypto: add a generic MAC API
crypto: add a generic MAC API
crypto: add a generic MAC API
crypto: add a generic MAC API