On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:
>
> Using the kernel crypto API one can relieve the CPU of the crypto work, if a
> hardware or assembler implementation is available. This may be of particular
> interest for smaller systems. So, for smaller systems (where kernel bloat is
> bad, but where now these days more and more hardware crypto support is
> added),
> we must weigh the kernel bloat (of 3 or 4 additional C files for the basic
> kernel crypto API logic) against relieving the CPU of work.
There are a number of caveats with using hardware acceleration; one is
that many hardware accelerators are optimized for bulk data
encryption, and so key scheduling, or switching between key schedules,
can have a higher overhead that a pure software implementation.
There have also been situations where the hardware crypto engine is
actually slower than a highly optimized software implementation. This
has been the case for certain ARM SOC's, for example.
This is not that big of deal, if you are developing a cryptographic
application (such as file system level encryption, for example) for a
specific hardware platform (such as a specific Nexus device). But if
you are trying to develop a generic service that has to work on a wide
variety of CPU architectures, and specific CPU/SOC implementations,
life is a lot more complicated. I've worked on both problems, let me
assure you the second is way tricker than the first.
> Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR
> implementation to suit their needs. The DRBG code is agnostic of the
> underlying cipher. So, you could even use Blowfish instead of AES or
> whirlpool
> instead of SHA -- these changes are just one entry in drbg_cores[] away
> without any code change.
I really question how much this matters in practice. Unless you are a
US Government Agency, where you might be laboring under a Federal
mandate to use DUAL-EC DRBG (for example), most users really don't
care about the details of the algorithm used in their random number
generator. Giving users choice (or lots of knobs) isn't necessarily
always a feature, as the many TLS downgrade attacks have demonstrated.
This is why from my perspectve it's more important to implement an
interface which is always there, and which by default is secure, to
minimize the chances that random JV-team kernel developers working for
a Linux distribution or some consumer electronics manufacturer won't
actually make things worse. As the Debian's attempt to "improve" the
security of OpenSSL demonstrates, it doesn't always end well. :-)
If we implement something which happens to result in a 2 minute stall
in boot times, the danger is that a clueless engineer at Sony, or LGE,
or Motorola, or BMW, or Toyota, etc, will "fix" the problem without
telling anyone about what they did, and we might not notice right away
that the fix was in fact catastrophically bad.
These aren't the standard things which academics tend to worry about,
which tend to assume that attackers will be able to read arbitrary
kernel memory, and recovering such an exposure of the entropy pool is
_the_ most important thing to worry about (as opposed to say, the
contents of the user's private keys in the ssh-agent process). But
this will perhaps explain why worrying about accomodating users who
care about whether Blowfish or AES should be used in their random
number generator isn't near the top of my personal priority list.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
