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

[Joshua Datko]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131028/aa28b8a7/attachment.html>