Re: [Freedombox-discuss] Hardware Crypto

[Sandy Harris]

Showing only the key parts of the message:

> From: John Gilmore 

An exceedingly knowledgeable guy, one we should probably take seriously.
https://en.wikipedia.org/wiki/John_Gilmore_(activist)

> Most hardware crypto accelerators are useless, ...
> ... you might as well have
> just computed the answer in userspace using ordinary instructions.

A strong claim, but one I'm inclined to believe. In the cases where it
applies, it may be a problem for much of the Linux crypto work.

Some CPUs have special instructions to speed up some crypto
operations, and not just AES. For example, Intel has them for several
hashes and for elliptic curve calculations:
https://software.intel.com/en-us/articles/intel-sha-extensions
https://en.wikipedia.org/wiki/CLMUL_instruction_set
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/polynomial-multiplication-instructions-paper.pdf

These move the goalposts; if doing it "using ordinary instructions" is
sometimes faster than hardware, then doing it with
application-specific instructions is even more likely to be faster.

> Even if a /dev/crypto interface existed and was faster for some kinds
> of operations than just doing the crypto manually, the standard crypto
> libraries would have to be portably tuned to detect when to use
> hardware and when to use software.  The libraries generally use
> hardware if it's available, since they were written with the
> assumption that nobody would bother with hardware crypto if it was
> slower than software.
>
> "Just make it fast for all cases" is hard when the hardware is poorly
> designed.  When the hardware is well designed, it *is* faster for all
> cases.  But that's uncommon.
>
> Making this determination in realtime would be a substantial
> enhancement to each crypto library.  Since it'd have to be written
> portably (or the maintainers of the portable crypto libraries won't
> take it back), it couldn't assume any particular timings of any
> particular driver, either in hardware or software.  So it would have
> to run some fraction of the calls (perhaps 1%) in more than one
> driver, and time each one, and then make decisions on which driver to
> use by default for the other 99% of the calls.  The resulting times
> differ dramatically, based on many factors, ...
>
> One advantage of running some of the calls using both hardware and
> software is that the library can check that the results match exactly,
> and abort with a clear message.  That would likely have caught some bugs
> that snuck through in earlier crypto libraries.

I'm not at all sure I'd want run-time testing of this since, at least
as a general rule, introducing complications to crypto code is rarely
a good idea. Such tests at development time seem like a fine idea,
though; do we have those already?

What about testing when it is time to decide on kernel configuration;
include a particular module or not? Another issue is whether the
module choice is all-or-nothing; if there is a hardware RNG can one
use that without loading the rest of the code for the crypto
accelerator?

[PATCH] crypto: sahara: constify platform_device_id

[Arvind Yadav]

platform_device_id are not supposed to change at runtime. All functions
working with platform_device_id provided by 
work with const platform_device_id. So mark the non-const structs as
const.

Signed-off-by: Arvind Yadav 
---
 drivers/crypto/sahara.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 1d9ecd3..39efa65 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -1376,7 +1376,7 @@ static void sahara_unregister_algs(struct sahara_dev *dev)
crypto_unregister_ahash(_v4_algs[i]);
 }
 
-static struct platform_device_id sahara_platform_ids[] = {
+static const struct platform_device_id sahara_platform_ids[] = {
{ .name = "sahara-imx27" },
{ /* sentinel */ }
 };
-- 
2.7.4

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Gilad Ben-Yossef]

On Fri, Aug 11, 2017 at 7:05 PM, Marcel Holtmann  wrote:
> Hi Stephan,
>
>>> AF_ALG is best suited for crypto use cases where a socket is set up once
>>> and there are lots of reads and writes to justify the setup cost. With
>>> asymmetric crypto, the setup cost is high when you might only use the
>>> socket for a brief time to do one verify or encrypt operation.
>>
>> To me, the entire AF_ALG purpose is solely to export hardware support to user
>> space. That said, if user space wants an accelerator, a socket would be 
>> opened
>> once followed by numerous read/write requests.
>>
>> Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring
>> and I planned to port it to the current implementation. But I thought I offer
>> a small patch focusing on the externalization of the akcipher API first.
>>
>> I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to
>> each other. The statement I made for the KPP AF_ALG RFC applies here too:
>>
>> """
>> I am aware and in fact supported development of the DH support in the keys
>> subsystem. The question will be raised whether the AF_ALG KPP interface is
>> superfluous in light of the keys DH support. My answer is that AF_ALG KPP is
>> orthogonal to the keys DH support. The keys DH support use case is that
>> the keys are managed inside the kernel and thus has the focus on the
>> key management. Contrary, AF_ALG KPP does not really focus on key management
>> but simply externalizes the DH/ECDH support found in the kernel including
>> hardware acceleration. User space is in full control of the key life cycle.
>> This way, AF_ALG could be used to complement user-space network protocol
>> implementations like TLS or IKE to offload the resource intense DH
>> calculations to accelerators.
>> “""
>
> we do not need two interfaces for doing the same thing. Especially not one 
> that can not handle hardware backed keys. And more important if you can not 
> abstract an accelerator that doesn’t expose the private key at all.

While I don't have anything to contribute to the choice between
keyctl() vs ALG_IF as interfaces for asymmetric  cryptography, I would
like to point out that there is both interest and HW support for
private symmetric key operations as well, for example for storage
encryption via DM-Crypt and fscrypt, so I do hope (and will work on)
adding some sort of HW key support the crypto API, community
acceptance withstanding of course.

So I hope we won't treat the idea of crypto API lack of support for HW
keys as a long standing immutable argument.

Thanks,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru