> > > > 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