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? -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
