Previous version was v0.0.1.1
New version is v0.0.2.1 (don't ask me why I skipped v0.0.2.0)
The most significant change is that the key derivation for the basis
is now split into two keys. One key is used for the page table ECB
encoding, and a different key is used for the data AES-GCM-SIV encoding.
This is because someone much smarter than me looked at my scheme
and said it is very dangerous to use the same key for two different
types of ciphers. This person is correct, so it had to be rectified.
For the System Basis, the keys are encrypted using the root keys
wrapper API. In this case, we simply create two random keys, one for
the page table, and one for the data region, and wrap them using
the root keys API.
For user secret Basis, the derived keys are sent through HKDF
with two different "info" strings to derive a pair of keys from
a common password.
In case the cryptographer who looked at this is reading along,
note that the basis name is encoded as a fixed-length, 0-padded
record, so, we don't encode the length of the basis in the hash
used to derive the keys. When I explained the scheme I thought
I was using a variable-length basis name to derive the key, but
when I checked the code, it's always 64 bytes long, and bytes
that are not used are 0-padded, so, I think we don't need the
length encoding field.
Now that we have full JSON parsing inside xtask, actually parse the
assets API endpoint to determine the correct URL.
Signed-off-by: Sean Cross <sean@xobs.io>
std::time::SystemTime returns time in UTC.
That's great, but a lot of times we want local time.
Unfortunately, we can't use `chrono` to do that, because
chrono figures out what your time zone is usind `libc`, which
is a thing Xous doesn't have.
the `LocalTime` server is Xous' solution to that problem. it
returns the corret time offset based on the time zone.
You can still use `chrono` to convert the returned time into
strings and to compute durations.
Add the loader into the main workspace, removing it from its own
sub-workspace. We can do this now that we can specify the linker script
in `build.rs`.
This improves IDE support, and should shrink disk storage requirements.
Signed-off-by: Sean Cross <sean@xobs.io>
this add some routines and test stubs that are helpful for debugging
C FFI integrations. In particular it provides some harnessing that adapts
a minimal selection of libc functions by copypasta of various bsd/mit
licensed libc implementations. It also provides a cheesy malloc using
a Rust Vec...only suitable for simple, single-threaded work, but enough
to unlock a reasonable range of middleware.
thanks again to Michael Rosenberg for catching this bug and
teaching about about how to use the Subtle/.ct_eq() traits to
implement constant time equality checks.
Keyboard setting is "the one and only" exception to user settings
that are saved without encryption. This is because you need your
keyboard layout to be set in order for you to type your password.
Thus, this needed a bit of a special-case to handle its storage record.
We decided to lop off 1 page from the loader and have it store
the keyboard layout code.
Let's hope we can have the discipline to really just store that
one word of information and not later be like "gee wally, you have
a whoooole 4092 unused bytes of space we can cram unencrypted
user settings in, sure would be a waste to not put those use those".
We run a branch of minifb because we need the `set_key_state`
function, which is not available on the main branch. This
function is necessary to extract raw scan keycodes from the
keyboard so we can respond to e.g. menu and prediction emulation
keys (Home and Fn keys). The mainline minifb crate eats all
of those key events and does not pass them on.
trust levels now default to a mid-level, with the password
modals explicitly tested for by the Context logic (the idea
being to deny any untrusted canvases the ability to render
inverted text).
ball bounce app also basically works, and context
switching between the bounce app and the main menu
is working too.
The first "app" is just going to be a whole-framebuffer
demo that gets raw keys and does some stuff on the screen.
It's the starting point if you wanted to eg. write a simple
video game or something for the device, but you didn't care
about much of the other UX sugar.
