Re: [Sks-devel] peer request for pgp.uplinklabs.net

[Christoph Egger]

Gunnar Wolf <address@hidden> writes:
> Andrew Gallagher dijo [Wed, Aug 31, 2016 at 10:14:01AM +0100]:
>> I'm sceptical of the utility of ECC keys personally. They were first
>> proposed as a way of reducing work and storage space (because the
>> space of usable ECC keys is more compact than the sparsely
>> distributed RSA primes). But they've taken so long to catch on that
>> technology advancement has made their original justification largely
>> irrelevant (the only exception to my knowledge being DNSSEC, where
>> signature length restrictions are still important). And because the
>> ECC keyspace is more efficiently packed, it is theoretically *more*
>> susceptible to quantum attacks.
>
> I'm far from a worthy crypto geek myself, but still — Storage space is
> not the decisive issue; storing a million 4096-bit keys is only an
> order of magnitude more than storing a million 256-bit keys (the same
> proportion would naturally apply for a single key), and information
> appended to the keys themselves (such as photo attributes and the
> signatures that constitute the web of trust) make the difference quite
> unnoticeable.

It also affects the size of each signature, certificate

| :signature packet: algo 22, keyid 1BB721A4B254D8E1
|       version 4, created 1472657540, md5len 0, sigclass 0x00
|       digest algo 8, begin of digest fd 82
|       hashed subpkt 2 len 4 (sig created 2016-08-31)
|       subpkt 16 len 8 (issuer key ID 1BB721A4B254D8E1)
|       data: [256 bits]
|       data: [256 bits]

vs

| :signature packet: algo 1, keyid ABFFEDB24008C6F9
|       version 4, created 1472657570, md5len 0, sigclass 0x00
|       digest algo 8, begin of digest c8 06
|       hashed subpkt 2 len 4 (sig created 2016-08-31)
|       subpkt 16 len 8 (issuer key ID ABFFEDB24008C6F9)
|       data: [4095 bits]

Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

signature.asc
Description: PGP signature