This is an issue I have been having as well, and I have about 5 adapters lying around that I've bought specifically for testing this project.

2 of them are Gigabit adapters, both are NCM. This may be a reliable thing.
1 of them is 10/100/1000 (also listed as Gigabit). It is also NCM.
It might be reliable that Gigabit adapters are NCM.

1 of them is 10/100 (Cablecreations). It is ECM.
A final one was 10/100. It is vendor-specific and thus did not work.
I could test more of these out.
I also have an Ethernet to WiFi-N with WPS adapter for testing that and it works as well. If there is a standard for SSID checking and selection (can we implement wpa_supplicant?), we may be able to support them too.

Regarding TLS, it seems our best bet for max compatibility for 1.2 is to support:
ECDSA Certificates: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
RSA Certificates: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
For TLS 1.3 we could use:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
or implement AES-CCM.
*SHA-384 not currently implemented

So to sum up...
For TLS .12

- Ephemeral Elliptic Curve Diffie-Hellman w SECP256k1
- RSA encrypt/decrypt/sign, min 2048 bits
- AES-128-GCM (already implemented)
- SHA-256 (already implemented)

and to support TLS 1.3, the following additional

- SHA-384

Lastly, here are a list of issues that are currently open for TLS support and assistance welcome. If anyone has time, knowledge, feel free to nab one and complete it, then pull request to the TLS branch.

https://github.com/cagstech/lwip-ce/issues/11
https://github.com/cagstech/lwip-ce/issues/12
https://github.com/cagstech/lwip-ce/issues/14
https://github.com/cagstech/lwip-ce/issues/15

Updates

0. https://www.youtube.com/@cagstech Any videos and content related to this (and my other projects) will use this channel now.

The recent pushes have been mostly quality of life, stability improvements, error handling, and preparations for app-library support if that ever gets implemented within the toolchain.

1. A function table of every exposed function in the raw API gets generated within the app now. For now we don't do anything with it; that is on the app-lib implementation to sort out and then I can make any necessary modifications.

2. A user has to pass the program's malloc and free functions as well as an lwIP heap limitation. This defaults to about 16kb but can be as high as the user needs. The app will probably claim space at the end of the BSS, meaning usages of the app as a library will need to set their own heap usage to ensure no conflicts.

3. With a slight addition to the Ethernet event callback, the driver now supports hubs. This can include a hub with a builtin Ethernet port (so long as it provides an ECM or NCM interface) as well as an Ethernet adapter connected via a hub. For example I tested with this hub this morning: https://a.co/d/iAc5h0U. If you use just the hub, it initializes the builtin port. If you use the hub AND another Ethernet adapter, it detects and initializes both--on interfaces en0 and en1.

4. The driver can support up to 8 simultaneous interfaces each marked by a flag. When all bits in the flag are set, no new interfaces can be assigned. The code nicely handles setting the correct bit when adding a netif, unsetting the bit when removing it, detecting the next available bit. And that bit (shift count) in turn controls the ifnum that is assigned to the netif. The user can call eth_get_interfaces(); to return a uint8_t which indicates all the interfaces assigned (bit 0 => en0) and a set bit meaning a device is present. A user can hold the previous state of these flags in their program memory and react to one of the bits changing appropriately.

5. More robust error handling within the USB layer. On failure of either the interrupt endpoint or the bulk rx/tx endpoints, the transfer is retried up to a max number of times. Upon hitting that, the device is disabled with "reset_with_error". This then triggers a reset of the device, a reconfiguration of the device, and then, the device being set back up for use...with the original netif still bound. It is my hope that this system allows lwIP to be able to hold onto existing resources bound to that netif despite the underlying usb device having been reset. I may let users configure some of this behavior within a modded lwip_init.

TLS PROGRESS

Hashes, sha-256 and hmac are ported
The secure RNG is ported.
I posted a separate topic asking for some assembly help with two math routines: https://www.cemetech.net/forum/viewtopic.php?t=19817. Please, if someone can help with these, I would be eternally grateful.

After discussions with some individuals on SAX and Discord (and over the objection of one :p) I have elected to focus on TLS 1.3 for this implementation. It has a shorter, more robust handshake with less processing, and that would probably make it measurably faster on calc.

TLS Implementation Progress

lwIP has been seeing strides towards a full TLS infrastructure baked into ALTCP with an exposed API for people to use for other purposes. Here are some of the recent bits of progress.

1. SHA-256 is ported, HMAC wrappers are ported.

2. TLS rand is ported with a new algorithm that is computed to produce even more entropy than the previous... 100.2 bits of entropy per u64. See computations: https://github.com/cagstech/lwip-ce/blob/tls/src/tls/INFO.md. The probabilities are based off the maximum allowable bias in the sampling.

3. AES CBC and GCM modes are ported -- I am dropping CTR. It's redundant of GCM but lacks authentication. CBC is there for file encryption mainly.

4. Base64 and ASN.1 are ported and an ASN.1 encoder is now provided as well. ASN.1 decode sports a better UI:

Code:

Simply initialize the decoder with "init" and then loop "decode_next" until false is returned. This function automatically traverses the tree structure properly.
It also takes an optional parameter (NULL to omit) that is a schema. Essentially this allows you to create arrays of structs containing schema data for what field names, tag values, some flags, and depth are expected in various positions in the struct. The schema struct also has fields for if a tag is optional (a mismatch returns true anyway), whether null is allowed, or if this field output is wanted (if this is passed as false, the passed pointers to len, tag, data, and depth are not touched). To see how the schema allows for easy parsing, check out https://github.com/cagstech/lwip-ce/blob/tls/src/tls/core/keyobject.c

5. It follows from the previous but decoding of PKCS#1, SEC1, and PKCS#8 public and private keyfiles is now fully supported. The user can generate a .pem file with openssl, run it through convbin to create an .8xv, send it to their calc and it should be recognizable by the keyobject module. This includes encrypted private keys although -- and this is very important -- the only algorithms that are supported for this are: PBES2 (password-based encryption scheme) using PBKDF2_HMAC with SHA-256 and ciphers AES-128-CBC or AES-256-CBC. For reference a command that can create what is needed is:

Code:

Just remember this is a graphing calculator, so you probably want -iter to be something low. Like 100 (a few seconds) or 1000 (~30 seconds).
I plan to support for decoding X.509 structures as well, for reading certificates sent by remotes during handshakes.

And some eye-candy to close it off nicely:

Update to an update

Houston we have X.509 implemented.


Next step is to research commonly used CA roots/intermediary roots and add their public keys to a "trust store" that I will dump into an appvar. Because of the speed of the calc, this will be optional. You can either not send the trust store to your device or enable implicit trust in the tls configurator to not validate certificates.

How would/could I use this?

The usual solution for this is to use something like the NSS root certificates (which are what most open source OSes ship as the system root certificates).

It's not really set up for easy use right now; the easiest way to do it would be to clone the repo and use the tls features by including whatever header you need.

When this is finally made available as a library, you would use it one of two ways.
To implement application-layer cryptography, you use the TLS api directly. There isn't the best documentation right now as its still work in progress, but it will feel somewhat similar to the api of your typical cryptography library.
You should also be able to just use TLS baked into ALTCP via the ALTCP_TLS module. This module connects to a host, and then handles the handshake by a series of callbacks with minimal interaction from the user. With much of the low level API being done, documentation and higher level stuff like handshake handling is next up.

But keep in mind that we still need a FAST ez80 implementation of prime256v1 ephemeral diffie hellman and ECDSA as well as RSA 2048-4096 bits. Without those this is a non-starter.

I've also been thinking about the practicality of implementing the full TLS handshake components, especially the certificate chain parsing. Normally when you connect to a server and it sends you certificates, that's a message containing a chain of certificates:

Code:

In a typical Certificate handling the signature of the leaf is verified with the public key of intermediate[0]. The signature of intermediate[0] is verified with the public key of intermediate[1]. And so on until you hit the last certificate in the chain, which should be be verifiable by one of the roots in your client's trust store.
I am fairly sure that if you do this entire process on the calculator, the remote server connection will time out waiting for the calculator to compute all this. So I'm thinking of a watered-down verification process in which we validate the leaf only, then follow the issuer chain back to a root that is in our trust store by name without actually validating the rest of the signatures. Yes, I know this isn't completely "secure" but skipping some of the intense math is the only way to not make this time out.

why wont text show up on screen until i click [clear]?

Do you have an ethernet device connected, and is it connected to a router?
aaand is it the most recent build?

yes, yes, and yes. it still doesn't work.