-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
On 11/22/18 17:32, Christopher Schultz wrote:
> 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).
>
> 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.
Okay, I did a1M rounds with:
a) Cipher.getInstance("AES").init(Cipher.ENCRYPT_MODE, key, IV)
b) existingCipher.init(Cipher.ENCRYPT_MODE, key, IV)
And I got these results:
New Cipher took 31485 ms
Only init took 307 ms
I ran my benchmark a bunch of times and got very similar results.
So, it looks like maintaining a pool of Cipher objects is really
beneficial.
Did you end up doing any work on this yet, or shall I take a stab at it?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv3MhsACgkQHPApP6U8
pFgD0g//V15YGjhwL0P75Rbk6r0q0W7KfwoOuNsi08AK+mQfZ1WKUnqDSIXKcNvC
G6VcQ4QGuwjXMxD0GI7WrBbnhtYtwgteX19AgoHdGxw1cPDRePJyt2e3MNKHj/7W
TIfgTJYXqPbJTDuBGRha2Y9UVqze7vgi21pRVcXtwlEQez9JJdzsWuufMXCH6RAs
a9BpfbpU48JJlyf8a84vKHT3ccuscsa1rIxQ+l2ldJk1Gf4Y/Rl41dDJyEVEOqaN
j2Zb/Jin3DXapDja9SFOwMO5Do9gbEi9/qDXGTgp53YQgTRX2wyVpbFD6JRmqs2z
czFa6zFf0D5rbw2/M4bPmIezyuQp7pydPUsHzMYwrrISfLGMQJbBZAjEtMC0jWPf
fqVGX/RHU2k1B2x9eFVKPZ8HUKbuum/9iZGK3vIrachncx7OyDQGZLAMsHQBWeU4
pJXnzQV6L83VPMriBymcDKINeVmA/lugUtQq90YpxRlicv1gFsP4gopQWBXL2bAI
uwsbOWYFRkYWMb6Rg+h+e2T6L1uNE5vQZtLN369xOcHnjZFNgJSrPCViwxsCayc6
dQByJH8EYkP96xBisNCzB8rL27J9E4EDeoXdumpr7XKn8BIaMtkrHedft17WUuiO
v/ptPuV7+FBEhj8sqetlxObYrMBmJMyl2JNrJgeJBDzq+ddIujs=
=po3H
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
