On 02/26/2012 04:47 AM, Kevin W. Wall wrote: > On Sat, Feb 25, 2012 at 2:22 PM, Ondrej Mikle <ondrej.mi...@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: http://lists.opendnssec.org/pipermail/opendnssec-user/2012-January/001619.html) >> 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 looking. >> 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 :-) Ondrej _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
