[cifs-protocol] FW: [REG:111061756137964] Encryption of the key for "netsh branchcache importkey and exportkey.

Christopher R. Hertel crh at ubiqx.mn.org
Mon Jul 4 11:42:15 MDT 2011


I am still unable to correctly decrypt the output of the branchcache export.

The recent clue that the encryption scheme uses PKCS7 is helpful.  It shows
me two things:

1) There are no PKCS7 padding bytes in the decrypted data I am producing.
   This, on its own, could mean that the original data did not need to be
   padded.  ...but...
2) Since the SHA256 of the resulting decrypted blob (the latter 48 bytes)
   does not match the included leading 32 bytes, it's not the failure to
   remove padding that is confusing things.

So... next question:
- What is the CBC block size that is being used?

  Since the total blob is 80 bytes, and we know that 32 bytes is the
  SHA256 of the (unpadded) plaintext, that leaves 48 bytes worth of
  (possibly padded--but we won't know until we decrypt it) ciphertext.

  So the block size could be either 8 bytes or 16 bytes.

Thanks for sticking with me on this.

Chris -)-----

Edgar Olougouna wrote:
> Chris,
> Please find a quick recap of the current status. Let me know whether this helps.
> *	The AES-256 encryption is in CBC mode.
> *	A default initialization vector with a block of all 0x00 bytes (i.e. 16 bytes of zeros) can be used, and has the same effect as if no IV was being used. 
> *	The key is the SHA-256 of the passphrase Unicode string. The NULL terminator is excluded from the passphrase string. 
> *	The encryption scheme uses PKCS7 block padding.
> Regards,
> Edgar

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org

More information about the cifs-protocol mailing list