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, <cmpil...@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?
