5 releases

1.0.0-rc.2 Dec 3, 2022
0.12.0 Jan 27, 2023
0.12.0-rc.2 Jan 20, 2023

#813 in Cryptography

Download history 61/week @ 2022-12-01 55/week @ 2022-12-08 24/week @ 2022-12-15 34/week @ 2022-12-22 16/week @ 2022-12-29 19/week @ 2023-01-05 10/week @ 2023-01-12 84/week @ 2023-01-19 80/week @ 2023-01-26

194 downloads per month
Used in 6 crates (2 directly)

Apache-2.0

30KB
699 lines

Zeroio provides utilities to communicate efficiently with the guest.

This is similar to serde's "Serialize" and "Deserialize", but has different design targets:

  • Guest runtime performance is paramount.
  • It's a significant performance degradation for the guest to have to read a value that's not aligned on a 32-bit boundary.
  • Space efficiency is nice, but less important than guest runtime performance.
  • We want to conveniently be able to take cryptographic hashes of a structure.

In response, zeroio does these things differently than serde:

  • There is only one on-wire format; zeroio does not try to be as featureful as serde.
  • Datatypes available are much more limited
  • We don't want to spend any cycles deserializing or copying, so we store the data in a format that's easy to access without copying, similarly to the `rkyv' crate.
  • In contrast to rkyv, we use slices instead of pointers to refer to available serialized data. This allows us to avoid unsafe code.
  • We store all data buffers as [u32] (as opposed to the more common [u8]).
  • There is one canonical format; any serialization of the same data will construct the same structure. To take a cryptographic hash, we simply hash the [u32] slice.
  • We null-pad all data buffers up to the size of the hash block (with one word remaining) to avoid copying when computing a hash.

Note that for deserializing, while we guarantee sha(a) == sha(b) implies deserialize_from(a) == deserialize_from(b), we do not guarantee the converse, that deserialize_from(a) == deserialize_from(b) implies a == b.

Dependencies

~0.7–1.2MB
~23K SLoC