From: Tudor Ambarus <tudor.ambarus-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
To: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: "bluez mailin list
(linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)"
<linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Linux Crypto Mailing List
<linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: in-kernel user of ecdsa
Date: Mon, 26 Mar 2018 17:59:09 +0300 [thread overview]
Message-ID: <4ce3391f-aa02-a157-bce1-754a6a87c8ed@microchip.com> (raw)
In-Reply-To: <0f698592-8ade-14d4-7891-1c35501c6285-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On 03/12/2018 07:07 PM, Tudor Ambarus wrote:
> Would you consider using ECDSA in the kernel module signing facility?
Any feedback is good. I can invest some time to make this happen, if
needed.
> When compared with RSA, ECDSA has shorter keys, the key generation
> process is faster, the sign operation is faster, but the verify
> operation is slower than with RSA.
>
> Smaller key sizes imply reduced memory footprint and bandwidth that are
> especially attractive for memory constrained devices. I'm working with
> such a device, capable of generating ecc keys, secure key storage and
> ecdsa/ecdh crypto acceleration. I'm trying to find an in-kernel user of
> ecdsa.
>
>
> ECDSA and RSA comparison
> ------------------------
> -> ECDSA requires a much smaller key length in order to provide the same
> security strength as RSA [1]:
>
> Security Strength RSA (bits) ECDSA (bits)
> 112 2048 224 - 255
> 128 3072 256 - 383
> 192 7680 384 - 511
> 256 15360 512+
>
> 7680 and 15360 keys are not included in the NIST standards for
> interoperability and efficiency reasons, the keys are just too big.
>
> -> key generation: ECC key generation is faster than IFC (Integer -
> Factorization Cryptography). RSA private key is based on large prime
> numbers, while for ECDSA any positive integer less than n is a valid
> private key.
>
> -> ECDSA sign operations are faster than RSA, but verify operations are
> slower. Here's an openssl speed test that I've run on my computer:
>
> sign verify sign/s verify/s
> rsa 2048 bits 0.000604s 0.000018s 1656.3 56813.7
> rsa 4096 bits 0.004027s 0.000062s 248.3 16052.5
>
> sign verify sign/s verify/s
> 256 bit ecdsa (nistp256) 0.0000s 0.0001s 28986.4 13516.3
> 384 bit ecdsa (nistp384) 0.0002s 0.0008s 5541.0 1322.2
> 521 bit ecdsa (nistp521) 0.0003s 0.0006s 3104.2 1756.2
>
> Best,
> ta
>
> [1] NIST SP 800-57 Pt. 1 Rev. 4, Recommendation for key management
> --
> To unsubscribe from this list: send the line "unsubscribe keyrings" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
prev parent reply other threads:[~2018-03-26 14:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 17:07 in-kernel user of ecdsa Tudor Ambarus
[not found] ` <0f698592-8ade-14d4-7891-1c35501c6285-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
2018-03-12 18:09 ` James Bottomley
[not found] ` <31045526.HZb3ddfbbg@tauon.chronox.de>
[not found] ` <31045526.HZb3ddfbbg-b2PLbiJbNv8ftSvlWXw0+g@public.gmane.org>
2018-03-12 21:55 ` James Bottomley
2018-03-26 14:59 ` Tudor Ambarus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ce3391f-aa02-a157-bce1-754a6a87c8ed@microchip.com \
--to=tudor.ambarus-uwl1gki3jzl3ogb3hspcza@public.gmane.org \
--cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).