AES256-CBC for encryption?
Wessel, Keith
kwessel at illinois.edu
Fri May 10 15:22:06 EDT 2019
Hi, all,
We're federating with a vendor, CrowdStrike Falcon, and they say they can't accept an assertion encrypted with AES128-CBC. They want AES256-CBC. Not completely clear why, if AES128 isn't good enough for them, they don't just go all the way and ask for GCM.
First question: is it a bad idea from a security standpoint to offer this? That is, is it any worse than AES128-CBC?
Second question: Is it as easy as a new security configuration bean that I could associate with their relying party config that looks like this?
<bean id="shibboleth.EncryptionConfiguration.AES256-CBC" parent="shibboleth.BasicEncryptionConfiguration">
<property name="dataEncryptionAlgorithms">
<list>
<util:constant
static-field="org.opensaml.xmlsec.encryption.support.EncryptionConstants.ALGO_ID_BLOCKCIPHER_AES256" />
</list>
</property>
<property name="keyTransportEncryptionAlgorithms">
<list>
<util:constant
static-field="org.opensaml.xmlsec.encryption.support.EncryptionConstants.ALGO_ID_KEYTRANSPORT_RSAOAEP" />
</list>
</property>
</bean>
Or better yet, inherit off of the existing CBC bean like this?
<bean id="shibboleth.EncryptionConfiguration.AES256-CBC" parent="shibboleth.EncryptionConfiguration.CBC">
<property name="dataEncryptionAlgorithms">
<list>
<util:constant
static-field="org.opensaml.xmlsec.encryption.support.EncryptionConstants.ALGO_ID_BLOCKCIPHER_AES256" />
</list>
</property>
</bean>
Just wanted a sanity check before shooting myself in the foot.
Thanks,
Keith
More information about the users
mailing list