Perform serialization of KES and DSIGN sign keys in MLocked memory #276
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Converting to hex prior to decoding ensures correct symbol range.
…e unintentional consequences downstream
This commit adds a function which can extend an `EpochInfo` linearly given a starting point. This is needed to put in place a patch for a bug that arose in the Alonzo era, where the `EpochInfo` was too generous in translating slots. In order to support this, this adds an additional function `epochInfoSlotLength`, which returns the 'SlotLength' for the given slot.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We will need this for a KES Agent: in order to send and receive keys over a secure network connection, we have to serialize and deserialize them. The serialized format is still just as confidential as the deserialized form, so we need to treat them with the same care, and that involves storing them in mlocked memory.
We also need to make sure no intermediate values ever reach unprotected memory, so we cannot use the usual Haskell serialization primitives, as these may store intermediates on the Haskell heap. At the same time, mlocked memory is a scarce resource, and we don't want to allocate excessive amounts of it, so in the case of staged KES algorithms (
SumKES/CompactSumKES), we cannot create a new temporary variable for each sub-key at each stage - ideally, we want to allocate a single block of mlocked memory for the final key, and perform all operations on it, in-place.Hence, we use the following approach:
MLockedSizedBytesAPI with a functionmlsbMemcpy, which, just like thememcpyC function, takes two pointers (MLockedSizedBytes) and a length, and copies this many bytes from oneMLockedSizedBytesto the other. However, this function has two additionaloffsetparameters, which allow us to address memory locations within theMLockedSizedBytes, and, unlikememcpy, we add bounds checking to prevent buffer overruns.DSIGNMandKESSignAlgorithmclasses expose two methods for serializing and deserializing their SignKeys; these methods accept a targetMLockedSizedBytesvalue that they write to, and an offset into it. This is a slightly awkward signature for user code, but it allows us to delegate the serialization of sub-keys recursively.SignKey -> IO MLockedSizedBytesfor serialization, andMLockedSizedBytes -> IO (Maybe SignKey)for deserialization). These can't be used for recursive ser/deser of composite keys, but they are perfect for user code.