Secure File Transfer

Developers
Anonymous
2011-05-15
2013-03-28

  • Anonymous
    2011-05-15

    question about implementing secure file transfer in another language

     

  • Anonymous
    2011-05-15

    oops… sorry, new to this, the actual question might be useful I suppose :)

    There is very little information on the MSN_SECURE_FTP protocol as you probably all know, and SIPE seems to have the only confirmed working and open implementation out in the web.

    I'm trying to implement a file transfer bot for OCS in Java or C# and my initial attempts (in C#) based off of the minimal documentation have failed. I have attempted to follow what pier11 suggested was the algorithm:

    1. K1 = 24 byte key
    2. Encryption-Key = Base64Encode(K1)

    On receipt of the encrypted file:
    1. K2 = SHA1(K1)
    2. K3 = first 16 bytes of K2
    3. plaintext = RC4(K3, ciphertext)

    Now I have tested the Base64 encoding, the SHA1 hash and the RC4 algorithm independently and they work.
    Combining them into the algorithm fails however and I end up with junk in the plaintext.

    Is there anything specific about the SHA1 hash or RC4 algorithm that needs to be specified? e.g. a specific variant that should be used.

    Any help would be very much appreciated.

     
  • Jakub Adam
    Jakub Adam
    2011-05-15

    Hi,

    the algorithm of pier11 is correct, I checked again the filetransfer code and it does exactly the same thing.

    SHA1 and RC4 should be just standard algorithms, nothing special on them. SIPE includes two implementations, using libpurple crypto API and one using NSS library (when standalone build is desired).

    Probably you should check again your implementation, I'm not familiar with C# so I can't tell you if there are any special options needed to make SHA1 and RC4 work the same way as the C libraries do.

    In the filetransfer discussion thread, where you most probably found the algorithm, pier11 noted he successfully encrypted data with Java standard security API, so try to use that if you get stuck.

     

  • Anonymous
    2011-05-15

    Howdy, thanks for the quick response.

    It's one of those things, I'm looking at the code and it looks fine to me,
    I would like to check that the following is correct too:
    1. FIL <file_size>
    2. TFR
    3. <encrypted_file> of length <file_size> (store as ciphertext)

    The encrypted file is just straight encrypted bytes correct? and I should only use the <file_size> number of bytes received as the ciphertext?

     

  • Anonymous
    2011-05-16

    Howdy! Breakthrough… Well me just being silly really.

    The algorithm works perfectly, it is the receiving of the encrypted file that I had messed up, not taking into account the 3 byte TFTP headers on every 2048 bytes. So my encrypted file contents was wrong…

    Thank you for your help!

     

  • Anonymous
    2011-08-08

    Hi,
    has written sending of files on c #, but there is an error, after sending HMAC, please explain how correctly to cipher a file.

     
  • Stefan Becker
    Stefan Becker
    2011-08-08

    HMAC(SHA1) is used to generate a digest over clear-text file contents, not to cipher it.

    The code in sipe-ft-tftp.c & sipe-digest.c  is pretty self-explanatory

      * generate SHA1 digest from hash key (hash_key) provided by sender (-> k2)
      * initialize HMAC(SHA1) with the first 16 bytes of k2
      * update digest with every clear-text send/received byte
      * at the end calculate HMAC digest result and send it/compare it to the value received

     

  • Anonymous
    2011-08-09

    > * update digest with every clear-text send/received byte

    sipe_digest_ft_update
    Here there is a calculation HMAC, or it is enough to execute calculation HMAC before sending MAC?
    What actions carries out PK11_DigestOp, puts the data in the buffer for the subsequent calculation in PK11_DigestFinal?

     
  • Stefan Becker
    Stefan Becker
    2011-08-09

    I wonder if you understood the concept of message digest. HMAC is just one of the algorithms used for message digest calculation.

    I wonder why you would like to store every byte read/written and calculate the MAC at the end. The cipher and digest operations lend themselves to streaming, i.e. "calculate as you go".