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));
Crypto hardware may be able to support various modes/key sizes and I would have thought one would want to support the algorithms allowed in TLS from the tor spec (MUST support SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD TLS_DHE_RSA_WITH_AES_128_CBC_SHA).
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.
To rephrase the opening question, it appears, by my limited review, that there is support for only a subset of the algorithms that Tor uses; what are the implications of increasing this support?
Thanks,
Josh
[1] https://lists.torproject.org/pipermail/tor-commits/2012-July/044878.html
p.s. My motivation for this question is that I'm trying to optimize the performance of the TI AM335X for use on the BeagleBone Black. While it can't compete with high end servers, it appears to hold its own behind a home network. Unfortunately, the processor doesn't support any asymmetric algorithms, which would help in circuit creation, but it does support various flavors of AES as well as SHA1.
On Mon, Oct 28, 2013 at 11:46 AM, Joshua Datko jbdatko@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,
Ah yes, thanks. I will cross-reference the tor spec with openssl and submit a patch for consideration.
On Mon, Oct 28, 2013 at 9:57 AM, Nick Mathewson nickm@alum.mit.edu wrote:
On Mon, Oct 28, 2013 at 11:46 AM, Joshua Datko jbdatko@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Joshua Datko -
Nick Mathewson