save/resume session key

[aep]

I need to save session keys to disk and restore them for failover.

CipherState is already public, and its use is fairly obvious.
StatelessTransportState::new is a bit lacking because HandshakeState contains a lot of stuff that isnt relevant after hs. I could of course zero them out, but meh cryptography is hard and i'd rather have a review here.

is it ok to introduce a

StatelessTransportState::from_parts(
    cipherstates: StatelessCipherStates,
    pattern: HandshakePattern,
    dh_len: usize,
    rs: Toggle<[u8; MAXDHLEN]>,
    initiator: bool
)

edit...

uuh actually CipherState doesn't have a get() so you can't get the session key.
can we introduce that too?

[mcginty]

Hey @aep, sorry for the delayed response. Can I ask what the use case for this would be, where an application wouldn't want to just establish a new session by completing a new handshake?

If the need makes sense, then it'd make sense to have a way to save/restore a (Stateless)TransportState, but it's a more dangerous API since I feel like (key,nonce) tuple reuse is more possible with it existing.

[aep]

hah, no worries.

we've got a couple million connections and i'm trying to figure out ways to migrate the server binary without reconnecting, because the key exchange is a lot of load. Idea would be to send the thing a signal, it then serializes all session keys, restarts with the new binary which then deserializes them again.

[fogti]

Would it be a possibility to add serde support there?

[mcginty]

@aep sorry for not getting to this feature yet! I think this is reasonable, and I think maybe it best fits behind some kind of feature-gate which can behave basically like a consent checkbox for understanding that this is a way to leak secrets if not handled correctly.

@zserik I don't see why not, especially if it's again behind this feature flag.

[aep]

No worries. As you know we're not using rust and therefor snow anymore anyways