9
0
Fork
You've already forked locksmith
0

verify local bundle == remote bundle #1

Open
opened 2026年04月01日 08:20:38 +02:00 by ryansquared · 1 comment

So, I accidentally ran the bundle-2-of-4.json when I deployed it with bundle-single. We need a way to verify that the shards that get produced are actually contributory to the secret we want to recreate. Shardfiles accomplish this at end-of-reconstitution by producing a root certificate that's also stored in the first metadata packet (decryptable by the root certificate), but that requires a full reconstitution.

There's a few options:

  • Client sends up the hash it has for its bundle.json.
  • Server sends down the hash it has for its bundle.json.
  • We break apart keyfork-shard and get hashes for every share.

Options 1 and 2 are easily doable and assume that users who are valid for an enclave are not going to throw in evil shards. Option 3 is the "most" secure but requires cracking open keyfork-shard entirely.

So, I accidentally ran the bundle-2-of-4.json when I deployed it with bundle-single. We need a way to verify that the shards that get produced are actually contributory to the secret we want to recreate. Shardfiles accomplish this at end-of-reconstitution by producing a root certificate that's also stored in the first metadata packet (decryptable by the root certificate), but that requires a full reconstitution. There's a few options: * Client sends up the hash it has for its bundle.json. * Server sends down the hash it has for its bundle.json. * We break apart keyfork-shard and get hashes for every share. Options 1 and 2 are easily doable and assume that users who are valid for an enclave are not going to throw in evil shards. Option 3 is the "most" secure but requires cracking open keyfork-shard entirely.
Author
Owner
Copy link

Deciding whether or not to go for option 3 is best done right now before we move to Shardfile v2. Note that this would be incompatible with Shardfile v1, because it's added data that we can't recover. We could also make the field optional and the upgrade path would continue to exist - shardfile v1 just wouldn't have the field, and shardfile v2 should always have the field.

Deciding whether or not to go for option 3 is best done right now before we move to Shardfile v2. Note that this would be incompatible with Shardfile v1, because it's added data that we can't recover. We could also make the field optional and the upgrade path would continue to exist - shardfile v1 just wouldn't have the field, and shardfile v2 should always have the field.
Sign in to join this conversation.
No Branch/Tag specified
main
feat/hosted-keymaker
deploy/hosted
deploy-tests
fix/preferred-hash-fallback
anton/fix-error-handling
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
caution/locksmith#1
Reference in a new issue
caution/locksmith
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?