linux-kernel - RE: [PATCH 0/6] Add Hygon SEV support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 Apr 2019 09:08:49 +0000
From:   Pascal Van Leeuwen <pvanleeuwen@...idesecure.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, Hao Feng <fenghao@...on.cn>,
        'Tom Lendacky ' <thomas.lendacky@....com>,
        'Gary Hook ' <gary.hook@....com>,
        'Herbert Xu ' <herbert@...dor.apana.org.au>,
        "' David S. Miller '" <davem@...emloft.net>,
        'Janakarajan Natarajan ' <Janakarajan.Natarajan@....com>,
        'Joerg Roedel ' <joro@...tes.org>,
        ' Radim Krčmář ' <rkrcmar@...hat.com>,
        'Thomas Gleixner ' <tglx@...utronix.de>,
        'Ingo Molnar ' <mingo@...hat.com>,
        'Borislav Petkov ' <bp@...en8.de>,
        "' H. Peter Anvin '" <hpa@...or.com>
CC:     'Zhaohui Du ' <duzhaohui@...on.cn>,
        'Zhiwei Ying ' <yingzhiwei@...on.cn>,
        'Wen Pu ' <puwen@...on.cn>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/6] Add Hygon SEV support

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