无法使用SUDS解密MTOM/XOP附件(python)

Question

我有一个从服务器下载文件的SOAP客户机。请求的主体和附件(文件)使用两个单独的密钥加密。这两个键都包含在各自的<xenc:EncryptedKey>标记中。我可以用其中一个密钥解密身体没有问题，但是附件给了我问题。

我的代码：

from Crypto.Cipher import AES
from Crypto import Random

class AESCipher:
    def __init__( self, key, BS = 16):
        self.key = key
        self.BS = BS
    def _pad(self, s):
        return s + (self.BS - len(s) % self.BS) * chr(self.BS - len(s) % self.BS) 
    def _unpad(self, s):
        return s[:-ord(s[len(s)-1:])]
    def decrypt( self, enc ):
        enc = base64.b64decode(enc)
        iv = enc[:self.BS]
        cipher = AES.new(self.key, AES.MODE_CBC, iv )
        return self._unpad(cipher.decrypt( enc[self.BS:]))

with open('test/resp-down-file','rb') as f:
    encFile = f.read()

#...the key is extracted elsewhere...

cryptor = AESCipher(key)
cryptor.decrypt(encFile)

充其量，我会把结果弄得乱七八糟，但通常只会说是Error while decrypting in CBC mode。问题：有人遇到过这个问题吗？我对Python、Java、PHP、Perl、C中的建议持开放态度，几乎所有在linux上运行的内容都可以使用。MTOM/XOP附件加密的方式有什么特别之处吗？

我已经看到了this的问题，但它没有正确的答案。八进制/流引用的是内容类型，而不是传递机制，因此答案是不正确的。

编辑:服务器规范说他们使用带有PKCS5填充的AES128-CBC算法对消息进行加密。对我来说，他们用DES填充加密是没有意义的，但他们对此很坚决。

Edit2:有时附加的消息没有正确的AES128解密长度(例如6023字节或4071字节)。

作为参考，消息以下列格式出现：

--MIMEBoundaryurn_uuid_641B9D88B371C8A80C1501095406237
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:641B9D88B371C8A80C1501095406238@apache.org>

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
...
</soapenv:Envelope>

--MIMEBoundaryurn_uuid_641B9D88B371C8A80C1501095406237
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <urn:uuid:641B9D88B371C8A80C1501095406240@apache.org>

­8eJ¨%• }\  Œ“\ò½<( nË%¸£käö0   ‡XW�5ìR Ë�¾p�Áëş3Âå'¹5¥#=Zg¡øø{I~FP�n ×aµR^Föž¤¥EÍf«Îê�0qÊMö²È€]®PÌ>A@‡ Cş®±9>Áf7P’#ã  …fç~yxÔ.å–×v›±Cô„Ê
...
--MIMEBoundaryurn_uuid_641B9D88B371C8A80C1501095406237--

Answer 1

我解决了问题。结果，我接收数据的方式(使用result = requests.post(....) )减少了一些不可打印的字符，因为我使用的是result.text。

现在我转到result.raw.read()，这个问题已经解决了。