Change Edgeview Token Hash size to full 256-bit SHA-256

[naiming-zededa]

Description

• a simple change, but would break the backwords compatibility due to EVE devices may continue to run with the older version images
• this patch will for now, try the full size first, if we don't get a match, then tried the original hash size of the token. We can remove the short version later on if we are sure all the EVE devices are upgraded to at least this version
• the dispatch currently supports 'probing' message, this patch utilize this feature to probing to see which size we are going to use.

PR dependencies

How to test and validate this PR

1. load the EVE image w/ this patch on device, then use the client to verify it is working
2. use the latest Edgeview container w/ this patch, and connect to the previous version of EVE image device and make sure it also works.

Changelog notes

Change Edgeview Token Hash size to full 256-bit SHA-256

PR Backports

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR

For backport PRs (remove it if it's not a backport):

• I've added a reference link to the original PR
• PR's title follows the template

And the last but not least:

• I've checked the boxes above, or I've provided a good reason why I didn't
  check them.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 28.08%. Comparing base (2281599) to head (d1812a2).
⚠️ Report is 187 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5541      +/-   ##
==========================================
+ Coverage   19.52%   28.08%   +8.55%     
==========================================
  Files          19       19              
  Lines        3021     2314     -707     
==========================================
+ Hits          590      650      +60     
+ Misses       2310     1520     -790     
- Partials      121      144      +23     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eriknordmark]

Code LGTM.

But I don't understand the text in the description about needing to keep the fallback around until all EVE nodes being updated. Isn't it all the dispatchers which need to be updated? [If so, can we release updated dispatcher containers and push for folks to run the latest to reduce the amount of time we need to keep the fallback in place.]

[naiming-zededa]

Code LGTM.

But I don't understand the text in the description about needing to keep the fallback around until all EVE nodes being updated. Isn't it all the dispatchers which need to be updated? [If so, can we release updated dispatcher containers and push for folks to run the latest to reduce the amount of time we need to keep the fallback in place.]

No, the encryption here is on the payload of edgeview message, which is transparent to dispatcher. The idea is if the dispatcher is compromised, the hacker still can not decode the edgeview message.

[eriknordmark]

Code LGTM.
But I don't understand the text in the description about needing to keep the fallback around until all EVE nodes being updated. Isn't it all the dispatchers which need to be updated? [If so, can we release updated dispatcher containers and push for folks to run the latest to reduce the amount of time we need to keep the fallback in place.]

No, the encryption here is on the payload of edgeview message, which is transparent to dispatcher. The idea is if the dispatcher is compromised, the hacker still can not decode the edgeview message.

Does that mean that the all edgeview clients need to be updated before we can remove the short key support from EVE?

[naiming-zededa]

Code LGTM.
But I don't understand the text in the description about needing to keep the fallback around until all EVE nodes being updated. Isn't it all the dispatchers which need to be updated? [If so, can we release updated dispatcher containers and push for folks to run the latest to reduce the amount of time we need to keep the fallback in place.]

No, the encryption here is on the payload of edgeview message, which is transparent to dispatcher. The idea is if the dispatcher is compromised, the hacker still can not decode the edgeview message.

Does that mean that the all edgeview clients need to be updated before we can remove the short key support from EVE?

yes. so I'm really wondering if we should do this PR or not.
I had a wrong reply above that i thought it was encryption case. but this one is just a hash to be used as 'index'. but both sides, the client and the eve device side need to send the same hash for 'index'.
so, 32bytes is better, but this backwards compatible thing is difficult to support.