-
-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[redbean] Expose more of mbedtls to Lua #1136
Comments
I'd say it's definitely possible and could be quite useful. I've been looking into this (see #966 and maybe #816), but it would be good to figure out which functions would need to be exposed, as there is a large number of them. I'd like to be able to do a key exchange to support let's encrypt integration without resorting to running openssl. Something along the lines of https://github.com/alexpeattie/letsencrypt-fromscratch, but with mbedtls functions called from Lua instead of openssl commands. If you have the correct sequence (and may be C code or pointers to the mbedtls samples), I can probably integrate them into redbean by adding crypto.* namespace. Couple of pointers that may be useful in that regard: https://github.com/srinskit/Crypt/blob/master/Crypt.cpp (C++ wrapper for mbedTLS) and https://mkottman.github.io/luacrypto/manual.html (for the API, although it's openssl-based; maybe crypt.h is enough). |
The link I added to my original messages links to the C source code for a couple of useful mbedtls based programs. I can see each of those programs becoming a Lua function at a higher level of abstraction than mbedtls primitives. |
I think the basics are:
1. Generate keypair (RSA, EC)
2. Encrypt and decrypt
3. Sign and verify signature
That'll cover the majority of the cases and give you a solid base to build
on.
I'm not really concerned with the api at this stage, as long as those
operations are exposed.
…On Thu, 4 Apr 2024, 2:30 pm Paul Kulchenko, ***@***.***> wrote:
I'd say it's definitely possible and could be quite useful. I've been
looking into this (see #966
<#966> and maybe #816
<#816>), but it would be good
to figure out *which* functions would need to be exposed, as there is a
large number of them.
I'd like to be able to do a key exchange to support let's encrypt
integration without resorting to running openssl. Something along the lines
of https://github.com/alexpeattie/letsencrypt-fromscratch, but with
mbedtls functions called from Lua instead of openssl commands. If you have
the correct sequence (and may be C code or pointers to the mbedtls
samples), I can probably integrate them into redbean by adding crypto.*
namespace.
Couple of pointers that may be useful in that regard:
https://github.com/srinskit/Crypt/blob/master/Crypt.cpp (C++ wrapper for
mbedTLS) and https://mkottman.github.io/luacrypto/manual.html (for the
API, although it's openssl-based; maybe crypt.h
<https://github.com/srinskit/Crypt/blob/master/Crypt.h#L58-L110> is
enough).
—
Reply to this email directly, view it on GitHub
<#1136 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABB2XW43ANH65FK3JBHCLNDY3SUKNAVCNFSM6AAAAABFWHUWWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVHEZDQMRVGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I found some of the stuff in redbean already, just not surfaces to the Lua system: cosmopolitan/tool/net/redbean.c Line 2005 in cf9a1f7
cosmopolitan/tool/net/redbean.c Line 1989 in cf9a1f7
|
@jart @pkulchenko what's the minimum functionality you expect from a crypto API based on mbedTLS? In my comment, I listed the 5 basic operations I can think of, is that sufficient or do you want to see something more comprehensive? |
I took the liberty to look at LuaCrypto and try to trim to a proposal that seems doable (and add references to the mbedTLS implementation of each function where applicable). This is pretty much a copy-paste of LuaCrypto reference page, all credit to the authors. The API tries to hide the mbedTLS internals, so in most cases it is not simply a pass-through to the existing mbedTLS API ReferenceParametersdigestA string naming the hashing algorithm to use for a digest operation. The list of supported algorithms may change with each version of the mbedTLS library. The supported algorithms are:
The list of supported hashing algorithms can also be retrieved by using the keyTypeA string representing public/private key type. Can be "rsa", "dsa", "Ed25519" or "ecdsa". cipherThis parameter is a string naming the cipher algorithm used by encryption and decryption. The list of supported hashing algorithms can also be retrieved by using the keyThe string key/password used for encryption/decryption. ivAn optional string initialization vector for encryption/decryption. pad (Not sure this is needed, we could just hide it away at the Lua layer?)An optional boolean flag whether padding should be used. The default is true, which means that input of any size can be provided. Returned date may be larger than input string due to the padding. If explicitly set to false, the padding is turned off and the input data size has to be multiple of block length. Error handlingThe functions throw an error when known invalid parameters are passed, such as non-existent digest/cipher and too large key or initialization vector. Otherwise, the functions return nil, error in case of runtime errors, such as incorrect input size when padding is enabled. Message Digest (hash) -
|
Have you seen our new
So now we have |
RSA is unavoidable to interoperate with basically anything else. The EC algorithms are nice too, you can build Ed25519 on top of Curve25519 but for interoperability you want the NIST curves too (P-256 and friends). You are right around a block cipher, this aims to be a workable first step, not a 100% complete solution. All that functionality is built into mbedTLS, what's missing is the Lua binding. |
MbedTLS has 16398 lines of header files. That's an enormous API surface area, considering it has only 78686 lines of source code. It's not a reasonable thing to ask that redbean wrap the MbedTLS API, because that's asking for literally thousands of interfaces. If you can clarify which specific algorithms you need, then I can write simple Lua APIs exporting them. |
Maybe I'm not explaining myself well (English is not my native language).
In the api proposal document I linked to every mbedtls code that implements
the proposed functions (all the See links) up to the specific line in some
cases. Never suggested that all of mbedtls be exposed, I think that'd be a
terrible idea actually.
Is that not what you mean with "clarify the algorithms"?
…On Fri, 19 Apr 2024, 4:06 pm Justine Tunney, ***@***.***> wrote:
MbedTLS has 16398 lines of header files. That's an enormous API surface
area, considering it has only 78686 lines of source code. It's not a
reasonable thing to ask that redbean wrap the MbedTLS API, because that's
asking for literally thousands of interfaces. If you can clarify which
specific algorithms you need, then I can write simple Lua APIs exporting
them.
—
Reply to this email directly, view it on GitHub
<#1136 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABB2XWZRZJRVEFGJESWD5PTY6CJ3FAVCNFSM6AAAAABFWHUWWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRVG4YTEOBWGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I've recently found myself re-implementing quite a lot of mbedtls functionality within Lua. Is it possible to expose more mbedtls functions/operations (create keypairs, create and validate signatures, parse "pem" files, etc) to the Lua environment?
From a high level perspective, some "programs" in mbedtls (gen_key.c, key_app.c, pk_*.c, ecdsa.c and ecdh_curve25519.c) could be useful to expose as Lua functions.
The text was updated successfully, but these errors were encountered: