Looking at the code, the encoded data block does not have a version number field in it, so the data format and general algorithm cannot be easily changed in the future.
The encoded data seems to be comprised of: base64 encode of: - salt (fixed length of sizeof(apr_uuid_t)) - the Initialization Vector - the encrypted data But to understand the algorithm, one would have to document what all the apr_crypto_* functions do in the module's encrypt/decrypt functions. For example, the apr_crypto_passphrase takes the passphrase and the salt as parameters (along with other parameters such as block chaining mode [which mod_session_crypto has set fixed to CBC], number of iterations [which mod_session_crypto has set fixed to 4096 iterations]). But what is done with it when it's passed to APR library? One would have to look at the implementation of that function in order to find out. Taking a quick look at the apr source, for the openssl implementation, apr_crypto_passphrase is using PKCS5_PBKDF2_HMAC_SHA1 to generate the key from the passphrase and salt. So, it doesn't look like it's an quick and easy thing to document or re-implement. On Tue, Jul 9, 2013 at 9:01 AM, André Malo <[email protected]> wrote: > On Tuesday 09 July 2013 14:51:49 Mikhail T. wrote: > > 09.07.2013 08:31, Eric Covener написав(ла): > > > I am not surprised that separately documenting is not a priority for > > > anyone, given it's implemented in httpd for anyone to see. > > > > Source code is not documentation, is it? In matters of encryption > > especially the methods chosen should be documented better -- not only > > for interoperability, but also to allow to better judge the strengths of > > the method (not that I personally am capable of the latter). > > I agree. And everybody is welcome to help fixing that issue. > > nd >
