subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@elego.de>
Subject Re: svn commit: r1308470 - in /subversion/trunk/subversion: libsvn_subr/crypto.c tests/libsvn_subr/crypto-test.c
Date Mon, 02 Apr 2012 20:46:29 GMT
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@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?

Mime
View raw message