Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03

[Peter Goldstein <[e-mail]>]

>
> Moreover, QC isn't the only possible event that could cause us to wish to
> have larger keys. There might be a modest improvement in dlog that would
> make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, this
> is how we got to the point where we wish to have RSA keys > 1024).


>
Support for larger keys isn't the issue at hand.  The issue is the 255
character limit imposed by the DNS crudware.  And I think keys for each of
those curves easily fit under the limit.

Based on my math (with 24 additional bytes allocated for version tag/value
and any other key/value pairs), then we've got (assuming my key sizes are
correct):

Curve448 - 114 bytes (key) + 24 bytes = 138 bytes maximum
P-521 - 212 bytes (key) + 24 bytes = 236 bytes maximum

I don't do much low level crypto these days, so if I'm off on my base 64
public key sizes, please let me know.  But in both cases it looks like
there's room to spare.

As for QC, I think John's point earlier in the thread isn't that QC will
require larger keys - but rather than real QC would require fundamental
reconsideration of DKIM as a whole.

Best,

Peter

-- 


[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[e-mail]
+1.415.793.5783