Thus spake Richard Levitte - VMS Whacker:
>
> Note that this puts a requirement on the algorithm functions to follow
> a certain name standard. The expected frunctions are, for a certain
> {prefix} (AES in the AES case, I assume :-)):
>
> {prefix}_ecb_encrypt
> {prefix}_cbc_encrypt
> {prefix}_ofb64_encrypt
> {prefix}_cfb64_encryptI called the AES versions ofb128 and cfb128 due to the block size. I expect this can be handled somehow by #defines. I could create 64-bit feedback variants, but I don't think this is what people expect by default. All the arguments etc. are like the other cfb/ofb functions. > I don't think CTR is considered at all in the EVP layer. In other > words, you may implement it, but it will only be available as a direct > algorithm function, not as part of the EVP layer. I suppose that's fine for now. It appears that CTR is going to be in the NIST FIPS for AES modes, so it'd be nice to get it into EVP someday. > In any case, I can most certainly help you out, as I've already > fiddled with the first patches you sent. I was figuring you would :) S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein
aes.modes.diff.bz2
Description: Binary data
