C. Michael Pilato wrote on Mon, Apr 02, 2012 at 16:10:43 -0400:
> On 04/02/2012 03:40 PM, Greg Stein wrote:
> > On Mon, Apr 2, 2012 at 15:10, <cmpilato_at_apache.org> wrote:
> >> Author: cmpilato
> >> Date: Mon Apr 2 19:10:26 2012
> >> New Revision: 1308470
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1308470&view=rev
> >> Log:
> >> Finish up the initial password encryption and decryption routines, and
> >> stare in amazement as the tests now pass. For me. On my box.
> >>
> >> * subversion/libsvn_subr/crypto.c
> >> (svn_crypto__encrypt_password): Per our plan, prepend the prefix to
> >> the password and pad up to the specified block size before
> >> encrypting. Lose a seemingly unfounded assertion (that the size
> >> of the input will match that of the output).
> >
> > What were you seeing? The encryption result *should* match the amount
> > of data we passed. N blocks of input data for N blocks of output data.
> > If they don't match, then something *is* wrong, as noted in the
> > assertion's comment.
>
> I saw 16 bytes go in, and 48 come out. And then I saw that when I removed
> the assertion and completed the encryption and decryption functions, my
> round-robin tests passed. :-)
>
> Out of curiosity, why must the input block size match the output block size?
> I mean, it sounds great and all, but wouldn't that make the whole "let's
> calculate the maximum possible result size" step sorta superfluous?
>
> Or maybe that's what's going on here: the docstring for
> apr_crypto_block_encrypt() sez "If out is NULL, outlen will contain the
> maximum size of the buffer needed to hold the data". Not the exact size --
> just a good, safe, maximum size. Maybe the implementation is being
> extremely conservative?
Maybe the implementation is prepending the IV to the ciphertext?
Received on 2012-04-02 22:47:16 CEST