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