on Tue, Sep 09, 2003 at 03:51:07PM +1000, Daniel Carosone wrote:
> Note that there is presently an "issue" in current with cgd and
> blowfish (only). The bugfix for this is known, but has not yet been
> committed, pending some testing and a decision about whether anyone
> else is using this combo. I think I may be the only one.
> 
> It requires a flag day in the kernel to change, and while it's
> possible to provide some back-compatibility (which Roland has
> written), it involves adding hair to cgdconfig(8) that is certainly
> unnecessary if it's just for me :)

I do not know if this is related, but I came across a small mistake
in the pbkdf2 implementation of cgdconfig(8).  For step 3, RFC 2898
says the blocks are:

	T_1 = F (P, S, c, 1) ,
	T_2 = F (P, S, c, 2) ,
	...
	T_l = F (P, S, c, l) ,

But the index in cgdconfig starts at 0, yeilding:

	T_1 = F (P, S, c, 0) ,
	T_2 = F (P, S, c, 1) ,
	...
	T_l = F (P, S, c, l-1) ,

[src/sbin/cgdconfig/pkcs5_pbkdf2.c::pkcs5_pbkdf2()]

This results in the implementation failing against several test
vectors.  By adjusting the prf_iterate call to i+1, the implementation
works fine with the test vectors I have.

Migration for existing configs seems simple since we just add an
extra stored key to old configs of pbkdf2_orig xor pbkdf2.

I guess this is something else?