On 01 Dec 2014, at 12:03 PM, Yann Ylavic <[email protected]> wrote:

> - The input filter seems to read and return blocksize bytes at once,
> couldn't it read up to readbytes - reabytes % blocksize, or even
> readbytes with retained buckets?
> It seems that buffering (at most blocksize[ - 1]) would benefit the
> output filter too (FLUSH).

We buffer up to CryptoSize bytes (default: 128k) on both the input and output 
filters, there is quite a song and dance to get this right.

> - The IV length seems to be forcibly corresponding to the cipher's
> blocksize, this is not applicable to all ciphers though.

This is true - the apr_crypto patch has been updated to provide the ivsize 
separately.

> - The following is used several times in exec_pass_conf_binary() and
> looks buggy :
> 
> +                if (len < size) {
> +                    b = apr_palloc(r->pool, size);
> +                    memset(b, 0, size - len);
> +                    [fn](b + size - len, arg, strlen(arg));
> +                }
> +                else {
> +                    b = apr_palloc(r->pool, len);
> +                    [fn](b, arg, strlen(arg), 1,
> +                            NULL);
> +                    b += size - len;
> 
> size - len is <= 0 here, maybe len - size?

Yep, that is definitely wrong.

> Also, maybe allocate size bytes only since the first len - size are ignored.

The various functions used for decoding don’t support arbitrary offsets, we 
have to decode the whole key/iv, and then take the least significant bits. This 
is easiest done with a simple move of the start of the key in this case.

> Finally, when len != size, why not use a key-type passphrase? (that
> would probably better be configurable though).

Passphrases are a whole other kettle of fish. You need to supply salts, and the 
number of iterations for the various algorithms.

I reverse engineered openssl’s passphrase support for symmetrical crypto, and 
there are a number of hard coded behaviours like a fixed length salt, a 
specific start constant, etc. Gnupg was different too. Keen to come up with 
something general enough that any tool could be used on the other side.

I plan to support passphrases, but wanted at the very least for the module to 
receive some wider public exposure before that happens. HLS is working really 
nicely, it would be ideal to have a solution out there in the mean time for 
this only.

Regards,
Graham
—

Reply via email to