I've read a few articles outlining a process for decrypting SSL/TLS traffic without a private key. Session keys are generated in a log file, which are then read from Wireshark by point to the log file.

Decrypting SSL Traffic with Session Keys

However, my particular log file with the session keys was created after we preformed a packet capture session with Wireshark. Is it possible to use the keys written to this log file to decrypt the packets that were previously captured in Wireshark, or does this process have to be done in parallel (writing to the log file and capturing the packets in Wireshark)?

The fact that these are session keys makes me think that the keys written to the log file would have to be associated with the packets captured, but I haven't been able to confirm this is indeed the case.

1 Answer 1


No, probably not, unless the key was logged later in the same session. Each session uses its own key.



An exchange of messages under the protection of a single piece of 
keying material. For example, SSL sessions use a single key to send
multiple messages back and forth under that key. 

session key

A relatively short-lived cryptographic key, often negotiated by a   
client and a server based on a shared secret. A session key's lifespan
is bounded by the session to which it is associated. A session key
should be strong enough to withstand cryptanalysis for the lifespan of
the session. When session keys are transmitted, they are generally
protected with key exchange keys (which are usually asymmetric keys)
so that only the intended recipient can access them. Session keys can
be derived from hash values by calling the CryptDeriveKey function.


So it is almost certain that the messages you captured are using a previous key unless you logging captured the key before a new session was started.

TLS and SSL use a Deterministic Psuedo Random number Generator (DPRNG), to generate a stream sequence for the key, being generated in parallel on both the host and the client based on a shared seed value which they negotiate, so you need to know the initial seed, and then the offset for each message (since its a stream cipher) and have the means to fast-forward the DPRNG to the correct position for the message's part of the stream. Wireshark likely has the ability to perform the later provided it captured the stream from the beginning, but without the seed, you won't be able to find the key for the specific message.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.