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?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-04-02 22:11:21 CEST