AES256-CBC for encryption?

Wessel, Keith kwessel at
Wed May 15 10:14:58 EDT 2019

And it was the unlikely possibility after all. Apparently, our Java fell into the really ancient category. Thanks for mentioning that edge case, Scott. JDK8U121 was the problem. We're upgraded, and the requested encryption method in metadata is now working.


-----Original Message-----
From: users <users-bounces at> On Behalf Of Cantor, Scott
Sent: Monday, May 13, 2019 12:12 PM
To: Shib Users <users at>
Subject: Re: AES256-CBC for encryption?

I reviewed the code to make sure I wasn't offbase and I think it works like I thought it did, but I did find the log categories. A lot of it is at trace, but the targeted categories are:


Those two on trace I think should provide some insight into what it's seeing.

The way it's working, and Brent can confirm, but it basically builds up lists of algorithms and the way it walks the sources of the lists determines which ones end up "on top" and get used by default. It blocks algorithms only by cross-checking the values it adds to the list at the end with the various white/blacklist sets, so since none of those are relevant here, that part won't matter.

With the metadata extension present, it instead defers to that exclusively and just checks the elements in order to find one that's acceptable, and ends up ignoring what's in the config as a default or whatever.

So, I think I know how it works, and it appears to work correctly even with all those properties I defined in use, and that matches what I see my system doing. So I don't see any obvious traps/accidents that would be tripping you up. possibility, but it seems really unlikely. If you were on an ancient/dead Java that wasn't shipping the unlimited policy files, you don't get AES 256 because of key size. But that hasn't been a consideration for a while now.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list