This Blog Is Not For Reading

A blog, just like any blog, only more so

  • Subscribe

  • Categories

  • RSS Bob Jonkman’s Microblog

    • New note by bobjonkman 4 January 2022
      According The Register's forum, this is the patch: "The current fix: Represent 2022-01-02 as 2021-12-33."https://forums.theregister.com/forum/all/2022/01/03/exchange_servery2k22_flaw/#c_4389861
    • Favorite 4 January 2022
      bobjonkman favorited something by lxo: what's most incredible about this date representation is that it was introduced after Y2K. it wouldn't have worked up to [19]99 think about it. someone implemented that after all the many years of preparation and patching decades-old systems for Y2K, knowing (or, worse, without realizing) that it had at most […]
    • bobjonkman repeated a notice by lxo 4 January 2022
      RT @lxo what's most incredible about this date representation is that it was introduced after Y2K. it wouldn't have worked up to [19]99 think about it. someone implemented that after all the many years of preparation and patching decades-old systems for Y2K, knowing (or, worse, without realizing) that it had at most a couple of […]
    • New note by bobjonkman 3 January 2022
      From what I can tell, they were using the decimal digits of the 32-bit number as a sort of BCD, with the base10 digits representing portions of the date. The example used is "the new date value of 2,201,010,001 is over the max value of 'long' int32 being 2,147,483,647". So, YY MMDDHHMM ? What an […]
    • New note by bobjonkman 17 December 2021
      Some days I'm glad my instance of #GNUsocial doesn't support #ActivityPub and isolates me from the idiocy on Mastodon of which I already get plenty from #Birdsite.
    • New note by bobjonkman 8 December 2021
      And, of course, Wikipedia knows everything: https://en.wikipedia.org/wiki/Foundation_series#Adaptations #Foundation
    • New note by bobjonkman 8 December 2021
      Happily, it's been about 50 years since I read the first three novels, and about 20 years since I started on the sequels (which never did finish, got about halfway through the third sequel book). So my foggy memories of the storyline in the original trilogy shouldn't detract from the TV series. I recall there […]
    • Favorite 8 December 2021
      bobjonkman favorited something by clacke: @Bob Jonkman It is highly character-driven.It uses key characters, the Empire, the exile, Terminus, Psychohistory, two kingdoms instead of the Four Kingdoms and some echoes of half of the first book and fainter echoes from other parts of the series, while the main story maps roughly to half the first […]
    • bobjonkman repeated a notice by clacke 8 December 2021
      RT @clacke @Bob Jonkman It is highly character-driven. It uses key characters, the Empire, the exile, Terminus, Psychohistory, two kingdoms instead of the Four Kingdoms and some echoes of half of the first book and fainter echoes from other parts of the series, while the main story maps roughly to half the first book. It […]
    • New note by bobjonkman 7 December 2021
      Don't get me wrong, I think Foundation is one of the greatest SF stories ever written. And I hadn't heard there was a series, must find out when and where it airs... !SciFi @clacke

The cost of long GnuPG/PGP keys

Posted by Bob Jonkman on 25th March 2014

Never Eat That Green Food At The Back Of The Fridge

Never Trust Anyone Over Thirty

and

Never Sign A GnuPG/PGP Key That’s Older Than You Are

Face peeking into fridge

Looking for green food at the back of the fridge

OK, only one of those is true, and it’s not the last one. At the University of Waterloo Keysigning Party last fall, some of the people signing my key were younger than the key they were signing!

At the keysigning I was having a discussion with someone about key lengths. In particular, choosing 4096 bits instead of 2048. I was reading that GnuPG has a limit of 4096 bits, but that 4096 should be enough for all time to come.

I’ve read online that GnuPG does actually support larger key sizes but that there is a const in the source code limiting it to 4096. The reasons for doing so are supposedly speed, 4096 would be very slow to generate and use, and comparability with other implementations that may not support larger keys. Personally I think it’s an inevitability that this will be increased in time but we’re not there yet.

In 1996 when I started with PGP a 1024 bit key was considered adequate, by 1999 a 2048 bit key was still considered large.

Consider Moore’s Law: every 18 months computing capacity doubles and costs halve. I’m not sure if that means that over 18 months x flops increases to 2x flops at the same price, or that in 18 months the cost of x flops is half of today’s cost, or if it means that in 18 months the cost of 2x flops will be half the cost of x flops today. If the latter, then today’s x flops/$ is x/4 flops/$ in 18 months. That factor of four is an increase of two bits every 18 months, or four bits every 3 years.

So, the cost in 1996 to brute-force crack a 1024 bit key is the same as the cost in 1999 to crack a 1028 bit key. And in 2014, 18 years later, it’s the same cost as cracking a 1048 bit key (an additional 24 bits).

An increase in key size from 1024 bits to 2048 bits buys an additional 768 years of Moore’s Law. And going from 2048 bits to 4096 bits buys an additional 1536 years of Moore’s Law.

Is Moore’s Law overestimating the cost of cracking keys? Are there fundamental advances in math that have dropped the cost of cracking 1024 bit keys to near-zero? What’s the economic justification for crippling keysizes in GnuPG, anyway?

–Bob, who is not trolling but really wants to know.

Day 57 / 365 – refrigerator by Jason Rogers is used under a CC BYCC BY license.

This post is based on a message to the KWCrypto Mailing List.

Tags: , , , , , , , , ,
Posted in Crypto, PGP/GPG | 1 Comment »

 
Better Tag Cloud