Authentication speed improvement

[ihrapsa]

I know it's early, but was wondering if you've experimented with ways of improving the authentication speed. I'm noticing some slight delay when authenticating. It's not awful but noticeable, maybe because I've seen how fast the authentication can get (on official locks or with @kormax's nfcpy UART home-key-reader project).

Did some quick tests and the whole transaction is taking about 1.25-2 s on the ESP32 while only 220 ms with the nfcpy project, both on fast transaction flow, the latter feeling instant.

esp32	esp32
esp32.mov	nfcpy.mov

There's certainly a hardware limitation implicated as well but I'm bringing this up here in case we can improve latency somehow.

[kormax]

I have no idea on how the ESP32 deals with crypto performance and what the possible improvements can be done, but wanted to add my two cents regarding this topic:

The way FAST transaction is implemented, it requires reader to brute-force (search) all possible cryptograms at runtime.
Depending on a number of users enrolled into a lock, it could actually be faster to automatically fallback to STANDARD flow, as even though it requires more data exchange, there would be less (slow?) crypto done.

[kormax]

Also, could be useful to test (timestamp) the FAST/STANDARD methods to find the bottleneck. It could be that the issue is not with crypto but with something else (NFC driver, etc?).

[rednblkx]

yeah, it's basically what kormax says, however that may be only part of the current slowdown as looking at the logs it seems that it hangs when reading the public key and x coordinate during this part main.cpp#L1224C1-L1227C132.
for the reader and the endpoint i can store the data and retrieve it when needed, however that still leaves us with the ephemeral keys which are well.....ephemeral, they change and i'll need see what i can improve when i get there, it may just be something very stupid since this current version was only made to just work not be efficient as that can come later.

[rednblkx]

Hello again,

I’ve made some modifications as part of my planned restructuring and also made some optimizations along the way.

Through my testing, the fast flow should now be around 580 ms when only one device is enrolled, haven’t yet tested it with multiple devices and the standard flow is just under 2s at around 1.9s

Give it a go when you can and let me know how it goes.

Make sure to erase the ESP as I’ve made some changes to the data structure.

[rednblkx]

That's great!

My guess on why it did not work the first time would be that the second device hasn't provisioned it's key which seems to only happen at setup that is then handled by this function here and so the lock had nothing to authenticate with if that did not happen or if it failed.

I still need to setup some more logging in order to get a more clear picture whenever something happens or doesn't, also currently the default log level is set to INFO, you can change it at runtime with the command @LN for none or @LD for debug or @LV for verbose, just for future reference.

I have also added a command to use the STANDARD flow always as it's useful for testing, just type @F1 for it or @F0 to go back to FAST. A web interface will be available in the future for all the stuff since you wouldn't have access to serial if you stick it on your door or something :))

[rednblkx]

@thorsten-gehrig MQTT will be coming soon once i'm done with some stuff.

[thorsten-gehrig]

great - thanks.
It looks like on the new code I don't see a "regular NFC Tag" presented to the reader - did you removed that?
It´s crucial for me to have those Card-ID also reported to NFC...

Beside that: it seems the new code didn't worked for me - I´ve tried it twice (with an iPhone 14 and Apple Watch 8). Reseted everything - but still not working (log shows plenty of stuff - but no success)

Best
Thorsten

[thorsten-gehrig]

Additional question: regarding the speed - is it possible to throw just more CPU on the code?
Is an ESP32-S3,C3 or C6 faster than a regular ESP32?
I didn't found a "performance-comparison"... but would expect an LX7 or an RISC-V might be faster than a LX6 CPU...
(obviously code optimisation is the first option - but more CPU power is most likely a benefit)
Best
Thorsten

[rednblkx]

i have opened a new issue #5 where we'll debug this problem.

On the subject of reading a "regular NFC tag", the functionality is still there as it's reading every tag on proximity, is just not logged and it will be added fully once the whole homekey implementation is more stabilized.

In regards to the using a different esp32 model, something like an ESP32-S3,C3 or C6 could potentially be beneficial to the cryptographic operations, however, i do not currently have any of those in possesion so i can't say exactly if that's the case but for the time being i'm focusing on optimizing the code.