#6 rs_mdfour family can't be used with librsync >= 0.9.6?

open
Interface (2)
5
2004-06-03
2004-04-03
No

It appears that rs_mdfour family of functions has
trouble in 0.9.6 because "struct rs_mdfour" is no
longer defined. Further, it appears that
rs_mdfour_begin still expects a pre-allocated buffer to
be passed in, so this can't be an anonymous type (we
need to allocate storage from the caller). librsync
0.9.5 defined struct rs_mdfour in rsync.h. This
definition has now been moved into mdfour.h, which
further depends on types.h.

None of these problems will surface if you only use the
whole file API: rs_mdfour_file. Unfortunately a bunch
of other stuff that uses buffer APIs:
rs_mdfour_{begin,update,result} will break.

Discussion

  • Donovan Baarda
    Donovan Baarda
    2004-06-03

    Logged In: YES
    user_id=10273

    The plan is to move to a libmd/RSA API, allowing librsync to
    use libmd's md4 implementation.

    We will continue to include a version for platforms that
    don't have libmd. Even on platforms that do have libmd, the
    implementation we provide might be faster.

     
  • Donovan Baarda
    Donovan Baarda
    2004-06-03

    • assigned_to: nobody --> abo
     
  • Martin Pool
    Martin Pool
    2004-09-09

    Logged In: YES
    user_id=521

    In my measurements the mdfour routines in librsync were
    substantially faster than those in the version of libmd that
    I downloaded from abo's site.

    I guess the function should be added back into the public
    interface.

     
  • Donovan Baarda
    Donovan Baarda
    2004-09-09

    Logged In: YES
    user_id=10273

    Ummm, which version of libmd would that have been? What
    platform?

    I have ported the librsync mdfour to the libmd API and made
    it slightly faster again. I have also fixed the "non-int
    aligned char *" problem by only enabling the "cast (char *)
    to (int *)" optimisation for i386, not just any little
    endian platform. I've benched mine vs libmd's, and mine is
    nearly 2x as fast on i386.

    I've also looked at the md4 library code in openssl. It
    seems that right now libmd is loosing ground against openssl
    as the prefered implementation.
    It has the same API as the RSA code in libmd, except for
    slight differences in the names (MD4_Update instead of
    MD4Update etc). Nothing that a few configure driven
    #define's can't fix.

    The code is scary complex. It has two completely different
    implementations for the little-endian+char aligned int * vs
    other platforms. I suspect it will be the fastest
    implementation, but wouldn't be surprised if all the
    complexity ends up producing something slower.

    I think librsync should switch to the libmd API, and provide
    configure support for using openssl vs libmd vs our own
    implementation.

     
  • Donovan Baarda
    Donovan Baarda
    2004-09-09

    Logged In: YES
    user_id=10273

    Ummm, which version of libmd would that have been? What
    platform?

    I have ported the librsync mdfour to the libmd API and made
    it slightly faster again. I have also fixed the "non-int
    aligned char *" problem by only enabling the "cast (char *)
    to (int *)" optimisation for i386, not just any little
    endian platform. I've benched mine vs libmd's, and mine is
    nearly 2x as fast on i386.

    I've also looked at the md4 library code in openssl. It
    seems that right now libmd is loosing ground against openssl
    as the prefered implementation.
    It has the same API as the RSA code in libmd, except for
    slight differences in the names (MD4_Update instead of
    MD4Update etc). Nothing that a few configure driven
    #define's can't fix.

    The code is scary complex. It has two completely different
    implementations for the little-endian+char aligned int * vs
    other platforms. I suspect it will be the fastest
    implementation, but wouldn't be surprised if all the
    complexity ends up producing something slower.

    I think librsync should switch to the libmd API, and provide
    configure support for using openssl vs libmd vs our own
    implementation.