[hipl-dev] Re: [Bug 680836] [NEW] ECC in HIPL
- From: Tobias Heer <heer@xxxxxxxxxxxxxxxxx>
- To: hipl-dev@xxxxxxxxxxxxx
- Date: Wed, 24 Nov 2010 11:19:19 +0100
Hi,
Am 24.11.2010 um 11:03 schrieb Samu Varjonen:
> On 24/11/10 11:33, Tobias Heer wrote:
>> Public bug reported:
>>
>> It would be fairly simple to implement ECC support in HIPL and some
>> preliminary comparisons using the openssl suite indicate that ECDSA has
>> a significant (4x) performance improvement over DSA (signatures).
>>
>> Verifications seem to be the same, though.
>>
>> As a first step, we could implement ECDSA and ECDH in HIPv1 style. Just
>> add another HIT type and expect that the other side implements the
>> necessary curves.
>
> Add another HIT type? Just curious about this, do you mean a new ORCHID
> prefix or a new Contex ID in the creation of the HIT.
Doing it HIPv1 style would mean: same ORCHID but different HOST_IDENTITY
parameters. The HIPv1 style implicity assumes that the receiver will support
the HOST_IDENTITY signature algorithm. If not, the connection fails. We have
the same situation with RSA and DSA already.
>
>>
>
> I was thinking this and wound up in situation where I did not find a solution
> and then I ran out of time. In HIP DSA is stored (in HOST_ID and in DNS)
> according to RFC 2536 and RSA is strored according to RFC 3110. For ECDSA I
> have not found any other document than this
> http://tools.ietf.org/html/draft-ietf-dnsext-ecc-key-10 expired draft. But
> the point that I am coming to is that we need (probably) a new specification
> that defines how elliptic curve keys are stored at least in HOST_ID if not in
> DNS. I have not checked this recently so the situation might have changed
> after that. Just thought that you might want to know.
The specs for the HOST_ID should be in RFC5201-bis. It's basically a new suite
ID and a wire-representation of the public key that is needed, right?
Tobias
>> The curves implemented in openssl are certainly low-hanging fruits for
>> doing this. All one needs to do is add anther cipher suite, and provide
>> the right parameter lengths and openssl parameters.
>>
>> In HIPv2 we will have ECDSA support anyway but that requires some
>> changes to the handshake as well.
>>
>> Some numbers coming from openssl speed
>>
>> openssl speed ecdsap160
>> Doing 160 bit sign ecdsa's for 10s: 42411 160 bit ECDSA signs in 9.96s
>> Doing 160 bit verify ecdsa's for 10s: 9610 160 bit ECDSA verify in 9.94s
>>
>> openssl speed ecdsap160
>> Doing 160 bit sign ecdsa's for 10s: 42546 160 bit ECDSA signs in 9.99s
>> Doing 160 bit verify ecdsa's for 10s: 9813 160 bit ECDSA verify in 9.98s
>>
>>
>> openssl speed ecdsab163
>> Doing 163 bit sign ecdsa's for 10s: 12296 163 bit ECDSA signs in 9.98s
>> Doing 163 bit verify ecdsa's for 10s: 4476 163 bit ECDSA verify in 9.99s
>>
>> openssl speed ecdsap256
>> Doing 256 bit sign ecdsa's for 10s: 25054 256 bit ECDSA signs in 9.91s
>> Doing 256 bit verify ecdsa's for 10s: 5400 256 bit ECDSA verify in 9.98s
>>
>> openssl speed dsa1024
>> Doing 1024 bit sign dsa's for 10s: 10264 1024 bit DSA signs in 9.99s
>> Doing 1024 bit verify dsa's for 10s: 8528 1024 bit DSA verify in 9.94s
>>
>> openssl speed dsa2048
>> Doing 2048 bit sign dsa's for 10s: 3139 2048 bit DSA signs in 9.86s
>> Doing 2048 bit verify dsa's for 10s: 2618 2048 bit DSA verify in 9.83s
>> These numbers were generated on a 2.1 GHz Intel Core 2 Duo.
>>
>> ** Affects: hipl
>> Importance: Undecided
>> Status: New
>>
>>
>> ** Tags: ecc improvement
>>
>
>
--
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
Other related posts:
