> >
> > Uhm ... no, the fact that something is actually *useful* to
> potentially
> > a billion plus people doesn't mean anything ...
>
> Useful does not mean secure, does it? PKZIP encryption was certainly
> useful back in the day, but it was not secure.
>
"Secure" is a relative term anyway. There's always a trade-off between
performance, cost, power consumption and security. Different use cases
require different levels of security. IMHO that decision should be up
to the application / user / market, and not up to some software
engineers that are not experts on the subject matter anyway (but I am
hopeful that some people here are, in fact, experts to some extent).
> "Freedom" didn't apply when Speck was proposed for inclusion in Linux,
> and I would like to make sure I don't make a mistake when adding crypto
> interfaces. If SM2/3/4 were broken, I couldn't care less if someone
> HAS to use them, they can patch their kernel.
>
Is Speck actually used in any real-life protocol or application?
I did not follow the Speck discussion but I have a hunch that was a far
more important reason not to include it than it being a weak cipher or
it's shady NSA origins ...
And yes, they can always fork the kernel and do their own stuff with it,
but that's going to be a support nightmare for people - like us - wanting
to add HW acceleration on top of that. And yes, "we" can do SM3 & SM4.
Full disclosure: it is in my/our interest to keep SM3 & SM4 in the tree.
> But if they're not then I appreciate that you wrote to correct me,
> it's helpful. Please
> understand that 99% of the community has not ever heard of anything but
> SHA-{1,2,3}, ECDSA, Ed25519, AES. If somebody comes up with a patch
> with "strange" crypto, it's up to them to say that they are secure---
> and again, the key word is secure, not useful.
>
I recognise the fact that most people are not experts on the subject
matter. However, there's a lot you can find out in a short Google session
before you start a discussion on incorrect assumptions ...
Anyway, always happy to educate people a bit.
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
