It works the opposite of what you think it does.
"Enable TLS" merely allows the TLS module to be used to open secure connections, it doesn't force people to not use insecure connections. Some people may not trust TLS from a calculator and so may want to disallow that entirely. Having Enable TLS disabled means the TLS module will disallow the use of TLS on connections, meaning you also cannot connect to anything that requires it.
If people think that setting isn't needed, I'll remove it, but it's there for a bit more user control.

https://i.imgur.com/SMSzNbg.jpeg

New test UI. From the main app, it will be possible to run a few tests.
Testing reveals that it..works, but bottlenecks at around 8-10 rapid refreshes (consistent with, you know, serving HTTP from a calculator...small TCP window sizes, small max TCP queue, small max TCP PCB slots). However, with a sizeable drop in WAIT_TIME, resources free up quickly, recovery is more sane and more stable.

https://i.imgur.com/MPYvlgw.mp4

A recording of the several network tests now implemented within lwIP.
Didn't run HTTP because there's no... verify it works on calc. You'd just go to the IP address the calc gives you.
Ping doesn't work yet.
NTP works... sometimes.

Update

I have published a pre-release of lwIP-CE.
https://github.com/cagscalclabs/lwip-ce/releases/tag/v1.0-pre
This pre-release is intended to let people experiment with the existing network tests in their own environments to confirm stability. People may also spin up their own tests if they wish. Report any issues in this thread or in the discussion on Github:
https://github.com/cagscalclabs/lwip-ce/discussions/38

TODO:
Wire in x25519 from the contest, and complete TLS support
Dylib/entrypoint support

Update

A few things to report.
Firstly, PT_ was the winner of the x25519 contest. So congrats to him. Algorithm times to about 5 seconds, and he and ti_kid seem to continue to work on improvements. I much appreciate the work on that, even though it did come with a non-trivial prize.

And as of that, with the exception of the slight snag of the virtuals + app quirk, we should now have the ability for the TI-84+ CE to implement the entire TLS 1.3 client-side without issue.
That means:

Code:

Additionally everything that is in CryptX will also be exposed within lwip=>tls. You will no longer need CryptX once this is released as a dylib.

There is a TLS test now added to the configuration wizard within the app. It lets you open a TLS connection to example.com and verify the response.

Also also, I reworked the ASN.1 parser system (it was a bit unintuitive), and broke the keyobject module into pkcs8 and x509 modules for simplicity and code separation. Here's a screenshot of the two new unit tests on CEmu.

And now I have a question. Does anyone specifically want me to implement within lwIP a viewer UI for showing the DER tree for keyfiles? As in, you can scroll through an iteration of TLV pairs, view how the bytes break down, etc? Or is the parser logic enough for people?

Does this mean that we can access the internet on the CE without any specialized hardware now?

You'd need an adapter and an Ethernet cable.
USB mini to USB A adapter => connect to calc
USB A to Ethernet adapter => connect to the above adapter
Ethernet cable => connect to router and above adapter

You could also connect via Ethernet to an Ethernet to WiFi-N adapter, but you'd need one with WiFi Protected Setup because there's no drivers for actually interacting with the adapter from the calc.

Update

I endeavored to add a timing consistency test to the array of unit/module tests for lwIP. The test is under tests/tls_timing.
https://github.com/cagscalclabs/lwip-ce/actions

It checks all primitives or modules that require constant time. This is:
random_bytes, secure_compare_bytes, SHA-256 (& HMAC), AES-CBC, AES-GCM, HKDF, PBKDF2, and x25519. RSA is currently omitted as I try to figure out what vectors it would need.

This test takes ~30 minutes to run via the cemu-autotester and would undoubtedly take hours to run on a calculator; that being said I encourage people to run it on their calculators if you can spare the time. I want to see:
1. If it fails a specific test category for anyone
2. What the averages are for specific tests

For #2, build the test with with the -DTLS_TIMING_VERBOSE compiler flag. That will make it print stability and differential data so I can review to confirm if our thresholds (particularly for differentials) are sane. Please post the verbose output to this thread, alongside your hardware revision and OS version, if you run it that way.

What do the two tests mean?
We test timing in two categories: stability, which is meant to capture jitter, and differential, which is meant to capture differences in timing based on a class of input.

For the stability test: Identical inputs are executed repeatedly. The primitive passes if the standard deviation of CPU cycle counts remains below 1% of the mean runtime. Any primitive exceeding this threshold fails.

For the differential test: Inputs are grouped into the following structural classes: best-case, worst-case, random, edge-case. Each class is executed multiple times. If a single class exhibits a statistically consistent runtime deviation from the others (>=75% of runs trending higher in the same direction beyond configured cycle thresholds), the primitive fails. The current thresholds are printed in the job summary for the test on github.

Update

Yet another progress update.
I have obtained v15 of the new CEdev toolchain and completed the migration of this project to the new toolchain.
This included converting fasmg assembly to GNU assembly with help from TIny_Hacker on x25519.

I had Claude run through the handshake code and streamline/optimize/flesh out what I'd already written, and we can now boast handshake reassembly and what should be a stable TLS handshake.

There is now a full whitepaper published for this project that provides attribution, introduction, why I did this, documents the membuffer and Ethernet implementation, documents the TLS implementation including min-entropy, calibration for correlation, the custom trust model, the threat scoping, cryptoguard, test harnesses, AI tooling disclosure... pretty much everything. If anyone cares enough to do some highly technical reading, link is: https://github.com/cagscalclabs/lwip-ce/releases/tag/whitepaper-latest

Additionally, we now have 3 harnesses:
1. Internally-hard coded RFC vectors (unit tests)
2. Timing analysis profiling (which can be a bit wonky on CEmu, hardware runs are more reliable)
** I have now added an ACVP- (Automated Cryptographic Validation Protocol) style test. I had to do an alternate style because we have no means of connecting the calculator yet directly, so the current test works by fetching the CAVP vector sets from NIST for: SHA, HMAC, and AES, then supplementing the ones that don't have a CAVP vector or where the set doesn't match our assumptions (like RSA) with samples from python3-cryptography and the RFCs to provide a proof ACVP-adjacent correctness.

Incidentally, the addition of the ACVP tests did reveal an un-covered edge case in AES and in RSA-PSS, so it's a good thing I added it.

All that remains is figuring out some linker shenanigans in APP building mode to get x25519's relocation to work right, embed the function table, code the LIBLOAD stub library... and then we should have this RC-ready.

Update

A feasible plan for getting lwIP to work as a dylib is now... being experimented with:

Memory Segmentation
1. lwIP uses about 5k of BSS/data for internal structures, state, immutables, etc. This means that for this specific use case, we can set BSS_HIGH to BSS_LOW + 6k (reserving enough space for its data + some headroom).
2. This means that any program using lwip will need its BSS_LOW set to BSS_LOW_DEFAULT + 6k.
3. For dynamically-allocated resources (pbufs, tls, ring buffers, etc), lwIP must share heap with the caller. Either through initializing the memory system statically, or dynamically.

Import/Export Environment
1. We must assume that lwIP (the app) and lwIP (the LIBLOAD stub) are agnostic of each other in terms of entry-points.
2. lwIP will bake into itself a function table of all of its internals stubbed as "app_start - function_loc".
3. lwIP will then encode a pointer to that table into its header somewhere as an "app_start - exports_table_ptr".
4. lwIP reserves an imports table into its BSS memory for malloc, free, and realloc as well as all the USBDRVCE dependencies.
5. lwIP will also include within its own code a `lwip_init_runtime_internal() function that calls its own crt/memory init routines, and also copies the pointer and size given to it to the imports table.

lwIP Stub
1. An lwip.s file will be created by `make dylib` which will contain a LIBLOAD-valid build that will, for all intents and purposes, act as though the lib is lwip. This means that every function exposed within the app will be indexed in the stub, with every function stubbed as just a "ret". The stub will also `include_library` USBDRVCE and have a function table carrying every symbol lwip will use, in the same order the import table expects them, as well as an entry for malloc, free, and realloc.
2. It will also contain a function `lwip_init_runtime` which patches the libload-state of the library according to how lwip works.

Load Bootstrapping
1. When LIBLOAD inits the lwIP stub, usb functions included become a valid jump table, but the lwip exports are still stale (since they point to the stubbed functions, not the App).
2. The user must first call `lwip_init_runtime`. This function will locate the lwIP App, find it's exports table, and then patch the exports table into entry points to the App.
3. Once the libload exports table is patched, the stub can now call "lwip_init_runtime_internal" with pointers to the imports table. Internally, lwIP, with awareness of it's own memory allocations, can initialize its BSS/data sections (by either calling or re-implementing the crt routines), and then copy the LIBLOAD imports table to the BSS so that the lwIP app has valid external call-sites.

By this point, the LIBLOAD stub can reference the app properly, and the App can call to its dependencies due to the imports table in RAM.

Where I still need to figure stuff out:
1. Properly linking the exports table.
2. Embedding the offset to the exports table into a fixed location in the App.
3. How to initialize BSS/data sections of the App (ie the runtime_internal function)

The final build of this project is blocked on a relocation error. Once this is resolved, we should be on to the test phase of this project:


Code:


Seems to happen when APPLICATION = yes is set. And the error is coming from the relocation inside x25519 code. Can anyone who understands the linker and what's supported where perhaps take a look and help me resolve this.

Edit: Probably could have done with adding this to this thread instead of adding it on via SAX later so here it is:
- Initially, lines like https://github.com/PeterTillema/X25519_submission/blob/master/src/x25519.s#L166 were triggering errors, so TIny wrote a linker script: https://github.com/PeterTillema/X25519_submission/blob/master/relocate.ld. This fixed it for programs, but Applications now give the relocation error.

Can you try this convbin and see if it behaves any better?
Just a random guess, I haven't tried it myself.