On 22/11/2018 22:32, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 11/22/18 16:43, Mark Thomas wrote:
On 22/11/2018 19:17, Christopher Schultz wrote:
Mark,
On 11/22/18 05:21, Mark Thomas wrote:
On 21/11/2018 22:39, Christopher Schultz wrote:
Mark,
<snip/>
I thought you were using CBC so a missing block (a message
being one or more blocks) means that the next message can't
be decrypted.
CBC *is* being used, but the cipher is reset after each
message, and a new IV is being randomly generated for that
purpose. There is no state-carryover between messages. At
least, there shouldn't be.
Ah. Thanks for the explanation. I should have looked at the
code. That should all work then.
I'll try and find some time today to figure out what is
causing the error messages I am seeing.
Thanks, I'd appreciate a second set of eyes.
I can't seem to find any problems with it. The only "problems" I
ended up finding were poorly-written tests :)
syncs on encrypt() and decrypt() seem to have done the trick. That
was just a quick hack to confirm a suspicion - it isn't the right
long term fix.
If we want this to be performant under load I'd lean towards using
a Queue for encryption ciphers and another for decryption ciphers
along the lines of the way SessionIdGeneratorBase handles
SecureRandom.
We should probably handle SecureRandom the same way.
I'll start working on a patch.
Hmm... I was under the impression that the message-sending operations
were single-threaded (and similar with the receiving operations).
There are locks in other Interceptors which are consistent with them
being multi-threaded.
I've read that calling Cipher.init() is expensive, but since it's
being done for every outgoing (and incoming) message, perhaps there is
no reason to re-use Cipher objects. I'd be interested to see a
micro-benchmark showing whether all that complexity (Cipher object
pool) is really worth it. It probably isn't, given that the code
without that complexity would be super clear and compact.
Good point. I'll try that. It will depend on how expensive creating the
object is.
Even with the pools the code is pretty clean but I take the point that
it would be (even) cleaner without.
I have a patch ready to go but I'll do some work on the benchmark first.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
