[tor-dev] Why the limited HW engine algos in crypto.c?

[Nick Mathewson]

On Mon, Oct 28, 2013 at 11:46 AM, Joshua Datko <jbdatko at gmail.com> wrote:
> Why is there a limited set of OpenSSL engine algorithms chosen in crypto.c
> (code below)?
>
> log_engine("RSA", ENGINE_get_default_RSA());
> log_engine("DH", ENGINE_get_default_DH());
> log_engine("RAND", ENGINE_get_default_RAND());
> log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1));
> log_engine("3DES", ENGINE_get_cipher_engine(NID_des_ede3_ecb));
> log_engine("AES", ENGINE_get_cipher_engine(NID_aes_128_ecb));


I think you're misunderstanding that code.  That function is called
"log_engine", not "load_engine."  The actual loading and registering
of engines happens earlier in the crypto_global_init() function.  All
that the log_engine function does is to log a short message about
which engine was chosen.

That said, it would sure be nice to have a more up-to-date list of
engines logged. I'd be happy to take a patch for that.

 [...]
> Also, I was a bit surprised to see ECB mode.  Is it true that ECB, when used
> as a stream generator, is equal to CTR mode?  ECB mode is not mentioned in
> the spec and after some digging, I found a reference to it [1] for
> encrypting at most one block length of data in the header.

Yup.  It's used to implement counter mode.  "ECB" in this case is an
alias for "Just the raw AES block function."   Nobody should ever use
ECB except as a building block for something that isn't ECB.


best wishes,
-- 
Nick