A third-party Pidgin plugin for OCS/LCS

>>Anibal, where are you with your file transfer code? You've last promised
to release it two weeks ago.

I told him you were working on it lol

created MAC from test file with Pidgin crypto-API successfully. Used 'hmac'
algorithm with 'sha1' as a 'hash' option.

This proves that we are good to go with just built-in Pidgin crypto-API.
No other tools necessary.
Now I have quite complete understanding of file transfer process.

@Anibal, where are you with your file transfer code? You've last promised
to release it two weeks ago.

The only thing you've forgotten in your pseudocode is to mention SHA-1 is a
hashing algorithm.

Exactly.
This is basically how I've figured things out initially (see below in this
thread).

I decrypted in windows api!!
pseudocode:
Base64Decode encryption-key
CryptCreateHash
CryptHashData(encryption-key)
CryptDeriveKey(CALG_RC4, encryption-key, output-key)
CryptDecrypt(output-key)

encrypted test file with Pidgin crypto-API successfully. Used 'sha1' and
'rc4' algorithms.

> Why SHA1? Because the operation says so:
> RC4_KEY = SUBSTR(SHA1(BASE64_DECODE(KEY_STRING)), 0, 15)

right, but how did you guys figure out there needed to be sha1sum, why not
some other function

Checked with LCS2005 - the same encryption scheme used.

Right,
but don't forget about data integrity part - MAC. Official client will
decline file transfer if that wouldn't match, I'm pretty sure.

No, the padding to 4096 bytes is only for the "openssl" program. It expects
at least 4096 bytes in the input file for some strange reason. That's why I
needed to cut the first 4 bytes from the decrypted file, because the rest
is just garbage :-)

Why SHA1? Because the operation says so:

RC4_KEY = SUBSTR(SHA1(BASE64_DECODE(KEY_STRING)), 0, 15)

KEYSTRING is 32 ASCII characters long.
BASE64_DECODE() decodes that string to a 24 byte long octal sequence.
SHA1() generates a digest from that sequence that is 160 bits (= 20 bytes)
long.
The SUBSTR() cuts it down to the correct RC4 key size, i.e. 128 bits (= 16
bytes).

this got me so riled up I have to go work out

ok I see I think sha1sum is the secret to make the key the correct size.
Why can't I just plug the key into the rc4 function without sha1sum, why
programmers have to make things so complicated :cry:

I didn't know I have to pad it! I thought RC4 is stream protocol, means the
encrypted data is as long as the decrypted data. Also is the entire 24 byte
binary of the encrypted-key string the key? can you verify it is 192 bit
key? pier11 pls send me your im via email

I guess in short that means we can implement encryption & decryption with
libpurple routines and don't have to call an external program?

Seems to work according to the instructions:

$ wget http://zoosmart.us/test.txt
...

# pad test.txt to 4096 to make openssl happy :-(
$ dd if=/dev/zero of=test.txt.pad bs=4092 count=1
1+0 records in
1+0 records out
4092 bytes (4.1 kB) copied, 0.000111258 s, 36.8 MB/s
$ cat test.txt test.txt.pad >encrypted.txt
$ ls -lt test.txt* encrypted.txt
-rw-rw-r--. 1 stefanb stefanb 4096 2009-09-29 22:20 encrypted.txt
-rw-rw-r--. 1 stefanb stefanb 4092 2009-09-29 22:20 test.txt.pad
-rw-rw-r--. 1 stefanb stefanb 4 2009-09-29 19:27 test.txt

Now the actual magic:

$ base64 -d >k1.txt
qiQkTTcCtvxDgYOJllkVaB6mEyrez7ML
$ sha1sum <k1.txt | cut -c1-32
a9d650234f385c86c5799194efbd23e2
$ openssl enc -rc4 -in encrypted.txt -out decrypted.txt -d -K
a9d650234f385c86c5799194efbd23e2 -iv 0
$ od -t a -N 4 decrypted.txt
0000000 t e s t

Voila: decrypted :-)

wow, congrats! I tried and tried but coudln't figure it out. what I want to
know is, when you base64-decode the 36 byte string you get a 24 byte
string, which means 24*8=192 bit key. However the windows api for RC4 only
goes up to 128, so that means not all of the encryption-key is the key? I
am noob so I don't know what MAC or SHA is, or salts or initialization
vectors and all that crap. I just wanted to figure it out like a good duct
tape programmer http://www.joelonsoftware.com/items/2009/09/23.html

How did you figure out what part of the encryption-key is actually the
key, and what part of it is something else, and how did you figure out what
that "something else" is?

and yes, I'm jealous!!!

File encryption/digesting scheme in version 2007
(c) pier11

K1[24] = ... ;
Encryption-Key = base64_encode(K1);
K2 = SHA1 (K1);
memcpy (K3, K2, 16);
RC4 (K3, data); // 'data' will be encrypted

MAC calculation:
K1[24] = ... ;
Hash-Key = base64_encode(K1);
K2 = SHA1 (K1);
memcpy (K3, K2, 16);
MAC = HMAC_SHA1 (K3, data); // 'data' here is original data, not just
encrypted one

========================
Decryption:
K1 = base64_decode(Encryption-Key);
K2 = SHA1 (K1);
memcpy (K3, K2, 16);
RC4 (K3, data);

MAC check:
K1 = base64_decode(Hash-Key);
K2 = SHA1 (K1);
memcpy (K3, K2, 16);
MAC = HMAC_SHA1 (K3, data); // 'data' here is the just decrypted one
// compare with received one

I've recreated MAC too!
That was MY day today!!

the text inside this file is:

test

I encrypted a file with this encryption-key
qiQkTTcCtvxDgYOJllkVaB6mEyrez7ML

the file is http://zoosmart.us/test.txt

Did successful encryption in Java with _standard_ security API.

well, I've decrypted my encrypted file back to the original file.

Lets make small experiment. You send me small (just 7 characters or so)
encrypted by Communicator file and the 'Encryption-Key' parameter used for
that. And I will decrypt it and say what was the original content.

I don't have testing facility for that.

I'm saying my encryption results give me the same byte sequence as I saw
in TCP packets when this file was transferred between two Communicators
(2007).

was communicator able to decrypt it?

I've successfully encrypted small test file!!! It was produced exactly the
same byte sequence as Communicator sent in the stream.

I think we would start with Windows Security API if no other progress has
been made on secured file transfer. Then on success we will try to
translate the knowledge to open implementations, ones we'd understand the
mechanics.

The following methods of the API the Communicator are working with.

CryptDestroyHash
CryptDestroyKey
CryptDeriveKey
CryptHashData
CryptCreateHash
CryptAcquireContextW
CryptGenRandom
CryptSetHashParam
--
CryptProtectData
CryptUnprotectData
--
CryptGetHashParam
CryptDecrypt
CryptEncrypt
--
CryptUnprotectMemory
CryptProtectMemory
--
CryptDecodeObjectEx

To my mind CryptEncrypt would be used for actual file encryption. (with
RC4)
http://msdn.microsoft.com/en-us/library/aa379924%28VS.85%29.aspx

The method takes a KEY handler as a parameter. The handler defines which
method of encryption to use.
I think the only suitable method to create the key is to use
CryptDeriveKey wich converts arbitrary text string to the key structure
(with appropriate key length). This would answer question why our
'Encryption-Key:' is too long for RC4. API ref:
http://msdn.microsoft.com/en-us/library/aa379916%28VS.85%29.aspx

Some other methods should be used to initialize the security framework
first: CryptAcquireContext, CryptCreateHash, CryptHashData,
CryptSetHashParam, CryptGetHashParam.
Example in C:
http://msdn.microsoft.com/en-us/library/aa382358%28VS.85%29.aspx

@alextheblade,

can you please receive from Communicator encrypted file AS IS, and then
post it here along with 1) Original file, 2) Encryption-Key and 3) Hash-Key
used for the transfer?

We will try to analyse that.

Looks like a tool to play with SHA1, HMAC, base64 - for MAC of the file.

Fsum Frontend
http://fsumfe.sourceforge.net/index.php?page=home

The encryption scheme for the file transfer should be:

RC4-HMAC_SHA1

I think it is a symmetric stream cipher, probably RC4. I'm trying to figure
it out here

http://social.msdn.microsoft.com/Forums/en-US/ucmanagedsdk/thread/82be5bb7-0cf2-4af3-82a7-d13afd427537

any ideas?

I got unencrypted file transfers to work for my trillian LCS plugin but
haven't yet attempted secure file xfrs. It seems to use MSN_SECURE_FTP,
maybe the freeware called "emesene" got this to work but I'm not sure.

More detailed file transfer protocol observations:

[A deep dive into the Office Communicator 2007 R2 file transfer process]
http://blogs.technet.com/daveh/archive/2009/05/17/a-deep-dive-into-the-office-communicator-2007-r2-file-transfer-process.aspx

What is unclear to me are methods for file encryption/signing. Any
info/ideas?

[Microsoft Office Communications Server 2007 Resource Kit Sample Chapters]
http://www.microsoft.com/downloads/details.aspx?familyid=407a3e40-350a-4e3d-b60e-c9505668b231&displaylang=en

See Chapter 4, pp 64-66
Examining What Happens When Sending a File (Step 5)

I appreciate it if the functionality would be implemented.

This would be a great feature is there a plan to send files, My company
uses Office Communicator 07

+1. Sending files is extremely useful. Especially as most of my
colleagues are 4K miles away !!