Key Rotation

[lbaird]

A sharer can currently update their share with the helper by sending the StoreShare message. It would be useful to also allow that message to update the sharer's keys for that secretID (public signing key, public encryption key, key ID). This would allow the sharer to do key rotation periodically, and at other times, such as immediately after recovering a secret.

This can be implemented by adding those 3 fields to the StoreShare message, and in the comments explain that if they are filled in, then the helper should update them.

[jorabin]

Mutatis mutandis, there is a need for the helper to rotate keys and think this should be addressed in the round while considering the proposals around authentication context.

It might make sense for there to be a KeyUpdate message and specific responses indicating failure modes around not being able to update keys at the present time?

[lbaird]

I agree. Let's add a KeyUpdate message and response.

[jorabin]

need to consider how a helper could send such a message in the request response environment. Possibly might be a response status code indicating that the sharer should initiate

[zanctor]

I have a question. To change the keys/IDs in a stored share, a helper must decode the share and somehow decode/decrypt the Secret itself to change key fields. A comment in the StoreShareRequestMessage protobuf says the following about the share field: A helper does not need to know the details of the algorithm used to construct the share and MUST treat the share as an opaque byte string.. How is that supposed to work?

I assume, the proposed KeyUpdate message would require the fully sharer-regenerated secret, and this message will act as the StoreShareRequest message: If the helper already has this version of the share, then it is a request to replace it. But then, why is a separate message type needed, if the same can be done using the existing one?

[lbaird]

The helper will not need to decode a share. And it will not change keys within an existing version of an existing share. And the actual committed secret itself doesn’t even use asymmetric keys. It simply has a different symmetric session key that is different for each version of the share, and which is split with Shamir secret sharing.

For the symmetric keys, the sharer can send a message to the helper saying that the sharer is now changing their keys. Then in future messages, the helper will know to use the new signing key when verifying the signature on the message, and use the new encryption key when sending back a reply. So the new keys are used for securing all future message traffic.

On Tue, Jan 16, 2024 at 2:39 PM Ihor Zinchenko @.***> wrote:

I have a question. To change the keys/IDs in a stored share, a helper must decode the share and somehow decode/decrypt the Secret itself to change key fields. The comment in the StoreShareRequestMessage protobuf says the following about the share field: A helper does not need to know the details of the algorithm used to construct the share and MUST treat the share as an opaque byte string.. How is that supposed to work?

I assume, the proposed KeyUpdate message would require the fully regenerated secret by a sharer, and this message will act as the StoreShareRequest message: If the helper already has this version of the share, then it is a request to replace it. And then, why is a separate message type needed, if the same can be done using the existing one?

— Reply to this email directly, view it on GitHub https://github.com/derecalliance/protobufs/issues/18#issuecomment-1893762201, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDBYWYIALSGYWTFWONXLLTYOZ7H7AVCNFSM6AAAAABALHPWGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJTG43DEMRQGE . You are receiving this because you were assigned.Message ID: @.***>

[lbaird]

Typo: that last paragraph should start “For the asymmetric keys, …”.

On Tue, Jan 16, 2024 at 2:55 PM Leemon Baird @.***> wrote:

The helper will not need to decode a share. And it will not change keys within an existing version of an existing share. And the actual committed secret itself doesn’t even use asymmetric keys. It simply has a different symmetric session key that is different for each version of the share, and which is split with Shamir secret sharing.

For the symmetric keys, the sharer can send a message to the helper saying that the sharer is now changing their keys. Then in future messages, the helper will know to use the new signing key when verifying the signature on the message, and use the new encryption key when sending back a reply. So the new keys are used for securing all future message traffic.

On Tue, Jan 16, 2024 at 2:39 PM Ihor Zinchenko @.***> wrote:

I have a question. To change the keys/IDs in a stored share, a helper must decode the share and somehow decode/decrypt the Secret itself to change key fields. The comment in the StoreShareRequestMessage protobuf says the following about the share field: A helper does not need to know the details of the algorithm used to construct the share and MUST treat the share as an opaque byte string.. How is that supposed to work?

I assume, the proposed KeyUpdate message would require the fully regenerated secret by a sharer, and this message will act as the StoreShareRequest message: If the helper already has this version of the share, then it is a request to replace it. And then, why is a separate message type needed, if the same can be done using the existing one?

— Reply to this email directly, view it on GitHub https://github.com/derecalliance/protobufs/issues/18#issuecomment-1893762201, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDBYWYIALSGYWTFWONXLLTYOZ7H7AVCNFSM6AAAAABALHPWGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJTG43DEMRQGE . You are receiving this because you were assigned.Message ID: @.***>

[zanctor]

Ah, I see. Then it makes total sense.