[cryptography] Explaining crypto to engineers

Ondrej Mikle ondrej.mikle at nic.cz
Sun Feb 26 12:00:29 EST 2012

On 02/26/2012 04:47 AM, Kevin W. Wall wrote:
> On Sat, Feb 25, 2012 at 2:22 PM, Ondrej Mikle <ondrej.mikle at nic.cz> wrote:
>> Estimating RSA key size: it's more an educated guess/magic given how the sizes
>> are derived than anything else. And if you base your estimate for given time
>> window on Lenstra or ECRYPT II keysize recommendations you might get reprimanded
>> for suggesting too conservative values :-)
> When someone asks, I first generally point them to http://www.keylength.com/
> and once they've read that, I tell them we can talk. At least that way,
> they aren't arguing with me. :)

That ECRYPT II 2011 report on keysizes and algorithms
(http://www.ecrypt.eu.org/documents/D.SPA.17.pdf) is one of the sources for the
values listed on http://www.keylength.com/.

However, keylength.com is not that useful when determining lower bound on
keysize when the key is expected to last 90 days (usual ZSK rollover period, but
I have a TODO to check how often does it really happen; you know, lazy admins,
understaffed teams and such :-) ). Thus reading the original source reports and
papers they reference is necessary.

While Jakob's suggestion to use ECDSA is probably the best one in the DNSSEC ZSK
case, following were my arguments for raising 1024-bit RSA ZSK lower bound to
1280-bit (just a "rounded" version of 1248-bit) in upcoming year or two:

- with the upcoming TLSA record in DNS, if an attacker can crack 1024-bit RSA
ZSK signing that TLSA record, he can forge TLSA record and does not have to
attack stronger long-lived key in X.509 TLS certificate of the server in order
to MitM TLS stream
- it's obvious that state-level attacker has to be expected (cf. Iran and their
CA-breaching shenenigans)
- RFC 4359 (written in 2006) gives 1024-bit RSA key 1 year lifetime
- RFC 3766 (written in 2004) gives 80-bit symmetric key 1 year lifetime
(equivalent of ~1200-1248-bit RSA)
- the ECRYPT report pdf page 37 cites worst case scenario that 1024-bit RSA
could have been already factored by now (just not publicly) and references RFC
3766 on pdf page 38
- chapter 7 in ECRYPT report gives _at most_ few months for 1024-bit RSA key
(~73-bit symmetric) against state-level attacker (more precisely: at most few
months for equivalent of 84-bit symmetric key against intelligence agency with
$300M budget)

It would still be grateful if somebody could explain to me what is wrong with
the above argumentation (except being conservative). Paul Hoffman referred back
to RFC 3766 and even though Paul has tons of experience, in my understanding the
ECRYPT II 2011 report "supersedes" RFC 3766, doesn't it?

(Paul's argumentation can be found in the link I posted before:

>> There was even better article from Matasano that showed the Vaudenay's attack
>> nicely step-by-step, included commentary about IV selection (can't find it
>> right now).
> If you do find it, please let me know. Usually I just point developers at
> the YouTube video by Duong and Rizzo using POET to crack ASP.NET's
> encryption and that convinces most of them.

I googled hard, still no luck. It's possible that it wasn't written by Matasano.
Every step was accompanied by a table showing the bytes sent, received,
important bytes highlighted and explaining the error side-channel. But I'll keep

>> Few days ago I've shown the Syllable /dev/random code
>> (http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/sys/kernel/drivers/misc/random/random.c?revision=1.4&view=markup)
>> to about 10-15 SW/HW guys and asked them to find the mistake in random_read.
>> One guy got it right (a crypto enthusiast), one was totally lost, third was
>> arguing that it was ok, because kernel rand() uses Mersenne Twister instead of
>> the age-old LCG rand(), but didn't catch that the seed has really low entropy
>> (seconds since last boot). Rest of them probably didn't care or it wasn't
>> interesting enough.
> I thought most *nix kernels with /dev/random save some entropy when they
> shutdown and reinitialize from that upon booting. Not so?

OK, but what happens if the device is booted for the first time? And that's
exactly when the predictable primes were generated by those embedded devices.

> But if I could put to something that was about 5-8 pages about something
> like "Ten Things Every Developer Should Know About Cryptography", that
> would be great for starters. Does such a thing exist? Maybe it can't
> distilled to only 10, but you get my point.

That's what I was aiming for :-)


More information about the cryptography mailing list