Hi MC,

> If you are given the private key as well, of course it can be decrypted.
> That is the whole point of keeping private keys private :)
> With HTTPS, first a handshake is done, and a unique session key is
> established next to the exchange of public parts of the certificates
> used. The encryption like any asymmetrical method, relies on a
> sufficiently large encryption key based on all this data, that can be
> decrypted by the client (web browser) quickly since the private part of
> the key needed is known to the client.

Ok, I was aware that HTTPS entailed generating a session key the way
you are describing here.

> In theory, every encrypted data stream can be decrypted given enough
> time. That is why browsers quite quickly moved from 56-bit to 128-bit
> encryption after the more widespread introduction of using SSL. It is,
> even with "low-grade" encryption, still a time consuming process since
> the way to find the right key would be to brute-force the private key to
> decipher the data. For normal web use, 128-bits is quite sufficient but
> like I said given enough time that can also be broken and decrypted. Not
> easily though, and not simply by scripting something to run over a
> captured stream.

But this was the point of my question. You seem to be saying that,
having the encrypted sniffs, you can brute-force them eventually, and I
agree that this is (at least in theory) doable. What I am asking is:
does having the server public AND private key help you in any way to
decrypt the sniffed traffic? In other words, if I give you full sniffed
traffic for a couple of requests / responses, and ask you to decrypt
them, would it make any difference to you (faster, easier) if I also
hand you the server's public / private keys?

Best regards.