panic on crypto/cipher: input not full blocks

[fformica]

Hi, we tried switching a python implementation of our SAML client with this go library, and one of our users managed to trigger a panic:

runtime.gopanic
	/usr/local/go/src/runtime/panic.go:770
crypto/cipher.(*cbcDecrypter).CryptBlocks
	/usr/local/go/src/crypto/cipher/cbc.go:145
github.com/russellhaering/gosaml2/types.(*EncryptedAssertion).DecryptBytes
	/gomod-cache/github.com/russellhaering/[email protected]/types/encrypted_assertion.go:68
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions.func1
	/gomod-cache/github.com/russellhaering/[email protected]/decode_response.go:176
github.com/russellhaering/goxmldsig/etreeutils.NSFindIterateCtx.func1
	/gomod-cache/github.com/russellhaering/[email protected]/etreeutils/namespace.go:299
github.com/russellhaering/goxmldsig/etreeutils.NSTraverse
	/gomod-cache/github.com/russellhaering/[email protected]/etreeutils/namespace.go:167
github.com/russellhaering/goxmldsig/etreeutils.NSTraverse
	/gomod-cache/github.com/russellhaering/[email protected]/etreeutils/namespace.go:174
github.com/russellhaering/goxmldsig/etreeutils.NSFindIterateCtx
	/gomod-cache/github.com/russellhaering/[email protected]/etreeutils/namespace.go:286
github.com/russellhaering/goxmldsig/etreeutils.NSFindIterate
	/gomod-cache/github.com/russellhaering/[email protected]/etreeutils/namespace.go:275
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions
	/gomod-cache/github.com/russellhaering/[email protected]/decode_response.go:196
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).ValidateEncodedResponse
	/gomod-cache/github.com/russellhaering/[email protected]/decode_response.go:287
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).RetrieveAssertionInfo
	/gomod-cache/github.com/russellhaering/[email protected]/retrieve_assertion.go:54

We didn't log the SAML response, unfortunately, but could the condition be anticipated in order to fail gracefully and avoid a panic?