EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Sporadic Corrupted Signature when using DecryptAndVerify

Posted: 10/20/2015 16:19:28
by Benjamin Rosenberg (Standard support level)
Joined: 06/12/2007
Posts: 4


I am seeing a sporadic issue when SecureBlackbox is being used to DecryptAndVerify a file. The decryption occurs as expected, but the signature verification is coming back with SBPGPStreams.TSBPGPSignatureValidity.svCorrupted. I find this a bit odd since other files are being encrypted and signed in the same manner and no issue occurs.

Unfortunately, I will be unable to provide the keys or files which can be used to reproduce this issue. I did check if decryption and verification was successful when using gpg, which it was. Below is the output of using gpg:

   D:\Program Files (x86)\GNU\GnuPG> gpg -d -vvv -o decrypted.xml encrypted.xml
   gpg: using character set 'CP850'
   gpg: armor: BEGIN PGP MESSAGE
   gpg: armor header: Version: McAfee E-Business Server v8.6.0 - Full License
   :marker packet: PGP
   :pubkey enc packet: version 3, algo 16, keyid 7F2FE2A12E52ED13
      data: [2048 bits]
      data: [2048 bits]
   gpg: public key is 2E52ED13
   :pubkey enc packet: version 3, algo 1, keyid 8D0C4E099D326F19
      data: [2048 bits]
   gpg: public key is 9D326F19
   gpg: using subkey 9D326F19 instead of primary key 6B44E02F

   You need a passphrase to unlock the secret key for
   user: "Bob (Bob) <bob@censored.com>"
   gpg: using subkey 9D326F19 instead of primary key 6B44E02F
   2048-bit RSA key, ID 9D326F19, created 2013-05-16 (main key ID 6B44E02F)

   gpg: public key encrypted data: good DEK
   :encrypted data packet:
      length: 2621
   gpg: using subkey 2E52ED13 instead of primary key C2E36CC8
   gpg: encrypted with 2048-bit ELG-E key, ID 2E52ED13, created 2001-10-15
   gpg: encrypted with 2048-bit RSA key, ID 9D326F19, created 2013-05-16
      "Bob (Bob) <bob@censored.com>"
   gpg: CAST5 encrypted data
   :compressed packet: algo=1
   :onepass_sig packet: keyid 3A70240FC2E36CC8
      version 3, sigclass 0x01, digest 2, pubkey 17, last=1
   :literal data packet:
      mode t (74), created 0, name="PGP8Encode_Temp_822db05b000001503aa1c7cb0064cdf9.tmp",
      raw data: unknown length
   gpg: original file name='PGP8Encode_Temp_822db05b000001503aa1c7cb0064cdf9.tmp'
   :signature packet: algo 17, keyid 3A70240FC2E36CC8
      version 3, created 1444092692, md5len 5, sigclass 0x01
      digest algo 2, begin of digest f2 cf
      data: [158 bits]
      data: [160 bits]
   gpg: Signature made 09/15/15 02:04:02 using DSA key ID C2E36CC8
   gpg: usign PGP trust model
   gpg: key 6B44E02F: accepted as trusted key
   gpg: key AD8A9D42: accepted as trusted key
   gpg: Good signature from "Alice"
   gpg: textmode signature, disgest algorithm SHA1
   gpg: decryption okay
   gpg: WARNING: message was not integrity protected

I have verified that the encrypted and decrypted file's contents are correct. The main thing that sticks out to me is that the character set used appears to be pretty old. Since the files are encrypted and signed the same way everytime, the only thing I can think of that would be different are the contents of the file. Are you aware of any issues involving character sets which cause sporadic issues? Does anything else seem out of the ordinary? I haven't been able to find anything that seemed pertinent on you KnowledgeBase or the Forum. Please let me know if you need more information.

Posted: 10/21/2015 04:47:32
by Ken Ivanov (Team)

Hi Ben,

Thank you for getting in touch.

Your assumption about character sets appears to be close to the point. The source file is protected in text mode, so that pretty much might be the case.

There is no current need for the keys. However, it would be great if you could send us a decrypted test file that causes the issue (if possible) so that we could understand what kind of source we have to deal with.

Besides, how much control do you actually have about such files? For example, can you actually generate them in your conditions or they come from a different source?

Posted: 10/21/2015 09:06:07
by Benjamin Rosenberg (Standard support level)
Joined: 06/12/2007
Posts: 4

Thanks for the quick response Ken.

Sorry, but I am also unable to send the decrypted text file. Also, the files come from an outside source and I have not been able to recreate them. I may be able to get a decrypted file which I would be able to send; this may be difficult since the issue only occurs for some files.

I've suggested that they try to protect the file in binary mode. They have not tried it yet, but do you think that may work if the issue lies with the character set?
Posted: 10/21/2015 09:37:55
by Ken Ivanov (Team)

If we are correct about our charset-related guess, then yes, protecting the file in binary mode should help, as there would be no charset interpretation on either side when calculating the signature.

Having a problematic file would help much in the investigation, so hopefully they'll manage to get something they would be able to share.
Posted: 10/21/2015 11:16:50
by Benjamin Rosenberg (Standard support level)
Joined: 06/12/2007
Posts: 4

Thanks, I will see what I can do.



Topic viewed 3945 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!