-
Notifications
You must be signed in to change notification settings - Fork 85
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
Change loader signature to ed25519-prehash (next-rev hw) #503
Comments
Also, fwiw, I heartily agree with the code comments in the ed25519 crate, ranting about the implementation of the ph scheme and not being able to specify your own nonce, but for my own reason: splitting the hash op is terrible for hardware hashers: Included in full here because links to other repos don't inline: // This is the dumbest, ten-years-late, non-admission of fucking up the
// domain separation I have ever seen. Why am I still required to put
// the upper half "prefix" of the hashed "secret key" in here? Why
// can't the user just supply their own nonce and decide for themselves
// whether or not they want a deterministic signature scheme? Why does
// the message go into what's ostensibly the signature domain separation
// hash? Why wasn't there always a way to provide a context string?
//
// ...
//
// This is a really fucking stupid bandaid, and the damned scheme is
// still bleeding from malleability, for fuck's sake. Glad I'm not alone in writing cathartic rants in code comments. |
Here are the impacted locations by this problem: loader self-signing xous-core/services/root-keys/src/implementation.rs Lines 2683 to 2792 in cff2473
bootstrap signing by the image creator xous-core/tools/src/sign_image.rs Lines 65 to 67 in cff2473
low level bootloader verification This all has to fit in 32k of code space. The API looks innocent: ...but the magic happens here: Basically, the crates are all monkey-patched to use hardware acceleration, and the hardware accelerators are hand-initialized before the calls (and cleaned up afterwards) to ensure it works for the context of the boot environment. |
This is a note mainly for @bunnie when implementing the next-gen hardware.
We should switch the loader verification to the ed25519-ph scheme. It is now standardized and using the pre-hash mechanism gives us the flexibility we need to parcel out the loader for fast hardware computation without having to re-implement tricky crypto APIs.
This is not done on the 1st-gen Precursor devices because it would involve a SoC update and a tricky re-factor of the extremely tiny, highly optimized ROM bootloader, which itself involves plenty of dangerous tricks to get it to fit into such a small space.
Basically, "don't fix it if it ain't broke", but "do it better next time".
And, the issue will hopefully help me remember to do it better next time, since I revisit the issue board regularly for old reminders like this.
The text was updated successfully, but these errors were encountered: